Github Collaboration

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');

Quote:

---

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/Contributin...ithub_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.

Quote:

---

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/

Quote:

---

Originally Posted by 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.