Error in upgrading OJS 3.0.2 to OJS 3.1.1

@NateWr When the ##api.submissions.unknownError## messages appears for me, no php error appears in the log. I’ve looked multiple times. My php is 7.2.4 and it is configured to report warnings and up.

As you requested above, I used Chrome (latest Linux edition) to record traffic. You can fetch the log from this url. Because I’m giving this link publicly, I edited the domain name to HOST and the journal abbreviation to JOURNAL. The actions recorded are: Log in as journal manager; select Settings->Journal. During this sequence, the ##api.submissions.unknownError## message appeared (but the Chrome log doesn’t show it) and a few javascript errors occurred.

Since this system is so far just in test mode, I can run experiments. For example, if you provide an instrumented version of ModalHandler.js (which produces the javascript errors), I can try it. I don’t speak javascript myself.

Brendan.

It looks like the link to the log isn’t working.

@NareWr Sorry, it had “hhttps”. Should work now. Brendan.

@NateWr,

It is suddenly working. I didn’t do anything.

Thanks.

Paul

@bdm this is the log for the browser events. But if you’re getting the API error, you’re probably running into a fatal error on the server. You’ll need to check the server logs for errors.

@Paul_Chen great, it was probably just some cache that needed to clear.

@NateWr I created the error about 6 times in quick succession. In apache2/error.log, tons of these warning messages and nothing else. In apache2/access.log some successful GETs and some 404s from missing favicons, and nothing else. In the postgres error log, nothing. I don’t know where else to look.

I’m sorry, I don’t know how else to help. If you’d like to send me the entire error log file via PM, I’ll search for any fatal errors (they’re easy to miss with all the warning messages).

@NateWr

I have discovered why nothing is in the server logs: the error is occuring in my browser as it executes javascript. Look for “api_submissions_unknownError” in js/build.js; there is code there for issuing this message.

To prove this theory, I edited js/build.js by changing the variable $.pkp.locale.api_submissions_unknownError into the literal string “BLAHBLAH”. Sure enough, the popup error message now says “BLAHBLAH”.

Looking again at that point in build.js, the code there is doing something related to the modalHandler — recall from above that I see 2 or 3 javascript errors in js/modalHandler.js at exactly the same time as the ##api.submissions.unknownError## message pops up.

I strongly suspect that the way to make the error popup disappear is to fix the errors in modalHandler.js.

@bdm, api_submissions_unknownError is the error message that the JavaScript code will display when it encounters an error it doesn’t know how to handle. This usually indicates that an ajax request to the server has failed. You’re correct that the error message is triggered in the JavaScipt, but it usually indicates a problem on the server.

@NateWr I spent 7-8 minutes clicking between the menus in the journal manager’s view (i.e Submissions, Issues, Settings, Users&Roles, Tools and Administration). The error pop appeared many times and the common situation between all of them was being in the Submissions area then leaving, either to one of the other admin sections, Settings.Website, or even to “View Site” or logout.

Contrary to what I thought before, it is not specific to Settings.Journal. Moving from Submissions to anywhere triggers it. Even being in Submissions and clicking again on Submissions triggers the error.

I could not trigger the error on leaving one of the other admin sections, for example leaving from Administration. I only managed it by leaving Submissions.

Before doing this, I set PHP’s reporting level to “everything” and restarted the web server (which began a new error log). After finishing, I made a copy of the error log. You can have a copy if you like, but I can tell you it has only:

  1. The web server startup message.
  2. One ssl error triggered by someone in another country.
  3. About 250 lines similar to “[Sat Apr 14 13:05:51.943824 2018] [php7:warn] [pid 21056] [client MYIPNUMBER:54400] PHP Warning: Declaration of PKPUsageEventPlugin::getEnabled() should be compatible with LazyLoadPlugin::getEnabled($contextId = NULL) in /usr/local/share/ojs/lib/pkp/plugins/generic/usageEvent/PKPUsageEventPlugin.inc.php on line 0, referer: https://MYJOURNALURL/…”

If you can think of some code that gets executed at the moment of leaving the Submissions area, I’m happy to insert some debugging code into it. At the moment I don’t even know where to look.

Thanks, Brendan.

Hi Brendan,

Unfortunately, I’m not familiar with any code that would be triggered on leaving a page. If you can send me by private message the error log I’ll take a look and see if I can spot anything unusual, but I don’t have many ideas at this point…

Hi guys,

I´m having the same problem. Anyone found the solution?

The ##api.submissions.unknownError## occur when the is restful_urls changed in config.inc.php to On. If restful_urls = Off no error occur.

Thanks,
Geucimar

The restful_urls = On remove the index.php between localhost/ and /journal and this causes the 404 error.

http://localhost//journal/api/v1/submissions?status=1&assignedTo=-1&searchPhrase=&count=20&offset=0&=15299993396

When I put index.php manually in the request it works fine.

http://localhost/index.php/journal/api/v1/submissions?status=1&assignedTo=-1&searchPhrase=&count=20&offset=0&=15299993396

I don’t know how to repair this error in jQuery request. Could someone help me?

Hi @Gecuimar,

When restful_urls = On the index.php should be removed from all of your requests. If it’s not, you’re probably missing the .htaccess configuration you need to run with restful_urls = On.

I’m using htaccess too. But, when I enable restful_urls, submissions URL returns the error, if I disable everything works fine.

@NateWr @Gecuimar Alas, the same problem occurs for me whether or not restful_urls is On. But the restful_urls option works as advertised.

@Gecuimar, I notice that http://localhost//journal/ includes a double slash (//). Maybe that’s the issue? Can you try removing any ending slash from your base_url to see if that helps?

Hi, @NateWr and @bdm,

My base_url is correct:

base_url = http://localhost
base_url[index] = http://localhost
base_url[journal] = http://localhost

I’ve checked that the restfulUrlsEnabled condition in function getApiUrl of file js/build.js is a bit confusing.

The condition removes the index.php page from api url http://localhost//journal/api/v1/_submissions and the ajax request produces the error message ##api.submissions.unknownError##.

The solution is to maintain the “index.php” still when restfulUrls are enabled.

getApiUrl: function(t) {
var e, n = “index.php”; // $.pkp.app.restfulUrlsEnabled ? “” : “index.php”;
return e = $.pkp.app.contextPath ? “/” + $.pkp.app.contextPath + $.pkp.app.apiBasePath : $.pkp.app.apiBasePath, $.pkp.app.pathInfoEnabled ? $.pkp.app.baseUrl + “/” + n + e + “/” + t : $.pkp.app.contextPath ? $.pkp.app.baseUrl + “/” + n + “?journal=” + encodeURIComponent($.pkp.app.contextPath) + “&endpoint=” + e + “/” + t : $.pkp.app.baseUrl + “/” + n + “?endpoint=” + e + “/” + t
}

Hi @Gecuimar,

The removal of the index.php with restful_urls enabled is intentional; see the config.inc.php note on the restful_urls setting and associated entry in docs/FAQ.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

I’m sure of this, but when using mod_rewrite to work with a single journal without contextPath, this condition causes the error message ## api.submissions.unknownError ##.

The change above is a solution that works for me.