Github Collaboration

Hi.

We have been making some changes to our github account in relation to how people can contribute to core code, as well as adding some stuff to make it easier to set up a development environment for v160.

To get started, see http://docs.zen-cart.com/Contributing/main

For the development environment see the Habitat repostitory and associated help pages
For the main v160 development, we are in the process of moving our internal issues, that we previously tracked with JIRA, directly on to github.

We have also created a Contributors team on Github that consists of people who have previously contributed pull requests to the github v160 branch.

Creating this team allows us to assign tasks to people in the Contributors team.
If you want to be part of this team, you need to:

1. create a github account
2. fork the zencart/zencart repository
3. PM a founder for them to activate your github team account, and include the link to your forked repository
4. When pm'ing a founder, it would help if you could give some detail about what areas of code you could help with

PM Links
DrByte http://www.zen-cart.com/private.php?do=newpm&u=6
wilt http://www.zen-cart.com/private.php?do=newpm&u=2

Hello, I had some problems to have habitat working on a win 7 machine. Here they are and how I solved them:

1. I already have mysql installed on my win 7, with the default port 3306. But running vagrant up says that there is a conflict over the port 3306, because habitat uses the same port.

The solution is to forward the port for mysql (for the vm we're installing) to another port. I used 33306.
To make this, go to habitat.rb in your habitat folder, near line 25 you find config.vm.network "forwarded_port", guest: 3306, host: 3306 just change the second value to 33306 (or any other value not conflicting).

2. After that I was able to access mysql via ssh (hmmm using putty, not yet simply typing vagrant ssh) and was able to access zen.local via browser but it was empty. Looking at the messages after vagrant up I understood that ssh commands were not executed, so, after a bit of google, I found that even if I had a ssh client installed, it was not available in my habitat folder. So the solution was to add the path to my ssh client exe to the path.

3. After that I run again vagrant provision, but new errors came up: something like \r command not found referred to line, line 8 etc... of serve.sh So I just opened serve.sh and changed the line endings from windows to Unix.

This solved everything and after another provisioning, it started syncing with Github (now I just have to remove everything again and try to provision the machine using my keys for Github).

Hope this may help others with similar issues :)

Hi

Thanks for the post. It probably makes sense to allow for defining of some of the port forwards. We are working on some updates habitat and will build that into it.

Please see the following links for additional related information:

Getting Started with Contributing
Guidelines for reporting issues via Github
Doing a Pull Request (ie: submitting code)
Coding Standards

I find the Github->New Issues->Submit button is not available/grayed/greened-out:

torvista:

I find the Github->New Issues->Submit button is not available/grayed/greened-out:

Are you logged in?

Are you logged in?
Yes...link to my profile is active

are you sure you are on the right repository?

https://github.com/zencart/zencart/issues/new

are you sure you are on the right repository?
Yes...I tried again with your link...and have just spotted that if you don't put a title...the Submit does not work...and does not flag the error!

So, I'll put that down to bad form design, it couldn't be user error!:blush:

torvista:

Yes...I tried again with your link...and have just spotted that if you don't put a title...the Submit does not work...and does not flag the error!

So, I'll put that down to bad form design, it couldn't be user error!:blush:

Yeah, there's a similar problem if you edit the code from the github website and after all sorts of clicking this, typing that, if the result of your code is to end up back to where you started, no matter how much content you put into the description box, the button to commit the changes behaves the same way. :P Sorry for not asking further as I misunderstood the condition(s) that were plainly provided. I thought the issue was that couldn't initiate the area to fill in an issue, not that while filling in the issue information it could not be further submitted. :)

FYI the github repo has been renamed from zencart/zencart to zencart/zencart

Existing checkouts/forks and issues/PRs will continue to work, because github has an internal redirect/alias in place.

Regarding working with the local clone fileset, I still feel in the dark about the process and would appreciate some clarification.

As far as I can see, after creating a local clone, I have to copy this again to make a fileset that can be installed/executed/modified/tested using my local server (since the admin name must be different). There is no way to use this clone directly?

Once I have finished the modifications, I have to
a) fetch any changes from origin to local clone to ensure no conflicts.
b) make a relevant branch in the local clone and copy changes from the installed fileset to the clone to start the push/pull process.

Seems unwieldy, but I don't find any info that details these nuts and bolts of actual use/testing.

You can keep the name "admin" in your local testing by adding to your admin/includes/configure.php file this line:

define('ADMIN_BLOCK_WARNING_OVERRIDE', '1');

You can keep the name "admin" in your local testing..
Well fancy that!

So reading between the lines, does that mean the usual way to work is use that override to work directly on the cloned fileset?
Anything else to add?

If not, a bit more padding along the lines of your reply and my posts should be added here for future novices:

http://docs.zen-cart.com/Contributing/main/github_workflow

• You should do your changes on a branch and submit them as a PR.
• Update frequently.
• If you are working on the develop branch (the old 1.6.0), you will need to recreate your database frequently; database changes are made that you'll need to have for things to keep working. Alternatively, you can keep a 1.5.5 database around and run the upgrade process, which usually works (if it doesn't open an Issue).
• Keep your PRs scoped to just the issue you are fixing; don't submit a PR with 10 fixes in it.
• Have fun! :)

what about having to rename/hide the zc_install directory?

When ADMIN_BLOCK_WARNING_OVERRIDE is defined, this check is skipped.

When ADMIN_BLOCK_WARNING_OVERRIDE is defined, this check is skipped.
No it isn't, you need this too.

define('WARN_INSTALL_EXISTENCE', '0');//allow zc_install folder

I put both of these in the admin /local/configure.php

Cool. Can you update the documentation page on this:
https://docs.zen-cart.com/dev/developer_environment/

swguy:

Cool. Can you update the documentation page on this:
https://docs.zen-cart.com/dev/developer_environment/

thanks both of you. couple of things:
2

• the ZC load function is complex, and while putting in the place above works, i have these vars defined in a separate script in the extra_configures directory. which also works. i would encourage documentation to somehow reflect this nuance.
• more importantly, can we simplify ZC? when needed? why are there 2 constants here? someone went in and said, "yo, yo, yo ZC, i know security by obfuscation, but i'm doing development work and i don't want to mess up my git repository, leave my admin directory as is." aka, the first constant. and ZC said, "cool, no worries." but then ZC tells this developer person, you have a security risk due to the presence of the zc_install directory. do we really need the second constant here? can we just use one?
• this gets to the debugging of ZC. it would be nice to be able to turn on debugging in one place, and boom, verbose logs, strict reporting, etc. instead, everywhere it seems there is another DEBUG constant being used. would make troubleshooting so much better IMO.

rant over.