[OJS 3.1] Unable to publish article

Hello all, @asmecher, @nate

This is urgent!!
I need to publish our latest issue, which is already very late TODAY.
Unfortunately, the schedule for publication button isn’t available anywhere in the production tab.
I have sent the submission as manager and editor, but can’t complete this simple task…

Hello @asmecher, @NateWr, @ctgraham,

I believe we have a more serious problem with our installation than suspected…

[Tue Aug 04 02:31:12.598251 2020] [php7:notice] [pid 92396] [client 192.168.0.240:38919] PHP Notice: Only variables should be assigned by reference in /var/www/revista.ibict.br/pages/index/IndexHandler.inc.php on line 68
[Tue Aug 04 02:31:12.602850 2020] [php7:warn] [pid 92396] [client 192.168.0.240:38919] PHP Warning: Creating default object from empty value in /var/www/revista.ibict.br/cache/t_compile/00a0a0910209607cb33eb0fe6474f30ed7399ed7^52019e87b90081f2c6bfa717994d81ab7712dd1f_0.app.frontendcomponentssearchF.php on line 30
[Tue Aug 04 02:31:15.872922 2020] [php7:warn] [pid 92396] [client 192.168.0.240:38919] PHP Warning: Declaration of PKPAssignPublicIdentifiersForm::execute($save = false) should be compatible with Form::execute(…$functionArgs) in /var/www/revista.ibict.br/lib/pkp/controllers/grid/pubIds/form/PKPAssignPublicIdentifiersForm.inc.php on line 125, referer: http://revista.ibict.br/ciinf/manageIssues
[Tue Aug 04 02:31:15.872977 2020] [php7:warn] [pid 92396] [client 192.168.0.240:38919] PHP Warning: Declaration of AssignPublicIdentifiersForm::fetch($request) should be compatible with PKPAssignPublicIdentifiersForm::fetch($request, $template = NULL, $display = false) in /var/www/revista.ibict.br/controllers/grid/pubIds/form/AssignPublicIdentifiersForm.inc.php on line 42, referer: http://revista.ibict.br/ciinf/manageIssues

Hi @ramon,

The log entries that you posted in your last message do not appear to contain a fatal error, so they don’t indicate the source of the problem with the issue publish modal. I’d recommend looking in your browser’s console for an error message.

Regarding your original post, about the missing schedule for publication button, it looks like this button only appears for managers and subeditors (see code). That’s the only thing I can see that looks like it would make the button not appear. Perhaps there’s a problem with the $userRoles variable…

Hello @NateWr,

I have all possible roles. I submitted as myself and the original authors (the editorial), yet the schedule for publication button is not available.
I noticed we cannot add all roles to a user anymore.
We have to assign a role during the editorial process, which I did.
I added myself to the submission in all possible roles, but to no avail.

We use multiple languages. Could that be an issue? I notice OJS is a lot more picky about this.
In OJS 2 we could publish an announcement with just one language. Now, it makes me translate the announcement, otherwise, I can’t save the form.

In the database, I only have these roles for the specific journal:
±-----------±--------±--------+
| journal_id | user_id | role_id |
±-----------±--------±--------+
| 1 | 1 | 16 |
| 1 | 1 | 256 |
| 1 | 1 | 768 |
| 1 | 1 | 4096 |
| 1 | 1 | 65536 |
| 1 | 1 | 1048576 |
±-----------±--------±--------+

What role do I need to be able to schedule the article?
How do I add the needed roles in my profile (in the database directly)?
Or are these roles applied when assigned to a submission?
Not all roles are available for selection…

Hello all, @asmecher, @NateWr, @ctgraham,

Apparently, certain tasks are based on roles. However, OJS now has the ability to create roles, so, it should instead be permissions oriented. Depending on the level of permission, the task should be allowed.

I’ll edit this when I get the info on the edited files and lines!

No, that won’t be effecting this.

What role do I need to be able to schedule the article?

It looks like you are assigned to the submission as a Journal Editor, so you should have the necessary role.

I suspect you’ll have the most luck by throwing some debug code into templates/controllers/tab/workflow/production.tpl around here: https://github.com/pkp/ojs/blob/stable-3_1_2/templates/controllers/tab/workflow/production.tpl#L18-L24

You can use $userRoles|@print_r to print the user’s current roles to the page. That might at least tell you whether the issue is with the roles the system thinks you have.

