Keeping myhacks support is a small price to pay for not breaking people's sites. Even if it is very very very few sites, breaking sites isn't something that should be encouraged. Even with 10 years of deprecation notices.
https://core.trac.wordpress.org/ticket/33741#comment:18 outlines all the ways that the hack_file and my-hacks options can be setup and thus all the ways that the removal of those options could break sites.
Fixes#33741.
Built from https://develop.svn.wordpress.org/trunk@35688
git-svn-id: http://core.svn.wordpress.org/trunk@35652 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
For the last 10 years, my-hacks has been deprecated and has been throwing a deprecation notice. For the last six years, you haven't been able to enable my-hacks.php in the admin UI. That should be enough time to give developers notice. Plugins and themes seem like they might have staying power.
Fixes#33741
Props bobbingwide
Built from https://develop.svn.wordpress.org/trunk@34291
git-svn-id: http://core.svn.wordpress.org/trunk@34255 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The check is true for `wp-admin/plugin-install.php` and `wp-admin/theme-install.php` too. This will end in a redirect to `/wp-admin/upgrade.php` or a screen with a bunch of errors.
The `WP_INSTALLING` constant was added in WordPress 1.5.1 to `wp-admin/install.php` which makes the check for "install.php" redundant.
props joemcgill.
fixes#29694.
Built from https://develop.svn.wordpress.org/trunk@30581
git-svn-id: http://core.svn.wordpress.org/trunk@30571 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Introduce clean_blog_cache() so we can run it independently of refresh_blog_details() which assumes the blog still exists and get_blog_details() can be called.
* Don't db escape cache keys in get_blog_id_from_url()
* prepare() the query in get_blog_id_from_url()
* Return 0 for all failures in get_blog_id_from_url()
* clean_blog_cache() after dropping tables in wpmu_delete_blog() to make sure the cache is for real cleaned.
git-svn-id: http://core.svn.wordpress.org/trunk@22092 1a063a9b-81f0-0310-95a4-ce76da25c4cd
We need to remove post_ancestors non-persistent caching for this. get_post_ancestors() can simply rely on the caching of get_post() instead. Previously, it was a direct query, hence the extra layers of caching and clearing.
Child cache clearing stays in wp_delete_post() as children get a new parent.
fixes#11399.
git-svn-id: http://core.svn.wordpress.org/trunk@21952 1a063a9b-81f0-0310-95a4-ce76da25c4cd
to avoid a parse error in a PHP4 environment (caused by use of
the clone keyword in option.php).
Manually include functions.php in the rare situations where it
is not already included by the time we need to load translations
early.
Remove the functions.php dependency by switching the wp_die() calls
to die(), in wp_check_php_mysql_versions().
props SergeyBiryukov, see #21316, for trunk.
git-svn-id: http://core.svn.wordpress.org/trunk@21715 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Change is_*_admin() to reference in_admin() with fallback to the WP_*_ADMIN constants during early bootstrap. This allows unit tests and ajax handlers to set the admin context.
fixes#21742
git-svn-id: http://core.svn.wordpress.org/trunk@21687 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add the blog id to the cache keys for multisite installs.
Use wp_cache_switch_to_blog() instead of wp_cache_init() in switch_to_blog().
Use wp_cache_switch_to_blog() instead of wp_cache_reset() in wp_start_object_cache().
Deprecate wp_cache_reset().
This avoids the many queries needed to re-prime the cache after switch_to_blog() on multisite installs using the default cache backend.
fixes#21434
git-svn-id: http://core.svn.wordpress.org/trunk@21403 1a063a9b-81f0-0310-95a4-ce76da25c4cd
