Automatic updates are automatic.
The basic, default behavior in WordPress 3.7 is automatic update of core for minor versions (i.e. X.Y.Z to X.Y.Z+1.)
No configuration options are exposed in the UI. To change the behavior, you'll need to modify your wp-config.php file, or add some filters:
Add the following to wp_config.php:
Instead of using the code from the question in functions.php, replace it with this:
* Prevent certain plugins from receiving automatic updates, and auto-update the rest.
* To auto-update certain plugins and exclude the rest, simply remove the "!" operator
* from the function.
* Also, by using the 'auto_update_theme' or 'auto_update_core' ...
Actually, the automatic update is pushed from wp.org. The update process still runs on your site, but in the background via wp-cron.
When a new minor update is released, the guys at WordPress start to roll out the update. The actual update process is started after your site checked wp.org for updates, an update is theoretically available, and your site is ...
PHP isn't a permanently-running process: it only runs when requested.
So as far as I can tell, Wordpress can only update itself when someone
loads a web page. But the update process is not instantaneous, so
surely a user visiting the site would have a really slow page load.
Is there a different trick they use for automatic updates? I've
Let me first answer your questions before giving some more info on the update process.
There is always some risk. But with the default of only doing minor core release you are pretty safe. (E.g. 3.8.1 had close to 100% update success rate) Also you should think of how while being some risk itself the update also protects you from other risks by e.g. fixing ...
You are correct, Wordpress checks for updates to core and plugins every 12 hours, but a better way to word it would be: it checks updates if last update was more than 12 hours ago.
The 12 hour setting is hard codded in wp-includes/update.php
The last updated dates are stored in wp_options table and the options are:
As of Wordpress 4.7.3, auto-updates are triggered whenever the following sequence is successful. All the code is in the file wp-includes/update.php.
1. _maybe_update_core() is called (via the admin_init action).
This function is run via the the admin_init action, which executes at the beginning of every admin page before the page is rendered. The update ...
I use XAMPP myself, but WAMP isn't much different.
I'll bet you have not enabled the curl module. WordPress can use other methods (streams and fsockopen) as a fallback, but these may be disabled by default as well in a stock install. Curl is preferred and easy to enable.
Go your the \bin\php\version directory in WAMP
Edit the php.ini, and ...
Disable Plugin updates all together
It should be as easy as that:
defined( 'ABSPATH' ) or exit;
/* Plugin Name: (#120589) Disable Plugin Updates */
remove_action( 'load-update-core.php', 'wp_update_plugins' );
Deny (or reroute) Updates for Themes/Plugins
Single core and theme updates can be deactivated by this script my Mark Jaquith:
For plugins ...
You can Disable HTTP Calls by adding this in your wp-config.php
define( 'WP_HTTP_BLOCK_EXTERNAL', TRUE );
This will disable/block all external HTTP requests and will make website alot faster.
And then you can whitelist domains that you don't want to block.
define( 'WP_ACCESSIBLE_HOSTS', 'example.com, domain.com' );
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 DISALLOW_FILE_MODS ...
From my perspective there are two issues with your plan - Git and "conventional" structure. So basically everything. :)
Git (and version control in general) is a poor tool for whole site stacks. Been there, done that, it hurt a lot.
What you call an "unconventional" structure with content separated from core has been a very conventional and robust choice ...
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
Plugin Name: Disable Auto Update Mails
Plugin URI: http://wordpress.stackexchange.com/questions/157056
Every 12+ Hours WordPress automatically goes out and checks if a plugin needs to be updated via the WordPress Repository. There's 3 cron jobs that WordPress runs to check on things:
wp_version_check - Checks for Core Updates
wp_update_plugins - Check for Plugin Updates
wp_update_themes - Checks for Theme Updates
A neat little plugin to view these is WP ...
The relevant functions wp_update_plugins() and wp_maybe_auto_update() are hooked to the wp-cron events of same name, running on twice daily schedule.
Logically the initial schedule will start to tick from the time of first run. Due to wp-cron implementation (not being real cron and trigered by site visits rather than server clock) it will also "drift" ...
If the theme slug matches, but you have no version number in the style.css file (even if Name is missing too), it will always try to update that theme. The easiest way to prevent this is to add a Version in the style.css header and set it to a really high number that is unlikely to be lower than that theme's version:
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 );
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', $...
The first argument is the plug-in's 'slug'. The plug-in slug is determined by the location of the .php file header containing the comment header necessary for plug-ins. (see source).
If your main plug-in file might be ~/wp-content/plugins/foo/bar.php, while your plug-in slug is foo/bar.php.
If the wp-content dir has a custom name, you can retrieve it using ...
First Open /wp-config.php
Now the first thing you need to do is to open the wp-config.php file from your WordPress root folder, the file is located at wordpress/wp-config.php
Paste the following code to your wp-config.php file, preferably just below every other line of code.
And Save it, It will definitely ...
There're a couple of libraries out there. One of the more well known is from Joey Kudish and hosted on GitHub itself.
Basically it does the following:
utilizes the GitHub API
Adds a callback to the 'pre_set_site_transient_update_plugins' filter
Adds another callback to the 'plugins_api' filter
finally utilizes the WP HTTP API and does a wp_remote_get() to ...
Found a fix. Simply add the following snippet to functions.php for your theme:
add_filter('filesystem_method', create_function('$a', 'return "direct";' ));
define( 'FS_CHMOD_DIR', 0751 );
The correct way to do this these days is to include your schema as a file in the plugin source and use the inbuilt WordPress function dbDelta() to update the database as needed using that scheme. The actual code required is very simple:
$sql = file_get_contents( plugin_dir_path(__FILE__) . "/schema.sql" );
dbDelta( $sql );
This will both create and update ...
How to disable core auto updates but enable plugins and themes auto
If you want to stop the autoupdates of the WordPress core, but to
enable them for your Plugins and/or Themes, you can add these lines in
the wp-config.php file: Stop the core auto updates:
define( 'WP_AUTO_UPDATE_CORE', false );
Then Enable the plugins/themes:
I found the answer here:
If the install uses FTP for updates (and prompts for credentials),
automatic updates are disabled. (I found this answer which will tell you how to avoid using FTP.)
If the install is running as a SVN or
GIT checkout, automatic updates are disabled
If the constants
DISALLOW_FILE_MODS or AUTOMATIC_UPDATER_DISABLED are defined,
You might take a look at this issue and this issue.
Also take a look at the README files in each repo as well:
markjaquith / WordPress-Skeleton
davidwinter / wordpress-with-git
Based on above repos, as another example of a Git/WP setup, I created this. I opted to use symlinks for themes (I try to cover that in my README).
I'm kinda in same boat with the ...
You actually have several questions in there, so I'll answer them one by one:
However, if I simply do this on my main plugin file, it doesn't work:
add_filter('pre_set_site_transient_update_plugins', array('XYZ', 'check_update'));
First of all, I'd like to understand what's the difference between the
This is failing because ...