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 ...
You could also try this.
In IIS manager
Go to Application pools and choose the one used by your Wordpress Blog.
Right Click and choose Advanced Settings...
Change the Identity to LocalSystem
Click OK to save changes.
Then on Sites,
Choose your Wordpress Blog from the sites list
Right Click on it and click on Edit permissions
Go to security tab and ...
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 ...
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 ...
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:
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:
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 ...
For the benefit of others who find this page, I suggest those wishing to provide their own updates outside the official WP repository check out this project on GitHub, that demonstrates the functionality:
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
An increasingly popular paid solution if ManageWP.com. I haven't used it nor am I affiliated with it, though I plan to try it out soon. It's aimed at this exact scenario (one-click upgrades for multiple sites across different servers). If you're looking for a custom solution, this obviously isn't it, but I've heard good things about this service.
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" ...
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 ...
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 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 ...
Update & the internal WP HTTP API
A slightly modified version of my answer to this question, but also as a plugin that shows how it could work.
Note: The code is not tested - I don't know your server setup, etc. - and just written out of my head. You'll have to test it, find the proper position for merging the arguments and set your URL, etc.
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 );
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 use the SVN approach for making most of my "separate" sites now, although really I tend to use multisite more often.
The trick, I find, is to make sure that you have the whole site in an SVN somewhere, with WordPress as an external. The key to this is to get all your changes to the site (plugins, themes, custom content, etc) outside of the main WordPress ...
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 ...
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 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 ...