The WPCS `WordPress.WhiteSpace.PrecisionAlignment` rule throws warnings for a bunch of code that will likely cause issues for `wpcbf`. Fixing these manually beforehand gives us better auto-fixed results later.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42228
git-svn-id: http://core.svn.wordpress.org/trunk@42057 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This pattern occurs a handful of times across the codebase:
`<div class="foo<?php if ( $bar ) { echo ' baz'; } ?>">`
Unfortunately, it doesn't really play nicely with `phpcbf`, so all instances need to be removed in preperation for auto code formatting.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42217
git-svn-id: http://core.svn.wordpress.org/trunk@42046 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Fix keeping text selection and scroll position when there are embeds from URL.
- Add editor setting to disable keeping selection and scroll position.
- Remove dependency on Underscore.js.
- Fix error in the Text widget editor.
Props biskobe.
Fixes#42059, see #40854.
Built from https://develop.svn.wordpress.org/trunk@41783
git-svn-id: http://core.svn.wordpress.org/trunk@41617 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The super admin on multisite as well as the administrator on non-multisite both have this capability already. For custom post types using different capabilities this change ensures that only users with that capability have permissions.
Fixes#39059. See #37616.
Built from https://develop.svn.wordpress.org/trunk@39539
git-svn-id: http://core.svn.wordpress.org/trunk@39479 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WordPress has supported custom page templates for over 12 years, allowing developers to create various layouts for specific pages.
While this feature is very helpful, it has always been limited to the 'page' post type and not was not available to other post types.
By opening up the page template functionality to all post types, we continue to improve the template hierarchy's flexibility.
In addition to the `Template Name` file header, the post types supported by a template can be specified using `Template Post Type: post, foo, bar`.
When at least one template exists for a post type, the 'Post Attributes' meta box will be displayed in the back end, without the need to add post type support for `'page-attributes'`. 'Post Attributes' can be customized per post type using the `'attributes'` label when registering a post type.
Props johnbillion, Mte90, dipesh.kakadiya, swissspidy.
Fixes#18375.
Built from https://develop.svn.wordpress.org/trunk@38951
git-svn-id: http://core.svn.wordpress.org/trunk@38894 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
The media library can contain files which aren't attached yet. When attaching a file you currently get "Media attachment reattached.", or the opposite "Media attachment detached.". That's redundant and can be inaccurate. It's also not easy to translate in some languages.
This change generalizes the strings to refer to a "media file" instead.
Props SergeyBiryukov, ocean90, netweb.
Fixes#36089.
Built from https://develop.svn.wordpress.org/trunk@36887
git-svn-id: http://core.svn.wordpress.org/trunk@36854 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Move the array processing to a new function, `_wp_post_revision_data()`.
* Make both functions accept a post array or a `WP_Post` object.
* Always apply the `_wp_post_revision_fields` filter and pass the post data to it.
Fixes#13382.
Built from https://develop.svn.wordpress.org/trunk@36659
git-svn-id: http://core.svn.wordpress.org/trunk@36626 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Shortlinks had their day in the popular usage sun before all these services moved to their own shorteners and running your own custom one became a lot easier. Shortlinks are still useful in some contexts, such as analytics or when links need to be shared verbally or copied down by hand.
If any filters are hooked onto `pre_get_shortlink` or `get_shortlink` and produce a non-empty value (with an exception described below), the button will magically reappear. This allows any custom shortlinks to keep the button without hiccups.
If you're in need of the default shortlinks, the fastest way to reenable them is `add_filter( 'pre_get_shortlink', '__return_false' )`. Note that it must return false in order to continue on to the rest of `wp_get_shortlink()`.
props grvrulz for the initial patch.
fixes#33495.
Built from https://develop.svn.wordpress.org/trunk@34556
git-svn-id: http://core.svn.wordpress.org/trunk@34520 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Discussion: Post Type stops supporting comments, but comments and/or pings are open on a post.
* Comments: Post is published or private, the post type has stopped supporting comments, but comments and/or pings are open on a post.
Currently, there is no way to toggle those settings off.
Props couturefreak, wonderboymusic, rachelbaker.
Fixes#28080.
Built from https://develop.svn.wordpress.org/trunk@34461
git-svn-id: http://core.svn.wordpress.org/trunk@34425 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
First step towards restoring a good heading structure in wp-admin.
The previous `<h1>` contained the site title and a link to the front page and was removed with the toolbar refactoring in 3.2.
Props joedolson, afercia.
Fixes#31650.
Built from https://develop.svn.wordpress.org/trunk@32974
git-svn-id: http://core.svn.wordpress.org/trunk@32945 1a063a9b-81f0-0310-95a4-ce76da25c4cd
