Feature: Allow publishing from preview #115
Conversation
js/customize-snapshots-front.js
Outdated
| } | ||
| request = wp.ajax.post( component.data.action, { | ||
| nonce: component.data.snapshotsFrontendPublishNonce, | ||
| uuid: component.data.uuid |
There was a problem hiding this comment.
Should this also include theme? Would not a theme switch also be needing to be accounted for here?
There was a problem hiding this comment.
Added.
One thought: maybe it would be useful to include the theme param into the preview link in Customizer in case a non-active theme is being customized? Otherwise I change the theme, customize it, click on preview icon, and end up previewing the active theme. Thoughts?
There was a problem hiding this comment.
Ah, okay, just saw that this will basically be part of #101. Will pick that up.
There was a problem hiding this comment.
The only hesitation to including the theme in the preview link is that if a user is not authenticated they won't be able to access the preview, since previewing a theme switch requires the switch_themes capability.
| ); | ||
| wp_add_inline_script( | ||
| $handle, | ||
| sprintf( 'CustomizeSnapshotsFront.init( %s )', wp_json_encode( $exports ) ), |
| } | ||
| $wp_admin_bar->add_menu( array( | ||
| 'id' => 'publish-customize-snapshot', | ||
| 'title' => __( 'Publish Snapshot', 'customize-snapshots' ), |
There was a problem hiding this comment.
Rename to “Publish Changeset”
| $msg = __( 'Publishing failed: ', 'customize-snapshots' ); | ||
| foreach ( $r->errors as $name => $value ) { | ||
| $msg .= $name . '; '; | ||
| } |
There was a problem hiding this comment.
This could be replaced with: $msg .= join( "; ", array_keys( $r->errors ) ). But is the it the key or the values that have the error messages to share?
There was a problem hiding this comment.
The keys seem to include the error messages.
| return; | ||
| } | ||
|
|
||
| $this->current_snapshot_uuid = esc_attr( $_POST['uuid'] ); |
There was a problem hiding this comment.
Replace esc_attr( $_POST['uuid'] ) with sanitize_key( wp_unslash( $_POST['uuid'] ) ).
| * These files control the behavior frontend. | ||
| */ | ||
| public function enqueue_frontend_scripts() { | ||
| if ( ! $this->snapshot ) { |
There was a problem hiding this comment.
This also needs to short-circuit if the current user cannot publish changesets. In other words:
if ( ! $this->snapshot || ! current_user_can( get_post_type_object( 'customize_changeset' )->cap->publish_posts ) ) {| * Publishes changeset from frontend. | ||
| */ | ||
| public function ajax_snapshot_frontend_publish() { | ||
| if ( ! check_ajax_referer( 'customize-snapshots-frontend-publish', 'nonce' ) ) { |
There was a problem hiding this comment.
Also important to check whether current_user_can( get_post_type_object( 'customize_changeset' )->cap->publish_posts )
|
@westonruter The changes should be done, let me know if there's anything that still needs improving. |
|
I'm waiting to do a final review and merge thus until 0.6.0 is released. |
js/customize-snapshots-front.js
Outdated
| if ( ! window.confirm( component.data.confirmationMsg ) ) { // eslint-disable-line no-alert | ||
| return false; | ||
| } | ||
| if ( ! wp.customize.settings.theme.active ) { |
There was a problem hiding this comment.
@westonruter After merging develop there is an issue with publishing changeset from preview:
Looks like wp.customize is not defined at this moment. Do you know if anything changed meanwhile in the logic or order of enqueuing the JS scripts? Tried to make the script dependent on customize-base but in this case wp.customize.settings is undefined.
Would be great if you could point out what to investigate or what might have changed to cause this issue. Not sure what I'm missing here, maybe it's something very obvious.
There was a problem hiding this comment.
This wp.customize.settings value is actually set in customize-preview (and customize-controls) not customize-base.
Note that it is set at jQuery.ready.
But since you'd be clicking the button after jQuery.ready anyway, I don't see why you it would be undefined. Is customize-preview itself not getting enqueued? It should be if you've loaded a changeset on the frontend.
There was a problem hiding this comment.
Seems like the issue was because I was using the param changeset_uuid=... instead of customize_changeset_uuid in frontend.
Note that customize-snapshots-frontend.js file was added to develop branch so I merged the frontend JS file from this branch (customize-snapshots-front.js) into the one in develop (customize-snapshots-frontend.js). Let me know if there are any concerns with that. Also added removing the UUID from storage after publishing.
There is another issue with publishing the changesets from frontend:
WP_Customize_Setting::_preview_filter is returning the dirty value as old value instead of the actual old value in DB meaning that the setting is not saved when publishing.
Although I can see that Post_Type::hooks() is adding this filter:
add_action( 'transition_post_status', array( $this, 'start_pretending_customize_save_ajax_action' ), $priority - 1, 3 );, this method is always returning true: WP_Customize_Setting::is_current_blog_previewed().
Looks like WP_Customize_Manager is initialized in _wp_customize_include() before the filters have any effect. Also, not sure if https://github.com/xwp/wordpress-develop/pull/231 would fix that since the $_REQUEST['action'] is not customize_save at that moment.
Am I missing something or is creating another workaround necessary, e.g. reinitializing WP_Customize_Manager?
Yes, that's perfect.
If I understand right, this is the exact same problem that you've patched for core, right? In other words: https://core.trac.wordpress.org/ticket/39221 The issue is that Ajax requests on the frontend get the So if you can prevent this from happening via another Another option, perhaps a better one, would be to eliminate the Ajax request entirely in favor of just linking to an admin URL that would be responsible for publishing the changeset. In other words, it could be a This would avoid having to try to override the |
|
@westonruter Reworked the logic to use |
… into feature/allow_publishing_from_preview
Resolves #103 .