PHP memory limit error
-
Hi, we’ve been getting the following error a lot. Website visitors get an error when this happens.
[Fri Nov 03 09:30:51.316295 2023] [php:error] [pid 1381830] [client x.x.x.x:0] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 54883587 bytes) in /.../wp-includes/class-wpdb.php on line 2459- Hummingbird plugin version: 3.6.0
- WordPress version: 6.3.2
- PHP version: 8.1
We’ve tried adding the MU plugin code given as the solution in another post, but that did not fix the problem:
<?php add_action( 'plugins_loaded', function() { if ( ! defined( 'WPHB_VERSION' ) ) { return; // Hummingbird is not installed/enabled. } add_action( 'pre_get_posts', function( $query ) { if ( ! empty( $query->query['post_type'] ) && 'wphb_minify_group' === $query->query['post_type'] ) { if ( -1 === $query->query['posts_per_page'] ) { $query->query['posts_per_page'] = 10; $query->query_vars['posts_per_page'] = 10; } } }); });SELECT COUNT(ID) FROM wp_posts WHERE post_type = 'wphb_minify_group';returns 1,474 matching posts.The error does not occur if we disable the Hummingbird plugin and install WP Fastest Cache instead, but it comes back again if we disable WP Fastest Cache and activate Hummingbird.
Any ideas? I’ve asked for the Site Health info, and will post it here as soon as I get it.
The page I need help with: [log in to see the link]
-
Hi @markmont
Thank you for response!
Nearly 27,000 assets is enormously high number and definitely shows that Asset Optimization in this case is not working correctly.
Usually it means that there is “something” on site that causes it to incorrectly detect – usually dynamically generated or dynamically loaded – assets. Commonly that’d be associated with things such as:
– conflicts with other JS/CSS optimization tools/features (e.g. other similar plugisn) on site
– some unusual or misconfigured page builder
– issues (related to access permissions or conflict with other plugins) with correct handling of data in DB
– or incorrectly functioning cron or action scheduler
– sometimes it may also be due to server-side cache that’s either malfunctioning or not fully/properly integrated with site itself.Basically, it looks like Asset Optimization is (re)generating optimized assets all over again without updating/removing any removed/changed ones.
—-
Another – very rare – but important case is when Hummingbird cannot write optimized files to the file system.
When plugin optimizes a file it does not “edit” CSS/JS file content “on the fly” but rather than this it saves optimized files into the /wp-content/uploads/hummingbird-assets folder and then it changes how site loads those files so it would load those saved ones instead of originals.
Technically speaking:
– files are analyzed and optimization actions (such as e.g. code minification/compression and combining multiple files togehter) are performed
– information about processed assets are saved into DB (“wphb_minify_group” records)
– optimized file is saved to aforementioned folderIf it can’t save the file it will not be able to find them also when minification happens and may try to opimize them over and over again as if they were new files.
I noticed that your /wp-content/ folder is currently not writable and that is very likely to be the cause of the issue. You have an SSH SFTP Updater Support plugin installed and I suppose you may have SSH configured in wp-config.php file via the FS_METHOD definition.
Is that right? Or do you have SFTP configured in wp-config.php?
If it’s SFTP – is there only FS_METHOD set or are there full credentials defined?
I’m asking because if the /wp-content/ folder is not writable and you only have FS_METHOD defined but no crednetials (and instead use some 3rd-party plugin) it’s quite likely simply impossible for Hummingbird (and quite likely other plugins too) to write to /uploads folder and that would cause multiple issues, including issues with Asset Optimization.
So the first thing to check here would be to make sure that site is configured in a way that allows plugin(s) to write to /wp-content/uploads folder. Once that’s done you would need to actually reset Asset Optimization so it would clear up all of its own data in DB and re-discover assets on site.
Kind regards,
Adam[Update]
Just to clarify:
1. I mentioned credentials configured in addition to FS_METHOD in wp-config. I’m sorry as I made it a bit unclear: I didn’t mean putting any credentials in “wp-config.php” file directly but rather making sure that if FS_METHOD is set – making sure that credentials are also added in site configuration in site’s back-end
2. Also, even if configured, it may still sometimes prevent Hummingbird form being able to directly write to files, depending on what FS_METHOD is set – so which one is configured?
- The topic ‘PHP memory limit error’ is closed to new replies.
