The MU forums have moved to WordPress.org

WPMU 2.6 wp-login redirects to itself for all blogs except main (46 posts)

  1. misterlib
    Member
    Posted 15 years ago #

    I am having this problem too, so I figured I would throw out my scenario and see if it helps.

    I did a fresh install of 2.6 this morning as a subdomain setup. I set it up like this:

    example.com

    then 2 additional blogs:

    other.example.com
    other2.example.com

    then I changed those values in the blog info page to:

    other.com
    other2.com

    both those domains are parked at example.com

    my goal is to have the user other be able to access other.com and example.com, and the user other2 to access other2.com and example.com.

    it is redirecting with the correct site, and i can log in at example.com/wp-login, but switching to one of the other dashboards or logging in from other.com/wp-login redirects back over and over and over.

    any ideas?

  2. coolgates
    Member
    Posted 15 years ago #

    I added this to the end of wp-config.php and my logins are working now: @define('ADMIN_COOKIE_PATH', '/');

  3. keppy
    Member
    Posted 15 years ago #

    Well, I can't explain it, but I finally, finally got everything working again. I tried a lot of the solutions on here but none of them were getting me anywhere. What finally did it was completely wiping out the WPMU files (including .htaccess, which I did each other attempt anyway), then uploading the 2.6 versions of everything again.

    Then, instead of altering wp-config by hand like I had been doing (and yes I was using the 2.6 version of wp-config with all the correct salts); I just went to the installer and pretended I was installing from scratch. So I let it do its thing, put in my DB info, let it create wp-config and .htaccess, and voila. Everything looks good.

    Hopefully the couple other people still unresolved in this thread get it figured out. If possible I'd suggest starting clean like I did. Don't worry, WPMU won't kill your existing database tables or anything.

    Thanks for the input everyone.

  4. lunabyte
    Member
    Posted 15 years ago #

    "So I let it do its thing, put in my DB info, let it create wp-config and .htaccess, and voila. "

    Which is exactly how it's supposed to be installed from the git go. ;)

  5. andrea_r
    Moderator
    Posted 15 years ago #

    "instead of altering wp-config by hand like I had been doing"

    And that's probably why you had problems. :)

  6. keppy
    Member
    Posted 15 years ago #

    Correct me if I'm wrong, but the normal upgrade process does not involve running wp-admin/install.php.

    I had WPMU 1.5.1 installed and working fine, so I took the normal upgrade steps (http://codex.wordpress.org/Upgrading_WPMU) of removing everything except wp-config and wp-content, uploading the new files, then navigating to wp-admin/upgrade.php. This worked fine, gave me a link to upgrade the database, then when I logged in to the back-end it alerted me that I needed to add several salt definitions to wp-config. I added them all as instructed, then ran into the issue that I opened this thread with.

    Anyway, I guess my point is that I think it would be useful if upgrade.php re-created wp-config.php and .htaccess for you (maybe only if those files have changes from the previous version, but it might not hurt to just do it every time).

    This would allow you to delete every WPMU file, then go to wp-admin/upgrade.php, put in your DB info, and have a new wp-config.php and .htaccess created for you in case there were changes to those files. Does anyone else think this would be a good thing?

  7. lunabyte
    Member
    Posted 15 years ago #

    Unfortunately, that would really irritate a lot of people with additional information in their files.

    You just can't go overwriting files like these all the time to try and solve problems which didn't really exist in the first place. Which is why when you logged in it told you to put "this and that" into your config file.

    Much safer option then automatically overwriting it.

    With the core files, yes it's a replacement procedure. But you know that's what you're doing, not just having it done for you.

  8. andrea_r
    Moderator
    Posted 15 years ago #

    Duh, nevermind me...

  9. keppy
    Member
    Posted 15 years ago #

    Yeah, that's a good point; anyone with extra settings in wp-config wouldn't want this happening. Anyway, thanks to everyone for the input.

  10. burtonkent
    Member
    Posted 15 years ago #

    In wp-includes/capabilities.php, I located the source of my problem. Not sure if it's the same cause for everyone else.

    In the WP_Users object's has_cap function, I set it to return "true". It fixed the continuous redirect problem, but obviously it breaks security, so it's not a viable fix.

    The problem is in the:
    $capabilities = apply_filters('user_has_cap', $this->allcaps, $caps, $args);
    line within that function - if any capability is missing it fails.

    Can someone else verify the has_cap return "true" behavior? I'd like to know if it's unique to my installation, or if it's the cause of everyone's problems.

    What the code in my case is doing is checking to see if you have permissions for all the menus/submenus allowed in whatever wp-admin/somefile.php you're accessing, such as edit.php, post-new.php, etc.. Unfortunately, it's denying access to index.php entirely, but there's nowhere else for it to redirect, so it keeps going back to the same place.

    The fix would probably be one of two things. Find out which capabilities are missing that shouldn't be. Looks to me like the WP_Roles object might be the object that should have been used instead of WP_Users.

    Otherwise check if someone is logged in. If they are, give them automatic access to index.php, instead of checking their capabilities. That's assuming something about index.php is breaking it.

    I haven't looked to see what might be best.

  11. kolen
    Member
    Posted 15 years ago #

    After i put into config:

    define('ADMIN_COOKIE_PATH', '/');
    define('COOKIE_DOMAIN', '');
    define('COOKIEPATH', '');
    define('SITECOOKIEPATH', '');

    everything becomes to work correct.
    I have mixed domain/subdirectory blog setup.

  12. buckyreal
    Member
    Posted 15 years ago #

    Same problem here. Same solution, defined the cookie stuff.

  13. thunderchld
    Member
    Posted 15 years ago #

    I am having this problem as well. I have tried everything listed here, as well as numerous other solutions, and nothing as worked so far.

    Can anyone suggest anything else?

  14. VentureMaker
    Member
    Posted 15 years ago #

    thunderchld, what error(s) do you get?

  15. andrea_r
    Moderator
    Posted 15 years ago #

    thunderchld - other than the logging in, can you access the front end of the sub-blogs?

  16. michael.souris
    Member
    Posted 15 years ago #

    Defining the cookie stuff:

    define('ADMIN_COOKIE_PATH', '/');
    define('COOKIE_DOMAIN', '');
    define('COOKIEPATH', '');
    define('SITECOOKIEPATH', '');

    Worked for me too - 2.7, with multiple domains and blogs.

About this Topic

  • Started 15 years ago by keppy
  • Latest reply from michael.souris