• Skip to main content

Victor Font Consulting Group, LLC

The DEX Intranet Specialists

Call Us:

+1 919-604-5828

  • Home
  • Care Plans
    • Care Articles
    • Optional Subscriptions
  • Consultations
  • Products
    • Code Snippets
    • Public GitHub Repositories
    • Gist Snippets
    • Pastebin Snippets (Free)
    • Free Plugins
  • FAQs
  • Support
    • Graphic Design
  • Contact
    • Speakers
    • Portfolio
  • Resources
    • Free WordPress Video Training
    • Tutorials
    • Articles
    • Cybersecurity
    • EU Referral Network
You are here: Home / Code Snippet / Fix WP Multisite Wp-admin Redirect Loop

Fix WP Multisite Wp-admin Redirect Loop

By Victor M. Font Jr.
October 13, 20146 Comments

Redirect Loop Error Message in FirefoxOne of the most difficult to troubleshoot issues I've ever encountered with WordPress is a redirect loop that happens when attempting to access any WordPress multisite site/wp-admin pages. Apparently, redirect loops have been a persistent problem in some installations. WordPress.org has, as of this article, 300 threads dedicated to the issue. There are quite a few posts that describe solutions that resolve the redirect issue when caused by www vs. non-www or ssl vs. non-ssl domains. There are also quite a few that indicate problems with a site's .htaccess file. Non of these solutions are applicable to the problem I encountered, which appeared quite suddenly and inexplicably one afternoon last week. I was able to log into my sites in the morning. In the afternoon, the redirect loop occurred. It drove me crazy for days and led to more than one argument with my host's support team, for which I apologize.

Of course, one of the first things I thought of was, “I've been hacked!" I went through all the steps required when a WordPress site gets hacked to no avail. I confirmed .htaccess and wp-config were right. I even dumped the database to search for redirects in the data. There was nothing to be found and the problem wouldn't go away.

Diagnosing the Redirect Loop

Redirect_DetectiveA redirect loop is by its very nature very difficult to diagnose because we can't see what the browser is seeing when a page is loading. Then I came across a great website for diagnosing redirect loops: http://redirectdetective.com/. Simply type in the offending web page URL and the site returns a display of what the browser is doing when attempting to load the page.

302 Redirects

When any browser communicates with a web server, it executes the following cycle:

  • Lookup the IP address from a domain name server (DNS).
  • Open an IP socket connection to that IP address.
  • Write an HTTP data stream through that socket.
  • Receive a response HTTP data stream back from the Web server.

The response data stream contains status codes whose values are determined by the HTTP protocol in use. The browser parses this data stream for useful information. The 302 error occurs when the client receives an HTTP status code that it recognizes as ‘302'. The browser receives a 302 error code when the Web server thinks that the URL has been temporarily redirected to another URL. The browser then immediately retries the alternate URL. If you look at the redirect error I was receiving as reported by Redirect Detective, the redirect was redirecting to itself. Under normal circumstances, this is not possible and it triggered the redirect loop. But this still doesn't get us to the root cause. Something else is going that create this redirect loop.

Determining the Root Cause

At this point, I know the problem is isolated to the wp-admin directory. The network admin page and all externally facing pages are working correctly. I can even login to the individual sites by directly calling wp-login. I just can't load the dashboard. Then I notice that every time I run the wp-admin page through the Redirect Detective site, the error log in the wp-admin directory was growing exponentially. Here is a sample of what the error log contained:

[13-Oct-2014 11:28:44 America/Chicago] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20090626/suhosin.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20090626/suhosin.so: undefined symbol: php_mb_gpc_encoding_detector in Unknown on line 0
[13-Oct-2014 11:28:45 America/Chicago] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20090626/bcmath.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20090626/bcmath.so: cannot open shared object file: No such file or directory in Unknown on line 0
[13-Oct-2014 11:28:45 America/Chicago] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20090626/mysql.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20090626/mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0
[13-Oct-2014 11:28:45 America/Chicago] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20090626/mysqli.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20090626/mysqli.so: cannot open shared object file: No such file or directory in Unknown on line 0
[13-Oct-2014 11:28:45 America/Chicago] PHP Warning:  Module 'imagick' already loaded in Unknown on line 0

