[wp-trac] [WordPress Trac] #36879: Allow post data to be filtered if is_customize_preview()
WordPress Trac
noreply at wordpress.org
Wed May 18 17:58:39 UTC 2016
#36879: Allow post data to be filtered if is_customize_preview()
-------------------------+-----------------
Reporter: westonruter | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: 4.6
Component: Customize | Version:
Severity: normal | Keywords:
Focuses: |
-------------------------+-----------------
This was originally reported as an an [https://github.com/xwp/wp-
customize-posts/issues/96 issue] in the [https://github.com/xwp/wp-
customize-posts Customize Posts] feature plugin for #34923. The plugin
currently previews post data via the `the_posts` filter. This is
problematic, however, because this filter is not called in queries with
`suppress_filters` on or in calls to `get_post()`:
> When querying posts via `get_posts()` or when using `new WP_Query(
array( 'suppress_filters' => true ) )`, the `the_posts` filters which
apply the previewed changes to the posts is not run. This is a problem
with Core in that there are not always filters applied to post data. This
necessitates, for example, for there to be a `comments_open` filter in
addition to a `the_posts` filter, since `get_post()` will return a
pristine copy of the post without any hooks for Customize Posts to apply
the previewed changes. In reality, `get_post()` should be returning the
dirty post as opposed to the pristine post, and so an additional
`comments_open` filter wouldn't be needed.
>
> So, what is needed is a new filter to run whenever getting a post via
`get_post()` to allow the array or object to be mutated. This filter can
only be applied if `is_customize_preview()` since applying such a filter
generally could be too far reaching.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/36879>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list