Skip to content
This repository has been archived by the owner on Jan 2, 2020. It is now read-only.

getContentFromTitle does not return the expected result when sticky posts are published #218

ataylorme opened this issue Oct 3, 2018 · 4 comments · Fixed by #226


Copy link

Expected behavior

Describe the bug; what should happen?

getContentFromTitle does not return the correct post when using an exact-match title parameter.

Current behavior

What happens instead of the expected behavior?

A seemingly random, incorrect post is returned

Possible solution

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

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. Have a Give donation form with the title "San Diego Refugees Donation"
  2. Also have others content posts
  3. Use Given I am on the edit screen for "San Diego Refugees Donation" in the Background of a feature
  4. Add Then I should see "San Diego Refugees Donation" in the "title" element to the Scenario of the same feature
  5. The feature test will fail


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 attempting to write custom tests for the Give donation form to provide a real-world WordHat example

I am using the wpcli driver but have tried the php driver locally as well.

I also created a custom step that passes $post_type as well to getContentFromTitle and still got an incorrect post back.

None of my tests are using JavaScript due to similar issues as outlined in #182 with admin login issues in a headless (Docker) environment.

In CircleCI the wpcli driver is being run against a remote URL on Pantheon, not a local URL. When testing locally the wpcli driver is used but against a local WordPress installation.

Your environment

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

  • WordHat version used: 3.0.0
  • Environment name and version (e.g. PHP 7.1 on nginx 1.11.9): Running tests locally and in CircleCI on this Dockerfile
  • Server operating system type and version: N/A
  • Type of Behat browser used (e.g. Selenium, headless Chrome, etc): goutte
  • Link to your project: The code is in this PR
  • Failing CircleCI build
Copy link
Contributor Author

@paulgibbs here is a better failure example.

I tracked this down to sticky posts. I am using the wp-cli driver and even when running wp-cli commands directly outside of Behat sticky a post shows up when I expect a different post as the result when using wp post list.

I think this is a result of wp-cli running WP_Query and the default functionality of WP_Query to be returning sticky posts unless ignore_sticky_posts is set to true.

I'm not familiar enough with the drivers to know:

  • whether this applies to the PHP driver as well
  • whether it is possible to set ignore_sticky_posts to true in the wp-cli driver
  • any adverse effects of setting ignore_sticky_posts to true in the wp-cli driver

@ataylorme ataylorme changed the title getContentFromTitle does not return the expected result getContentFromTitle does not return the expected result when sticky posts are published Oct 4, 2018
@paulgibbs paulgibbs added the bug label Nov 30, 2018
@paulgibbs paulgibbs self-assigned this Nov 30, 2018
@paulgibbs paulgibbs added this to the 3.1 milestone Nov 30, 2018
paulgibbs added a commit that referenced this issue Nov 30, 2018
This prevents the underlying `WP_Query` in WP-PHP driver and WP-CLI itself
returning sticky posts when retriving a post ID by post title, as seen with
the "I am on the edit screen for" step definition.

This does not affect intentionally retrieving sticky posts in this way.

Fixes #218
Copy link

Hi. Yep, you found the correct fix.

I've tested this, and the underlying queries, as best as I can, and it is safe to always set ignore_sticky_posts for both drivers, so that's what I've done in the attached PR.

Copy link

Sorry for taking a while to look at this

Copy link
Contributor Author

Great, thanks @paulgibbs. It threw me off for a while before I figured out what was going on.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

Successfully merging a pull request may close this issue.

2 participants