Preventing WordPress Automatic Updates From Deleting Custom Settings (Themes and Plugins)

with 11 Comments

WordPress uses a drop in / replacement method for updating. This can be a disaster for sites with custom configurations like themes or custom site specific information like plugins caches or translators. Here is my solution to fix the whole problem!

My System…

Keep in mind that I have a lot of low to medium traffic sites.

I am writing a custom plugin called the Gamot Global Translator (not released yet!).  I also use a custom theme called Constructor. On top of this I have a complex install of WordPress 3 with multi sites built on second and third level domains and some starting as the default page, while others start in a WP directory, or CMS or Forum, or custom coded page (all on one WordPress Install mind you! – Cool!).

Note: Due to some issues with my setup I cannot resolve, I no longer am using the Constructor Theme.  I now use the Atahualpa Theme.  I also use the site/domain notation I wrote about at:

http://alantait.net/2011/01/15/wordpress-multisite-wp-multi-network-atahualpa-theme-easy-header-images/

Plus I have a CMS and two kinds of forums and plenty of custom pages all sharing the same directory structure, the same IP address space, and with 125 domain names and thousands of sub-domains all pointing at the same place! Obviously I need order and security!

Automatic Updates

Because I am thinking about releasing my code for the Gamot Global Translator – the ultimate in automatic translators – I have been thinking about Automatic Updates. Honestly, I usually do updates manually, but I needed to write this for people who use the Automatic Updates…

Here is the problem…

When you update WordPress, or WP Themes, or WP Plugins, it uses a drop in replacement method. In other words, it basically deletes what is there, and it replaces it with what is new. If there is nothing there, outside of your plugin files, other that options, that works great! But I have sites with, shall I say, special needs!

Constructor

Constructor is a Theme that let’s you build a custom theme right in WordPress. It is great, as long as you do not add any custom graphics or save any custom themes! Obviously, most people will want to add at least a custom header image! I am playing with it on three sites.

Note: I am currently switching to Atahualpa Theme (see note below for details).

