Yea, what you suggested is better. On a similar note, I had a bit of a think and was wondering your thoughts if there should be an ACL-locked CMS resource for editing the routes.php settings, or if it should stay strictly to those with FTP access.
Hmm, that wouldn't be bad to have, but would definitely have to be made simple to use. I think we would also have to move to using a conf/routes.ENV.php naming convention then, so as to encourage less editing of original Elefant source files (like we do with app configs).
Btw, I've been a bit slow at getting to PRs, sorry about that. Last big project is finishing up this month and I'm away most of this week, so I'm hoping to start catching up and not being so slow starting later this month. Fingers crossed ;)
No worries. I've been pretty busy with other things myself until just recently. I've got a couple small improvements I'm tackling right now. I'll get that ACL-locked resource built soon with the ENV convention implemented.
A side note I've also been thinking about: Do you think it would be good to have a public dev branch that people can push changes to instead of the master incase their is a security or functionality issue that isn't caught right away? It would also give you chance to review locally before it hits distribution I think.
I've been in the bad habit of relying too heavily on the master branch atm. I figured once I tag a final 2.0 release I'd branch that off so we can keep developing towards the next version on master and push fixes on the 2.0 branch.
I also have to get into the habit of creating branches for testing PRs before merging into master, as well as for my own new features too.
For example, I went to work on the grid-based editor some more but it had been so long that when I went to merge the latest changes from master into that branch to get it back up to speed, it completely blew up in my face. Gotta start the cleanup on that over at some point...