`post-template.php` loads after `post.php` in `wp-settings.php`. It could probably also be loaded in `post.php`, but avoiding that for the moment.
See #33413.
git-svn-id: https://develop.svn.wordpress.org/trunk@34109 602fd350-edb4-49c9-b593-d223f7449a82
Creates:
`class-wp-post.php`
`post-functions.php`
`post.php` contains only top-level code. Class file only contains the class. Functions file only contains functions.
See #33413.
git-svn-id: https://develop.svn.wordpress.org/trunk@33759 602fd350-edb4-49c9-b593-d223f7449a82
* 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.
git-svn-id: https://develop.svn.wordpress.org/trunk@33666 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@33630 602fd350-edb4-49c9-b593-d223f7449a82
The documentation should make it clear that the function does not modify the
post object in the database, but only fires hooks related to the transition.
Props AramZS.
Fixes#33014.
git-svn-id: https://develop.svn.wordpress.org/trunk@33296 602fd350-edb4-49c9-b593-d223f7449a82
This prevents existing posts with numeric slugs from having their permalinks
changed on update.
Fixes#5305.
git-svn-id: https://develop.svn.wordpress.org/trunk@33262 602fd350-edb4-49c9-b593-d223f7449a82
Pages are static content, for which comments are not expected out of the box.
Props valendesigns, rachelbaker.
Fixes#31168.
git-svn-id: https://develop.svn.wordpress.org/trunk@33041 602fd350-edb4-49c9-b593-d223f7449a82
Update docs for `WP_Post` constructor to indicate that `WP_Post|object` can be the supplied param, as opposed to just `WP_Post`.
props westonruter.
fixes#32632.
git-svn-id: https://develop.svn.wordpress.org/trunk@32762 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@32647 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@32621 602fd350-edb4-49c9-b593-d223f7449a82
Clarify some existing values for `@param` and `@return`.
Some functions do not need to set a variable before immediately returning it.
See #32444.
git-svn-id: https://develop.svn.wordpress.org/trunk@32619 602fd350-edb4-49c9-b593-d223f7449a82
* Don't accept a comma-separated list, only a single post type or an array of post types. This is easier to document.
* Add changelog entries to all calling functions.
Props DrewAPicture.
Fixes#32243.
git-svn-id: https://develop.svn.wordpress.org/trunk@32524 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@32355 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@32342 602fd350-edb4-49c9-b593-d223f7449a82
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
git-svn-id: https://develop.svn.wordpress.org/trunk@31733 602fd350-edb4-49c9-b593-d223f7449a82
Also adds a changelog entry to the DocBlock for `wp_attachment_is_image()` to denote that it serves as a wrapper for `wp_attachment_is()` as of 4.2.0.
See [31645]. See #25275.
git-svn-id: https://develop.svn.wordpress.org/trunk@31659 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@31653 602fd350-edb4-49c9-b593-d223f7449a82
This is admittedly a first pass. There needs to be a generic handler for when any other type is passed, but for now it accepts the whitelist.
See #25275.
git-svn-id: https://develop.svn.wordpress.org/trunk@31645 602fd350-edb4-49c9-b593-d223f7449a82
`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.
git-svn-id: https://develop.svn.wordpress.org/trunk@31614 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@31461 602fd350-edb4-49c9-b593-d223f7449a82
