OJS 3.1.1 upgrade problem

Hi @akyeame,

Hmm, those would generally represent PHP errors in my experience, so it’s odd you’re not seeing them in the log. Another place to look is the browser’s error console.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

This is what I get on Masthead using the Inspect feature of Chrome:

blob:https://laghana.org/7d9ffcf0-4f85-453f-9fe9-5007305b33cd Failed to load resource: net::ERR_FILE_NOT_FOUND
context:1 Uncaught SyntaxError: Unexpected end of JSON input
at JSON.parse ()
at Function.n.parseJSON (jquery.min.js:4)
at a.pkp.controllers.TabHandler.dataFilter (pkp.min.js:211)
at Object.dataFilter (pkp.min.js:123)
at Qc (jquery.min.js:4)
at x (jquery.min.js:4)
at XMLHttpRequest.b (jquery.min.js:4)

Hi @akyeame,

Check on the Network tab (or equivalent) to see if you can capture the AJAX request that’s being parsed here – and watch in particular for the response code (200 for OK, 500 for Internal Server Error, etc).

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

I tried and I only get 200 codes as shown on the screenshot.

2018-07-03_22-52-15

I’ll check back tomorrow. Gotta run for now.

Hi @akyeame,

Watch for the specific request that gets called when you try to load the Issue Data tab, and check out the response to see what it contains.

Also check your log file to see whether any of your warnings mention json_encode – my current best guess is that some of your database content is encoded in correctly.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

When I click the Issue Data tab once already in the lightbox, absolutely nothing happens. Json isn’t there. The only thing close with “encode” is this:

[03-Jul-2018 19:09:10 UTC] Malformed UTF-8 characters, possibly incorrectly encoded

These are my Localization settings:

;;;;;;;;;;;;;;;;;;;;;;;;;
; Localization Settings ;
;;;;;;;;;;;;;;;;;;;;;;;;;

[i18n]

; Default locale
locale = en_US

; Client output/input character set
client_charset = utf-8

; Database connection character set
; Must be set to “Off” if not supported by the database server
; If enabled, must be the same character set as “client_charset”
; (although the actual name may differ slightly depending on the server)
connection_charset = utf-8

; Database storage character set
; Must be set to “Off” if not supported by the database server
database_charset = utf-8

; Enable character normalization to utf-8 (recommended)
; If disabled, strings will be passed through in their native encoding
; Note that client_charset and database collation must be set
; to “utf-8” for this to work, as characters are stored in utf-8
charset_normalization = On

Hi @akyeame,

Did you manually change connection_charset and database_charset from utf8 to utf-8? They should actually be utf8.

Regards,
Alec Smecher
Public Knowledge Project Team

I did. When I had it as utf8, the system couldn’t render apostrophes, quotation marks, tones or diacritic marks – all a big deal, especially for a Linguistics journal. I’ll try again for all of them.

Okay, now those tabs are working, but quotation marks and all else are garbled up as you see in the screenshot. 2018-07-03_23-39-212018-07-03_23-38-46
2018-07-03_23-46-30

Hi @asmecher
So the issue is definitely related to the charset:

;;;;;;;;;;;;;;;;;;;;;;;;;
; Localization Settings ;
;;;;;;;;;;;;;;;;;;;;;;;;;

[i18n]

; Default locale
locale = en_US

; Client output/input character set
client_charset = utf-8

; Database connection character set
; Must be set to “Off” if not supported by the database server
; If enabled, must be the same character set as “client_charset”
; (although the actual name may differ slightly depending on the server)
connection_charset = utf8

; Database storage character set
; Must be set to “Off” if not supported by the database server
database_charset = utf8

; Enable character normalization to utf-8 (recommended)
; If disabled, strings will be passed through in their native encoding
; Note that client_charset and database collation must be set
; to “utf-8” for this to work, as characters are stored in utf-8
charset_normalization = On

That’s what I have now, and things work, but apostrophes and quotation marks do not show correctly. They show correctly with utf-8, but those tabs don’t work. Any way to get both?

Hi @akyeame,

The connection_charset and database_charset should definitely not be utf-8. The best configuration is to use utf8, but it’s also possible (though not ideal) for the system to work with these set to Off. Either way, the data already stored in the database needs to agree with the setting you use.

To get to an ideal configuration, you should use utf8, and if your accented characters aren’t displaying properly, you may need to transcode your database. There are tools like iconv and ftfy you can use for this, as well as several threads in this forum about it. However, it’s more of a MySQL question than an OJS question, so you might also consult stackoverflow.com.

Regards,
Alec Smecher
Public Knowledge Project Team

Hello @asmecher,

I was finally able to resolve the utf-8 after changing servers. Now I’m having an issue with images not showing up.
What is currently being served:

img src=“https://gjl.laghana.org//home/laghana/public_html/gjl/journals/1/pageHeaderLogoImage_en_US.png” width=“107” height=“17” alt=“Page Header Logo”

What should be served: <img src=“https://gjl.laghana.org/journals/1/pageHeaderLogoImage_en_US.png” width=“107” height=“17” alt=“Page Header Logo”

