Multiple ACF blocks Failed to load resource: the server responded with a status of 503

[amitbiswas06]

I am here with a heart breaking situation and requires your help. I have been working on my new WP theme for the last 5 months. I am using ACF pro 5.8.7 and developed 18~20 custom guten blocks with it. I have tested and found no issues in my local host which is a wamp server.

But since I moved the site to my staging web server, I am getting admin-ajax.php errors(503) in it. So the page with acf blocks is not loading properly in wp admin. However the front end site is working nicely.

My custom blocks are having moderate fields that requires for them. I am really hopeful that you can help me.

Thanks, Amit Biswas

[elliotcondon]

Hi @amitbiswas06

Sorry to hear about the issue.

I suspect this issue may be due to the number of HTTP requests made during the admin page load to render ACF's dynamic block previews.

Using your browser's inspector tools, can you please review the number of HTTP AJAX requests fired on page load when editing your page/post?

It will be very beneficial to also initiate a conversation with your web host to discuss the HTTP requests, and better understand why the server is returning 503 errors.

[amitbiswas06]

Dear Elliot,

I have checked the HTTP requests. There are about 20 HTTP AJAX request at the time I am opening the edit page. Literally 1 request per ACF block I guess. But that's really small isn't it? I am attaching a snapshot for your reference. Please have a look.

There is no request made for native blocks though. I also have other sites that have tons of ACF meta fields which are loading with no time almost. But this time ACF block having the issue.

I am on a shared web hosting with almost no issues for my other heavy sites. My server also configured with -

max_execution_time = 1200 max_input_time = 600 max_input_vars = 5000 memory_limit = 256M max_file_uploads = 100 upload_max_filesize = 100M post_max_size = 100M

Apart from that, my blocks are not too heavy, some of them have repeater field or taxonomy field or image field or simple text field etc.

It is also noted that when I am clicking a ACF block and toggling the edit/preview, after couple of second the block loads up. But that is not good as I am going to sell my theme at Worlds most popular marketplace. This will hang me down.

Please help me if you can. I can provide you a test server if needed.

Thanks, Amit

[elliotcondon]

Hi @amitbiswas06

Thanks for the reply.

Q1.

Literally 1 request per ACF block I guess. But that's really small isn't it?

This is how dynamic blocks work in the Gutenberg API. Each dynamic block is rendered via an AJAX request to fetch the HTML via PHP. It is possible that we could "pre-load" the HTML on initial page load for optimal performance which I'll consider in future dev.

Q2.

It is also noted that when I am clicking a ACF block and toggling the edit/preview, after couple of second the block loads up.

To determine if the "slowness problem" is due to the actual fields, please register a new block without any fields assigned to it. Provide a callback function/template which simply outputs the text "Hello world". How long does it take to render this block when clicked on?

Q3.

But that is not good as I am going to sell my theme at Worlds most popular marketplace. This will hang me down.

Correct. I would not advise it. Dynamic blocks are great for sites that require a PHP friendly environment for block development, but they will never be able to match the performance of a native static block.

Hope that helps.

[amitbiswas06]

To determine if the "slowness problem" is due to the actual fields, please register a new block without any fields assigned to it. Provide a callback function/template which simply outputs the text "Hello world". How long does it take to render this block when clicked on?

I have tested this now. Just created a simple "Hello World" block without any ACF field. Then I have used the block 16 times in a new page. Then saved it and reopened it in admin. The result is same. admin-ajax.php 503 error same as before.

Can you advise me what I should do now? Should I switch to native block development for the simple blocks and remain in ACF block for the complex ones that have taxonomy/postObject etc?

But the issue will bug me and I guess lots of other devs too. Your advise is more important in this situation. I already have invested 4-5 months on the project and now I found myself alone in the desert without water. There is no warnings at ACF documentation for the block. Otherwise I would have planned my project different way.

Please help if possible.

Thanks, Amit

[nick6352683]

I hope this helps, even though I have no simple solution for you here.

I have created more than 50 ACF Blocks, with some of them pretty heavy on settings (fields), some more than 30... For testing I have created moderate size pages, with about 40-50 blocks without any issues.

Just like you, ,my localserver is xampp, but my live server is a crappy/weak Godaddy shared hosting. The only difference between the 2 environments, is that in the Godaddy shared hosting the blocks load with a 2-3 second delay in the backsite, due to the facts that ACF blocks are dynamic and the actual hosting is really bad ! So I'm not experiencing any of the problems that you are reporting nor anyone else (that I know of). BTW, on the front end things load instantly, like a VPS or even a dedicated server thanks to a good cache plugin I have in place.

