Tag Archives: Blog

A long time ago I became frustrated with having to update my WordPress plugins manually, so I created a Perl script and a blog post (https://blog.vpetkov.net/2011/08/03/script-to-upgrade-plugins-on-wordpress-to-the-latest-version-fully-automatically/) that explained how to automate this. The idea was quite simple: feed a plugin name, have the script check the WordPress plugins page for the latest versioned download, grab it, and extract it over the specified blog plugins directory and thus update the plugin.

The script was simple and it worked very well. It made dealing with plugins many times easier. However, there was one big down side as some users pointed out — it did not actually check if a plugin needed to be updated. It blindly replaced the current plugin with the latest version. This meant that there was no way to “efficiently” automate it. If you cron-ed it directly, it would simply pull and update all your plugins at whatever period you specified. For the longest time this really irritated me, but I didn’t have time to dig through WordPress to understand how the engined checked and signaled for local plugins. One particular user (Joel) forked a copy and made many improvements to deal with this specific issue.

As time went on, I decided to look at this problem again. A couple of years ago I solved it in a really elegant way, but I didn’t have time to update the blog post. A few days ago, after looking at the blog statistics, I realized that the WordPress article was one of the top 10 most popular ones. So, with that said, here is:

A new simple and elegant solution

The idea is to use the WordPress CLI in order to “query” the local plugins database for plugin names, version number, and “activated” status, and then compare the “local” plugin version with the “remote” plugin version. If the plugin is active and in need of an update, fall back to my original Perl script to update it. Aha! And now we have something that can be cron-ed ­čÖé

To get started, first grab the WP CLI utility. We are going to rename it, move it to an accessible place, and take care of permissions so that we can use it:

Continue Reading →Easy fully automated WordPress plugin update system

[updated: Sep 30th, 2018 | New easy and fully automated system for updating plugins – this is the “perfect” solution to this problem]

[updated: Feb 11th, 2018 | Updated script to deal with new format, syntax, urls]

LATEST UPDATE: Please checkout my “perfect” WordPress plugin update solution: http://blog.vpetkov.net/2018/09/30/easy-fully-automated-wordpress-plugin-update-system

Droidzone (Joel Mathew) has created a much more advanced fork of this with many improvements – check it out: http://blog.droidzone.in/2013/03/31/automatically-update-all-wordpress-plugins-from-bash/ (While I still very much support this, I believe my updated solution from Sept 30th, 2018 is incredibly easier and has a single dependency on “WWW::Mechanize”. Leaving the link here to Joel’s for anyone that is interested in taking a look at his. His original fork + extension supports good visual output and other options that someone may be interested in. I believe the last update was in 2014.)

I already created a script to upgrade wordpress installations automatically. You can find it here:┬áhttp://blog.vpetkov.net/2011/06/01/script-to-upgrade-wordpress-to-the-latest-version-fully-automatically┬áRecently, the same general problem came about when it came to plugins. The biggest problem I had is that I had to log-into wordpress, see a number of plugins that were outdated, and then go hunt each one down by generally just copying the name and pasting it into google . Even thought most of the time, the plugin was the first hit, I then had to download the latest version, extract it, and clean it up. Imagine doing this for 10+ plugins for 5+ blogs — constantly. It was just time consuming and frustrating.

Here is my solution in the form of a perl script:

This script can be used in one of two ways:

1.) You can simply run it, and it will update everything that you have listed in the @plugins array.

2.) You can give it a parameter of a registered plugin name. This does 2 jobs — upgrades an existing plugin, AND installs new ones.

You can definitely add an extension to this. For #1, you can go a step further by making it scan your plugin directory and populating the list from there. If you want to be even fancier, you can relatively easily keep version tracks of what you have installed and what’s currently available, so that you don’t just blindly download new plugins. For me this is sufficient. If anyone is interested in getting help implementing any of these extra additions, feel free to ask and I’ll help as much as I can.

[updated: Sep 30th, 2018 | Cleaned up script, and references “perfect” plugin update system]