These errors are saying that php couldn't load! Something was blocking php. I checked all directory and file permissions. Everything was right. My next thought was, “Maybe the host updated their firewall rules and that stopped php from executing in wp-admin. I contacted support again, but knowing the turn around time can vary, I thought, “What have I got to lose if I install a php.ini file directly in the wp-admin directory?" This could force php to load and hopefully solve the problem.

Well, was I get surprised when I discovered that there was already a php.ini file the wp-admin directory. The file was timestamped from early 2013. So instead of adding a new php.ini to the wp-admin directory, I renamed the one that was already there to php.old so it wouldn't execute. This solved the wp-admin redirect loop. There was no actual redirect. The wp-admin pages couldn't execute. I have no idea where the php.ini file came from and as far as I know, there's no reason why there should be one in that directory. It may have been left over from an old security plugin that I no longer use, but I certainly can't rule out that it was placed there by someone wanting to do damage.

  • 6shares
  • Facebook0
  • Twitter0
  • Pinterest0
  • LinkedIn6
  • Print
  • SMS0

About Victor M. Font Jr.

Victor M. Font Jr. is an award winning author, entrepreneur, and Senior IT Executive. A Founding Board Member of the North Carolina Executive Roundtable, he has served on the Board of Advisors, of the North Carolina Technology Association, the International Institute of Business Analysis, Association of Information Technology Professionals, Toastmasters International, and the North Carolina Commission for Mental Health, Developmental Disabilities, and Substance Abuse Services. He is author of several books including The Ultimate Guide to the SDLC and Winning With WordPress Basics, and Cybersecurity.

Reader Interactions

VictorFont.com runs on the Genesis Framework

Genesis FrameworkThe Genesis Framework empowers you to quickly and easily build incredible websites with WordPress. Genesis provides the secure and search-engine-optimized foundation that takes WordPress to places you never thought it could go.

Check out the incredible features and the selection of designs. It's that simple—start using Genesis now!

Click here to download The Genesis Guide for Absolute Beginners (PDF - 1.4 MB)

Leave a Reply Cancel reply

Your email address and website will not be published. Required fields are marked *
Posting a comment means that you agree with and accept our Comment & Product Review Policy

Comments

  1. Walid

    February 24, 2016 at 6:06 pm

    Don’t know the best way to say THANK YOU,

    It is really not clear how php.ini is related to this issue,

    my wp-admin/php.ini just contains the following:
    memory_limit = 2048M ;

    Renaming php.ini to _php.ini solved it,

    Thanks again.

    Reply
  2. Mikka

    September 16, 2015 at 12:07 pm

    Excellent article!
    I wish I found it earlier…
    When it first happened I looked into it, but soon gave up and called my hosting support. Even they took almost an hour to fix it. I knew it was something with php.ini, but what? You explained it so well here…
    What a drag this redirect is…
    Cheers!

    Reply
    • Victor M. Font Jr.

      September 16, 2015 at 12:15 pm

      Thank you Mikka!

      Reply
  3. Rima

    July 27, 2015 at 11:19 am

    Thanks a lot :) Even though that was not my issue for my multisite redirect loop, I ended up checkign the .htaccess file in wp-admin where permissions were missing for my IP address. Duh! Thanks for pointing me in the right direction.

    Reply
  4. Kevin

    March 31, 2015 at 12:28 pm

    Man you saved me. Was coming to terms with doing a fresh install of WordPress for a 5+ year old site with Gallery 2 and custom tweaked Theme. I had the exact same issue. You saved me I don’t know how many hours and money from downtime. THANK YOU!

    Reply
    • Victor M. Font Jr.

      March 31, 2015 at 12:53 pm

      Awesome! Glad to help.

      Reply

Call: +1 919-604-5828

Send us an E-mail

Accessibility Statement | Affiliate Marketing Disclosure | Capability Statement

Cookie Policy | Comment & Product Review Policy | Privacy Policy | Site Map | Terms & Conditions

Copyright © 2003–2023 Victor M. Font Jr.

Return to top of page