The first is a site for the New Liphe Health and Healing Program (say “New Life” – http://newliphe.org/):

Today I will try it in a Filipina (http://filipina.fil.net/blog), a new blog presenting the Filipina in true colors.

Then I will try to add it to the Francis Kong Archive site (http://franciskong.acts-29.net/)… a collection of short inspirational articles by Francis Kong.

Note: The first is a default for the domain, the second is a directory within the domain and the third is a sub-domain!

The problem is that these have custom files that are deleted when I use automatic update.

Gamot Global Translator

I am likewise testing the Gamot Global Translator, a multi language, multi format, cache or no cache machine translator.  I will be adding this to the Francis Kong site (http://franciskong.acts-29.net/) and the New (coming soon) Full Gospel Business Men’s Fellowship International site (http://fgbmfi.net/).

Likewise, the problem is the cache, logs and other files are deleted when the Gamot Global Translator Plugin is Automatically Updated on my test bench.

WordPress Core Team Suggestion!

First of all I suggest the the Word Press Core Team adds a directory to
wp-content
Called:
wp-content/custom

If anyone knows anyone on the Core Team you might suggest this to them! It works great on my sites.

Step 1 ~ Custom to the Rescue!

Step 1 ~ The blogs.dir to the Rescue!

Frumph pointed out a nice function, wp_upload_dir(), that delivers a safe place to put custom files and already exist. Therefore I am modifying the below post to use the blogs.dir directory or the wp_upload_dir() function.

For this post, blue is the modification, srtikethrough is the former way.

Here is the very easy solution for any web developer or anyone with PHP skills.

I started by creating the the custom directory here…
wp-content
Called:
wp-content/custom

At this writing this directory (wp-content/blogs.dir) is NOT deleted or overwritten in any automatic update process. So if you use automatic update for a new version of WordPress, WP Plugins or WP Themes, this directory is not deleted.

Step 2 ~ Plugin / Theme / Cache Directory

I now create the custom directories I wish to protect. For ease of memory I use the exact same name at the Plugin or Theme directory name. For example, I have these directories:
wp-content/themes/constructor
wp-content/plugins/gamot-global-translator

So I created these directories:
wp-content/custom/constructor
wp-content/custom/gamot-global-translator

wp-content/uploads/constructor
wp-content/blogs.dir/gamot-global-translator

Note: The Gamot Global Translator was written to do this for me!

Step 3 ~ Create Custom Folders and Information

The Gamot Global Translator does this for me. Hopefully in the future other Theme and Plugin authors will do this too. Here is the what I did with the Constructor Theme.

I moved the directory and all the contents of this directory:
wp-content/themes/constructor/themes
To this directory:
wp-content/custom/constructor/themes
wp-content/blogs.dir/constructor/themes

Then I hacked the Constructor code to point to this new directory instead of the old one.

What happens is when I do the automatic upload on the Constructor, it overwrites everything in the directory:
wp-content/themes/constructor
However my custom theme designs are safe in the directory:
wp-content/custom/constructor/themes
wp-content/blogs.dir/constructor/themes

So all I need to do is again hack the new Constructor code to point to the new directory and I have lost nothing!

If the author of the Constructor Theme were to slightly modify his script to always point to directory at:
wp-content/custom/constructor/themes
wp-content/blogs.dir/constructor/themes
Then people could use the automatic theme update and not lose their custom theme graphics and design.

Someone may want to suggest this or point him to this page. All I ask is a little credit for the suggestion.

By the way, running a lot of low to medium volume sites on a single WordPress like I do, the Constructor is a good Theme, as I can dress up each site differently without having a lot of different themes!

Note: I am currently switching to Atahualpa Theme as Constructor needs access to the default domain to serve CSS and that breaks with the default being a static or custom dynamic page as it is on some of my sites. On those sites Constructor servers no CSS. Atahualpa and TwentyTen both work properly under the same conditions. I will post about this soon and the mods I made to make each site have different headers.

Good luck with this.

Sorry, I cannot give specific code details here. (Note: I do not maintain the Constructor Theme and the Gamot Global Translator is not even ready for Alpha Testing!) This is a little more advanced PHP than the average WordPress user would be doing.

Plugin Developers or Theme Authors asking specific questions about moving their custom files as suggested above, to avoid being deleted during automatic updates, I will try to help you.

Codifically,

LAN

11 Responses

  1. remy
    | Reply

    Hi,

    We had a custom theme and we updated our wp and lost the theme. How can we recover it ?

  2. remy
    | Reply

    Thanks Lan, appreciate the assistance.

  3. Dan Hatcher
    | Reply

    I take it that the only “custom” part of the theme that you have to do this way is the “Header” images? I’ve customized sidebars and widgets and header images, then updated the theme and have only noticed the header images reverting back to the original. Is there something else I have missed that I lose when doing a version update?

    I did the /blogs.dir/mydomain.com/images/header thing according to your directions and it works like a charm! First try too! Thanks!
    Dan

    • Lan
      | Reply

      Hi Dan, I suggest you wait for the new release (very soon!), it will be much easier.

      As to your question…

      The BAD news is… What you upload via FTP to the Atahualpa Theme directory, or ANY of its subdirectories, is pretty much deleted when you do an automatic update.

      The GOOD news is… Most things, like widgets and such are stored in your database, or uploaded as a plugin, not uploaded via FTP into your Themes folder.

      What people most commonly upload via FTP to the Theme Folder (and what usually gets wiped out) is the Site Images. This would include custom Header Images, a custom Logo, and a custom Favicon.

      The new version of this mod, puts these in safe places! For each and every site. Plus it uses the normal Media Unloader in WordPress to make it even easier (no more making custom directories! WordPress does it for you!).

      Hopefully the next step will be to merge this into the BytesForAll code so that updates are even easier!

      Codifically,

      Lan

      Watch for the new update.

  4. Russell
    | Reply

    Thanks for that. I’d be keen to see the plugin if you finish it.

    • Lan
      | Reply

      We plan to release this as part of the TuKod (To Code) project on tukod.com

  5. Ivan
    | Reply

    I have reached this post by looking for something similar but not what I needed. The problem I am trying to solve (or at least find the best approach possible) is about custom code. That is the PHP, HTML, JAVASCRIPT, CSS code you use to modify WordPress core, plugin or theme behaviour or look. Whereas it is reasonably easy to modify WordPress code to adapt it to your needs I couldn’t find a good way to do it and not ruin it when you update your applciation (either WordPress core, plugins or theme). Using actions and filters is a good solution for some cases but still there are other situations where you have to mix wordpress code with yours. That makes updating a real headache as you must redo all this modifications for the new version.

    Do you have any good advices on that?Good practices, nice plugin or something that might help?

    Thanks in advance!!

    • Lan
      | Reply

      Thanks for the strokes, due to a massive work load, (MyDomain shut down there server with about 24,000 DNS records for sites we maintain and Monikers new owner had problems effecting ALL our registered domains).

      However the TuKod Theme and the three (or four) TuKod plugins are working, just the documents are not finished. I hope the team and I can start to finish these up and get them posted on WordPress.org. Sooner!

  6. FarmerJohn
    | Reply

    I’ve inherited a WP site where the previous developer made both changes to WP core file and plugin files. The blog’s owner was in the position where any update would, essentially, hose the entire site.

    It took about 40 hours of coding and running constant ‘diff’ commands, but I’ve finally gotten the WordPress core to it’s stock version and updated. The problem I face now is the plugins (BuddyPress, ProfileBuilder, Cubepoints, etc). What’s the best practice for tending customizations to plugins and still allowing updates to those plugins?

    • Lan
      | Reply

      @FarmerJohn – For me, I write a plugin that modifies the plugin. IF I really need to make a customization to a plugin, I rename the plugin, make the mods with heavy documentation and do not put them into the same place in the plugin directory. For example, add your name to the beginning so you know it is a custom plugin that needs to be manually updated.

Leave a Reply