Hello, I am preparing to upgrade my Journal to OJS 3 from 2.4.8.1. To do that the network engineer migrated the journal completely to a new server for better performance and now as the system adminsitrator I am left with the upgrade. The problem is I can’t do that because (see picture).
I am really confused as of why this happend. I have a different server where I have a copy of the sql from before the migration, uploaded it there and it seems to be displayed normal but temporarly, reverting to this truncated form after some time (aprox 1 day) without any further changes. If i check the sql file on the server i have all OK.
Sry if repost, I didn’t found any other topic related.
Unfortunately i don’t have an SSH key so i’m only using the cPanel, the problem however is not when upgrading. I didn’t upgrade yet thinking that it might be best to try and do it only after the Journal is clean of truncations. Is this in any way perhaps related to the UTF-8? I am affraid i have limited understanding on how the server interprets the php and displays the Journal online. Also I don’t have any errors on the server except for :
[30-Jun-2018 09:45:01 Europe/Helsinki] PHP Warning: require(/home/notulae/lib/pkp/includes/bootstrap.inc.php): failed to open stream: No such file or directory in /home/notulae/public_html/lib/pkp/lib/tinymce/jscripts/tiny_mce/plugins/jbimages/integratePKP.php on line 27
[30-Jun-2018 09:45:01 Europe/Helsinki] PHP Fatal error: require(): Failed opening required ‘/home/notulae/lib/pkp/includes/bootstrap.inc.php’ (include_path=’.:/usr/lib/php:/usr/local/lib/php’) in /home/notulae/public_html/lib/pkp/lib/tinymce/jscripts/tiny_mce/plugins/jbimages/integratePKP.php on line 27
My personal opinion due to the date of the error is that it doesn’t have anything to do with the current problem.
Could you double check/compare your encoding in the OJS config.inc.php file earlier and now, as well as the server DB settings for the encoding earlier and now?
Thanks for the reply! I will return as soon as I have some answers, the old server right now is pretty hard to reach sadly Hopefully i can still access its settings somehow.
Upon investigating the config.inc.php file from before and after the migration is identical. However, the server settings from the previous server and from the actual serever are different.
I can see that the values are different but I am not entierly sure how to interpret them. If I were to change the <<character_set_database | latin1>> to <<character_set_database | utf8>> would that fix the problem? Or should I change all the values as they were before?
mysql> SHOW VARIABLES LIKE “character_set_database”;
±-----------------------±-------+
| Variable_name | Value |
±-----------------------±-------+
| character_set_database | latin1 |
±-----------------------±-------+
1 row in set (0.00 sec)
NEW SETTINGS
mysql> SHOW VARIABLES LIKE ‘character_set_%’;
±-------------------------±-------+
| Variable_name | Value |
±-------------------------±-------+
| character_set_client | utf8 |
| character_set_connection | utf8 | | character_set_database | utf8 | ← Truncated text
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
±-------------------------±-------+
7 rows in set (0.00 sec)
mysql> SHOW VARIABLES LIKE “character_set_database”;
±-----------------------±------+
| Variable_name | Value |
±-----------------------±------+
| character_set_database | utf8 |
±-----------------------±------+
1 row in set (0.00 sec)
What are your encoding settings in config.inc.php?
One possibility is to reconfigure your new database character sets to be identical to the old ones (you may need to consider more than just the character_set_database change); another possibility is that you may just be looking a discrepancy with a successful data load into the new databases’ expectations, but your config.inc.php isn’t set to read it correctly.
; 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 = Off
; Database storage character set
; Must be set to “Off” if not supported by the database server
database_charset = Off
; Enable character normalization to utf-8
; 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
; (Note that this is generally no longer needed, as UTF8 adoption is good.) charset_normalization = Off
My opinion is that is something in regards to the server encoding settings. Problem is that while truncated as the Journal is now, some areas are blank (i.e. the journal description section) but on the Journal homepage the description is there. After adding only 1 word in that section, the entired Step 5. Customizing the Look went blank and everything on the journal homepage dissapeard except for the 1 corrected word.
Bottom line it seems like the informaton is there (truncated) but also when checking the specific section in the Journal Management > The Look is not there and all the fields are empty except for the pictures.
Right now I am a bit confused if I should start tempering with the server encoding settings or start correcting the Journal manually (it will take ages since we go all the way back to 1965)…
My approach here would be to drop the database from the new server, reconfigure all character_set_% settings on the new server to match the old server, then reload the data from the backup of the old server onto the new server. This would be the foundational test just to confirm functionality. If it works, you then then choose to look at the individual configuration settings in detail.
Hopefully i can still access its settings somehow.