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.
Hi @mpbraendle,
Can you include screenshots? I’m not sure which typography options you mean, and wonder what the journal homepages look like.
Regards,
Alec Smecher
Public Knowledge Project Team
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.
These are the typography settings after migration:
English UI
German UI
This is the garbled home page of the journal:
You can’t access our test server because it is hidden behind the firewall.
Hi @mpbraendle,
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.
All the best,
Shawn
Hi @dewolfe001,
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?
All the best,
Shawn
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:
All the best,
Shawn
Hi @dewolfe001,
First, I’d suggest upgrading to OJS 3.0.1. There’s little or no risk – it includes a lot of tweaks and improvements.
Are you writing your own theme, or just using one of the third-party ones that people are broadly working with?
Regards,
Alec Smecher
Public Knowledge Project Team
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.
The other theme in question was the Bootstrap Theme (GitHub - NateWr/bootstrap3: A community-built theme for OJS 3 that implements Bootstrap 3 components. - v.1.0.0). My attempts last week were around adding the theme (first FTP’d into place, later attempts were uploads via the UI). My intention was to get it activated, then consider modification.
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.
All the best,
Shawn
Hi @dewolfe001,
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