7.14.4 - There was an error processing your request, please try again at a later time

šŸ’¬ General Discussion
1

Recently we began seeing the ā€œThere was an error processing your request, please try again at a later timeā€ error message (at the bottom it also says, ā€œIf this error persists, please have your administrator disable Ajax for this moduleā€) and Iā€™m struggling to make any sense of it. I have two sites both running SuiteCRM. Iā€™ll call them Sites A and B. They were both at 7.14.3 and were on two different servers, Site A still running on PHP 7.4, Site B on PHP 8.1. I moved Site A to the PHP 8.1 server and sometime around then the error started showing up. If it only happened on Site A, I might think it had to do with the move but itā€™s happening on both sites, including Site B, which wasnā€™t changed. I noticed that there was an security update available and upgraded both to 7.14.4 and also ran ā€˜composer update --no-devā€™ and while that was a good thing to do, it made no obvious difference. I even deleted the vendor directory and ran ā€˜composer install --no-devā€™. That seemed to fix things temporarily but then the error started to appear again. Likewise, running Quick Repair and Rebuild seems to fix things for a little while but then the error returns.

One very frustrating thing is that the errors seem to come and go. It will work for a while, then the error will show up. Later, the error goes away and things are working again. In addition to the error message, some modules are not always listed in the menu or some tabs for modules are missing. Then later both the modules are back in the menu and all the tabs will be there again. Itā€™s very hard to diagnose, as the problem comes and goes.

In the log files I see things like this:

[Fri Aug 23 14:53:10.058274 2024] [proxy_fcgi:error] [pid 3894:tid 140066064168704] [client 10.17.10.77:53944] AH01071: Got error ā€˜PHP message: PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /websites/SITE-B/www/cache/smarty/templates_c/fc6169268c1880b89bbc702d08172a989abbd49c_0.file.DetailView.tpl.php:1012\nStack trace:\n#0 /websites/SITE-B/www/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_66c62db4ca7ea8_29868753()\n#1 /websites/SITE-B/www/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#2 /websites/SITE-B/www/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render()\n#3 /websites/SITE-B/www/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(238): Smarty_Internal_Template->render()\n#4 /websites/SITE-B/www/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(116): Smarty_Internal_TemplateBase->_execute()\n#5 /websites/SITE-B/www/include/Sugar_Smarty.php(150): Smarty_Internal_Tā€¦ā€™, referer: https://SITE-B.EXAMPLE.com/index.php?action=ajaxui

Iā€™ve tried deleting vendor/smarty, running ā€˜composer install --no-devā€™ again (and then changing the ownership and permissions back to what they need to be). Once again, that seems to fix it for a little while but then things stop working again. Itā€™s very frustrating and I really donā€™t know what to do. The suitecrm.log file doesnā€™t have anything obvious, either.

To be honest, it feel like a resource issue on the web server. The server had 8GB of RAM and I doubled that, to see if it made any difference. It did not. I have the php memory_limit set to 256M, which seems like itā€™s enough for pretty much anything (and itā€™s been that way for a few years without this issue showing up until now). Iā€™ve tried changing the php-fpm max_children and related settings but nothing seems to help.

Any suggestions or pointers would be greatly appreciated.

Note that when running composer, I also get a long list of notices about classes that do ā€œnot comply with psr-4 autoloading standardā€ which is a little disconcerting, but I donā€™t know if itā€™s relevant or not.

Any suggestions would be very welcome, as Iā€™m somewhat at sea.

ā€“ Henry Hartley

2

Have you tried to set permissions and ownership of files?

3

configure_ajax_user_interface

4

Yes, all files are owned by apache and have proper permissions.

5

I disabled AJAX for the three primary modules and weā€™ll see if that makes any difference. It feels like a work-around rather than a fix, as it seems AJAX is supposed to work and itā€™s odd that thing behave as they do here. But maybe Iā€™m misunderstanding or overestimating AJAX support.

6

Donā€™t mess with AJAX settings, that is surely not the problem. I wish we would remove that message about AJAX from SuiteCRMā€¦

To reset your vendor directory to factory condition, you can download the full installer of your version of SuiteCRM, and get a neat vendor directory from the zip. This shouldnā€™t be necessary but it might be good as a diagnostic measure - that is the vendor directory that surely works well. If it doesnā€™t change anything, then at least you know for sure you should be looking elsewhere.

I recommend deleting the offending cached templates from cache/smarty/ (or just delete that whole subdirectory).
Also cache/themes/SuiteP subdirectory.

The templates will be cached again when you visit the screens. The point of this diagnostic is to see if youā€™re hitting a transient error (something wrong when the templates were cached, but not any more) or if itā€™s always generating things wrong.

7

I copied the vendor directory from the SuiteCRM-7.14.4.zip file (setting the ownership and SELinux context as appropriate) and deleted cache/smarty and cache/themes/SuiteP subdirectories as suggested. I also re-enabled AJAX on the three modules where I had disabled it. No change in behavior.

8

Is there any specific thing youā€™re doing in the UI when the problems occur?

Do you have custom code?

Has your system been running slow lately?

9

It seems to happen randomly when navigating around the site or entering or editing content. There is a lot of SuiteCRM that we arenā€™t using. In one of the two sites we have Hospitals, Contacts, and Calls, Emails, and Meetings and not a lot else. The other is the same but adds Facilities which are units within Hospitals. Clicking on a hospital, facility, or contact will often work but sometimes gives the error message. Sometimes tabs are missing from the hospital page. Sometimes Hospitals or Facilities is missing from the menu (but there other times).

There is no custom code except a small patch to insert a Byte Order Mark when exporting to CSV, since Excel seems to get confused otherwise.

No particular slowness. It either works or gives the error message as quickly as youā€™d expect.

10

Is it displaying error in log file or on your crm window? Which module? After which actions? Check browser console too for errors.

Also, in php.ini file. Check display errors:

;display_errors = on

11

Since the problem started when I moved one site onto the same server with the other site without any update to code on either system, we decided to move that site off onto its own server again. That seems to have fixed the problem on both sites. That leads me to believe that there is some temporary file, possibly PHPā€™s session file, thatā€™s being shared between the two sites when they run on the same server. Note that there is an overlap in users on the two systems. If it is the case that two SuiteCRM installations on the same server could be sharing a file, then Iā€™d suggest itā€™s a bug. But those more familiar with the inner workings would have to confirm that.

For now, the main thing is that the problem has gone away.

12

This is interesting to know, thanks for the feedback.

Regarding a SuiteCRM bug - I would say that running two SuiteCRM instances on the same server simultaneously is not a supported scenario. But I have done it without problems quite often, as long as I have separate ā€œeverythingā€: separate DB, separate files, separate web server virtual hosts.

Your case could probably have been solved with some clever web server configuration, but these things can get tricky and sometimes itā€™s just not worth the effort.

13

I did have separate DB, separate files, separate web server virtual hosts but what I didnā€™t have and what may need to added to your list, is separate users. I agree that with this in mind (and assuming that this is actually the source of the problem) it could be solved with some configuration changes. For now, it isnā€™t worth the effort, but itā€™s certainly worth knowing that this combination seems to be problematic.

1 Like