That said, my only advice I can provide you right now is to change the hosting company. Error 503 is a server error, so I don't expect for you to get different results by changing browsers of even devices.. . I can with almost certainly blame this on your hosting...

Also, there is no need to look at your code and see how you set and configured things, since the blocks are working in your localserver environment. I keep coming to your hosting server, every time I'm thinking how to resolve this, and at this point, probably the only people who can really help you are the hosting people... Muck easier to dump them and get better hosting (if I were you).

[elliotcondon]

@amitbiswas06

Thank-you for testing the simple block. These results do point towards a server level issue due to the number of simultaneous AJAX requests.

I'll add this to out to-do list and perform some testing with a larger number of dynamic blocks during page load. I can already think of a few solutions to avoid the n x blocks requests.

As @nick6352683 points out, it would be wise to test the issue on another web host. If this is possible, please share with me your results.

If your project allows the time to invest in "native" block development, please do so. Creating native blocks will remove all kinds of limitations found in our PHP framework, but will also require much more time.

Hope this helps.

[amitbiswas06]

@elliotcondon @nick6352683 I have tested my theme at a different server and there I found no issues with the admin-ajax.php POST 503 errors. As this is a relief for me though I really appreciate Elliot's thinking of solutions to avoid n x blocks requests. I am looking forward to that.

As I don't have control over the user's/customer's choice for the hosting, I really need to think and modify my project wisely. A mix solution with ACF dynamic blocks + Custom Native Blocks + Page templates with ACF Flexible fields would be good I hope.

What you think @elliotcondon ?

Thank you so much to all of your valuable time.

[elliotcondon]

@amitbiswas06 Without knowing the size/scope of your editing experience, I can't make any meaningful decisions for you. Please consider all your options and do what is best for your specific project.

I'll be sure to post back here once I investigate the idea of pre-rendering the blocks to avoid multiple AJAX calls.

[amitbiswas06]

@elliotcondon Today I started using the new hosting that I have had tested once and reported that no admin-ajax.php errors are there, unfortunately I am getting same errors now while using the new hosting. Just thought you should get this latest info.

[elliotcondon]

Thanks for the update.

[despecial]

Unfortunately, I have the same experience on my local machine and there are not too many blocks. maybe 15-20 on the page. but it loads for half a minute. way too long

[amitbiswas06]

So far tested with 3 live servers. Results are - Godaddy - Failed Host Gator - Failed Blue Host - Passed with only 1 admin-ajax error.

Tested with 23 ACF blocks in a page!

[elliotcondon]

Thanks for the additional info.

[Log1x]

It is possible that we could "pre-load" the HTML on initial page load for optimal performance which I'll consider in future dev.

I really feel like this should be a priority and perhaps split off into a separate issue if it hasn't been already.

With ACF 5.9 having Innerblock support – it is quickly turning into a performance nightmare...

See:

• https://support.advancedcustomfields.com/forums/topic/acf-blocks-causing-over-200-ajax-requests-on-page-load/
• https://support.advancedcustomfields.com/forums/topic/gutenberg-blocks-load-process-hanging/

[elliotcondon]

Hi @Log1x - How many ACF Blocks are you adding to the page?

[joelschlotterer]

I am in a similar situation. My team has spent months building out ACF based blocks to now discover that in it is completely unusable when editing an existing page (502/504 errors from too many requests). On a page with 35 blocks, it took me 16 minutes to make a text change to a block built with ACF. The page I'm currently scrambling to examine has 30 ACF blocks mixed in with some WP blocks. I really hope to hear some kind info on a plan for addressing this.

[elliotcondon]

Hi @joelschlotterer

Thanks for the comment. I'm sorry to hear how badly this AJAX request performance issue is effecting your project. This issue is the crux of our PHP based framework, but it is definitely something that can be fixed.

The issue is simply due to the way that dynamic blocks are loaded in the editor - via AJAX. This isn't an issue on the front end (thank goodness), but is a serious issues for content editors.

Our idea is to render all the blocks in the backend, similar to how they are rendered on the front end (without individual AJAX requests). The reason why your site is timing out - or taking multiple minutes to load is most likely a protection layer on your server that is preventing it from crashing on too many simultaneous requests.

