Symphony.

I have an issue I just wanted to put here, no idea where to file it. Might be QA, might be development, I'm new so please bare.

I downloaded and installed symphony CMS on a windows box. I've seen the warning that it is for UNIX only. I have no problem with that, infact, I think that's the right direction.

However, I've seen many files in that package that don't have UNIX end of lines, but windows ones.

So I'm wondering, how come? Fault on my end?

I just wanted to say that it would be worth to have everything in UNIX line endings in the packages. So it's streamlined and operation are flawlessly.

Especially with GIT, each edit of files when you use UNIX endings (as I naturally do) becomes bogus with diff.

I don't wanna sound complaining, I have already fixed all those files in my local git repo, but it would have been nice to not need to bother with it in the first place :)

Additionally and somewhat related is the use of whitespaces at the end of lines and mixed use of tabs and spaces for indenting. Not saying to prefer one over the other, but just to have this consistent in the package would be useful. Also there is no need for whitespace at the end of lines which I think is something commonly agreed on.

Should I open an issue for such things on github? Is there a build script that could do some checks before packaging?

This does need addressing, and some of us are aware of it.

If you'd like to help out, could you identify a list of the files and log an issue on Github for us? It would be appreciated, and will remind us to look at it ;o)

That's great feedback. Is there a preference in this project between tabs or spaces? Or you have some coding style-guide I can take a look into?

Last I heard one was either in progress, or being discussed, but if we all follow suit to how the vast majority of the core is coded, we won't go wrong really.

I've seen a few comments talking about standardising to PHP_EOL, along with commits to that effect. I think it was slated for the 2.3 release.

Edit: Found this after a brief search: https://github.com/symphonycms/symphony-2/issues/694

If you find any other places in the code where this is required and hasn't yet been addressed in the integration branch it might be worth posting an issue on GitHub.

Completely forgot about that, well reminded Henry.

I'd say that PHP_EOL is the wrong way to go (I mean it's better than rn which is what the changeset corrected).

But that constant is mainly useless if you target UNIX systems (as I thought symphony does). Especially if some users are pre-compiling setups on windows platforms. So why not opt for n and fine? I want to copy over my files later on anyway to a UNIX box but would love to have the flexibility to use Windows + GIT Bash for compiling a site up.