Bug: ACF Pro 5.2.3 and WP Multisite

• Jan

• April 23, 2015 at 5:47 am

Just a bug report: I have a WordPress multisite (4.1.2) installed with the plugin WordPress MU Domain Mapping (0.5.5.1).

ACF Version 5.2.2 works like a charm but after installing your new Version (ACF 5.2.3) this happened: I couldn’t login to the admin network dashboard anymore (redirect loop). Maybe this has something to do with this new feature: “Core: Added network database upgrade admin page and functionality”?

Because after switching back to ACF 5.2.2 I could login to the network dashboard as usual.

I know this might be tricky but I just want to let you know.

Thanks for your wonderful work!

All the best,
Jan

• Manioums

• April 24, 2015 at 3:42 am

Hello,

Same problem here !

Manioums

• Austin Ginder

• April 25, 2015 at 4:40 am

Same issue here. Ok so some more details on my situation here: https://wordpress.org/support/topic/wordpress-42-network-admin-multisite-redirect-loop?replies=4#post-6866952. I only noticed when I updated to WordPress 4.2 with ACF 5.2.3. Downgrading to ACF 5.2.2 fixed my redirect loop.

• PB

• April 29, 2015 at 2:32 am

Same issue here.

• Adam Norwood

• April 29, 2015 at 7:39 am

Upgrading to ACF Pro 5.2.3 is also causing Multisite issues for our installation (WP 4.2.1). We’re not using the Domain Mapping plugin, and the problem isn’t manifesting itself as a redirect loop, but it seems like this might be related to the above issue reports.

What I’m seeing is that WordPress’s PATH_CURRENT_SITE constant is incorrect when 5.2.3 is activated. The problem is very visible when looking at the Multisite “Network Setup” page (/wp-admin/network/setup.php) — for reasons unclear, PATH_CURRENT_SITE is listed there as the path to one of our child sites, not the actual top-level site path (e.g. it’s set to ‘/child-site/’ when it should just be ‘/’ as set in wp-config.php). Deactivating ACF Pro corrects this issue.

The wrong PATH_CURRENT_SITE seems to be wigging out things elsewhere in the WordPress admin dashboard, causing some of our other plugins to break (like WP Migrate DB Pro), where that plugin gets confused about why we’re running a Network-level plugin on a child site.

As a shot in the dark, I’d suspect that maybe the issue is in the change to ACF’s /admin/update.php, with the new acf_admin_update->network_admin_menu() method. It’s using restore_current_blog(), which I think actually just bounces WP back to the “previous” blog in the stack, not the “original” blog? Or in any case, the normal recommendation is to run it after every switch_to_blog() according to the docs: https://codex.wordpress.org/Function_Reference/restore_current_blog

In our case, the PATH_CURRENT_SITE is set to our next-to-last (based on site ID) child site’s path, so that seems to back up the restore_current_blog() theory…? Maybe.

• PB

• April 29, 2015 at 7:46 am

In support of this theory, my redirect issue is also trying to move me to the next-to-last (id-wise) blog in my network. Thanks for the extra information anorwood!

• Jan

• April 29, 2015 at 6:28 pm

Yes, it’s the same here: “my redirect issue is also trying to move me to the next-to-last (id-wise) blog in my network.”

• grahamharper

• April 29, 2015 at 9:12 pm

I can confirm the same problem. My network admin area gets stuck in a redirect loop between my main blog and my 2nd (of 3) blog. The problem is present when the domain mapping plugin is active. Reverting to ACF 5.2.2 fixes the problem. I’m on WP 4.2.1

• robhuska

• May 2, 2015 at 12:39 am

Same problem on our installs. ACF Pro 5.2.3 and WP 4.2.1 with Domain Mapping.

• mtsuwd

• May 2, 2015 at 4:02 pm

Same problem on our installs. In addition, the Customfileds only on the website but are not displayed in the post edit mode. Is there already a solution?

• mtsuwd

• May 2, 2015 at 4:18 pm

Reverting to ACF 5.2.2 fixes the problem for the Moment.

• Elliot

• May 6, 2015 at 5:12 pm

Hi guys

Sorry about this issue and thanks for all the info / links.

It seems like an easy fix, but can someone please confirm the following:

Change line 72 loop to:

