Are those errors in suitecrm.log happening at the time of an upgrade?
What do you have in upgradeWizard.log?
What did the “echo ini_get” command I gave above say?
1 Like
Here you have the upgradeWizard.log
Tue, 25 Jul 2017 08:52:51 +0000 [UpgradeWizard] - Upgrade started. At start.php
Tue, 25 Jul 2017 08:52:51 +0000 [UpgradeWizard] - at unlinkUWTempFiles()
Tue, 25 Jul 2017 08:52:51 +0000 [UpgradeWizard] - finished!
Tue, 25 Jul 2017 08:52:51 +0000 [UpgradeWizard] - resetting $_SESSION
Tue, 25 Jul 2017 08:52:55 +0000 [UpgradeWizard] - setting session variables...
Tue, 25 Jul 2017 08:52:55 +0000 [UpgradeWizard] - [At systemCheck.php]
Tue, 25 Jul 2017 08:52:55 +0000 [UpgradeWizard] - Starting file permission check...
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Finished file permission check.
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Starting database permissions check...
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Checking CREATE TABLE permissions...
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Checking INSERT INTO permissions...
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Checking UPDATE TABLE permissions...
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Checking SELECT permissions...
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Checking DELETE FROM permissions...
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Checking ALTER TABLE ADD COLUMN permissions...
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Checking ALTER TABLE CHANGE COLUMN permissions...
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Checking ALTER TABLE DROP COLUMN permissions...
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Checking DROP TABLE permissions...
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - No permissions errors found!
Tue, 25 Jul 2017 08:53:06 +0000 [UpgradeWizard] - Finished database permissions check.
Tue, 25 Jul 2017 08:53:11 +0000 [UpgradeWizard] - setting session variables...
Tue, 25 Jul 2017 08:53:11 +0000 [UpgradeWizard] - At upload.php
Tue, 25 Jul 2017 08:53:11 +0000 [UpgradeWizard] - finding new files for upgrade
Tue, 25 Jul 2017 08:53:11 +0000 [UpgradeWizard] - *** UW using [ ] as source for patch files.
Tue, 25 Jul 2017 08:53:32 +0000 [UpgradeWizard] - setting session variables...
Tue, 25 Jul 2017 08:53:32 +0000 [UpgradeWizard] - [At cancel.php]
Tue, 25 Jul 2017 08:53:32 +0000 [UpgradeWizard] - cleaning up files and session. goodbye.
Tue, 25 Jul 2017 08:53:32 +0000 [UpgradeWizard] - at unlinkUWTempFiles()
Tue, 25 Jul 2017 08:53:32 +0000 [UpgradeWizard] - finished!
Tue, 25 Jul 2017 08:53:32 +0000 [UpgradeWizard] - resetting $_SESSION
Tue, 25 Jul 2017 08:55:43 +0000 [UpgradeWizard] - setting session variables...
Tue, 25 Jul 2017 08:55:43 +0000 [UpgradeWizard] - -----------------------------------------------------------------------------
Tue, 25 Jul 2017 08:55:43 +0000 [UpgradeWizard] - Upgrade started. At start.php
Tue, 25 Jul 2017 08:55:43 +0000 [UpgradeWizard] - at unlinkUWTempFiles()
Tue, 25 Jul 2017 08:55:43 +0000 [UpgradeWizard] - finished!
Tue, 25 Jul 2017 08:55:43 +0000 [UpgradeWizard] - resetting $_SESSION
Tue, 25 Jul 2017 08:55:47 +0000 [UpgradeWizard] - setting session variables...
Tue, 25 Jul 2017 08:55:47 +0000 [UpgradeWizard] - [At systemCheck.php]
Tue, 25 Jul 2017 08:55:47 +0000 [UpgradeWizard] - Starting file permission check...
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Finished file permission check.
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Starting database permissions check...
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Checking CREATE TABLE permissions...
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Checking INSERT INTO permissions...
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Checking UPDATE TABLE permissions...
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Checking SELECT permissions...
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Checking DELETE FROM permissions...
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Checking ALTER TABLE ADD COLUMN permissions...
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Checking ALTER TABLE CHANGE COLUMN permissions...
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Checking ALTER TABLE DROP COLUMN permissions...
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Checking DROP TABLE permissions...
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - No permissions errors found!
Tue, 25 Jul 2017 08:55:58 +0000 [UpgradeWizard] - Finished database permissions check.
Tue, 25 Jul 2017 08:56:03 +0000 [UpgradeWizard] - setting session variables...
Tue, 25 Jul 2017 08:56:03 +0000 [UpgradeWizard] - At upload.php
Tue, 25 Jul 2017 08:56:03 +0000 [UpgradeWizard] - finding new files for upgrade
Tue, 25 Jul 2017 08:56:03 +0000 [UpgradeWizard] - *** UW using [ ] as source for patch files.
concerning the suitecrm.log the last logs are from yesterday and have nothing to do with the failed upgrade attempts. I just tried a new upgrade and the fail/error is not registered at suitecrm.lob.
As for the 'echo ini_get" where do I check what it say, please?
There are lots of threads in these forums with people having that message in upgradeWizard.log, where the source dir is empty:
*** UW using [ ] as source for patch files.There should be a path inside those brackets… but there have been many attempts and some solutions, but not a single cause that I can recommend to you…
The echo should simply send the resulting text out on the screen, so unless it’s returning an empty string, you should see it on the top of your screen when accessing index.php.
You can also create a simple PHP file just to echo that value, and call it from the browser (not from the command-line PHP, that’s a different thing).
1 Like
many thanks ptr! 
i see now that the issue is really a bug on SuiteCRM. No problem. I installed SuiteCRM using softaculous. Is there any way to upgrade it manually without losing the configurations I applied to it up to today? I can for instance upload the SuiteCRM upgrade zip file to the proper upgrade folder in the server, but what are the next steps from that?
Any advice is welcome.
Rgs
@ptr seems like Apache is not compatible with zlib https://httpd.apache.org/docs/current/mod/mod_deflate.html while zlib module is one of the prerequisits for installing SuiteCRM. Perhaps this have to do with the upgrade issue?
That document you linked does not say that Apache is incompatible with zlib.
There are thousands of installations of SuiteCRM (the majority of them, actually) running on Apache.
I don’t think this is a SuiteCRM bug, I think you have a problem with your PHP configuration. But I would like to identify it and try to make SuiteCRM give a better error message.
Try playing with the modules that you can turn on and off in your Cpanel, there might be more than one module for compression, one that works, and one that doesn’t.
You can also try changing PHP version, sometimes that solves problems “by miracle”. Use PHP 7.0 if you can, but try also other versions.
1 Like
Is there any way I can PM you? Could not find where.
No, there is no way to PM… but I sort of feel more comfortable that way, there are limits to what I can help each individual person in this forum… I cannot give private support to everyone, it would be impossible. I’m sure you’ll understand.
1 Like
Well, I was thinking about paid support. If you change your mind, get back in touch here.
Many thanks!
I did two jobs of remote paid support related to SuiteCRM, both small.
One I got paid, the other one it’s been two months and I’m still waiting…
I don’t mind considering these offers, but my holidays start on Friday, I’m not taking up anything now.
If you search for “SuiteCRM” on Upwork, you’ll find people there, some of them seem to have good reputations, and they charge less than me… I’m not very motivated for this kind of work, so I charge more to keep customers away : - )
And there’s also the guy from Urhdva tech (http://urdhva-tech.com/) he writes lots of add-ons for SuiteCRM and SugarCRM, he does consulting.
No problem! It is understandable. Have nice vacations! Thank you for indicating Urhdva.
Hello,
for the sake of helping others, the solution for those who run their websites with Apache 2.4, WHM 64 and PHP 7.0 is to go (or ask your hosting provider) to WHM>PHP ini Editor and check if both
upload_max_filesize = 10M
post_max_size = 10M
are set to more than the filesize you intend to upload (substitute the 10 for any size you need).
Do not try to set this through SSH by hardcoding php.ini because there are several such files in the server and even with a command line in SSH requesting information about which of them is being loaded, I could not find the right php.ini to modify.
Do it through WHM and it will fix the issue in 3 minutes. It works for SuiteCRM and also Wordpress upload limits.
Rgs
IM