We modified
/var/www/revista.ibict.br/lib/pkp/controllers/tab/settings/AdminSettingsTabHandler.inc.php
line 28
$this->addRoleAssignment([ROLE_ID_MANAGER, ROLE_ID_SITE_ADMIN, ROLE_ID_SUB_EDITOR]

We added ROLE_ID_SUB_EDITOR

We also modified
/var/www/revista.ibict.br/lib/pkp/controllers/tab/settings/ManagerSettingsTabHandler.inc.php
line 29
$role = array(ROLE_ID_MANAGER, ROLE_ID_SITE_ADMIN, ROLE_ID_SUB_EDITOR);
We added again ROLE_ID_SUB_EDITOR

If this are not based on permissions, then, I would suggest rethinking this logic, as we can create as many roles as we want and provide them with the necessary permissions.
Also, the Journal Manager and Editor are above hierarchically to the SUB_EDITOR (I assume!), and they should have that permission enabled by default.

Unless we have some serious problem with our installation that we are not aware of.

I don’t think that these changes will effect the schedule for publication button in any way. These changes will permit any section editor to modify settings under the Administration area. They will not be presented with the link in the navigation menu, but if they navigate directly to the page they will be able to access the forms and edit them. You probably don’t want that.

The problems that you are experiencing with the schedule for publication button do not appear to be a general problem. The version you are using is quite old by now and we don’t have any other reports of journals experiencing this.

Hello @asmecher, @NateWr,

I’m still struggling with the “schedule for publication” button.
I followed your suggestions and reverted the changes to the Manager and Admin tabs we made.
Adding {$userRoles|@print_r} the result is:

Array ( [0] => 1 [1] => 16 [2] => 17 [3] => 4097 [4] => 65536 [5] => 4096 [6] => 1048576 ) 1

What does this mean?

I added myself as Production Manager, Layout editor, and any other related role, but the schedule for publication is unavailable.
Even if I send a DOC file as a galley, the button doesn’t show…
Do I have to conclude the editing stage??
Why has it become so complicated to schedule an article to an issue?
Once it’s approved, this should be available even if the next stages are not complete, in order to provide immediate access to approved papers or at least their abstracts.

Whenever I move an article to Production, the following warning is shown, but even when I send galleys, the schedule for publication continues unavailable.

Notification
Awaiting Galleys.

Hello all,

This is also a strange behavior.
I have an issue with several articles already scheduled to it. If I remove any of them, I’m not able to schedule it anymore, to any issue.
Always showing the Notice above…

However, these guys at Edinburgh don’t have the same problem.

Hello anyone,

I need to report that OJS 3.2 once worked and then it started having problems saving administration configuration information.
We believe that it worked when it was in Ubuntu 18 and started failing when upgraded to Ubuntu 20, which has serious compatibility issues with lots of things.

Could this be our general problem?

Even on Ubuntu 18, we are unable to save admin settings (theme is empty and can’t apply).

Here are some error messages:

[16:07, 13/08/2020] Alexandre Ribeiro: WARNING: The NavigationMenu (ContextId: 1, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 1, Title: Primary Navigation Menu, Area: primary) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 2, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 2, Title: Primary Navigation Menu, Area: primary) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 5, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 5, Title: Primary Navigation Menu, Area: primary) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 9, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 9, Title: Primary Navigation Menu, Area: primary) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 3, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 3, Title: Primary Navigation Menu, Area: primary) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 4, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 4, Title: Primary Navigation Menu, Area: primary) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 8, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 8, Title: Primary Navigation Menu, Area: primary) will be skipped because the specified area has already a NavigationMenu attached.
WARNING: The NavigationMenu (ContextId: 0, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.
[16:11, 13/08/2020] Alexandre Ribeiro: file_put_contents(/var/www/revista.ibict.br/cache/fc-pluginSettings-0-defaultthemeplugin.php): failed to open stream: Permission denied in /var/www/revista.ibict.br/lib/pkp/classes/cache/FileCache.inc.php on line 90, referer: http://192.168.0.70/admin

Hi @ramon,

What are permissions to the cache folder?

Hello @Vitaliy,

We tried everything, even 777.
I don’t think that’s the problem.

Hello anyone,

Interestingly enough, we updated our production server and scheduling for publication still stuck.

Some OJS background info first.

Submission details

Publication screen…

My roles

Not sure if these cause any problems as well:

[Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.
main.js?attr=5tvh_5oWNZfsHRDrSGKNcaEhXqPLs2XMCB0V5va26cZRBr3jNLdHQL_fk4kKV0ViqFHIa4Yhi51u_UWxASqt-TXRkRFz5SDerSIFvD1D9iM:1012 [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/. window.XMLHttpRequest.open @ main.js?attr=5tvh_5oWNZfsHRDrSGKNcaEhXqPLs2XMCB0V5va26cZRBr3jNLdHQL_fk4kKV0ViqFHIa4Yhi51u_UWxASqt-TXRkRFz5SDerSIFvD1D9iM:1012 send @ jquery.min.js?v=3.2.1.1:2 ajax @ jquery.min.js?v=3.2.1.1:2 a.pkp.controllers.NotificationHandler.fetchNotificationHandler_ @ pkp.min.js?v=3.2.1.1:225 a.pkp.classes.Handler.handleEvent @ pkp.min.js?v=3.2.1.1:129 dispatch @ jquery.min.js?v=3.2.1.1:2 y.handle @ jquery.min.js?v=3.2.1.1:2 trigger @ jquery.min.js?v=3.2.1.1:2 triggerHandler @ jquery.min.js?v=3.2.1.1:2 a.pkp.controllers.NotificationHandler @ pkp.min.js?v=3.2.1.1:224 a.pkp.classes.ObjectProxy.parent @ pkp.min.js?v=3.2.1.1:124 b @ pkp.min.js?v=3.2.1.1:122 a.pkp.classes.Helper.objectFactory @ pkp.min.js?v=3.2.1.1:120 (anonymous) @ pkp.min.js?v=3.2.1.1:429 each @ jquery.min.js?v=3.2.1.1:2 each @ jquery.min.js?v=3.2.1.1:2 a.fn.pkpHandler @ pkp.min.js?v=3.2.1.1:429 (anonymous) @ 5:222 l @ jquery.min.js?v=3.2.1.1:2 c @ jquery.min.js?v=3.2.1.1:2 setTimeout (async) (anonymous) @ jquery.min.js?v=3.2.1.1:2 u @ jquery.min.js?v=3.2.1.1:2 fireWith @ jquery.min.js?v=3.2.1.1:2 fire @ jquery.min.js?v=3.2.1.1:2 u @ jquery.min.js?v=3.2.1.1:2 fireWith @ jquery.min.js?v=3.2.1.1:2 ready @ jquery.min.js?v=3.2.1.1:2 _ @ jquery.min.js?v=3.2.1.1:2 DevTools failed to load SourceMap: Could not load content for http://revista.ibict.br/lib/pkp/lib/vendor/tinymce/tinymce/skins/lightgray/skin.min.css.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

Also, the Metadata tab is unavailable… the guide shows a leftside tab with access to a bunch of options not available to us…

I found this in the error log:

[Fri Aug 14 17:36:43.407193 2020] [php7:error] [pid 105466] [client 192.168.0.240:46407] PHP Fatal error: Uncaught TypeError: Argument 1 passed to Sokil\IsoCodes\Database\Countries::getByAlpha2() must be of the type string, null given, called in /var/www/revista.ibict.br/pages/search/SearchHandler.inc.php on line 272 and defined in /var/www/revista.ibict.br/lib/pkp/lib/vendor/sokil/php-isocodes/src/Database/Countries.php:42\nStack trace:\n#0 /var/www/revista.ibict.br/pages/search/SearchHandler.inc.php(272): Sokil\IsoCodes\Database\Countries->getByAlpha2()\n#1 /var/www/revista.ibict.br/lib/pkp/classes/core/PKPRouter.inc.php(391): SearchHandler->authors()\n#2 /var/www/revista.ibict.br/lib/pkp/classes/core/PKPPageRouter.inc.php(231): PKPRouter->_authorizeInitializeAndCallRequest()\n#3 /var/www/revista.ibict.br/lib/pkp/classes/core/Dispatcher.inc.php(143): PKPPageRouter->route()\n#4 /var/www/revista.ibict.br/lib/pkp/classes/core/PKPApplication.inc.php(279): Dispatcher->dispatch()\n#5 /var/www/revista.ibict.br/index.php(68): PKPApplication->execute()\n#6 {main}\n thrown in /var/www/revista.ibict.br/lib/pkp/lib/vendor/sokil/php-isocodes/src/Database/Countries.php on line 42

Hi @ramon,

I’m having a hard time keeping track of which problem we are dealing with. Initially, the problem you described was that the Schedule for Publication button was missing. However, based on your screenshot in this post, it is appearing now.

Like your original report, some of the other issues you describe appear to be be problems specific to your installation. We have not had problems like this reported from anyone else.

Unfortunately, this is beyond the level of support that we can provide on the forum. You are likely going to need to contract with a technical support expert who can investigate each problem you’re encountering at the server, database and software levels in order to identify the source of these problems.

If that is not possible due to budget constraints, another option you might pursue is doing a fresh install of OJS 3.2.1 and then using the export and import tools to bring your existing submissions over. The downside is that you’ll lose your editorial history, but you can keep an archived instance of your 3.1.x OJS installation offline for historical reference. (If you do this, be sure to keep the database and files and to keep your old instance offline for security purposes.)

Hello @NateWr,

Sorry for all the confusion, but, we are trying anything that may help.
Unfortunately, our production server doesn’t allow us to publish articles at all, independently of OJS version. With 3.1, we are unable to schedule. With 3.2, we can send to production, but the page appears empty, which prevents editing metadata and scheduling to an issue. Also, with 3.2 we’re unable to save site administration configurations.

Our log seems useless and we are unable to find a way to figure out what the problem really is…

Hello @NateWr, all,

Very strange behavior.
When I’m logged into OJS from home, the schedule for publication button doesn’t show.
Only when logged through my work computer the button is shown (remote connection works).
Any ideas?

No, sorry. Try a third computer from a different network?