Support » Networking WordPress » Cannot login to or access Network Admin on Multisite

  • gubblebums

    (@gubblebums)


    Hello,
    This is the primary domain and network admin dashboard for our multisite setup. The other websites work fine, but http://65.1.67.121.nip.io cannot be accessed at all. It was working until a few weeks back.
    Here’s the error message:
    This page isn’t working65.1.67.121.nip.io redirected you too many times.
    Try clearing your cookies.
    ERR_TOO_MANY_REDIRECTS

    It’s not a problem with cookies as I’ve cleared cache and tried on several other browsers.

    Here’s the wp-config file:
    —————–
    define( ‘WP_DEBUG’,false );
    define( ʻCOOKIE_DOMAINʼ, $_SERVER[ ʻHTTP_HOSTʼ ] );
    define( ‘COOKIE_DOMAIN’, false );
    /* That’s all, stop editing! Happy publishing. */
    define( ‘MULTISITE’, true );
    define( ‘SUBDOMAIN_INSTALL’, true );
    $base = ‘/’;
    define( ‘DOMAIN_CURRENT_SITE’, ‘65.1.67.121.nip.io’ );
    define( ‘PATH_CURRENT_SITE’, ‘/’ );
    define( ‘SITE_ID_CURRENT_SITE’, 1 );
    define( ‘BLOG_ID_CURRENT_SITE’, 1 );
    define(‘FS_METHOD’, ‘direct’);
    /** Absolute path to the WordPress directory. */ if ( ! defined( ‘ABSPATH’ ) ) {
    define( ‘ABSPATH’, dirname( __FILE__ ) . ‘/’ );
    }
    /** Sets up WordPress vars and included files. */
    define( ʻSUNRISEʼ,’on’);
    require_once( ABSPATH . ‘wp-settings.php’ );
    define(‘WP_TEMP_DIR’, ‘/opt/bitnami/apps/wordpress/tmp’);
    // Disable pingback.ping xmlrpc method to prevent WordPress from participating in DDoS attacks
    // More info at: https://docs.bitnami.com/general/apps/wordpress/troubleshooting/xmlrpc-and-pingback/
    if ( !defined( ‘WP_CLI’ ) ) {
    // remove x-pingback HTTP header
    add_filter(‘wp_headers’, function($headers) {
    unset($headers[‘X-Pingback’]);
    return $headers;
    });
    // disable pingbacks
    add_filter( ‘xmlrpc_methods’, function( $methods ) {
    unset( $methods[‘pingback.ping’] );
    return $methods;
    });
    add_filter( ‘auto_update_translation’, ‘__return_false’ );
    }
    ————————

    Here’s htaccess:
    ———————–
    # BEGIN LSCACHE
    ## LITESPEED WP CACHE PLUGIN – Do not edit the contents of this block! ##
    <IfModule LiteSpeed>
    RewriteEngine on
    CacheLookup on
    RewriteRule .* – [E=Cache-Control:no-autoflush]
    RewriteRule \.object-cache\.ini – [F,L]

    </IfModule>
    ## LITESPEED WP CACHE PLUGIN – Do not edit the contents of this block! ##
    # END LSCACHE

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>

    # END WordPress
    —————————————

    Any help is appreciated!

    The page I need help with: [log in to see the link]

Viewing 8 replies - 1 through 8 (of 8 total)
  • Moderator bcworkz

    (@bcworkz)

    The .htaccess rewrite rule set for WP is incorrect for multisite. Replace it with this:

    # BEGIN WordPress
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index.php$ - [L]
     
    # add a trailing slash to /wp-admin
    RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
     
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
    RewriteRule ^(.*\.php)$ wp/$1 [L]
    RewriteRule . index.php [L]
    # END WordPress
    Thread Starter gubblebums

    (@gubblebums)

    Hello bcworkz, I replaced the rewrite rule in htaccess with the code you provided, still getting the same error.

    Here’s the current htaccess file:
    # BEGIN LSCACHE
    ## LITESPEED WP CACHE PLUGIN – Do not edit the contents of this block! ##
    <IfModule LiteSpeed>
    RewriteEngine on
    CacheLookup on
    RewriteRule .* – [E=Cache-Control:no-autoflush]
    RewriteRule \.object-cache\.ini – [F,L]

    </IfModule>
    ## LITESPEED WP CACHE PLUGIN – Do not edit the contents of this block! ##
    # END LSCACHE

    # BEGIN WordPress
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index.php$ – [L]

    # add a trailing slash to /wp-admin
    RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ – [L]
    RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
    RewriteRule ^(.*\.php)$ wp/$1 [L]
    RewriteRule . index.php [L]
    # END WordPress

    Moderator bcworkz

    (@bcworkz)

    See if disabling LiteSpeed cache resolves the issue.

    Thread Starter gubblebums

    (@gubblebums)

    Can I disable Lightcache through Filezilla? As we cannot access network admin currently.

    Moderator bcworkz

    (@bcworkz)

    Oh, right, I should have explained further (apologies)–

    You can disable plugins via FTP and Filezilla by renaming the plugin’s folder. When WP cannot find the plugin files, it disables the plugin. When you regain access you’ll need to reactivate the plugin, after restoring its correct name of course.

    In the case of caching plugins, it can happen certain remnants remain after disabling this way because their deactivation script doesn’t run. For example, you’ll have to manually comment out the cache’s .htaccess directives. (place a # hash at the start of each line) There could be other elements I’m unfamiliar with. Should be enough to prevent redirect loops anyway, if that was the cause.

    If you still get too many redirects, deactivate other plugins until the problem goes away. Or deactivate all at once by renaming the /plugins/ folder. Once you gain access, restore plugins one at a time, testing after each, to identify the responsible plugin.

    To verify the cause is not your theme, its folder also can be renamed. There ought to be a twenty* default theme installed so WP can switch to it when it cannot find your normal theme. If you don’t have any installed, one can be manually installed via FTP using the files from its extracted .zip download.

    Thread Starter gubblebums

    (@gubblebums)

    Thank you so much for taking the time to provide such a detailed response, I will try these out and let you know if it worked! 🙂

    Thread Starter gubblebums

    (@gubblebums)

    So the problem was that the database values still had xip.io stored. The solution was to update the database values to nip.io using the following commands:
    ————————

    sudo mysql -u bn_wordpress -p -e "USE bitnami_wordpress; UPDATE wp_options SET option_value='http://65.1.67.121.nip.io' WHERE option_name='siteurl' OR option_name='home';"
    
    sudo mysql -u bn_wordpress -p -e "USE bitnami_wordpress; UPDATE wp_blogs SET domain='65.1.67.121.nip.io' WHERE blog_id='1';"

    ————————
    The issue is solved now, thank you for your time!

    • This reply was modified 1 week, 5 days ago by gubblebums.
    • This reply was modified 1 week, 5 days ago by gubblebums.
    Moderator Yui

    (@fierevere)

    ゆい

    note:
    calling “mysql” command does not require “sudo”, unless you use passwordless authentification via unix socket (without -u and -p params)

Viewing 8 replies - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.