I'll hope to have some solutions for you shortly :)

[Log1x]

Sorry for the late reply.

The block count comes out to be somewhat similar to @joelschlotterer

In my case, it is about 8-9 ACF blocks that each have 4-5 other ACF blocks inside of their InnerContent. (e.g. a How To block with multiple "Step" blocks inside)

[hatchetaustralia]

We have the same issue, the site was running on PHP 7.4. Since downgrading to PHP 7.3 the issue has resolved itself.

[artemsivak]

Same issue here. All our multisite project based on acf blocks. And it's a nightmare to edit page with a lot of blocks. It takes a lot of time to edit something

[elliotcondon]

Hi all 👋. I'm very pleased to announce we have a solution for this issue, and are pushing hard to get a release out tomorrow 🎉🎉!

The solution we ended up with is very elegant but requires testing. We understand the time sensitive nature of this issue, and as a result, have decided to treat this fix as "experimental" for version 5.9.2 with the goal of lifting this "flag" in version 5.9.3.

What does this mean exactly? Simply put, this allows us to roll out the fix to developers willing to test without the risk of effecting any other live sites. After updating to version 5.9.2, please add the following code to your wp-config.php to enable the fix:

define('ACF_EXPERIMENTAL_PRELOAD_BLOCKS', true);

Please post your result here on GitHub. We're very excited about tomorrow's release - see you then!

[palmiak]

@elliotcondon I did some quick tests and it looks great. I had a problem with many ACF Blocks being loaded at once on one cheap hosting. With PRELOAD enabled it works blazing fast with no errors.

[Hackima]

What a great new ! @elliotcondon , it seems that only preview mode is going to be preloaded. Any chance that edit mode will be preloaded too ?

[elliotcondon]

Hi @Hackima - That might be a little tricky, but let me consider it for a future update 👍

[justinkruit]

Just tried the experimental feature and I'm absolutely loving it. Haven't noticed any problems with it.

[joelschlotterer]

First, thank you so much for making this fix a priority!
We are now testing in our environments and the preview of the blocks is great! I agree with @Hackima that it would be ideal if both the preview and the fields were preloaded (if possible). Having to encourage our users to keep the blocks in preview mode until they want to edit them isn't ideal, but this update does make our blocks usable in the admin again. So again thank you so much for getting this out quickly! Will the final version of this update still require a line in the WP config? Is there a roadmap/ time frame you're looking at to release 5.9.3 with the final fix?

[joshuafredrickson]

The experimental flag reduced a page with 12 blocks from about 30 seconds load time down to about 5 in admin.

This has changed my life. 🙏

[JiveDig]

Another +1 here. I don't really need edit mode for our stuff, personally.

But our theme that has 2 blocks with 30+ fields is loading lightning fast now. Great work!

[Log1x]

+1 – it's like magic. Thanks!

[thomasjulienalain]

Love it ! Thank you.

[arjendejong12]

@elliotcondon Did this constant get removed in 5.9.3? I have it enabled but it's not preloading anything, unlike 5.9.2.

[elliotcondon]

@arjendejong12 No. The constant has not been removed in 5.9.3. Can you please elaborate more on the issue?

[virgo79]

I can't see any valuable change too. Checking the browser inspector I see that Block preload always rely on ajax requests.

Tested with both ACF 5.9.2 and 5.9.3. Below ACF (5.9.2) is network enabled on WP 5.5.1 multisite.

@elliotcondon

[despecial]

Did you add this to your config? @virgo79 define('ACF_EXPERIMENTAL_PRELOAD_BLOCKS', true);

[virgo79]

@despecial yes. I've also updated to wp 5.5.3.

Below is a more details screenshot with ajax requests panel.

[amitbiswas06]

@virgo79 It seems the nature of the problem is not understood properly. Please refer the actual question followed by @elliotcondon and my discussion.

[elliotcondon]

Hi @virgo79 - The demonstration in your screen-record is not something that the ACF_EXPERIMENTAL_PRELOAD_BLOCKS constant will change. Due to the dynamic nature of ACF Blocks, there will always be an AJAX call fired after making a "change" to field values.

The ACF_EXPERIMENTAL_PRELOAD_BLOCKS constant is intended to help speed up the initial page load by preloading any previewed that will be rendered on the edit screen.

[joelschlotterer]

