10

Is there any way to disable core and plugin updates? I am modifying a plugin and bit of WordPress Core (I know its a sin to do so), but can't help it.

| improve this question | | | | |
8

Yes you can do that…

define( 'DISALLOW_FILE_MODS', true ); 

Put this snippet in your wp-config.php file and you will able to disable core and plugin updates.

| improve this answer | | | | |
  • 1
    the drawback is that it will disable some other functionality as well - the theme and plugin editors. I think that there are more specific constants for the automatic upgrade itself – Mark Kaplun Oct 30 '13 at 6:41
  • @MarkKaplun I think its better if end-user don't access editors – Josh Karteson Oct 30 '13 at 6:44
  • According to me to disallow theme and plugin editor, we have to use... define( ‘DISALLOW_FILE_EDIT’ , true ); – Abhishek Kaushik Oct 30 '13 at 6:47
  • maybe, just saying that your answer, while technically correct, can be improved. – Mark Kaplun Oct 30 '13 at 6:49
  • 4
    Curly quotes in wp-config.php are a source for endless fun. ;) – fuxia Oct 30 '13 at 8:27
8

Disable Plugin updates all together

It should be as easy as that:

<?php
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 from within some themes files

// Plugins
add_filter( 'http_request_args', 'cws_hidden_plugin_12345', 5, 2 );
function cws_hidden_plugin_12345( $r, $url )
{
    if ( 0 !== strpos( $url, 'http://api.wordpress.org/plugins/update-check' ) )
        return $r;

    $plugins = unserialize( $r['body']['plugins'] );
    unset(
        $plugins->plugins[ plugin_basename( __FILE__ ) ],
        $plugins->active[ array_search( plugin_basename( __FILE__ ), $plugins->active ) ]
    );
    $r['body']['plugins'] = serialize( $plugins );

    return $r;
}

For themes from within a themes functions.php file

// Themes
add_filter( 'http_request_args', 'cws_hidden_theme_12345', 5, 2 );
    function cws_hidden_theme_12345( $r, $url )
    {
    if ( 0 !== strpos( $url, 'http://api.wordpress.org/themes/update-check' ) )
        return $r;

    $themes = unserialize( $r['body']['themes'] );
    unset(
        $themes[ get_option( 'template' ) ],
        $themes[ get_option( 'stylesheet' ) ]
    );
    $r['body']['themes'] = serialize( $themes );

    return $r;
}

Disable specific plugins

From within any custom plugin as described in this answer here on the stack:

<?php
defined( 'ABSPATH' ) or exit;
/* Plugin Name: (#120589) Disable Aksimet Updates */
add_filter( 'site_transient_update_plugins', 'wpse120589DisableAkismetUpdates' );
function filter_plugin_updates( $value )
{
    unset( $value->response['akismet/akismet.php'] );
    return $value;
}

Core updates

Actually that should be as easy as that:

<?php
defined( 'ABSPATH' ) or exit;
/* Plugin Name: (#120589) Disable Core Updates */
add_filter( 'pre_site_transient_update_core', '__return_null' );

For older versions John Billion has written a complete plugin that targets them all.

Further info and fine grained control for Automatic updates

Andi Nacin just put up a post on WordPress/Make that gets into detail on that topic:

Version Control is a shut down switch:

If WordPress detects a version control system, it recognizes you know what you are doing and avoids automatic updates of any kind. It looks for Subversion, Git, Mercurial, and Bazaar, and it looks everywhere.

It works by searching two directories (ABSPATH and whatever you are updating, like WP_PLUGINS_DIR, or WP_LANG_DIR) for VCS directories (.svn, .git, .hg, .bz). And it looks a level up, too — and keeps looking until it reaches the root of the drive. So if you are running a single Subversion checkout at / or /var/www/ or /var/www/mysite.com/, the WordPress install at /var/www/mysite.com/public_html/wordpress/ will be blocked from receiving updates. Clearly, it errs on the site of caution.

The same goes for disabling the File and Themes Editor:

The DISALLOW_FILE_MODS constant blocks any kind of filesystem changes, not just by background updates but by all users as well. So, gone are the file editors; the ability to update core, themes, or plugins; and the ability to install new themes or plugins.

Single wp-config.php switch:

define( 'AUTOMATIC_UPDATER_DISABLED', (bool) true/false );

and

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );

# Enables core updates for minor releases (default):
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

More detail on the linked post.


Note: All above code is scraped during a 5 minute google search run and therefore not tested, only visually diffed/tested against the GitHub WordPress source code and GitHub search results. You have to verify the contents yourself. Also, for the future, please include such research in your question.

| improve this answer | | | | |
0

simple, don't modify the core...... modifying the core is basically forking wordpress and unless you part of a development team that can maintain a fork for a long time you are putting your client into a dead end where the only upgrade path is to redevelop the site. He might be ok with that but it is something that needs to be agreed in advance.

Anyway, disabling the automatic update will not be enough in your case and you will need to also remove all the upgrade notifications from the dashboard, or better make sure that the cient doesn't have FTP access to the server.

Same logic applies to non trivial plugins from a reputable source (example, jetpack) with the exception that in this case you might be able to maintain the fork for a long term.

To disable plugin updates and discourage anybody from trying to upgrade it manually you can just change the plugin's name and its directory. Of course you should use a plugin name and directory name not used by another plugin, something like "${original plugin name} tailored for $client DON"T UPGRADE" as the new plugin name and ${original plugin name}-for-$client as the new directory.

| improve this answer | | | | |
  • hmm, I don't get it. my answer is that you should avoid disabling automatic upgrade. don't know of any code required for that :). people that want to play with constants in wp-config.php have the info in other answer. – Mark Kaplun Oct 30 '13 at 8:31
  • Sorry, Mark. Didn't sleep much :P Anyway, I wasn't the downvoter, but I can't agree with you. Your answer also is lots of opinion and not really hard facts. – kaiser Oct 30 '13 at 8:36
  • changing the plugins name is a very useful and easy way to disable plugin update as a name match is required. It also convey to the admin the fact that the plugin is not the same as the forked one and therefor hoefully he will not try to upgrade it via FTP. This is what I do in this situation. As to the core upgrade, yes it is an opinion, hopefully shared with most wordress developers :) – Mark Kaplun Oct 30 '13 at 8:42
  • You should also note what happens if you rename the folder to some plugin that has the same folder in use in the official wp dot org repo. – kaiser Oct 30 '13 at 8:44
  • 1
    I will add that – Mark Kaplun Oct 30 '13 at 8:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.