Having a view mode switcher nestled within table navigation makes no sense, especially now that it's a sticky user option. While less convenient for frequent switching, there is no evidence as of yet that there is a large userbase of frequent view mode switchers.
Introduces a filter for `view_mode_post_types`, which by default is all hierarchical post types with edit UI on.
props Oxymoron.
fixes#22222.
Built from https://develop.svn.wordpress.org/trunk@35357
git-svn-id: http://core.svn.wordpress.org/trunk@35323 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change also makes it bail early (without writing) if the markers content is the same as the existing, and uses `ftell()` rather than `$bytes` for the location to truncate the file to - based on the file pointer being at the end of the written stream.
Props willmot tigertech kevinatelement
See #31767
Built from https://develop.svn.wordpress.org/trunk@35267
git-svn-id: http://core.svn.wordpress.org/trunk@35233 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `WP_INSTALLING` constant is a flag that WordPress sets in a number of
places, telling the system that options should be fetched directly from the
database instead of from the cache, that WP should not ping wordpress.org for
updates, that the normal "not installed" checks should be bypassed, and so on.
A constant is generally necessary for this purpose, because the flag is
typically set before the WP bootstrap, meaning that WP functions are not yet
available. However, it is possible - notably, during `wpmu_create_blog()` -
for the "installing" flag to be set after WP has already loaded. In these
cases, `WP_INSTALLING` would be set for the remainder of the process, since
there's no way to change a constant once it's defined. This, in turn, polluted
later function calls that ought to have been outside the scope of site
creation, particularly the non-caching of option data. The problem was
particularly evident in the case of the automated tests, where `WP_INSTALLING`
was set the first time a site was created, and remained set for the rest of the
suite.
The new `wp_installing()` function allows developers to fetch the current
installation status (when called without any arguments) or to set the
installation status (when called with a boolean `true` or `false`). Use of
the `WP_INSTALLING` constant is still supported; `wp_installing()` will default
to `true` if the constant is defined during the bootstrap.
Props boonebgorges, jeremyfelt.
See #31130.
Built from https://develop.svn.wordpress.org/trunk@34828
git-svn-id: http://core.svn.wordpress.org/trunk@34793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The call to `flock()` is an exclusive advisory lock, which in my testing only PHP respects (apache continues to read it).
Not all filesystems support locking (remote NFS mounts for example) so this offers minimal benefit to those platforms, but offers much better protection against file corruption on systems which do support it.
The call is blocking, so a second process will wait for the first to complete before writing if supported.
See #31767
Built from https://develop.svn.wordpress.org/trunk@34740
git-svn-id: http://core.svn.wordpress.org/trunk@34704 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`admin-filters.php`
`ms-admin-filters.php`
There are random actions and filters littered among files like `misc.php`. These files contain functions that won't work outside of admin context and are typically only loaded in files that have already loaded the admin bootstrap.
See #32529.
Built from https://develop.svn.wordpress.org/trunk@32653
git-svn-id: http://core.svn.wordpress.org/trunk@32623 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These no longer return upon refreshing the page when JS is on and working, so users should be able to dismiss them. This is particularly important on the post edit screen when DFW is triggered, but pretty much all notices can be dismissed if needed. A post on Make/Core will follow with information on how this can be leveraged in plugins.
props valendesigns, afercia, paulwilde, adamsilverstein, helen.
fixes#31233. see #23367.
Built from https://develop.svn.wordpress.org/trunk@31973
git-svn-id: http://core.svn.wordpress.org/trunk@31952 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Update about page, there's now 8.
* Display them four wide, not three, and ensure adequate spacing.
* Use a dedicated nonce.
* Push Light to the front in addition to Default.
* Use user-profile.js on about.php. A few extra things are initialized but they are harmless.
see #26468, #26387.
Built from https://develop.svn.wordpress.org/trunk@26776
git-svn-id: http://core.svn.wordpress.org/trunk@26663 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Both of these icons can be colored to match the color scheme, including hover states.
Both are accepted for register_post_type()'s menu_icon argument, and also add_menu_page()'s $icon_url argument.
To use a Dashicon, pass the name of the helper class, e.g. 'dashicons-piechart'.
To use an SVG, pass a valid data URI string starting with 'data:image/svg+xml;base64,'.
props helen.
fixes#25147.
Built from https://develop.svn.wordpress.org/trunk@26664
git-svn-id: http://core.svn.wordpress.org/trunk@26554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Color scheme selection on your own profile page gives you a preview and autosaves the selection.
Also introduces the usage of a preprocessor for core files, namely Sass. For 3.8, we will not expand its implementation past the color schemes. This does require Ruby as well as Sass 3.3.0+ due to the usage of the sourcemap option.
Note that only the default color scheme is available when running out of src. Use build to test the rest as well as the color picker.
props ryelle, melchoyce, tillkruess, drw158, littlethingsstudio, helen. see #25858, #22862.
Built from https://develop.svn.wordpress.org/trunk@26137
git-svn-id: http://core.svn.wordpress.org/trunk@26048 1a063a9b-81f0-0310-95a4-ce76da25c4cd
