In [56515], the default value of `Add New` was changed to "Add New Post / Add New Page". This caused problems with post types where `add_new` was not declared.
Change core usage to reference the `add_new_item` value and revert the default value of `add_new` back to "Add New / Add New". This retains the accessibility advantages without creating counter intuitive usage of the `add_new` key.
With this change, post types registered with no `add_new` key will be unimpacted in core, and post types registered with no `add_new_item` key will use the default "Add New Post", which is not a change from the current state.
Props smerriman, afercia, rcreators, joedolson, eclev91, johnbillion.
Fixes#60045.
Built from https://develop.svn.wordpress.org/trunk@59161
git-svn-id: http://core.svn.wordpress.org/trunk@58556 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Not all post types support autosaving. By making autosave a post type feature, support can be more granularly handled without any workarounds or hardcoded allowlists. `wp_font_family` and `wp_font_face` are examples of built-in post types which do not support autosave.
For backward compatibility reasons, adding `editor` support implies `autosave` support, so one would need to explicitly use `remove_post_type_support()` to remove it again.
Props swissspidy, youknowriad, hellofromtonya, peterwilsoncc.
Fixes#41172.
Built from https://develop.svn.wordpress.org/trunk@58201
git-svn-id: http://core.svn.wordpress.org/trunk@57664 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Updated the global styles endpoints in the REST API to extend from existing posts and revisions controllers. This reduces duplicated code and inconsistencies. The revisions controller is now a subclass of the WP_REST_Revisions_Controller. Related redundant methods were removed and schema generation and collection parameters were adjusted to suit the global styles context. Updated permission checks, constructor, and collection parameters accordingly. This change allows for easy override of these classes using the `register_post_type_args` filter.
Props ramonopoly, spacedmonkey, mukesh27.
Fixes#60131.
Built from https://develop.svn.wordpress.org/trunk@57624
git-svn-id: http://core.svn.wordpress.org/trunk@57125 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The Template and Template Part REST API controllers have unique characteristics compared to other post type REST API controllers. They do not rely on integer IDs to reference objects; instead, they use a combination of the theme name and slug of the template, like 'twentytwentyfour//home.' Consequently, when the post types template and template part were introduced in [52062], it led to the registration of REST API endpoints for autosaves and revisions with invalid URL structures.
In this commit, we introduce new functionality to enable custom autosave and revisions endpoints to be registered at the post type level. Similar to the 'rest_controller_class' parameter, developers can now define 'revisions_rest_controller' and 'autosave_rest_controller.' This empowers developers to create custom controllers for these functionalities. Additionally, we introduce a 'late_route_registration' parameter, which proves helpful when dealing with custom URL patterns and regex pattern matching issues.
This commit registers new classes for template and template part autosave and revisions controllers, differentiating them from standard controllers in the following ways:
* The response shape now matches that of the template controller.
* Permission checks align with the template controller.
* A custom URL pattern is introduced to support slug-based identification of templates.
Furthermore, we've updated the utility function '_build_block_template_result_from_post' to support passing revision post objects. This enhancement ensures compatibility with the custom revisions controller.
Props spacedmonkey, revgeorge, andraganescu, hellofromTonya, antonvlasenko, kadamwhite, ironprogrammer, costdev, mukesh27, timothyblynjacobs, adamsilverstein.
Fixes 56922.
Built from https://develop.svn.wordpress.org/trunk@56819
git-svn-id: http://core.svn.wordpress.org/trunk@56331 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`str_contains()` was introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) contains the given substring (needle).
WordPress core includes a polyfill for `str_contains()` on PHP < 8.0 as of WordPress 5.9.
This commit replaces `false !== strpos( ... )` with `str_contains()` in core files, making the code more readable and consistent, as well as better aligned with modern development practices.
Follow-up to [52039], [52040], [52326], [55703], [55710], [55987].
Props Soean, spacedmonkey, costdev, dingo_d, azaozz, mikeschroder, flixos90, peterwilsoncc, SergeyBiryukov.
Fixes#58206.
Built from https://develop.svn.wordpress.org/trunk@55988
git-svn-id: http://core.svn.wordpress.org/trunk@55500 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0.
There are a number of ways to mitigate this:
* If it is an accidental typo for a declared property: fix the typo.
* For known properties: declare them on the class.
* For unknown properties: add the magic `__get()`, `__set()`, et al. methods to the class or let the class extend `stdClass` which has highly optimized versions of these magic methods built in.
* For unknown ''use'' of dynamic properties, the `#[AllowDynamicProperties]` attribute can be added to the class. The attribute will automatically be inherited by child classes.
Trac ticket #56034 is open to investigate and handle the third and fourth type of situations, however it has become clear this will need more time and will not be ready in time for WP 6.1.
To reduce “noise” in the meantime, both in the error logs of WP users moving onto PHP 8.2, in the test run logs of WP itself, in test runs of plugins and themes, as well as to prevent duplicate tickets from being opened for the same issue, this commit adds the `#[AllowDynamicProperties]` attribute to all “parent” classes in WP.
The logic used for this commit is as follows:
* If a class already has the attribute: no action needed.
* If a class does not `extend`: add the attribute.
* If a class does `extend`:
- If it extends `stdClass`: no action needed (as `stdClass` supports dynamic properties).
- If it extends a PHP native class: add the attribute.
- If it extends a class from one of WP's external dependencies: add the attribute.
* In all other cases: no action — the attribute should not be needed as child classes inherit from the parent.
Whether or not a class contains magic methods has not been taken into account, as a review of the currently existing magic methods has shown that those are generally not sturdy enough and often even set dynamic properties (which they should not). See the [https://www.youtube.com/watch?v=vDZWepDQQVE live stream from August 16, 2022] for more details.
This commit only affects classes in the `src` directory of WordPress core.
* Tests should not get this attribute, but should be fixed to not use dynamic properties instead. Patches for this are already being committed under ticket #56033.
* While a number bundled themes (2014, 2019, 2020, 2021) contain classes, they are not a part of this commit and may be updated separately.
Reference: [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties].
Follow-up to [53922].
Props jrf, hellofromTonya, markjaquith, peterwilsoncc, costdev, knutsp, aristath.
See #56513, #56034.
Built from https://develop.svn.wordpress.org/trunk@54133
git-svn-id: http://core.svn.wordpress.org/trunk@53692 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add post type and taxonomy specific registration argument hooks.
Introduces the filters `register_{$post_type}_post_type_args` and `register_{$taxonomy}_taxonomy_args`. Introduces the actions `registered_post_type_{$post_type}` and `registered_taxonomy_{$taxonomy}`.
Props pbiron, dlh, davidbaumwald, hellofromTonya, milana_cap.
Fixes#53212.
Built from https://develop.svn.wordpress.org/trunk@53126
git-svn-id: http://core.svn.wordpress.org/trunk@52715 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Improve the translation of post type and taxonomy labels by caching the translations during runtime. To account for internationalisation plugins, the runtime cache is cleared as the post types/taxonomies are reinitiated on `change_local` hook.
The same property and methods are added to both `WP_Post_Type` and `WP_Taxonomy`:
* `$default_labels`: for storing the translated strings at runtime
* `get_default_labels()`: for getting the default labels, these are translated on the first run and stored in the new property.
* `reset_default_labels()`: to clear the runtime cache and force a re-translation of the default labels
Props Chouby, nacin, SergeyBiryukov, Rarst, chriscct7, ocean90, audrasjb, costdev.
Fixes#26746.
Built from https://develop.svn.wordpress.org/trunk@53058
git-svn-id: http://core.svn.wordpress.org/trunk@52647 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Use 3-digit, x.x.x-style semantic versioning for `@since` tags of the `$rest_namespace` property in `WP_Post_Type` and `WP_Taxonomy`.
Add a `@since` note to `WP_REST_Taxonomies_Controller::get_item_schema()` for the `visibility` and `rest_namespace` properties.
The `rest_base` property was also added after the method was initially introduced, but that happened during the same release cycle, so it doesn't need a separate `@since` note.
Follow-up to [38832], [39191], [42729], [51959], [51961], [51962], [51964].
See #53399.
Built from https://develop.svn.wordpress.org/trunk@51965
git-svn-id: http://core.svn.wordpress.org/trunk@51554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While a custom post type can define a custom route by using the `rest_base` argument, a namespace of `wp/v2` was assumed. This commit introduces support for a `rest_namespace` argument.
A new `rest_get_route_for_post_type_items` function has been introduced and the `rest_get_route_for_post` function updated to facilitate getting the correct route for custom post types.
While the WordPress Core Block Editor bootstrap code has been updated to use these API functions, for maximum compatibility sticking with the default `wp/v2` namespace is recommended until the API functions see wider use.
Props spacedmonkey, swissspidy.
Fixes#53656.
Built from https://develop.svn.wordpress.org/trunk@51962
git-svn-id: http://core.svn.wordpress.org/trunk@51551 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Split the summary for `$template` per the documentation standards. The summary should be a single sentence.
* Change the type for `$template_lock` to `string|false`, to clarify that `true` is not supported.
* Fix typo in `$delete_with_user` description, adjust for better readability.
Follow-up to [49041], [49492].
See #46261.
Built from https://develop.svn.wordpress.org/trunk@49494
git-svn-id: http://core.svn.wordpress.org/trunk@49253 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Ensures that the ::get_rest_controller() method will always return an instanceof the expected controller class, or null.
Removes unused private static property $post_type_controllers.
Props dlh, TimothyBlynJacobs.
Fixes#45677.
Built from https://develop.svn.wordpress.org/trunk@46435
git-svn-id: http://core.svn.wordpress.org/trunk@46233 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Cache REST controller references on their associated post type object to prevent unnecessary controller re-instantiation, which previously caused "rest_prepare_{$post_type}" and "rest_{$post_type}_query" to run twice per request.
Props TimothyBlynJacobs, patrelentlesstechnologycom.
Fixes#45677.
Built from https://develop.svn.wordpress.org/trunk@46272
git-svn-id: http://core.svn.wordpress.org/trunk@46084 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `add_post_type_support()` function accepts an optional third parameter that allows extra arguments to be supplied to configure post type support for a given feature. However, because of how `register_post_type()` and `WP_Post_Type->add_supports()` work, it is currently impossible to pass these additional arguments when initially registering a post type with `register_post_type()`.
This change makes it possible to supply additional arguments for a feature using the `supports` argument of `register_post_type()`.
Props MaximeCulea, seuser, desrosj, johnbillion.
Fixes#40413.
Built from https://develop.svn.wordpress.org/trunk@46160
git-svn-id: http://core.svn.wordpress.org/trunk@45972 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prior to about 2013, many class methods lacked even access modifiers which made the `@access` notations that much more useful. Now that we've gotten to a point where the codebase is more mature from a maintenance perspective and we can finally remove these notations. Notable exceptions to this change include standalone functions notated as private as well as some classes still considered to represent "private" APIs.
See #41452.
Built from https://develop.svn.wordpress.org/trunk@41162
git-svn-id: http://core.svn.wordpress.org/trunk@41002 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
