wpseek.com
Eine auf WordPress spezialiserte Suchmaschine für Entwickler und Theme-Autoren
_wp_customize_publish_changeset is private and should not be used in themes or plugins directly.
_wp_customize_publish_changeset › WordPress Function
Seit4.7.0
Veraltetn/v
› _wp_customize_publish_changeset ( $new_status, $old_status, $changeset_post )
Zugriff: |
|
Parameter: (3) |
|
Definiert in: |
|
Codex: |
Publishes a snapshot's changes.
Quellcode
function _wp_customize_publish_changeset( $new_status, $old_status, $changeset_post ) { global $wp_customize; $is_publishing_changeset = ( 'customize_changeset' === $changeset_post->post_type && 'publish' === $new_status && 'publish' !== $old_status ); if ( ! $is_publishing_changeset ) { return; } if ( empty( $wp_customize ) ) { require_once ABSPATH . WPINC . '/class-wp-customize-manager.php'; $wp_customize = new WP_Customize_Manager( array( 'changeset_uuid' => $changeset_post->post_name, 'settings_previewed' => false, ) ); } if ( ! did_action( 'customize_register' ) ) { /* * When running from CLI or Cron, the customize_register action will need * to be triggered in order for core, themes, and plugins to register their * settings. Normally core will add_action( 'customize_register' ) at * priority 10 to register the core settings, and if any themes/plugins * also add_action( 'customize_register' ) at the same priority, they * will have a $wp_customize with those settings registered since they * call add_action() afterward, normally. However, when manually doing * the customize_register action after the setup_theme, then the order * will be reversed for two actions added at priority 10, resulting in * the core settings no longer being available as expected to themes/plugins. * So the following manually calls the method that registers the core * settings up front before doing the action. */ remove_action( 'customize_register', array( $wp_customize, 'register_controls' ) ); $wp_customize->register_controls(); /** This filter is documented in wp-includes/class-wp-customize-manager.php */ do_action( 'customize_register', $wp_customize ); } $wp_customize->_publish_changeset_values( $changeset_post->ID ); /* * Trash the changeset post if revisions are not enabled. Unpublished * changesets by default get garbage collected due to the auto-draft status. * When a changeset post is published, however, it would no longer get cleaned * out. This is a problem when the changeset posts are never displayed anywhere, * since they would just be endlessly piling up. So here we use the revisions * feature to indicate whether or not a published changeset should get trashed * and thus garbage collected. */ if ( ! wp_revisions_enabled( $changeset_post ) ) { $wp_customize->trash_changeset_post( $changeset_post->ID ); } }