A client with a huge Arabic news website called us on April 26th (the day Joomla 3.7 was released) and told us that he’s not able to save articles after updating to Joomla 3.7. He told us that article saving was timing out, and urged us to take a look.
As usual, we obliged. We started our investigation by checking whether the issue is caused by one of the 5 reasons we listed in an earlier post. Unfortunately, it was none of them.
We then went to testing the website, and we noticed something odd: the problem was only happening when there is a lot of Arabic content in the article, because when we reduced the article’s content to a few Arabic sentences, the saving process went smoothly. When the article’s content was left as it was, the saving process was timing out. This gave us an idea:
- We reduced the PHP maximum execution time to 30 seconds by creating a local .user.ini file at the root directory of the Joomla website and adding the following to it:
max_execution_time = 30;
-
We changed Error Reporting to Maximum under System -> Global Configuration -> Server.
-
We tried saving the article (using the original, long Arabic content).
-
We saw the following error after 30 seconds:
Fatal error: Maximum execution time of 30 seconds exceeded in /home/[cpanel-user]/public_html/libraries/vendor/joomla/string/src/phputf8/mbstring/core.php on line 41
Aha! We had a lead! We didn’t know what the problem was exactly but we had a lead. So, we opened the file core.php which is located under the libraries/vendor/joomla/string/src/phputf8/mbstring and we checked the problematic line, and it was this line…
return mb_strpos($str, $search, $offset);
which was located in the following function:
function utf8_strpos($str, $search, $offset = FALSE){ if ( $offset === FALSE ) { return mb_strpos($str, $search); } else { return mb_strpos($str, $search, $offset); } }
Hmmm! We felt, for some reason, that there was an infinite loop going on, and so we added a couple of lines to write the following variables $str, $search, and $offset to a file (we did it just before the problematic line), and, then we tried to add the article. Unsurprisingly, the file was several megabytes large after our test (mostly the same content being repeated over and over), so there was definitely an infinite loop going on.
Now, if you look at the above function, you will notice that it’s not recursive and doesn’t have any kind of loop, so, it must be the function calling it that is running into an infinite loop. Luckily, PHP has a very sweet method to know which function is the caller function, which is this line:
echo('Calling function: '.debug_backtrace()[1]['function']);
So, we used the above line to know which function was the caller function, and it was the function strpos which is located under the libraries/vendor/joomla/string/src folder. The following is the implementation of the strpos function:
public static function strpos($str, $search, $offset = false) { if ($offset === false) { return utf8_strpos($str, $search); } return utf8_strpos($str, $search, $offset); }
As you can see, the strpos function is not recursive, which means that the problem is caused by whichever function is calling it (or whichever function is calling the function calling it, or whichever function is calling the function that is calling it, OK – you get the idea!), ultimately, our investigation pointed us to the cleanTags function which is defined in the input.php file, which is located in the libraries/joomla/filter folder. So we thought, let’s compare the input.php file from the Joomla 3.7 website to the input.php file from the Joomla 3.6.5, and so we did, and, to our non-surprise, there were substantial differences between the two files.
Our next step (yes, you’ve guessed it!) was to replace the input.php file on the Joomla 3.7 website with one from a Joomla 3.6.5 fresh install. So we did that, and we tested the content adding (in Arabic) afterwards, and it worked, even when the content was very large! Hooray!
But why was the problem happening on Joomla 3.7?
Unfortunately, we can only say that the problem is caused by the cleanTags function (and possibly other functions called by cleanTags) in the aforementioned input.php file. We can’t give more details because we weren’t commissioned by the client to investigate the issue further (we can’t expect the client to pay for debugging Joomla errors).
We hope that you found this post useful. If you are running into a timeout when adding Arabic content (or any other UTF-8 content) to your Joomla 3.7 website, then try replacing the input.php file we mentioned above with the one from a Joomla 3.6.5 website. If that doesn’t work, then please contact us. We are always here to help, we will always find a solution, and our fees are extremely affordable!
Guys, you’ve saved my life. Brilliant solution. Thank you.
I have the same issue, not an issue with small articles but, large articles seem to not like the slanted type of apostrophes and emdashes, when I change to the straight apostrophe (DOS type) and hyphen instead of emdash I can save my articles.
Rob
Hi Attila,
You are most welcome. Just out of curiosity, which language(s) do you have on your Joomla website?
Hi Rob,
Odd – thanks for pointing that out. Hopefully your comment will help others with the same problem.