Support

Account

Home Forums Bug Reports Bug: ACF Pro 5.2.3 and WP Multisite

Solved

Bug: ACF Pro 5.2.3 and WP Multisite

  • 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

  • Hello,

    Same problem here !

    Manioums

  • 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.

  • Same issue here.

  • 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.

  • 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!

  • 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.”

  • 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

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

  • 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?

  • Reverting to ACF 5.2.2 fixes the problem for the Moment.

  • 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

  • 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();
    			
    		}
    
  • 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!

  • Thanks @anorwood

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

    Thanks
    E

  • 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

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

  • Perfect!

    Thanks guys

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

    Thanks

  • 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

  • @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

  • 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

  • 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

Viewing 23 posts - 1 through 23 (of 23 total)

The topic ‘Bug: ACF Pro 5.2.3 and WP Multisite’ is closed to new replies.