Although the test upgrade on our test platform ran fine (OJS 2.4.8.1 → OJS 3.0.0.0), none of the typography options in Settings > Website is ticked for any of the journals.
This results in not loading the theme correctly; the displays of the journal homepages look strange.
At least a default typography should be selected in the course of the migration.
No default typography option should be selected. The default theme should work fine with no option selected. If it’s not, please share some screenshots of what’s not appearing correctly and we’ll look into it.
It looks like some of the CSS code is missing, but then other parts of it appear to be styled properly. Without looking at your specific setup, I can’t say what’s going on. But I don’t believe it’s related to the typography option.
I had the same thing happen.
Calls to load the CSS and JQuery code (eg. $this->addStyle(…) and $this->addScript(…) ) are not being executed.
I added the Bootstrap3 theme (1.0.0.0 for OJS 3.0). The Default theme stopped working. The Bootstrap 3 theme would not initialize with its subtheme options. The Default theme thereafter would not initialize and run. I added test code into the theme plugins and the ThemePlugin class.
From what I can see: the adtivation of the plugin is causing something needed to declare an active class from working.
Are you using OJS 3.0.0, or 3.0.1? There was an issue in OJS 3.0.0 that caused theme templates to clash when different themes were active (e.g. on different journals) within the same installation. If you’re using 3.0.0, I’d suggest upgrading to 3.0.1.
Regards,
Alec Smecher
Public Knowledge Project Team
We’re using 3.0.0. To add additional meta data fields into we forked OJS, so we could reproduce those changes but I would rather not.
Is there a circumstance where 3.0.0 could handle themes other than the default? After discovering the issues with addStyle and addScript calls, I tried to remove the new theme, then I tried to resolve this by removing the default theme and have only the new theme in place. Neither theme on its own, nor one theme in use while the other code is present, will function.
What has to happen for a theme to operate in OJS 3.0.0?
In deeper digging, I have found that the value, themePluginPath, is not being set in the database table for journal settings. When I set it manually in the db and in the cache file, it does look to the appropriate theme.
So my questions:
Why doesn’t it write that setting, instead blanking it out?
With Bootstrap and its styles, how can I manually set the settings to choose the style I want? (this latter piece I am working through now).
With OJS 3.0.1: there are time pressures. In an earlier thread, it was suggested that as there was no straight forward way for a module to introduce new form fields to the meta data UI and then populate associated dropdowns. The other thread lead me to a fork of 3.0.0 as the way forward. I was reluctant to fork the application, thinking that form should have been extensible, but there was no clear way to make that happen, so we’re working with a fork of 3.0.0 where the changes are specifically adding fields to the meta data UI and storing those values.
It’s biggest issue is that the inclusion of this theme somehow made setting themePluginPath in the database no longer function. When I updated the value and cleared the cache, it got closer to working. There were typos in the naming so it was not able to find the cleanblog directory and the associated .less files.
I would suggest at least trying an upgrade. You could extract your modifications via e.g. diff, and then try patching a 3.0.1 codebase. There’s a fair likelihood that you’re trying to debug something that’s already been fixed in 3.0.1, which might be a considerable waste of time.
Regards,
Alec Smecher
Public Knowledge Project Team