if( $sites ) {
			
			foreach( $sites as $site ) {
				
				// switch blog
				switch_to_blog( $site['blog_id'] );
				
				
				// get site updates
				$updates = acf_get_updates();
				
				if( $updates ) {
				
					$prompt = true;
					break;
					
				}
				
				// restore
				restore_current_blog();
				
			}
			
		}

All that is changed is the restore_current_blog(); function is moved within the foreach loop.

This should fix the issue, and upon confirmation, I will release a new version!

Cheers
E

• Austin Ginder

• May 6, 2015 at 7:50 pm

I tested it out on one of my affected installs. Simply putting the restore_current_blog() inside the loop did not work. However through some trial and error I was able to get it working by keeping your original code and adding it inside the loop like so.

		// loop through sites and find updates
		$sites = wp_get_sites();
		
		if( $sites ) {
			
			foreach( $sites as $site ) {
				
				// switch blog
				switch_to_blog( $site['blog_id'] );
				
				
				// get site updates
				$updates = acf_get_updates();
				
				if( $updates ) {
				
					$prompt = true;
					break;
					
				}
				
				// restore
				restore_current_blog();
				
			}

		// restore
		restore_current_blog();
			
		}

• Adam Norwood

• May 6, 2015 at 10:59 pm

I can’t speak for the folks who are having trouble with the Domain Mapping plugin, but simply moving restore_current_blog() up into the foreach loop as Elliot suggest appears to fix my PATH_CURRENT_SITE problem!

Adding the extra restore_current_blog() as in Austin’s example seems redundant, but it also doesn’t appear to be hurting things in my case, so if that fixes the Domain Mapping issues maybe that’s a reasonable tradeoff…

Thanks for investigating, Elliot!

• Elliot

• May 7, 2015 at 10:15 am

Thanks @anorwood

The restore function should be needed to allow further functionality to target the correct blog tables in the DB.

Thanks
E

• Elliot

• May 7, 2015 at 10:42 am

Hi @anchordev

Thanks for the reply. Perhaps my logic is slightly incorrect. Can you replace the line with this code instead:

if( $sites ) {
	
	foreach( $sites as $site ) {
		
		// switch blog
		switch_to_blog( $site['blog_id'] );
		
		
		// get site updates
		$updates = acf_get_updates();
		
		
		// restore
		restore_current_blog();
		
		
		if( $updates ) {
		
			$prompt = true;
			break;
			
		}
		
	}
	
}

I’ve moved the restore function above the break which may have prevented it from working as expected. This should work for sure

Please let me know ASAP so I can get an update out!

Thanks
E

• Austin Ginder

• May 7, 2015 at 10:48 am

@elliot I tried out your revised code and yes it works on my install. Thanks for figuring this out.

• Elliot

• May 7, 2015 at 10:53 am

Perfect!

Thanks guys

• augusto

• May 7, 2015 at 2:11 pm

@elliot, just to register here as well, your updated code works on my scenario too.

Thanks

• ednailor

• May 8, 2015 at 2:31 am

Any idea as to when the fix will be applied? I am having the same redirect loop when upgrading from 5.2.2 to 5.2.3 using WP 4.2.2

Thanks
Ed

• augusto

• May 8, 2015 at 3:09 am

@ednailor,

yesterday @elliot told us that will launch the update version in the next days (maybe today).

For now, I recommend you to update a single file of your ACF PRO:
advanced-custom-fields-pro/admin/update.php

locate the line 72 and replace the actual loop code with the one posted by elliot (that one marked as the solution for the post).

cheers

• mboesken

• January 31, 2020 at 9:27 pm

Hi,

with version 5.8.7. of custom fields pro this problem still exists. I host more than 2k sites in one multisite environment. Loading the network admin needs round about 45 seconds on every page. With removing the code part explained above the pages load in 2 seconds.

In version 5.8.7. you will find the code in advanced-custom-fields-pro\includes\admin\admin-upgrade.php line 70-97.

Is there an option to fix this bug with the next release?

Thanks
Michael

• Elliot

• February 3, 2020 at 9:47 am

Hi @mboesken

Thanks for the comment.

It is possible that we may need to implement a different strategy for large scale multisites like the one that you are hosting. Would you mind opening a new private support ticket via this link (https://www.advancedcustomfields.com/contact/) and ask for me, Elliot.

To determine why the page is taking so long to load, we will need to perform some debugging. If possible, please install the Query Monitor plugin and take a look at the Database Queries that are run during this 45s admin page.

Thanks
Elliot