Great, @andymp. I’ve gone through the code to see what you’re doing – now that it’s in as a fork of OJS and pkp-lib, I can easily compare the versions through the Github interface and make comments etc:
I see that some of what you’re doing is site-specific, which is exactly what you set out to do, so no surprises there. I hope that OJS 3.0’s theme plugin support will allow you to do much of that as a theme plugin so you won’t have to modify the core code anymore.
I think you’ll find that managing your code with github gives you a much easier way to upgrade when it comes time to re-apply your changes to a newer release (e.g. OJS 2.4.6-1, which will be released shortly). You’ll need to do a
git rebase to apply your changes to the new tag, and that should be it.
I see what you’re doing with the
overrides template directory and it does have advantages, but one disadvantage is that it won’t allow you to easily maintain templates when you have to upgrade. Your override copies can’t be compared against the stock OJS templates (via git, anyway) so you’ll have to figure out a way to manually manage updating them. (There’s a good role for these, and we’ve talked about how to mitigate the risk of version incompatibilities, and IIRC we decided to better break up templates into smaller pieces and to document what promises we make about compatibility between versions. IIRC this mirrors what other major apps have done.) I’d suggest not including override copies unless you need to change their behavior from the default.
@NateWr will probably also have some useful comments.
Very good stuff, @andymp, and thanks again for being such a good FOSS citizen!
Public Knowledge Project Team