; 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 = Off
If warnings and deprecation messages are configured in your php.ini to go to the browser (rather than just the log file), they may be getting injected into JSON responses that OJS generates. I’d suggest making sure that all warnings etc. are directed to log files, not the browser. (This is recommended for production use in any case.)
Regards,
Alec Smecher
Public Knowledge Project Team
; Display a stack trace when a fatal error occurs.
; Note that this may expose private information and should be disabled
; for any production system.
show_stacktrace = Off
; Display an error message when something goes wrong.
display_errors = Off
; Display deprecation warnings
deprecation_warnings = Off
; Log web service request information for debugging
log_web_service_info = Off
I also have this for localization settings, is that correct? Before I had them like this, but maybe with the update to the 3.x version it should be “utf-8” instead of “utf8”?
; 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
The settings that define where log messages are sent are in your PHP configuration (php.ini), not your OJS configuration (config.inc.php). Depending on your hosting provider’s setup, the details of configuring PHP will differ.
Regards,
Alec Smecher
Public Knowledge Project Team
We can confirm whether this is the problem or not by inspecting the AJAX request/response. Try using a developer tool like Firebug for Firefox to look at the individual requests and responses between your browser and OJS; see if you can identify the one that corresponds to the error message. Take a look at the JSON response from OJS and see whether there is something unusual there (like a PHP error message).
Regards,
Alec Smecher
Public Knowledge Project Team
OK I completely deleted all files (except public folder and files) and re-uploaded everything (the new OJS files). Imported back he old db dump. And upgraded again.
The problem with the tab Masthead not loading is solved.
But I have a new problem: all cover images for the journals are gone (not visible, they are still on the server). With the previous upgrade (plus the test upgrade I did locally on a server) this did not happen.
Sorry I’m making it hard for you to help here, but I’ve been working on this upgrade for 10 hours now and it’s still giving me problems.
Glad to hear one part of it’s resolved, but generally speaking it’s better to stick with a set of conditions and debug it than to start again from scratch and potentially introduce other problems. Sticking with a line of investigation is easier for me to follow and will keep this forum organized as a knowledge base.
Have you looked at file permissions on the public files directory (and its contents)? If those have inadvertently changed, it might be causing the requests for the cover images to be denied. I’m not sure what would cause one upgrade to fail in this regard when the others have succeeded.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher I understand. But debugging is difficult and time consuming and sometimes a single file not correctly transferred in an FTP upload causes these hard to track problems, so a complete redo does work sometimes.
The file permissions haven’t changed. But I do have the option of correcting file permissions from within the control panel of the webhost. I’ll try that.
The problem is that the image is not even in the HTML source. This is showing up in my local version but is missing on the live website:
OK finally have it working. Unfortunately I can’t tell why.
What I did now was export the -local- db which I had upgraded locally. And imported that db dump on the live server. Now everything works. So it seems the remote server has something which prevents the upgrade process to work properly.