To make a long story short:
If your WordPress webpage delivers a HTTP 500 error page on mobile devices and you have the WP-Statistics plugin installed, check the setting of the PHP memory limit. If it is set at a low value like 32 MB or similar then increase it to a reasonable size like 64, 96 or 128 MB.
But now to the background story.
As I collected ideas about the topics for this blog, I did not expect that I will write any post about website creation and web programming at all. But due to my recently gained experiences with creating this website with WordPress as a complete Newbie in WordPress, I want to share some aspects. So, this post will be a little off topic.
The main reason for writing this post is mentioned in the headline. My page delivered a HTTP 500 error page (Internal Sever error) if someone tried to browse it via a smartphone. After reloading the site, it worked. But anyway, the first what the visitor saw was a dead / broken / unavailable page. That is … probably not so good. 😉
First, I discovered the issue by myself by accident as I wanted to check the appearance on mobile devices. I thought it was a temporary issue of my host service provider. Although the strange thing was, that the page worked absolutely fine when I used any browser from a desktop computer. But then a half day later I heard from others that they still have this issue on my page when they go there via a smartphone.
So, I nearly opened a support ticket at my host service provider already. But then I found the hint in the net, that a newly installed WordPress plugin could be the root cause for a HTTP 500 error.
Ah, didn’t I just yesterday install the WP-Statistics plugin for see how often my page is visited and which parts?
Just for fun I disabled it and browsed to my page on the smartphone. Everything was loaded fine.
To prove it for sure, I enabled the plugin again and guess what happened? Right, the HTTP 500 error page was shown again.
So, the plugin is the reason? I started to wonder, because it is the most often installed plugin for visitor statistics with over 800k installations. And my page is not very big, complex or somehow special in the term of web programming techniques.
It really took me a while to find something but then I stumbled upon a 2 sentences message from a user who also mention a HTTP 500 error code and said something about increasing the PHP memory limit.
Ok?!?!? Can something special like this be the reason on my standard and ready to use setup? So, I had to figure out where I can find this setting and how to change it (for CPanel users: Something with PHPini in the name).
I found the setting, saw that it was set to incredibly low 32 MB (are we still in the 90’s??) and increased it to unbelievable 64(!) MB(!) (wow, I just doubled my memory!!!).
I enabled the plugin and everything worked fine! Puuuhh!
But wait a minute…
We are in 2022.
Do I really have to manual configure the memory settings for my web page? With a trial-and-error method?
I think there is a lot of room for improvements.
And that is my overall impression for the whole area so far. I don’t want to blame the WP-Statistics plugin in this case. It is related to the whole machinery.
On the one hand it is really awesome to see how “pluginable” the whole WordPress framework is. The abilities of the plugins are nearly endless because they can hook up everywhere at every place with everything. And also, how the different parts of things (PHP, Database, WordPress, etc.) just work together and were ready to use with one click is really great.
But then on the other hand everything is very loose connected. One plugin could disturb the other just because the way of hooking up will destruct the other plugin and vice versa. One adds a new entry in the main menu for its setting, the other creates a new sub menu nested elsewhere. Some change the top status bar of WordPress with completely new visual gadgets, others even add a half custom page at the bottom of each page in the edit view. They are even creating new columns, tables and queries in the database or double up the internal directory layout (e.g., for multi-language pages).
But at all I am very happy what I can do with it and the things available are just awesome!
However, after a while you will notice that there are things rising up which cannot be solved with the available options.
For example, I had to:
- Manual change html (adding meta tags to the head element, but it would need just 4 strings in the database to offer a handy solution for it.)
- Manual modify PHP code for customize the last line of the footer.
- Manual modify CSS code (well, the CSS attribute hell is a story by its own. 😉)
- Add custom style sheet code for overwrite or add style settings.
- Modify JavaScript code for make the syntax highlighter work with TeaScript code and fix some aspects for C++.
- ….
I did not expect before that I have to dive into those number of different aspects of web programming to make my own page look, feel and work like I want. And I just started…
Well, if this last on, I will become a web programming expert soon, although I wanted to focus mainly on C++. *laugh*