This adds three new functions for getting/displaying attachment captions:
* `wp_get_attachment_caption` - Retrieves a caption for a specific attachment.
* `get_the_post_thumbnail_caption()` - Returns the post thumbnail caption.
* `the_post_thumbnail_caption()` - Displays the post thumbnail caption.
These are helpful for displaying a caption associated with an image directly
in a template, rather than using the caption shortcode.
This also introduces two new filters:
* `wp_get_attachment_caption` - Filters the value of `wp_get_attachment_caption()`.
* `the_post_thumbnail_caption` - Filters the display of the post thumbnail caption.
`the_post_thumbnail_caption()` is automatically filtered by `wptexturize()`,
`convert_smilies()`, and `convert_chars()` in `wp-includes/default-filters.php`.
Props flixos90, joemcgill.
Fixes#12235.
Built from https://develop.svn.wordpress.org/trunk@37915
git-svn-id: http://core.svn.wordpress.org/trunk@37856 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changes the global `$wp_post_types` to an array of `WP_Post_Type` objects. `WP_Post_Type` includes methods to handle post type supports, rewrite rules, meta boxes, hooks, and taxonomies.
Each post type argument becomes a property of `WP_Post_Type`.
Props swissspidy, flixos90.
Fixes#36217.
Built from https://develop.svn.wordpress.org/trunk@37890
git-svn-id: http://core.svn.wordpress.org/trunk@37831 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Known functions, classes, and methods are now auto-linked in Code Reference pages following #meta1483.
Note: Hook references are still linked via inline `@see` tags due to the unlikelihood of reliably matching for known hooks based on a RegEx pattern.
See #32246.
Built from https://develop.svn.wordpress.org/trunk@37342
git-svn-id: http://core.svn.wordpress.org/trunk@37308 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Percent signs are reserved characters in URIs. As such, it was impossible for
plugins to route requests to trashed posts, as happens in bbPress. The new
`__trashed` suffix should be sufficiently unique.
Also adds a test that demonstrates that the `__trashed` suffix can be
appended to slugs that contain the suffix somewhere other than the end of
the string.
Props netweb, ericlewis.
Fixes#11863.
Built from https://develop.svn.wordpress.org/trunk@37165
git-svn-id: http://core.svn.wordpress.org/trunk@37132 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When determining a unique post slug, trashed posts are taken into account. Previously, new posts would add suffixes to their slugs (e.g. `about-2`) when a post in the trash had the desired slug (e.g. `about`).
To avoid this behavior, when a post is trashed its slug (i.e. `post_name`) is now suffixed with `-%trashed%`. The post's pre-trash slug is stored as post meta, and if the post is restored from trash, its desired slug is reapplied.
For existing trashed posts which don't have the `-%trashed%` suffix, the suffix is added when a post with its desired slug is created.
Props ocean90, boonebgorges, ryan, SergeyBiryukov, coffee2code, helen, williamsba1.
See #11863.
Built from https://develop.svn.wordpress.org/trunk@36607
git-svn-id: http://core.svn.wordpress.org/trunk@36574 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Comment and term meta lazyloading for `WP_Query` loops, introduced in 4.4,
depended on filter callback methods belonging to `WP_Query` objects. This meant
storing `WP_Query` objects in the `$wp_filter` global (via `add_filter()`),
requiring that PHP retain the objects in memory, even when the local variables
would typically be expunged during normal garbage collection. In cases where a
large number of `WP_Query` objects were instantiated on a single pageload,
and/or where the contents of the `WP_Query` objects were quite large, serious
performance issues could result.
We skirt this problem by moving metadata lazyloading out of `WP_Query`. The
new `WP_Metadata_Lazyloader` class acts as a lazyload queue. Query instances
register items whose metadata should be lazyloaded - such as post terms, or
comments - and a `WP_Metadata_Lazyloader` method will intercept comment and
term meta requests to perform the cache priming. Since `WP_Metadata_Lazyloader`
instances are far smaller than `WP_Query` (containing only object IDs), and
clean up after themselves far better than the previous `WP_Query` methods (bp
only running their callbacks a single time for a given set of queued objects),
the resource use is decreased dramatically.
See [36525] for an earlier step in this direction.
Props lpawlik, stevegrunwell, boonebgorges.
Fixes#35816.
Built from https://develop.svn.wordpress.org/trunk@36566
git-svn-id: http://core.svn.wordpress.org/trunk@36533 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously when updating a post using wp_insert_post(), post_name was
regenerated based on post_title every time if post_name was not passed in
explicitly. This irons out the expectation that properties not passed into the
function should not be modified.
Props jason_the_adams.
Fixes#34865.
Built from https://develop.svn.wordpress.org/trunk@35800
git-svn-id: http://core.svn.wordpress.org/trunk@35764 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Introduce `is_post_type_viewable( $post_type_object )`
* Separate the HTML bits from the translatable bits in the `post` messages array in `edit-form-advanced.php`
* Don't show certain UI pieces when a post is not viewable on the front end
When a custom post type item is not viewable on the front end, we don't want to show links to View it (on the front end) all over the admin. We also want to hide the Preview link, et al. We also want our admin messages to not contain said links.
Custom post types with `public_queryable` set to `false` are not viewable on the front end.
`'page'` is viewable on the front end, but `'page'` is a `_builtin` type, and `public_queryable` is set to `false` when it is registered - see `WP::parse_request()` for when `public_queryable` gets used.
This is confusing, but also somewhat straightforward: to determine if a post type is viewable on the front end, we can check one way for `_builtin => true` and another way for `_builtin => false`:
`$post_type->publicly_queryable || ( $post_type->_builtin && $post_type->public )`
If a post type is `publicly_queryable`, it's viewable. If that value is `false`, it is viewable if it's a `_builtin` type that is also `public`.
I am in search of edge cases, so this shall land.
Props wonderboymusic, DrewAPicture.
See #17609.
Built from https://develop.svn.wordpress.org/trunk@33666
git-svn-id: http://core.svn.wordpress.org/trunk@33633 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If the post cache is not cleared at this point, the cache can become stale
for operations performed before the cache is cleared later in the function.
Specifically, the generation of a `guid` for new posts can use stale data,
resulting in non-unique values. [33262] introduced a call to `get_post()`
that introduced just such an invalidation problem.
Fixes#5305.
Built from https://develop.svn.wordpress.org/trunk@33630
git-svn-id: http://core.svn.wordpress.org/trunk@33597 1a063a9b-81f0-0310-95a4-ce76da25c4cd
On certain permalink structures, a numeric post slug will result in a post
permalink that conflicts with a date archive URL. For example, with permastruct
`/%year%/%monthnum%/%postname%/`, a post published in May 2015 with slug
`'15'` will result in a URL (`/2015/05/15/`) that conflicts with the archive
for May 15, 2015.
To avoid this problem, `wp_unique_post_slug()` rejects a requested slug when it
would generate a conflict of this type. Thus, in our example, `'15'` would
become `'15-2'`.
Props valendesigns, boonebgorges, Denis-de-Bernardy, loushou.
See #5305.
Built from https://develop.svn.wordpress.org/trunk@32647
git-svn-id: http://core.svn.wordpress.org/trunk@32617 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Clarify `@return` values where necessary.
In `wp_delete_post_revision()`, `wp_delete_post()` doesn't return `WP_Error`, so that check can be removed.
`wp_revisions_to_keep()` always returns an `int`, so `wp_revisions_enabled()` can use strict comparison.
See #32444.
Built from https://develop.svn.wordpress.org/trunk@32621
git-svn-id: http://core.svn.wordpress.org/trunk@32591 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The new algorithm uses a hash table rather than function recursion, reducing
complexity to O(N). On large numbers of pages, the performance improvement is
several orders of magnitude.
Props santagada, hailin, mihai.
Fixes#10852.
Built from https://develop.svn.wordpress.org/trunk@32355
git-svn-id: http://core.svn.wordpress.org/trunk@32326 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Detecting SSL status on the Dashboard introduces problems when writing content
that is saved to the database and then displayed on the front end, where SSL
may be optional (or impossible, due to self-signed certificates). The new
approach parallels the logic in `get_home_url()` for forcing HTTPS.
See [31614] #15928 for background.
Fixes#32112 for trunk.
Built from https://develop.svn.wordpress.org/trunk@32342
git-svn-id: http://core.svn.wordpress.org/trunk@32313 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Replace exisiting smilies with equivalent emoji, or with shiny new smiley images where no emoji existed.
Props batmoo, joen and mkaz for the original plugin upon which this is based.
Props pento, iseulde, kraftbj and peterwilsoncc for making the internet's dreams come true.
See #31242
Built from https://develop.svn.wordpress.org/trunk@31733
git-svn-id: http://core.svn.wordpress.org/trunk@31714 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change makes the 'post_type' clause in `wp_list_authors()` redundant, so
we remove it. Third-party plugins using `get_posts_by_author_sql()` may have
similarly redundant clauses, but this won't change the results returned by the
SQL queries.
Also adds unit tests for `get_posts_by_author_sql()`.
Props pbearne.
Fixes#30354.
Built from https://develop.svn.wordpress.org/trunk@31653
git-svn-id: http://core.svn.wordpress.org/trunk@31634 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`wp_get_attachment_url()`, via `wp_upload_dir()`, uses 'siteurl' to generate
attachment URLs. When a site is SSL-optional on the front end - ie, 'siteurl'
is non-HTTPS, but SSL is available - a number of situations can arise where
non-HTTPS attachment URLs cause browser mixed-content warnings:
a) SSL is forced in the admin and `wp_get_attachment_url()` is used to generate the `<img>` tag for an inserted image. In these cases, the post content will contain non-HTTPS. Viewing/editing this post in the Dashboard will result in non-HTTPS images being served in an SSL environment.
b) `wp_get_attachment_url()` is used in a theme to generate an `<img>` `src` attribute on a public page. When viewing that page over SSL, the images will have HTTP URLs.
This changeset switches attachment URLs to HTTPS when it's determined that the
host supports SSL. This happens when 'siteurl' is non-SSL, but the current page
request *is* over SSL, and the host of the current request matches the host of
the URL being generated.
Props joemcgill, boonebgorges.
Fixes#15928.
Built from https://develop.svn.wordpress.org/trunk@31614
git-svn-id: http://core.svn.wordpress.org/trunk@31595 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In some cases, the values of `$old_status` and `$new_status` may be the same thing before and after a post status is "transitioned". An example of this would be the scenario where a published post is being updated: the status before and after the update both equal 'publish'.
Further, the documentation clarifies that if the intent is to only execute code when initially transitioningto a post status from something else, the 'transition_post_status' hook should be used instead of one of the dynamic hooks to avoid confusion.
Props Idealien for the initial patch.
Fixes#31099.
Built from https://develop.svn.wordpress.org/trunk@31461
git-svn-id: http://core.svn.wordpress.org/trunk@31442 1a063a9b-81f0-0310-95a4-ce76da25c4cd
