Brain imploding trying to get bedrock + bedrock-ansible running... please help

bedrock
6

Argh.

Managed to connect via sequel pro using your instructions (massive thanks for that!), and even after setting a new password using:

  UPDATE (wp_users) SET user_pass = MD5('pork') WHERE ID = (1);

…I still can’t log in. This is baffling.

I just keep getting presented with a fresh login screen at…

http://example.dev/wp/wp-login.php?redirect_to=http%3A%2F%2Fexample.dev%2Fwp-admin%2F&reauth=1

The reauth=1 arg in that URL is making me think that somehow the ansible/bedrock wp install isn’t setting the proper login cookie(s)?

7

Strange. This area isn’t my expertise (as if anything were my epertise!). But I haven’t heard of that login problem happening with bedrock-ansible.

  • Does your install of wp-cli seem to be in working order and up-to-date?
  • There weren’t any errors in the log after vagrant up?
8

  • wp-cli is working to the best of my knowledge — was installed fresh for another project circa yesterday, and seems fine. also, presumably, when being run from inside the vm, I’d assume that wp-cli is using a copy installed on the vm itself, not my local copy. It’s perplexing.

  • I’m going to guess that wp-cli commands run from the host are failing due to some kind of pathing error, but I can’t find any clarity on how to resolve that — particularly since with bedrock I’m still pretty unclear where wp-cli would even find the db information to connect properly, since that’s been abstracted out of wp-config

  • where would I find the log in question? I watched the vagrant up run each time and didn’t witness any explosions, but the log might show something different?

Thanks,
T

9

wp-cli: You’re totally right. Bedrock-ansible installs its own copy. Sorry about that.

log: I just meant the terminal output, sorry. You’d have noticed errors in red. I shouldn’t have mentioned it.

I think I’ll be better troubleshooting after some rest. Sorry.

10

I’m now officially certain that the password IS being setup correctly —but then getting booted out immediately after login, and sent back to the login screen.

Just tested with an incorrect password, and I get a password error. Tested with the pass configured in group_vars/development, on the other hand, and finally realized that it fails back to the login screen silently — no login error.

What the actual…

11

No worries, and again, sincere thanks!

12

Not sure, but maybe the WP logs in /srv/www/sample.com/logs would have info.

13

This has happened to me when I had similar issues with Multisite. Clear your cache, including cookies, and I think you should be able to login.

2 Likes
14

I’m… getting even more perplexed.

I tried switching browsers (was using FF, so tried chrome), and I got the following:

Cookies are most certainly not disabled. Other non-bedrock wp sites work fine. This is bananas.

15

Is this back to a multi site install?

16

Yes — multisite.

Thankfully, I seem to have been able to make a bit of progress here, and did manage to get a multisite bedrock-ansible + bedrock installation running, and accepting login credentials. phew. Not really sure what did the trick, however, unless there’s some inherent issue with using example.dev verbatim — switching to a distinct url across the board, coupled with the steps articulated at the multisite wiki entry linked above plus god knows what else seemed to work in the end.

Still wrestling with the wp-cli stuff however. I’ll break the WP-CLI issue and some other questions I’ve got into separate discussions.

Thanks for all the help folks!

17

I am having the same issue. Is the only way you fixed this is by using multisite support?

Thanks!

18

Have you defined DOMAIN_CURRENT_SITE on your .env file and on your group_vars/development?

Also, on your config/application.php you should have something like this somewhere in the code.


    /**
     * Wordpress Multisite
     */
    define('WP_ALLOW_MULTISITE', true);
    define('MULTISITE', true);
    define('SUBDOMAIN_INSTALL', true); // Set to false if using subdirectories
    define('DOMAIN_CURRENT_SITE', getenv('DOMAIN_CURRENT_SITE'));
    define('PATH_CURRENT_SITE', '/');
    define('SITE_ID_CURRENT_SITE', 1);
    define('BLOG_ID_CURRENT_SITE', 1);
19

Hello,

Just my two cents because I stumbled on this post having quite a similar issue yesterday.
When trying to access example.dev/wp-admin, I was redirected to /wp/wp-login.php and after logging in, I was presented with the login page with the same URL as you with no message :
http://example.dev/wp/wp-login.php?redirect_to=http%3A%2F%2Fexample.dev%2Fwp-admin%2F&reauth=1

What I finally did was trying to access /wp/wp-admin instead of /wp-admin, which worked.
I hope you’re in the same case :slight_smile: !

For more informations (if this happens to be the same issue), I don’t think I encountered the issue installing bedrock-ansible on my mac but did on windows.

20

Hi jchapron, first of all, your question doesn’t really have anything to do with this thread. If you have a question, you can post your own topic.

Secondly, yes, since WordPress is installed to wp in a default Bedrock installation, going to /wp/wp-admin is the correct way to do it.

21

Hi Kalen,

I’m truly sorry if I didn’t grasp the right topic of this thread or misused discourse in any way.
To clarify, I wasn’t asking anything, I was trying to help @timichango with his login error.
I noticed that the “redirect_to” attribute in the URL he provided was to “/wp-admin”, not “/wp/wp-admin”, which redirects to /wp/wp-login with no user feedback which is what he seemed to experience.

Given your answer, I probably misunderstood the issue at stake here and I apologise once again for interfering.

22

Hey jchapron, no sorry my mistake, I thought you were asking your own question. Thank you for helping out :slight_smile:

23

Thank you for this. +1 to add this to the docs.

24

Or you can bypass all that which is what I normally do before provisioning and go into trellis/roles/nginx/templates and edit wordpress.conf switching out

location / {
  try_files $uri $uri/ /index.php?$args;
}

for

 location / {
    try_files $uri $uri/ /index.php?$args;
  }
  rewrite ^/(wp-.*.php)$ /wp/$1 last;
  rewrite ^/(wp-(content|admin|includes).*) /wp/$1 last;
  location ~* ^.+\.(jpe?g|gif|js|css|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mp3)$ {
    expires 30d;
    rewrite ^/(wp-(content|admin|includes).*) /wp/$1 break;
  }

Then you are able to swap out in your wordpress_sites file

wp_home: http://example.dev
wp_siteurl: http://example.dev/wp

for

wp_home: http://example.dev
wp_siteurl: http://example.dev

Then your multisite functions just like it wasn’t set up in a subfolder and it drops all instances of the /wp/ out of all your links, you can go right in between network admin and sites, I used to have to manually go in and add /wp/ into the database because it would never get confirmed right for multisite, and I would get white screens in between network and site admin areas.

Just for reference my code snippet came from

I have been using it for months on multisites live and in development never a problem. Any reason you guys don’t use something like this standard? Makes it seem much more fluid in my opinion for users and admins

2 Likes
25

Oh and for the WP-CLI errors you just need to pass --url=example.dev at the end of your command, for multisite it doesn’t know what site it is supposed to be targeting so you just tell it the root domain, then commands work as expected

Also I have found I need to be in the /web/ folder with the wp-config file, even though there is a wp-cli config file telling it where your wp-config file is, this only happens to me sometimes, 90% for the time now if it has to do with the database I just jump into mysql -u root -p and just do what I need to do because wp-cli and multisite I do not think is perfect by any means