New pages scheduled via Customizer trashed when changeset publish triggered by visitor

[bwmarkle]

Here is the bug I believe:
When a page is scheduled (via the Customizer) to be published, it is only published if the customize_changeset publishing is triggered by a user with permission to do so. When a visitor to the site triggers wp-cron.php > check_and_publish_future_post, the page is instead trashed.

I posted a Google Doc with steps to reproduce and screenshots here:
​https://docs.google.com/document/d/1HtSemFofPAmYbDReit-zygmlKcvHo6ACQpZJGvEdwY8/edit?usp=sharing

If the document is unreachable, here are the steps from the doc:
# I just installed a brand new WordPress site via Softaculous.
# I used the WordPress Beta plugin to install WordPress 4.9-RC2-42139.
# Via the Customizer, I added a new page to a menu, “Test Page 1”. (Menus > Top Menu > Add Items > (Add New Page) Test Page 1 > Add.
# I scheduled to publish the changes in 5 minutes.
# Before that 5 minutes comes, I can see my Test Page 1 is a Customization Draft.
# I log out.
# When the time comes for the scheduled changes to be published, I access the front page a few times to run the scheduled cron.
# 2 minutes after the scheduled time for the change to go live, I login to the dashboard.
# I go to Pages > All Pages > Trash, and my “Test Page 1” has been trashed, instead of published.

I believe this bug is triggered by the check_capabilities method in wp-includes/class-wp-customize-setting.php:
​https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-customize-setting.php#L811-L826
When a visitor to the site triggers wp-cron.php > check_and_publish_future_post, the current_user_can calls return false, and so the page is not published.

[westonruter]

The the capability check is supposed to be accounted for by changing the current user and overriding the capability during publishing (since it was previously checked when the changeset was written to): ​https://github.com/WordPress/wordpress-develop/blob/c994a2e9bb094e51506e600aa1fc3862c63a934c/src/wp-includes/class-wp-customize-manager.php#L3342-L3377

If this is not working, it needs to be fixed.

[westonruter]

I just tried to reproduce the problem, after a second attempt. I'm investigating.

[westonruter]

@bwmarkle Thank you very much for your detailed test case and report. I've identified the problem and it makes complete sense why it wasn't working when not logged-in. The \WP_Customize_Nav_Menus::save_nav_menus_created_posts() handler was not getting added to the customize_save_nav_menus_created_posts if the current user cannot edit_theme_options. By moving this add_action() call up then it successfully triggers when the changeset is published without an authenticated users. Please apply 42489.diff​ and attempt to re-reproduce the problem.

Test script I put together to automate the steps to reproduce: ​https://gist.github.com/westonruter/a38db7bd13a8d58695a66453570338de

[designsimply]

Tested and confirmed using the 4.9 branch r165236 on WordPress.com and Firefox 56.0.2 on Mac OS X 10.12.6.

Steps to reproduce:

1. Log in as an admin.
2. Go to Customize > Menus > Add Items > Add New Page.
3. Create a new page.
4. Schedule the customizer changes for 5 minutes in the future.
5. Wait for the scheduling to happen.
6. Log in as a contributor.
7. View the front end of the blog.

Result: the scheduled customizer change (new menu item) is visible but clicking on it results in a page not found error.

8. Log out.
9. Log back in as an admin.
10. View the front end of the blog.

Result: the page is now visible and no longer displays a page not found error.

Nice find @bwmarkle!

[westonruter]

@designsimply To confirm, you just tested with the 42489.diff​ patch applied and you confirm it fixes the issue?

[dlh]

Tested 42489.diff​ and it worked as expected.

[obenland]

Makes sense, LGTM 👍

[designsimply]

@westonruter I tested 42489.diff just now and LGTM.

[westonruter]

In 42148:

Customize: Ensure customization drafts are published instead of trashed when scheduled changeset goes live while non-admin user is authenticated (such as during WP Cron).

Props designsimply for testing, dlh for testing, melchoyce for testing.
See #28721, #34923, #42220.
Fixes #42489 for trunk.

[westonruter]

In 42149:

Customize: Ensure customization drafts are published instead of trashed when scheduled changeset goes live while non-admin user is authenticated (such as during WP Cron).

Props designsimply for testing, dlh for testing, melchoyce for testing.
See #28721, #34923, #42220.
Fixes #42489 for 4.9.