As a web programmer, I’m often asked to fix the problems that others have, but when I see problems appearing on sites I’ve had a hand in, I’m infinitely more concerned. This is exactly what happened recently, when I custom post type I had provided for a client started generating memory errors in the WordPress Dashboard.
The problem in question was with the client’s custom post types, exceeding the maximum amount of memory allowed. The post types in question had in excess of 20,000 records, which isn’t anything that a MySQL database can’t handle, but WordPress on the other hand threw the following error each and every time I tried to load the custom post type in the Dashboard.
Furthermore, the same data was perfectly accessible via queries from the front end of the site, so what gives?
The Solution and Process
Firstly I attempted a few php.ini or .htaccess fixes increasing the PHP memory limit. Naturally, from the allowed memory size detailed above I knew this would likely prove futile, but it was worth a shot. No joy.
Next I changed a line in /wp-admin/admin.php that said:
This removed the error and I could finally load the Dashboard custom post type, but loading times were very slow and I could see my host would clamp down on my CPU usage pretty quick.
Finally, looking over the options that were set when registering the custom post type I recalled something from a while back concerning custom post types and the parameters included to create them. The hierarchical parameter in my custom post types was set to true. Changing it to false, eliminated the memory error and the pages loaded in an instant again, even with 20,000+ records.
For reference, the hierarchical option was designed for Pages only, and not custom post types that use Posts. With hierarchical set to true, WordPress fetches all entries of that particular post type, in addition to all meta data, for every Dashboard page you load for that post type.
I hope this is of use to someone out there with the same WordPress web programmer problems.