wp-login.php path hard-coded, site_url Behat parameter not used

[ataylorme]

Expected behaviour

Describe the bug; what should happen?

When using WordHat on a site with WordPress core in a subdirectory I should be able to log in.

Current behaviour

What happens instead of the expected behaviour?

Intermittent login failures due to WordHat not using the set} /wp subdirectory when navigating to the WP admin.

According to the installation docs if WordPress is in a subdirectory the site_url parameter should be set.

However, site_url is not used when navigating to the login page. Instead the wp-login.php path is hard-coded.

Possible solution

Not obligatory, but you can suggest a fix/reason for the bug. Thanks!

Update path in the login page object from wp-login.php to $this->getWordpressParameter('site_url') . '/wp-login.php.

Similarly in the UserAwareContextTrait update the visitPath call to use the site_url parameter.

path is also hard-coded in the DashboardPage object

Steps to reproduce

Provide a link to a live example, or an unambiguous set of steps to reproduce this bug. Include code to reproduce, if relevant.

1. Install WordPress core in a subdirectory, such as /wp. I do this when managing WordPress projects with Composer
2. Run Behat with the Headless Chrome Driver
3. Set up a test that authenticates as an administrator and visits the dashboard (example).
4. Watch the test fail intermittently. My guess is due to multiple redirects (wp-login.php to wp/wp-login.php, back to the page prior to login, wp-admin/index.php to wp/wp-admin/index.php, etc.)

Context

How has this issue affected you? What are you trying to accomplish? Providing context helps us come up with a solution that is most useful in the real world.

I am trying to write tests that interact with the WordPress admin. I had to look at the WordHat source code for logging in and recreate it, using the correct paths. My tests now pass consistently but I would much rather use the WordHat contexts then to have to recreate/maintain my own.

Your environment

Include as many relevant details about the environment you experienced the bug in:

• WordHat version used: 3.3.0
• Environment name and version (e.g. PHP 7.2 on nginx 1.11.9): This Dockerfile on CircleCI (PHP 7.2 + Headless Chrome)
• Server operating system type and version:
• Type of Behat browser used (e.g. Selenium, headless Chrome, etc): Headless Chrome
• Link to your project:
  • Failing build
  • Passing build using custom login context
  • Custom login context code

[paulgibbs]

Thanks, I'll look at your report soon -- I'm pretty busy over here at the moment.

[paulgibbs]

I've not had issues with this on a site I have that runs WP in a subdirectory, so once I've got a few bug fixes in, I will come back here and look at this a bit deeper.

[ataylorme]

@paulgibbs no rush since I have a workaround. I think the intermittent failures were happening due to the path WordHat goes to for login pages being incorrect and then having to follow redirects to get to the correct path.

Even if/when it does work, following redirects, it seems like a bug.