I’am planning on moving at least 10 journals over to OJS. I’ve been reading up on MOJO installs and was wondering if they would be better suited then a single OJS install? The main website is a Wordpress site, I would like to integrate WP with OJS and preferably keep the journal DBs seperate. I’m planning on using OJS 3.0.1, the new layout and features are amazing.
Also I was wondering what would the best way be to customise the layout without having to change the core code. Making it easier to keep the software updated. I’ve tried to install customTemplateManager, however, I’m not sure this is compatible with OJS 3.x.x.
MOJO is an excellent bit of third-party management tooling, contributed by one of our users in Spain. I’ll see if he wants to comment on this thread. That work was done with OJS 2.x but off the top of my head OJS 3.x doesn’t differ so much on management respects that MOJO wouldn’t be adaptable.
The elements MOJO addresses are the complications of customizing many different installations of OJS without incurring a huge overhead in care and feeding many copies of the OJS codebase, each with limited customizations. If you aren’t interested in customizing the code for each journal, then you might not need MOJO. (OJS, of course, has numerous setup/layout options available through the settings user interface, and those wouldn’t make code changes necessary.)
If it’s possible, the easiest thing to do is to host one OJS installation for all 10 journals and use the layout/settings options available within OJS to adapt the journal appearance and settings as needed. However, if those settings aren’t enough, you may need to consider hosting modified copies of OJS.
Regards,
Alec Smecher
Public Knowledge Project Team
I think I’ll be using the features built in OJS 3.x, since the layout will remain the same for all the journals.
Also I was wondering what would the best way be to customise the layout without having to change the core code. Making it easier to keep the software updated. I’ve tried to install customTemplateManager, however, I’m not sure this is compatible with OJS 3.x.x.
The best approach would be to work with pure CSS. If that’s not sufficient, try creating a child theme plugin – this will allow you to selectively override templates. See this example child theme plugin and the PKP Theming Guide for details.
Regards,
Alec Smecher
Public Knowledge Project Team
But I’m really writing to say that mOJO is death, long live DOJO.
To cut the long story short… dojo is the same idea, but based on docker.
I mean, I still see the benefits in a model based in independent OJS instead of a monolithic installation, but we all know that, when you have more than 10 OJS, keeping versions up to date, backups, upgrades is a mess so this is why I started DOJO.
I expected to finish it some time ago, but dojo have an strong dependence… we need an official docker image for OJS and no body was doing this so with some enthusiasts we are right now talking about how this official image will be and how we are going to keep it updated, sorted and so on.
Once finished this part, I will spend more time to extend dojo (aka. docker4ojs) again.
If somebody knows about docker or bash scripts, any help is welcomed.
