I have just installed suiteCRM on a freshly purchased shared Linux host, said by the seller (A2Hosting) to be suitable for suiteCRM. I have experience of installing/maintaining/running Wordpress on a shared host but no previous experience with suiteCRM. I used Softaculous for the install and mostly accepted defaults; it installed 7.10.11. I was happy because it all seemed to work. I added users and a couple of accounts; I managed to hook it our to our email. Everything looked good. And then I thought I would Import some data. My first move was to attempt to download the import template. That led to a server error. Then I though I would attempt to export some data. A colleague had entered a couple of Accounts by hand so I tried to export the Accounts - that led to a server error.
Using cPanel I managed to turn on PHP error reporting and found this:
[07-Dec-2018 06:48:30 America/New_York] PHP Notice: Only variables should be passed by reference in /home/koreahos/public_html/include/export_utils.php on line 526
[07-Dec-2018 06:48:30 America/New_York] PHP Notice: Undefined variable: where in /home/koreahos/public_html/include/export_utils.php on line 531
[07-Dec-2018 06:48:30 America/New_York] PHP Notice: Undefined variable: where in /home/koreahos/public_html/include/export_utils.php on line 532
[07-Dec-2018 06:48:30 America/New_York] PHP Fatal error: Allowed memory size of 805306368 bytes exhausted (tried to allocate 1503358064 bytes) in /home/koreahos/public_html/include/database/MysqliManager.php on line 251
The PHP version is 7.0.32
I found the diagnostic utily in suiteCRM and had trouble until I unticked “MySQL - Configuration Table Dumps” - a permissions issue? related?. Everything else downloaded, but it seemed like a lot of stuff to dump in my first post
So much seems to work, but if I can’t Import/Export I can’t use it so I have to find a solution. Do I try randon PHP version changes? Is 7.10.11 a bit new and therefore not so debugged? I guess it will likely turn out to be a permissions/PHP config error. I would be very grateful if someone could point me in the right direction.
Memory errors are solved by increasing memory_limit in your PHP. I normally use 512MB. Which value do you have?
Make sure you are looking at the correct php.ini, check that from Admin / Diagnostics / phpinfo.
Restart your web server after any changes to php.ini.
Then tell me if this changes anything, and if there are any errors in suitecrm.log.
Thanks for the reply.
The limit quoted in phpinfo().html as generated from the diagnostics, is 768M. The error message says 805306368 which is the same thing. I rather assumed that the silly size allocation attempt (~1.4G) was some sort of fall-out from the first problem mentioned, the “Undefined variable”.There are only two accounts to export.
I used phpMyAdmin to have a look at and download the Accounts table as SQL. There didn’t seem to be any issue doing that.
Yes I agree with you that those memory values are absurd, especially if you don’t have any huge tables. The problem can be something different.
It would be nice to have also the contents of suitecrm.log at the same time these PHP errors are showing. If you go in Admin/System settings and raise your log level to DEBUG, you should get a message like this near that point: "Export Where Clause: "
Thanks for the advice. I set the log-level to Debug, selected Accounts, marked all (2) and used bulk action/export which generated the error. That log sure grows quickly! This excerpt from the PHP log gives a timestamp for the problem:
[08-Dec-2018 07:51:19 America/New_York] PHP Notice: Only variables should be passed by reference in /home/koreahos/public_html/include/export_utils.php on line 526
[08-Dec-2018 07:51:19 America/New_York] PHP Notice: Undefined variable: where in /home/koreahos/public_html/include/export_utils.php on line 531
[08-Dec-2018 07:51:19 America/New_York] PHP Notice: Undefined variable: where in /home/koreahos/public_html/include/export_utils.php on line 532
[08-Dec-2018 07:51:19 America/New_York] PHP Fatal error: Allowed memory size of 805306368 bytes exhausted (tried to allocate 1503358064 bytes) in /home/koreahos/public_html/include/database/MysqliManager.php on line 251
I have attached the suitecrm.log file. We are small and have not used a CRM system before, so are at the exploring stage. The two accounts were entered by a colleague having a look at what is possible. He was using the normal web interface as a normal user (not admin), but is it possible that a field vital to the operation of export has not been filled in? Do you think that the error thrown by my earlier attempt to download an import template, using the link provided for the purpose, is related, or just a red herring?
Thanks taking the trouble to help
I don’t find anything suspicious in your suitecrm.log. Not much is happening there at that time. I don’t see how it can be requiring a huge chunk of memory. It doesn’t seem to be in an infinite loop; it doesn’t look like it’s doing any large operation…
Do you want to try upgrading to PHP 7.2? Version 7.0 is about to be deprecated, and maybe this is a PHP bug. I think it’s worth trying, then if it doesn’t work we’ll try something else (I’ll have to think what!)
First, sorry for the slow reply - many interruptions today.
I have a solution - for now.
In an odd moment yesterday I was wandering round looking for inspiration. I was looking at the database with phpMyAdmin and I looked at the version information in the starting page which went like this:
Server: Localhost via UNIX socket
Server type: MariaDB
Server version: 10.2.18-MariaDB-cll-lve - MariaDB Server
Protocol version: 10
Server charset: UTF-8 Unicode (utf8)
Database client version: libmysql - 5.1.73
PHP extension: mysqliDocumentation curlDocumentation mbstringDocumentation
PHP version: 5.6.30
Version information: 4.7.7
That suggested (though I may be in error) that phpMyAdmin (launched from cPanel) was using PHP 5.6 even though the cPanel PHP version setting for the site was PHP 7.0. So I thought, phpMyAdmin works, I’ll try PHP 5.6 for the cPanel setting. Suddenly everything worked.
Later, I caught sight of your message suggesting PHP 7.2 i.e. pretty much the same idea but moving forward rather than backwards. So I tried that. The error returned. I tried a screen capture of the PHP extension list and options for both 5.6 and 7.2 but did not see anything obvious. One had mysqInd ticked, the other did not, but changing this setting made no difference for good (fix 7.2) or bad (break 5.6). However, I don’t really know where to look and there are too many places to guess.
So my only concern, apart from wanting to understand on principle, is that there may be pressure in future times to move to a more recent version of PHP.
I really appreciate you trying to help me out and whilst the pressure is off for now, if you have any further suggestions I am happy to try them within reason. The route I have taken (Softaculous install on a shared host) seems like a normal thing to do, so I might expect others would hit the same problem.
If I was in your position I would simply go with PHP 7.2, you get a safer PHP, with more features and better performance. No reason not to.
Then you have to make sure that version is used consistently, and that it has all the required modules activated.
For example, on Ubuntu I install these for PHP 7.2:
apt install zip unzip php-mbstring php7.2-mbstring php-gettext php-xml php7.2-zip php7.2-imap php7.2-gd php7.2-curl php-gd phpmyadmin
You can look for their equivalents in CPanel.
If you still can’t get it to work, I would suspect an actual bug, and we could try reproducing it in a different installation. Maybe it’s something specific in your data, we could try to reproduce that elsewhere.
The reason not to go with 7.2 for now is that suiteCRM is then slightly broken in that I can’t export, which makes me worry other things I haven’t tried yet will also not work. I don’t want to undermine my colleagues confidence at this early stage by having them run into mysterious problems. On the other hand, having set PHP5.6 everything seems to work, even if I don’t know why.
So looking at the non working 7.2 extension list and comparing it with your direct installs
mbstring, imap, zip gd are ticked
gettext is included in the configuration given in phpinfo()
xmlreader xmlrpc and xmlwriter all ticked (no other xml options I can see)
curl is in phpinfo() and said to be enabled
phpAdmin is available to me via cPanel (but with versions as described above). Does suiteCRM make any use of phpMyAdmin? I had assumed not.
One other clue (maybe). While collecting diagnostic information from within suiteCRM I discovered that the option
“MySQL - Configuration Table Dumps” (the only one ticked) does not complete under PHP7.2 - at any rate I gave up after ~10minutes. whereas there seems to be no problem under PHP5.6.
I have attached two versiosn of phpinfo(), one generated under each version, in case this is useful. Thanks again.
phpMyAdmin is optional, it’s just for your use as an Administrator. But it is extremely useful, in my experience.
I wonder if you’re seeing this bug?
phpMyAdmin is indeed useful. I have been using the version of phpMyAdmin made available from cPanel, but that does appear to use an older copy of PHP, even when I have used the cPanel PHP version selector to choose 7.2 (see above).
I have looked at the link you suggested, but it seems to relate to filtering on an additional field. The export fails for me in all circumstances. It fails if I select only one account and try to export that; export of all accounts fails; it also fails if I try and export user or contact information. All Exports fail under PHP 7.2 but work ok when I have selected PHP5.6
I wondered if it was something to do with making a file for download, but the absurd memory allocation attempt seems to take place earlier in the code, so far as I can tell. Also, I can run the diagnostic and download the resulting file, which seems like a similar process from the point of view of making a file for download by the browser.
So my question is, what is different about database access as a precursor to exporting data, as opposed to all other database access which seems to work (given limited use with a new installation).
You would know more than me but it feels like a bug in the PHP somewhere of a type that is dealt with more gracefully under one version of PHP (presumably the MySQLi part) than another. However, the major objection to this is that I don’t see anyone else report the same problem.
The alternative is some subtle configuration problem. Working with a shared server I have very limited means to mess with the configuration and frankly I’m not competent to do so anyway. If I could reproduce the problem with a small isolated code fragment, I guess I could put in a support ticket with the hosting provider, but I have no idea what is special about Export.
I can’t reproduce this, my Accounts export works fine with PHP 7.2.
Maybe there’s something peculiar about your data…
A fair question. Though I would have thought it should be difficult to enter bad data if only using the web interface.
So I’ve just tried to test it. I entered a fresh imaginary account and exported it while using PHP5.6, having just selected that one new account from the list. I then switched to PHP 7.2 and confirmed that attempting to export the same account caused a crash. I have attached the successful export file in case you have the energy to try it with your suiteCRM 7.10.11 with PHP7.2 system. My guess is that it won’t be the data, but it’s worth a try.
My guess is there must be something about my install/permissions/configuration that is different from yours in a bad way. The problem is so selective; so much works! I wish I knew how to find out what it is. I’ll be perfectly happy if you prove me wrong and it is the data.