I recently had fun figuring out why editing my home page would give me a white screen with no errors (debug mode enabled) and I wanted to share what I found.
I have a large WooCommerce site that I’m developing for a client, and when I say large I mean 158 products, but that actually comes out to 820 combined simple products and product variations. Over a collective 3 hours, I determined that the issue was caused by a Page Link field’s “Post Type” field being set to All, which included product variations. By selecting all post types except for product variations, the edit page for my home page was loading properly.
So I figured the page was dying for either taking too much time to load all that data, or eating up the max memory, but my question is why would that happen without showing any errors with WP_DEBUG set to true? And why were there no errors in any of my error logs? Also, I know that private post types are supposed to be ignored by a Page Link field, so perhaps WooCommerce needs to do something to make sure product variations aren’t a public option? And finally, is there anything that can be done to protect against this type of situation?
I had the same issue. I have Page Link fields in a repeater, and having about 8 of them on a page brought the loading time of the editing screen to 1.5+ minutes, which on my host often results in a 502 error. Changing the field to list only pages instead of All brings it down to about 10~15 seconds. Slow, but manageable.
I’m guessing that whatever function outputs the dropdown for the Page Link field runs through all the pages, generating the html for each page, every time you have a Page Link dropdown. This could instead generate the html once on the page, save that html, and output the same code every time a Page Link dropdown needs to be displayed on the page.
Faison, there were no Debug errors because the php is fine – no errors to raise. It’s just taking so long to loop through all those posts that the server gives up, or you give up waiting. There should probably be a timeout error or something in your error log though, I think, but that has to do with server settings, and whether it’s actually timing out.
Thanks for this question.
Currently, the page_link and post_object fields load in all the choices in one go which is not a great idea for large sites as you have.
This has been a driving force behind the work on version 5. ACF v5 will use AJAX for all post_object and page_link fields to minimize the amount of data needed on the first page load!
v5 will be out in feb next year. Until then, I’m not sure what I can do to help, but wish you good luck with your project.
Thanks, that’s great to hear! As Jonathan stated, we both did come up with work-arounds, I just wanted to bring this to your attention in case you didn’t already know.
And Jonathan, I remember seeing some tweets a while back where Elliot said he as going to be looking into things like Selectize for ACF.
So the solution for the time being: Make sure to set the Post Types for a Page Link field to something other than All. For my situation, just had to exclude product variations.
The topic ‘Page Link field causing white screen of death with too many posts’ is closed to new replies.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
📣 “ACF Chat Fridays”— Advanced Custom Fields (@wp_acf) January 31, 2023
The ACF team holds their first open office hours this Friday! Come and talk ACF, and ask questions about building sites with the plugin.
We’d love to see you there!
📆 Friday 3rd Feb - 3pm UTC
👉 Register here - https://t.co/3UtvQbE4CU pic.twitter.com/oTwW9K1XQ0
© 2023 Advanced Custom Fields.