@Ph_We: there isnât really a âbestâ way here. There are only a couple options with pros and cons. In general, though, I recommend never modifying any code distributed by a third-party (in this case, PKP).
In general, I would say there are two models: using a Child Theme or Base Theme. With the Child Theme approach, you base all of your work off the default theme or another theme created and distributed by someone else (ie - Manuscript or Bootstrap3).
The Base Theme model is what @ajnyga has described: creating your own base theme and extending from that.
By using a Child Theme approach, you can benefit from any of the rolling changes that are provided by a third-party. For instance, a popular request is for us to redo the citation block on the article details page to make it smaller. So weâll probably do that at some point, and weâll integrate those changes with the default theme, and make sure they work with Bootstrap3 and Manuscript as well. If you use a Child Theme, youâll get those changes for âfreeâ just by updating the plugin.
However, that also means that youâll need to keep an eye on changes that are happening. If we make a change that effects one of your custom themes in an unexpected way, youâll need to have some way of identifying and correcting that before you update.
By using a Base Theme approach, you can insulate yourself from some of these changes. With the citations change, for instance, if you donât like the change weâve made, you can drop the old template into your base theme and keep all the same styles. However, you wonât get any of the rolling updates we make, like the recent bug weâve fixed with the navigation submenus on some mobile devices.
So either way works. It really just depends on how you prefer to manage the changes that are coming down the pipeline. A custom base theme is a good way to insulate yourself from some of those changes, but it may mean more work is needed down the line to integrate the changes you want to include.
Personally, hereâs how I would organize things if I was running a platform with lots of journals that each needed customizations.
-
Iâd create a custom child theme, myPlatformTheme, of the default theme. This would act like a âbase themeâ for all of my journals. It would allow me to place any code that I wanted to include with all journals, but I wanted to remain separate from the default theme. For instance, maybe my journal platform includes a custom link to the platform in the footer of every journal. That would be something to include in this base theme.
-
Iâd create a custom child theme of myPlatformTheme for every journal that needed more customizations. That way each themeâs modifications could be isolated from each other.
With this setup, I can still take advantage of all basic bug fixes and improvements from the default theme. Because I havneât touched any of the code there, I can just update and get those improvements easily. But if the default theme does something that doesnât fit with what I need for my platform, I can insert modifications into myPlatformTheme and automatically have them applied to every journal on my platform.
But thatâs just my preference. Depending on how involved youâll be for maintenance and upgrades, you might find other strategies work best for you.