As you can see on the home page, images are broken: https://gjl.laghana.org
Any Ides to get relative links to be served rather than absolute links?

Hello @asmecher,

I was able to resolve the images not showing by changing the public files directory to /, however, I realize that pdfs of previous issues are not accessible and that clicking on them just takes one to a blank white page. Any idea of what path needs to be set to allow downloading of files?

[files]

; Complete path to directory to store uploaded files
; (This directory should not be directly web-accessible)
; Windows users should use forward slashes
files_dir =/home/laghana/public_html/gjl

; Path to the directory to store public uploaded files
; (This directory should be web-accessible and the specified path
; should be relative to the base OJS directory)
; Windows users should use forward slashes
public_files_dir =/

@asmecher,
This is the error log, in case it may assist in tracking down the reason for the issue.

[07-Aug-2018 20:00:13 UTC] PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; ADODB_Cache_File has a deprecated constructor in /home/laghana/public_html/gjl/lib/pkp/lib/adodb/adodb.inc.php on line 263
[07-Aug-2018 20:00:13 UTC] PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; ADOConnection has a deprecated constructor in /home/laghana/public_html/gjl/lib/pkp/lib/adodb/adodb.inc.php on line 359
[07-Aug-2018 20:00:13 UTC] PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; ADORecordSet has a deprecated constructor in /home/laghana/public_html/gjl/lib/pkp/lib/adodb/adodb.inc.php on line 2921
[07-Aug-2018 20:00:13 UTC] PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; ADORecordSet_array has a deprecated constructor in /home/laghana/public_html/gjl/lib/pkp/lib/adodb/adodb.inc.php on line 3939
[07-Aug-2018 20:00:13 UTC] PHP Warning: Declaration of PKPUsageEventPlugin::getEnabled() should be compatible with LazyLoadPlugin::getEnabled($contextId = NULL) in /home/laghana/public_html/gjl/lib/pkp/plugins/generic/usageEvent/PKPUsageEventPlugin.inc.php on line 386
[07-Aug-2018 20:00:13 UTC] PHP Deprecated: Non-static method Config::getContextBaseUrls() should not be called statically in /home/laghana/public_html/gjl/lib/pkp/plugins/generic/usageEvent/PKPUsageEventPlugin.inc.php on line 199
[07-Aug-2018 20:00:13 UTC] PHP Warning: Declaration of IssueFileManager::downloadFile($fileId, $inline = false) should be compatible with FileManager::downloadFile($filePath, $mediaType = NULL, $inline = false, $fileName = NULL) in /home/laghana/public_html/gjl/classes/file/IssueFileManager.inc.php on line 189

Hi @akyeame,

Your files_dir looks wrong; it should never be something inside the public_html directory, unless you’ve specifically protected it from direct access (see docs/README). It would generally be called files or something similar. I suspect you’ve used the OJS install directory as your files_dir, which is not correct and will lead to broken PDFs etc.

Your public directory probably shouldn’t be / either – it should be public, to refer to the public subdirectory inside your OJS installation. You will see things like issue cover images stop working if this is not set correctly.

Regards,
Alec Smecher
Public Knowledge Project Team

Hello @asmecher,

Right now, the images are showing, but the PDFs are showing a blank page.
In the directory structure I see a folder called files above public_html in the root directory as attached here 2018-08-08_23-27-36

I have changed config to read like this:

[files]

; Complete path to directory to store uploaded files
; (This directory should not be directly web-accessible)
; Windows users should use forward slashes
files_dir =/files

; Path to the directory to store public uploaded files
; (This directory should be web-accessible and the specified path
; should be relative to the base OJS directory)
; Windows users should use forward slashes
public_files_dir =/

The images are still showing, but the pdf downloads are giving a white screen.

The website in question is https://gjl.laghana.org

Hi @akyeame,

In that case your files directory should probably be /home/laghana/files. Note that if you ran the upgrade script with the wrong files_dir configured, your files won’t have been appropriately rearranged for OJS 3.x. (In this case you would’ve received a number of warnings when the upgrade script ran.)

Regards,
Alec Smecher
Public Knowledge Project Team

Hello @asmecher,

It looks like that solution worked. I was able to upgrade successfully on the old server, but I just migrated and these issues cropped up for some reason on the new server.
The images are loading as well, so is the setting for public_files_dir=/ okay or should this be changed as well. At this point I’m trying not to rock the boat if things are working.

Greetings @asmecher,

All of the sudden, images just stopped working. Image URLs show https://laghana.org/gjl///journals/1/cover_issue_15_en_US.jpg
With three slashes in a row. Any idea what could have caused this? The settings are still the same, but I am unable to upload images and the images do not display on the front end.

Hi @akyeame,

I suspect your public_files_dir is the problem; I’d strongly suggest leaving it as public (and making sure PHP has permissions to upload files there). You may need to rearrange the cover images etc. into that directory.

I think the /// is probably a red herring – UNIX-like systems will ignore these repetitions. But restoring your public_files_dir setting should also resolve this.

Regards,
Alec Smecher
Public Knowledge Project Team