Hot answers tagged auto-update
To answer the first question... If you look within the WP_Automatic_Updater class found in wp-admin/includes/class-wp-upgrader.php we note the method is_disabled which is used by the method should_update to determine whether or not an automatic update is allowed. The is_disabled method will return true under the following conditions, if ...
An alternative is to create a simple Must-use plugin so this doesn't depend on the theme. Create a file wp-content/mu-plugins/disable-auto-update-mail.php <?php /* Plugin Name: Disable Auto Update Mails Plugin URI: http://wordpress.stackexchange.com/questions/157056 Version: 1.0 Author: kraftner AuthorURI: ...
Skimming through the Core_Upgrader::should_update_to_version() method, it looks like we can override the defined( 'WP_AUTO_UPDATE_CORE' ) // true (all), false, minor check, used to setup the local boolean variables$upgrade_dev, $upgrade_minor and $upgrade_major, with the following filters: ... apply_filters( 'allow_dev_auto_core_updates', ...
First things first, avoid defining functions inside functions. PHP doesn't have a problem with it, but it's usually a sign you're "doing it wrong" and it just leads to unnecessary headaches. Second, your foreach loop at the bottom is a little malformed. You need to define the <ul> outside the loop, and then append to $html - otherwise you just end up ...
As so often, WP-CLI already has you covered: wp core update --version=3.8 ../latest.zip Have a look here for more details: http://wp-cli.org/commands/core/update/
So are you going to automate your backup as well to be triggered before the DB upgrade starts? While the question has merit especially in a multisite context (in which the scenario is a little different) I am not sure that it is smart thing to do. That message could have said "this is your last chance to perform a backup of the DB, click the button only ...
Not sure if I understand your question, but I think installing the debug bar with the hooks and filters plugin could help you. Debugbar Actions and filters addon
has_filter() checks if any filter has been registered for a hook. This is what I want really
The point of hardening is to avoid the core files to be manipulated by external users (on shared hosting) and by the webserver (as it is the main source of exploits). Since the update runs via the webserver it is obvious that if you hardened your files against webserver initiated manipulation, the update will fail. Most people probably get around it by ...
This one is actually surprisingly simple; add this to your wp-config.php file and all automatic updates will be blocked when outside of the specified hours: // Suspend updates when outside of business hours, 9:00 AM to 5:30 PM $updates_suspended = (date('Hi') < 0900 || date('Hi') > 1730); define( 'AUTOMATIC_UPDATER_DISABLED', $updates_suspended ); ...
I often do Manual Update, it's not that pain. :) Just do it in this way (I hope you know how to update manually): Step 1: Remove wp-includes, and wp-admin from Server and Upload new two Step 2: Cut/Copy all the loose files from local folder and Paste them to the server root with Overwrite permission - Just a replace And you are done. :) Optional Step 1: ...
Fixed it. Put in a few commands that helped give wordpress the permissions it needed to auto update: sudo usermod -aG www-data $USER sudo chown -R www-data:www-data /var/www sudo chmod -R 774 /var/www This problem has been plaguing me for months. I feel like a huge weight has been lifted off my chest now haha.
As it turns out there's a difference between 127.0.0.1 and localhost. Once I change my requests to: http://localhost/white/check-plugins/plugins/test-plugin.zip and a few other instances of the IP version, the update worked like a charm. Stack Overflow has some good answers on why this could be: What is the difference between 127.0.0.1 and localhost?
Only top voted, non community-wiki answers of a minimum length are eligible