VPetkov.net

UPDATE: Please check out latest version from my git repo: http://git.vpetkov.net/projects – project name: “wordpress”

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:

#!/usr/bin/perl
# Usage:
# ./update-wp-plugins.pl
#   or
# ./update-wp-plugins.pl registered-name-of-plugin
# (and this works to update an exiting plugin or download+install a new one)
chdir("/var/www/domain/blog/wp-content/plugins");
use WWW::Mechanize;
my $mech = WWW::Mechanize->new();
$mech->agent_alias( 'Mac Safari' );
my $wp_base_url = "http://wordpress.org/extend/plugins";
 
################################################
# Add New Plugins Here:
# Format:
#   'registered-name-of-plugin',
#
my @plugins = (
    'google-sitemap-generator',
    'wptouch',
);
################################################
 
if(defined($ARGV[0])) {
    my $name = $ARGV[0];
    &update_plugin($name);
}
else {
    for my $name (@plugins) {
        &update_plugin($name);
    }
}
 
sub update_plugin {
    my $name = shift;
    my $url = "$wp_base_url/$name";
    $mech->get( $url );
    my $page = $mech->content;
    my ($url,$version,$file) = "";
    if($page =~ /.*<p class="button"><a href='(.*)'>Download Version (.*)<\/a><\/p>.*/) {
        $url = $1;
        $version = $2;
        if($url =~ /http:\/\/downloads\.wordpress\.org\/plugin\/(.*)/) {
            $file = $1;
        }
    }
    print "\nPLUGIN: $name | Version $version\n";
    `/bin/rm -f $file`; print "Downloading: \t$url\n";
    `/usr/bin/wget -q $url`; print "Unzipping: \t$file\n";
    `/usr/bin/unzip -o $file`; print "Installed: \t$name\n";
    `/bin/rm -f $file`;
}

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.

UPDATE: Please check out latest version from my git repo: http://git.vpetkov.net/projects – project name: “wordpress”

When you host a WordPress installation for yourself, and there is some sort of an update about every month, it can get 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 500+. Welcome to my nightmare. Eventually I caved in and wrote this:

# http://codex.wordpress.org/Updating_WordPress#Step_1:_Replace_WordPress_files
# This strictly follow the directions mentioned above.
# Utilizes: "rm", "cp", "mv", "wget", "unzip"
 
umask 0022
WEBROOT=/var/www/domain
CURRENT_BLOG=$WEBROOT/CURRENT_BLOG
TEMP_NEW=$WEBROOT/wordpress
 
cd $WEBROOT
/bin/rm -Rf latest.zip
/usr/bin/wget http://wordpress.org/latest.zip
/usr/bin/unzip -q latest.zip
 
# Remove outdated CURRENT_BLOG files per instructions
cd $CURRENT_BLOG
/bin/rm -Rf wp-includes wp-admin
 
# Copy TEMP_NEW files per instructions
cd $TEMP_NEW
/bin/cp -Rf wp-includes $CURRENT_BLOG/.
/bin/cp -Rf wp-admin $CURRENT_BLOG/.
 
cd wp-content
/bin/cp -Rf * $CURRENT_BLOG/wp-content/.
cd ..
/bin/mv *.php $CURRENT_BLOG/.
/bin/mv readme.html $CURRENT_BLOG/.
/bin/mv license.txt $CURRENT_BLOG/.
 
# Cleanup TEMP_NEW - remove extraction and download.
cd $WEBROOT
/bin/rm -Rf wordpress latest.zip
 
# CUSTOM
echo "go to: http://YOUR-BLOG-URL/wp-admin/upgrade.php"

So, to summarize, this will download the latest version of wordpress, unzip it, and move the new things accordingly. At the end, it will remind you to upgrade your DB, just in case. I highly suggest backing up your primary blog before you begin this, just because it’s the “safe thing” to do.

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.