Tag Info

Hot answers tagged

11

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. * * This function could easily be altered to do the opposite, by auto-updating specific * plugins and excluding the rest. * * Also, by using the 'auto_update_theme' or ...


7

http://wordpress.org/extend/plugins/wordpress-beta-tester/ Sets you up for the nightlies, if that is what you are looking for. I've got it running on my dev install @ cdn.rvoodoo.com. Works great there


6

Try flushing out the transient data(options prefixed with _site_transient_update_ - wp_options table), WP will recreate them for you anyway. Not always a solution but tends to work for me when i have that problem. You can do this by adding the following lines to your current theme's functions.php (in wp-content/themes/YOURTHEME/functions.php). ...


6

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: _site_transient_update_core ...


6

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. Close WAMP Go your the \bin\php\version directory in WAMP Edit the php.ini, and ...


5

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" ...


5

Things will move the quickest if you're willing to do some work on your own. Take some time to write a patch with your proposed hook Post a ticket on the WordPress Trac explaining the hook, why it's important, and linking to your patch file. Send a message to WP-Hackers explaining the same and referencing your Trac ticket. Attend the WP development chat on ...


5

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.


5

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: https://github.com/jeremyclark13/automatic-theme-plugin-update


4

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 ...


4

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 ...


4

From my perspective there are about two issues with your plan - Git and "conventional" structure. So basically everything. :) Git (and version control in general) is poor tool for whole site stacks. Been there, done that, it hurt a lot. What you call "unconventional" structure with content separated from core has been for a while very conventional and ...


4

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 ...


3

It's likely that the files aren't writable by WP for whatever reason. Do a manual upgrade instead. http://codex.wordpress.org/Updating_WordPress#Manual_Update


3

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. The ...


3

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() ...


3

WP checks for updates by sending data about all plugins and themes to the repository. To prevent false update messages for your own code you need to selectively scrub it out of those requests. The example for theme by Mark Jaquith: function cws_hidden_theme_12345( $r, $url ) { if ( 0 !== strpos( $url, 'http://api.wordpress.org/themes/update-check' ) ) ...


3

The setting you are looking for is found in "Settings"=>"General"=>"E-Mail Adress". All the Emails WordPress or Plugins send out are sent to the admin_mail, which is returned by get_option( 'admin_mail' ), and this Emailadress is not always connected to a user. If you first install WordPress, the first user created gets the role administrator, and the same ...


3

I'm not aware of any solutions for iterating through and automatically updating your list of plug-ins, but my guess is that any system that can automatically update WordPress itself can be modified to update everything in fairly short order. That said, I know of two good ways to update WordPress automatically: WP Remote This is an online service that ...


3

It's quite possible. I've been doing this for years with my Version Checker plugin. I do not distribute it openly, but in essence it checks a private version API , and then tosses the extra results into the update_core, update_plugins and update_themes site transients. WP then takes it seamlessly from there courtesy of the WP patches I supplied when I was ...


3

There is no config setting or definition you can set that will automatically update WordPress. Your options are to use the Beta Tester plugin, manually update, or do an svn up. You could set up a cron job on your server to run the svn up command every 12 or 24 hours but if there is a database upgrade you will still have to manually push the "upgrade ...


2

Yes, this is possible. There's an entire chapter in Professional WordPress Plugin Development dedicated to this. If you haven't already, pick up a copy. It will definitely help.


2

Auto update doesn't always work, it almost always works. I'd just upgrade manually and not worry about it. The few times I've had an auto update failure it succeeds the next time a new version comes out (after I'm manually updated during the breakage).


2

You'll want to make a new ticket here: http://core.trac.wordpress.org/ Explain why you want a new hook and how it could be used. Including a patch file also goes a long ways towards getting the hook included in WordPress.


2

I would approach that problem slightly differently. The entire bar does not need to reload. Instead it needs to stay "current". So to do that you load your initial value...let's say $100.00 Then you use Javascript to see if new values have been added and then you update it client side. You could even do a cool little fade out and fade in of the old vs ...


2

The markup above looks like a menu was not actually assigned to the area and is using the wp_list_pages() fallback instead. Point release changes (e.g. 3.3 to 3.3.1) are always going to be for major bugfixes and/or security, never for changes in functionality.


2

This is most likely because of file permissions on your server. WordPress needs to be able to write to the wp-content folder. I highly suggest you read this article about changing file permissions for WordPress. You may also need to CHOWN the directory that contains WordPress to the user that your web server uses. More here.


2

FTP credentials are fallback for when writing directly to the file system is not available. Naturally they take active FTP (or SSH) server - which is typical for any hosting out there, but not necessarily part of local installation. Essentially you have two options: Troubleshoot why direct file system access is not available to your WP installation. On ...


2

make a copy of the site in localhost,this will be better approch.To upgrade site see below link. https://codex.wordpress.org/Upgrading_WordPress_-_Extended_Instructions



Only top voted, non community-wiki answers of a minimum length are eligible