Welcome to ProjeQtOr new Forum. We migrated old forum to the new website.
You will find all your posts here, with your usual account.
Just one point : you’ll have to reinitialize your password. Use “Lost password” feature.
Hello,
today we changed our application server from a virtual machine to a real server (and the database is on its own server).
So we set up the new server and copied the whole /var/www/projeqtor/ directory to the new server (and we didn't change anything on the database server).
At the same time, our IT decided to also upgrade to 6.4.2
Issue #1 :
The software is working correctly except we now have UTF8 issues as "enregistré" instead of "enregistré". What's worrying me is that the data itself looks incorrect in the database 🙁 (obviously, everything was correct until then).
When I look to the log file I can see following lines :
** ERROR ** [V6.4.1] mbstring module not enabled (mb_check_encoding not existing) : install module and unable module in php.ini
** ERROR ** [V6.4.1] Impossible to load class ZipArchive
=> Not found in ../model/custom/ZipArchive.php
=> Not found in ../model/ZipArchive.php
=> Not found in ../model/persistence/ZipArchive.php
** ERROR ** [V6.4.1] Impossible to load class DOMDocument
=> Not found in ../model/custom/DOMDocument.php
=> Not found in ../model/DOMDocument.php
=> Not found in ../model/persistence/DOMDocument.php
Issue #2 :
I can't say I saw it, but I guess those lines in the log file look quite incorrect :
** ERROR ** [V6.4.2] Exception-[42S22] SQLSTATE[42S22]: Column not found: 1054 Unknown column 'work.rate' in 'field list'
** ERROR ** [V6.4.2] For query : select work.id as id, T1.fullName as nameResource, work.idResource as idResource, T2.name as nameProject, work.rate as rate, work.idle as idle,work.idProject as idproject from work left join resource as T1 on work.idResource = T1.id left join project as T2 on work.idProject = T2.id where 1=1 and idResource in (4, 6, 25, 13, 10, 9, 14, 18, 8, 15, 31, 12, 32, 5, 27, 7) order by work.id desc
** ERROR ** [V6.4.2] Strack trace :
** ERROR ** [V6.4.2] #0 Sql->query called at [/var/www/projeqtor/tool/jsonQuery.php:701]
[EDIT]
I'm afraid I have a part of the answer: my IT installed PHP 7 on the new server ... :angry:
First issues are not linked to PHP7 but to new server that does not include required module.
Check prerequisites on readme file.
Log show missing :
- mbstring
- zip
- domdocument
Then charset issue may come from migration process that moved to correct UTF8 .
Try and add in parameters.php :
$enforceUTF8 = '1';
OK for prerequisites, my IT installed it just after the messages.
the UTF8 line in parameters.php doesn't seem to change anything (at least now, maybe it could have changed something during the migration process).
It seems that only the short name fields suffered of this UTF8 issue: indeed, the descriptions, results and so on (rich text fields) does not have any problem. I can't verify the db right now, but I guess they have the same type.
Well, I manually corrected the important lines. It's not such a big issue in my case.
It seems that only the short name fields suffered of this UTF8 issue: indeed, the descriptions, results and so on (rich text fields) does not have any problem.
It's because they are html encoded.
the UTF8 line in parameters.php doesn't seem to change anything (at least now, maybe it could have changed something during the migration process).
EnforceUTF8 will have no effect on migration as you don't import dump from ProjeQtOR.
Sure it is the migration process that brought the issue.
Check new accentuated characters in database (with phpMyAdmin for instance) : are they correctly stored ?
Check accentuated characters from migration in database : are they correctly stored ?
This will show you if your database correctly stores UTF8.
Maybe you'll have to convert your dump file before importing.
Hello,
the database shows the exact same thing as I can see in the gui :
- If the displayed field is incorrect : the data in the db is incorrect
- If the displayed field is correct (I manually corrected it) : the data in the db is correct
such fields in the db are now defined as follow (eg for the name field of actions):
name varchar(100) utf8_general_ci
hope this helps.
I corrected almost every weird characters in my database, so I guess I shouldn't face this issue anymore.
So it is import that fails.
Maybe you shoud convert to UTF8 the exported file.