Plugin creates json and 505 errors

Hi Rogerio,

HTTP 505 would be a bit odd, as that specific code means that the server does not support the HTTP protocol version being requested by the browser. It usually indicates an out-of-date browser in use or a misconfigured proxy service, such as Cloudflare or Imunify360.

However, when I load the URL you provided, I get an error 500 (not 505), which is a generic server error, and I can see the site is not behind Cloudflare. With the information provided, I was able to verify some things, which may narrow down the possibilities of what could be causing the error:

• I can load https://greenlines-institute.org/license.txt successfully and consistently in multiple browsers. This indicates that your HTTP server, which appears to be Nginx on Plesk, is working fine for static files, but not PHP.
• This article indicates Plesk will return an error 500 is PHP hits an out-of-memory error, or if .htaccess or nginx.conf has errors, such as recursion.
• If it is an out-of-memory error, see this article on wp-config.php and check the PHP error logs, which would indicate an out of memory error from PHP and possibly a file responsible. The wp-config setting will only modify the limit of what is allowed for an individual request — it will not change the amount of physical memory available for all processes. This Plesk extension may be available and relevant for viewing memory usage. If not that, the CLI commands cat /proc/meminfo or free or vmstat or top might give you the relevant information.
• I mention memory in particular because if I try to load https://greenlines-institute.org/xyz, I am able to see a 404 page from the maintenance plugin, but only intermittently. Sometimes it indicates an error 500. This intermittent nature of the error again indicates a server under load or running out of memory. I can also load https://greenlines-institute.org/en/ with the same maintenance page displayed intermittently. As you indicated maintenance is active and Pods is inactive, this indicates a general memory issue with the server, infinite redirects, background tasks running on Cron, or a combination of such things.
• Regarding the connection to Permalinks and valid JSON responses: it is the case that Permalinks not being set will cause /wp-json/ requests, such as Gutenberg and various plugins, to not work. But again, the intermittent issue points to memory — either due to load or a memory leak due to recursion or aggressive queries or other errors in logic.

Based on those items, here are some things I would look for:

• First, check PHP and Nginx error logs to see if more relevant information, such as a path to a failing file, can be found. Also check Apache if it’s running behind Nginx.
• Check .htaccess and nginx.conf and Pods and WPML for any configurations that might result in infinite loops. e.g., non-default configurations, or URL mappings that might conflict with each other. For example, I see your home page redirects to /en/. If there is some HTTP server rewrite, custom post type, taxonomy, multisite, or other data structure existing in multiple plugin or code configurations that conflict in such a way as to cause an infinite loop, it would cause an out of memory error 500 very quickly. Query Monitor can be useful for analyzing what rewrite rules are registered, for example. It will also tell you how much time, memory, and how many database queries occur for a given page load. Keep in mind this metric is for one load of WordPress — the server’s total available memory divided by memory for one uncached load would be an indicator of how many simultaneous page loads it can bear without crashing. Some configurations of page loads, such as the maintenance page with a 404 mentioned below, load WordPress multiple times.
• Check your templates for potentially errant redirects or infinite loops. Testing with a default theme or disabling custom Pods templates one-by-one is a quick way to rule this out.
• If all that fails, check for any background processes or aggressive queries that might be running intermittently or on catch-all actions such as wp, init, or template_redirect. As you’re having issues with REST responses, I’d suspect functions on the first two more than the third.

When attempting to analyze the site further, I was blocked for a period with HTTP 403 from a service called Imunify360 (imunify360-webshield/1.21), so if searches for memory usage or infinite redirects don’t pan out, it might also be worth checking the logs of that firewall service. Its documentation indicates some configurations and conflicts can result in an error 500. If that service is running in Plesk, it’s also taking memory to operate.

Some final edge-case notes:

• It’s running PHP 7.4.33. The end of life date for PHP 7.4 was November 28, 2022. This means it is no longer updated for newly found vulnerabilities or errors. It might be worthwhile to try updating PHP.
• XML-RPC is enabled. It’s usually prudent to disable this if you’re not using it, which you’re probably not, as it can be used by robots to automate login attempts, which consumes server resources, such as memory.
• There’s no WordPress version being output by the 404 page. Unless this is a behavior of the maintenance plugin, this might indicate the site running a security plugin, such as Wordfence, which could be a source of conflicts with the redirects or memory consumption.
• If analysis leads to memory problems, and you’re not running an object cache such as Memcache, Pods Alternative Cache may help reduce memory usage.
• This probably isn’t it, but the maintenance plugin the site is running has a setting which intentionally sends a 503 Service temporarily unavailable HTTP error. Doesn’t seem like that would be the case, as it sometimes displays, but might as well check that it’s off.
• Check for 404 occurring in templates. For example, the logo on the maintenance page is a 404. When a file 404s in WordPress with permalinks enabled, it causes the 404 template to load, which instantiates a additional HTTP and PHP threads to load WordPress to display that template. As your 404 template currently itself contains that 404, this would be an example of a possible infinite loop that would only be mitigated by a browser choosing to not process HTML returned in response to a request for an image. At a minimum, every page load for the maintenance page and 404 page is loading WordPress twice. 404 should be cached to load as quickly as possible to conserve memory, as robots will often request random paths from web servers. If a web crawler were configured to parse HTML responses regardless of the type of file requested, such a configuration could query your site infinitely until either the server fails to respond or the crawler hits a recursion limit.
• If you are running any database writes on frontend page loads without user interaction, this will consume memory very quickly.
• If your test site was installed on the same server that’s running the site with memory errors, the test site would still be on a server that’s running out of memory.

If all that doesn’t lead anywhere and you’re still at a loss, if you deploy a test instance to Digital Ocean with Sail, it has a performance profiler that will tell you exactly how much processing time and memory is used by every action, filter, and function for any analyzed page request. Doing that would take some time, but the server resources for a test analysis are fairly inexpensive.

Since your configuration is specific to Pods + WPML, here is an open issue on the Pods GitHub that gives an example complex query that may result, along with a possible resolution.

As multilingual sites are complex, such things will vary significantly depending on your configuration and templates, but that may help to get an idea of possible optimization that may be necessary, or reasons for increasing memory in general.

I can’t comment on WPML much further than that — in my limited experience with multilingual sites, I’ve generally had better luck with Polylang, and more recently moved to a plugin of my own design that fits my limited use cases.

It’s also possible to configure ML using a WP multisite and switch_to_blog() for necessary cross-site queries.

Much of this will change in the near future, as multilingual block editor support is slated for the 4th phase of the long-term Gutenberg roadmap.