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:

Attachment 16315

Quote:

---

Originally Posted by torvista

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

Attachment 16315

---

Are you logged in?

Quote:

---

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

Quote:

---

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:

Quote:

---

Originally Posted by 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');

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.

> why are there 2 constants here?
Fine tuning these settings might not be the best use of your time, given the small audience. Let's document them and move on.

> it would be nice to be able to turn on debugging in one place, and boom, verbose logs, strict reporting, etc.
If you're using Zen Cart 1.5.6, verbose logging with backtrace is turned on by default. It's only if you want Notice level logging (that you really don't need), that you need to turn it on.

But again, please feel free to add to the documentation repo with best practice steps, and then you won't have to remember it - you can just check the FAQ.

Quote:

---

Can you update the documentation page

---

...after an afternoon of pain with hugo, git, "permission denied", ssh-windows and three kids climbing the walls after three weeks in anti-quarantine:bangin:, the answer is surely no.

@carlwhat can you pitch in here?

Quote:

---

Originally Posted by swguy

@carlwhat can you pitch in here?

---

yes. i can. and i will.

i am trying to find my documentation repo on my local machine and update it. if i have to recreate it, it may be a bit.

i have other things i am working on.

documentation always seems to be the last thing on any project. although i am a fan of the process as well as encouragement.

thanks for your patience.

best.

So, downloading ZC157 from sourceforge and also checking out branch ZC157 with a Git client, should result in an identical comparison.

On Windows, with Beyond Compare, it shows that the files from Sourceforge have unix line endings, and the ones from Git have Windows line endings and so there are many "differences" indicated....with no actual code differences.

I imagine the git client converts unix-windows on checkout and converts back windows-unix on commit.

So, how to stop that so the git checkout is unix and all compares the same?
A setting in the gitattributes I believe...but this is part of the checkout files....so what can be done to force the checkout to stay as unix/make the compare identical?

The zip on sourceforge was built by doing a fresh git checkout, on my Mac.
Your git checkout was done on your computer, apparently Windows.
Your git client is converting all the line-endings to windows-style, and mine to linux style.

The .gitattributes setting is pretty standard: "* text=auto" ... which is what I see in most other repositories I work with, where people are using various OS's.

I don't really have a definitive answer for Windows.

Now with 1.5.7 released today maybe now is a good time to experiment with tweaking your git client configuration and eventually end up with a new more compatible directory?

That said, zcwilt and I will be chatting about re-normalizing all files in 1.5.8. If we do it, be prepared for a massive number of changed files ... which upgraders will hate :(

Upon further digging, turns out it's doing exactly what it's supposed to do: translate to your local machine based on your machine's configuration.

For Windows: https://help.github.com/en/github/us...r-line-endings

Code:

---

$ git config --global core.autocrlf true
# Configure Git to ensure line endings in files you checkout are correct for Windows.
# For compatibility, line endings are converted to Unix style when you commit files.

---

In Beyond Compare, line endings can be made to be "non-essential" by running a rules based comparison between the file(s). Session->Session Settings->Compare Tab->Compare Contents (section), rules based radio. It doesn't address the "saving" part, though in my git checkout/checkin I think I have set it to always use a particular style, though I haven't reviewed my global settings in a while.

i will say that administration/housekeeping tends to be the bane of my existence. and the handling of line feeds tends to fall into that category.

i am not sure why you would want to or care why the sourceforge download is different from the git checkout; but hey we all have our reasons. i would think all of the compare programs have a setting to ignore the line endings, but i can not say for sure.

i know at times on the github repo, it seems that files have linux line endings except for the lines inserted by the stamper witch have windows line endings.... perhaps, it is me and my config. i will look a bit more closely. but for me low priority...

Quote:

---

Originally Posted by DrByte

zcwilt and I will be chatting about re-normalizing all files in 1.5.8. If we do it, be prepared for a massive number of changed files ... which upgraders will hate :(

---

and as far as normalizing files; as long as they have unix line endings, and contributors do not have to conform to one spec for existing files and another spec for new(er/ish) files, that would be great. considering any number of contributors all use phpStorm for their IDE, it might be advantageous to put in the docs the exact settings that one can use to conform to the new normalized files. i know one upgrader that will not say "boo" about the normalizing. :laugh:

Quote:

---

Originally Posted by DrByte

That said, zcwilt and I will be chatting about re-normalizing all files. If we do it, be prepared for a massive number of changed files ... which upgraders will hate :(

---

Using the Linux tool diff with the option -w will only show non-whitespace differences. Using this utility, you can build the changed file list and only show files that have changed by more than whitespace.

Quote:

---

Beyond Compare
Session->Session Settings->Compare Tab->Compare Contents (section), rules based radio

---

Thanks.
Never used that until now. It shows correctly that files are identical. Fast enough for local comparisons...
(I note that there is an additional docs css rule in the ZC157 checkout compared to the release.)

I want this comparison to compare the ongoing ZC158 changes with a reference ZC157 installation and production shop etc.

Quote:

---

Originally Posted by torvista

Thanks.
Never used that until now. It shows correctly that files are identical. Fast enough for local comparisons...
(I note that there is an additional docs css rule in the ZC157 checkout compared to the release.)

I want this comparison to compare the ongoing ZC158 changes with a reference ZC157 installation and production shop etc.

---

In reference to the additional css file, are you comparing the v157 branch to the release or the tagged v1.5.7?

As a side note, versions may have additional files/changes that are not part of the latest release... v156 compared to v1.5.6f is an example... Basically changes "prepped" to support a future sub-release, whether that release occurs or not...

While I understand the emphasis on local as associated to a previous comment, I point out that the comparison works for local to remote or remote to remote as well...

Quote:

---

comparing the v157 branch to the release

---

Yes

Attachment 19063

Git line endings

Quote:

---

turns out it's doing exactly what it's supposed to do: translate to your local machine based on your machine's configuration.

---

Yes, I got that. But is it not doing that based on the .gitattributes of the fileset, not the machine configuration?

My scenario is
1) my new shop starts with a sourceforge fileset: unix endings.
2) I merge my mods in from the current production shop, taking care to convert these to unix endings.
3) over time, new things appear in Github v158 that I may want to merge in too: but these checkout automatically converted to Windows endings as per the .gitattributes "* text=auto" that is in the github fileset. So any file I want to merge, I'll have to convert manually.

So if I want to stop Git checkout converting the checkout to windows endings, I suppose I need to change the gitattributes "* text command....but if it is part of the fileset, how can I do that/override it?