NOTE: Please checkout my “perfect” WordPress plugin update solution: http://blog.vpetkov.net/2018/09/30/easy-fully-automated-wordpress-plugin-update-system

When you host your own WordPress installation, and there is some sort of an update about every month or so, it can quickly get very annoying doing all the upgrade steps manually (for the people who do not have a CPANEL or FTP account). Now imagine hosting 5-6 WordPress installations. Now imagine 100+. Welcome to my nightmare. Eventually I caved in and wrote this:

So, to summarize, this will download the latest version of wordpress, unzip it, and move the new files accordingly.
At the end, it will remind you to “upgrade” your DB, just in case there is an upgrade. I highly suggest backing up your primary blog before you begin this, just because it’s the “safe thing” to do.
That said, in the 10+ years I’ve used this (started long before I posted something here) – I’ve never had anything go wrong!

Hey There, Welcome! I finally brought up a new website. It is far from complete, but a little by little, it will get there. Recreating all of the documentation will take a long time, so please be patient and check back often. My website needed a redesign for a very long time, and I kept putting it off since there was never enough time. I thought long and hard about how this website should look and feel in order to be simple/minimalistic, and clean, while offering ┬ávery rich and detailed information — mostly in the form of documentation and “what’s new or on my mind” articles.

What started this was my realization that it was time to migrate everything away from PmWiki. While PmWiki was a great replacement for my original static site, I slowly outgrew it. I started using it (no, I actually used about 7 other wikis first until I stumbled onto PmWiki) because I wanted a quick way to add documentation while I wasn’t near a terminal. After wikis got popular and the spammers started hitting them, I quickly password protected it. Then, a little by little, I kept adding more plugg-ins/mods, themes, and custom code. A little by little, I realized that other than the dynamic text entry, I had re-written or customized almost everything. It got to a point where I spent more time maintaining the wiki around upgrades than the actual documents and articles.

Due to this, I started a blog — using WordPress. My initial impression was that WordPress was very heavy and bogged down, and very ugly. I did not like my initial experience. I switched to another blog suite — textblog. After a few months I realized that I needed more functionality, so I deployed a simple php blog. After a few more weeks I decided to give WordPress another chance, since I had just read an article that they were going to release a new “ajax” management interface. This is what hooked me onto WordPress. However, as time went on, I realized that maintaing PmWiki *and* WordPress was almost a full time job. I spent endless nights trying to customize the code on each one in order to make them fit a common theme. I finally gave up and decided to just shut down my website. After a few months, I came to the conclusion that the documentation and articles I had were not only useful to others, but to myself too, and I actually missed having them up to date. This brought on a new goal: use a documentation source and a dynamic article software under one common system. I looked at WordPress’ ‘Pages’, and liked them for the most part. While not amazing, they suffice. At last, it was decided: I was going to use WordPress to replace my Wiki and Blog.

Before I started head on, I looked at some content management systems (CMS) like Joomla, and Drupal. I had actually used Drupal at a previous job, and I hated it, and Joomla simply reminded me too much of Drupal. I looked at a few other ones, but the story was the same. The reality is that the documentation pages are static for the most part. They get written once, and stay the same for the most part, with small changes here and there. CMS’ on the other hand are more like portal drop-ins. This is also why they require a lot more work. I had already been on the side of maintaining things, and I just wanted something that “worked”.

Here we are now, with WordPress as the documentation system (via Pages), and the dynamic article system (via the blog engine). I did have to spend a good 4-5 hours getting everything configured and customized, but with the exception of a small piece of code, all of my customizations will not be impacted all all by upgrades. This is it. I will keep this theme, look, and feel for a very long time. My main goal is provide lots of documentation in a few categories: Network Services, Smart Phones, Security, Programming, and at last, Operating Systems. Each of those has many sub-categories, but you can find more from the Pages. I will also provide any and all files/scripts/programs that I either come accross, or create.

At last, everything is free for grabs. You may take, modify, and/or share anything from this website — of course, at your own risk. I would prefer if you give credit and put a link to my site, but you are not required to. Thanks, and I hope you find all of the information here useful.