WordPress.org

Make WordPress Core

Opened 20 months ago

Closed 19 months ago

Last modified 19 months ago

#42489 closed defect (bug) (fixed)

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

Reported by: bwmarkle Owned by: westonruter
Milestone: 4.9 Priority: normal
Severity: normal Version: 4.9
Component: Customize Keywords: has-patch commit dev-reviewed
Focuses: Cc:

Description

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.

Attachments (1)

42489.diff (1.4 KB) - added by westonruter 20 months ago.

Download all attachments as: .zip

Change History (16)

#1 @westonruter
20 months ago

  • Component changed from General to Customize
  • Owner set to westonruter
  • Status changed from new to accepted

#2 @westonruter
20 months ago

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.

#3 @westonruter
20 months ago

  • Milestone changed from Awaiting Review to 4.9

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

@westonruter
20 months ago

#4 @westonruter
20 months ago

  • Keywords has-patch needs-testing added

@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

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


20 months ago

#6 @designsimply
20 months ago

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.

  1. Log out.
  2. Log back in as an admin.
  3. 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!

#7 @westonruter
20 months ago

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

#8 @dlh
20 months ago

Tested 42489.diff and it worked as expected.

#9 @westonruter
20 months ago

  • Keywords dev-feedback commit added; needs-testing removed

This ticket was mentioned in Slack in #core-committers by westonruter. View the logs.


20 months ago

This ticket was mentioned in Slack in #core-committers by westonruter. View the logs.


19 months ago

#12 @obenland
19 months ago

  • Keywords dev-reviewed added; dev-feedback removed

Makes sense, LGTM 👍

#13 @designsimply
19 months ago

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

#14 @westonruter
19 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#15 @westonruter
19 months ago

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.

Note: See TracTickets for help on using tickets.