@elliotcondon so is the plan to leave the ACF_EXPERIMENTAL_PRELOAD_BLOCKS constant as a requirement for this functionality? We are trying to decide if we need to script this into our dev ops process for setting up and maintaining sites. Is there a release coming where this functionality is no longer considered experimental?

[elliotcondon]

Hi @joelschlotterer. This constant will only be required whilst we consider the functionality "experimental". With enough feedback and bug fixes, we will merge this into core without the need to define any constant 👍.

[virgo79]

Hi @virgo79 - The demonstration in your screen-record is not something that the ACF_EXPERIMENTAL_PRELOAD_BLOCKS constant will change. Due to the dynamic nature of ACF Blocks, there will always be an AJAX call fired after making a "change" to field values.

The ACF_EXPERIMENTAL_PRELOAD_BLOCKS constant is intended to help speed up the initial page load by preloading any previewed that will be rendered on the edit screen.

@elliotcondon thanks for the clarification!

[FuSan21]

@elliotcondon The new experimental constant ACF_EXPERIMENTAL_PRELOAD_BLOCKS fixes one of the issues I was facing in the backend. Some contents weren't showing in the frontend but it worked in the backend properly. For example <h2><?php echo get_the_title(); ?> Overview</h2> didn't show in backend editor but worked correctly in frontend. This is fixed.

But the below function still doesn't work in the backend. It works in frontend as usual. <img src="<?php echo get_the_post_thumbnail_url( null, 'full' ); ?>" class="character-icon" alt="Traveler (Anemo)">

It appears like this in the editor

[elliotcondon]

Hi @Fu-San. Thanks for the comment. Please keep in mind that some WP functions such as get_the_title() and get_the_post_thumbnail_url() refer to a global $post object if the $post_id variable is not provided (or in your case set to null). During the AJAX request to render the block preview, that global $post object is not setup, which explains why those functions are not running as intended.

The soution is simple, either setup the gobal $post object manually, or use the provided $post_id parameter in any get_the_title() or get_the_post_thumbnail_url() calls 👍.

[gallivanmedia]

Hi @joelschlotterer. This constant will only be required whilst we consider the functionality "experimental". With enough feedback and bug fixes, we will merge this into core without the need to define any constant 👍.

I always have my clients see the "preview" first... so, this "experimental" fix with the ACF_EXPERIMENTAL_PRELOAD_BLOCKS constant is exactly what I need. From there, I don't even mind them waiting for the individual block editors to load. THANK YOU for the quick solution.

[joelschlotterer]

So still loving this fix. I did notice that it doesn't preload the preview for Reusable blocks. I don't know if that is something you can even control, just wanted to note it though. Again, without this fix we would have had to start over so thank you for taking this seriously and we appreciate your efforts!

[kmcaloon]

@elliotcondon appreciate you being so responsive. I might be missing something, but since admin-ajax tends to be pretty resource intensive, is there a reason why the rest api couldn’t be leveraged here?

[elliotcondon]

Hi @kmcaloon. In this use-case, the difference between admin-ajax and a custom REST API endpoint would be negligible. The issue here is simply due to multiple asynchronous requests hitting the server at once, which is solved completely via a preloading solution (like the one we are working on) or a JS solution to delay the AJAX request (similar to lazyloading).

We're confident this won't be am issue for much longer, but will have to wait until the new year until anything get's released :)

[kmcaloon]

Thanks @elliotcondon. Totally understood on the timing. As far as admin-ajax, my first concern when seeing the network requests while interacting with the blocks was actually the impact on the server it would have while multiple content editors edit the site throughout the day. Unfortunately I don’t think preloading would help here.

I’m assuming custom endpoints wouldn’t help here because either way acf would need to load a ton of WP core files anyway?

[smerriman]

By default, when I create an ACF block in preview mode that has links in it, clicking on a link inside the block in the editor redirects the browser, rather than allowing me to edit the block.

I've been resolving this by adding:

.acf-block-preview a {pointer-events:none;}

to my editor styles. However, with the experimental constant, the acf-block-preview class isn't added.

Can this class be retained during preload? (And/or, is there a better way of preventing clicks in the first place?)

[JiveDig]

I do the same, but scoped to my specific block by the container html class. You probably should do similar too, so it only applies to the blocks you want it to. It still works for me with the constant added.

[smerriman]

That does work, but given you never want someone who clicks on an ACF preview to be taken away from the editor, it's better to have a generic class rather than have to add extra code for each new block. Given it's still a preview, the lack of a preview class seems accidental.