The biggest appeal WordPress has is it’s extensibility via plugins. But if you create a plugin for personal use or for a corporation with a very specific purpose, you may not want to go through the process of having it submitted, approved, and available for the world on the WordPress Plugin repository. So what’s wrong with just hosting your plugin .zip file and providing a link for convenient access? One answer: updates.

When a plugin is installed via the official repository, it will automatically make a call back periodically and check for updates. If updates are available, it will alert the user and provide a link to “update automatically.” With a home-grown private plugin, or a plugin kept out of the official repo. for whatever reason, there is no such lookup and link available. Until now!

Don’t You Just Love Open Source?

The wonderful thing about Open Source products like WordPress, is that you can see how things are working, and make your own solutions for issues like the scenario described above. After a lot of tinkering and investigation I came up with a really easy and simple solution with just 3 easy steps.

Step 1: Host an update file.

Create a plain-text file that contains 2 parts. The first part contains the current version number of your plugin, the second part contains the URL of where your plugin .zip file can be downloaded from. Separate these parts from each other using a simple pipe. Like this:

1.2.3|http://www.mycustomrepository.com/plugins/myplugin-1.2.3.zip

Now you need to host this file somewhere accessible by WordPress. My recomendation is to include this file right within your plugin folder prior to compressing it, and host the folder along side your .zip file. So the URL for the update file in our example above might be:

http://www.mycustomrepository.com/plugins/myplugin/myplugin.chk

Notice that I added a .chk extension on the filename. The extension does not matter here, just as long as the file is saved out as plain text. Using .chk just makes it easy to distinguish. It could just as well be .txt or whatever you want.

Step 2: Include update checker

I have developed a php file that contains all of the code necessary to make this work. You can either copy/paste its contents unchanged into your plugin’s main .php file, or I recommend just adding this file to your plugin folder and require it in your code.

You will also add some code to your plugin referencing the update check file discussed in step 1, and set a quick variable referencing your plugin.

To accomplish all of this, follow this example at the bottom of your plugin php:
//custom updates/upgrades
$this_file = __FILE__;
$update_check = "http://www.mycustomrepository.com/plugins/myplugin/myplugin.chk";
require_once('gill-updates.php');

Step 3: Host your plugin .zip file in the location you specified above

In our case, you would add the myplugin.zip file to the web host so that it will be accessible at the exact location specified in your update check file. For example:

http://www.mycustomrepository.com/plugins/myplugin-1.2.3.zip

What now?

Once you have completed the steps above you are set to allow your plugin to automatically check for updates of itself. All you need to do when you update your plugin, is edit the update file to a new version. Also, make sure the .zip file it points to contains your new version.For example:

2.0|http://www.mycustomrepository.com/plugins/myplugin-2.0.zip

That’s it! The plugin will now compare it’s current version (specified in the meta information of your plugin) to the version listed in the check file. If the check file number is greater than the number in your plugin, it will provide an “update automatically” link as though it were being hosted in the official repository, and when clicked it will update the plugin automatically with the file specified.

Credit

Ainun Nazieb who wrote a similar post on How to Make Your Own Plugins/Themes Updating Service. Ainun’s post claims it will work for plugins, but there wasn’t any specific information to support that claim. It was specifically related to Themes. This post certainly saved me a lot of work and started me on the right path, however.

The image used above was stolen from Smashingmagazine.com

CForms II WordPress Plugin

Using Cforms II, when I select font17.ttf as the captcha font (the one that looks comic book style) it will not validate…ever. I continue to get the message “Please double-check your verification code.” If I switch fonts, it validates just fine.

This has nothing to do with disabling other plugins and using default theme, as I have attempted all of that in order to track down what was causing this issue.

I’m now using font4.ttf instead, so I don’t really have an issue anymore, but I’m sure there are many others out there encountering this problem not realizing it is simply a font choice causing their headaches.

if($(".cform").length!=0){
  $(".cform select option").each(function(){
    if($(this).val() == "groupstart"){
      var label = $(this).text();
      $(this).nextUntil('option[value|="groupend"]')
        .wrapAll("<optgroup label='"+label+"' />");
      $(this).detach();
    }
  });
  $('option[value|="groupend"]').detach();
}

Once you have that code in place, all you need to do is add groupstart and groupend codes to your cforms settings for your select box. For the groupstart you will add it as though it were just another option, with the label being the label you want for your group, and the value being the literal string “groupstart.” For the groupend, it doesn’t matter what the label is, as long as the value is “groupend.” It’s easiest just to use groupend as the label, and leaving the value empty so that CForms will automatically use the label as the value.

Here’s an example of how to form your CForms settings in conjunction with the JQuery code above:

Color#Choose|#Warm Colors|groupstart#red#orange#yellow#groupend#Cool Colors|groupstart#blue#green#purple#groupend#brown#black#white

Which will result in the following:

Let me know if this works as well for you as it did for me.

# add a trailing slash to /wp-admin
RewriteCond %{REQUEST_URI} ^.*/wp-admin$
RewriteRule ^(.+)$ /wp-admin/ [R=301,L]

1. Using cPanel, go to PHP Configuration under the “software/services” section. There you will see 3 options: PHP5, PHP5 (Single php.ini), and PHP5 (FastCGI). If you are going to be using multiple domains in a single Bluehost account, make sure the first option is selected. If you are only using one domain on Bluehost or you want to use one setting to handle all of your domains, select the second option.
2. In the same PHP Configuration panel, under the install default php.ini section, select to include IonCube & SourceGuardian
3. Click on install php.ini master file. If the file already exists, it will give you an error. That’s fine, we can use the newly generated file or an existing file.
4. Using either the file manager, your ftp program, or SSH, navigate to the root of public_html and make a copy of php.ini.default named php.ini
5. If you selected the first option in #1 above, copy that php.ini file into the root of your cforms plugin directory. If you selected the second option, leave that file where it is.
6. Edit the newly created php.ini file by doing a text search for sendmail_path and replacing the entire line with something similar to the following:

sendmail_path = /usr/sbin/sendmail -t -i -f '"User Frienldy Name" <friendly@yourdomain.com>'

(note: you are allowed to use a Friendly Name, which isn’t something I could find in any other documentation. I was just experimenting and found out it worked for me.)

1. Create a file named info.php and place it at the same directory as your php.ini file. In the info.php file, simply include the following php:

<?php phpinfo(); ?>

1. View that page by visiting the correct path in your browser, whether it be yourdomain.com/info.php or if it be yourdomain.com/wp-content/plugins/cforms/info.php
2. Verify that the “Loaded Configuration File” option is showing the directory you placed your php.ini file in. If it shows /etc as part of your location, something is not right. Repeat steps 1-8 until that shows up.
3. Also using cPanel, go into the Email Accounts settings under the “Mail” section. Add friendly@yourdomain.com as a valid Bluehost email address.
   (note: this does NOT have to be wordpress@yourdomain.com, it can be anything as long as this matches what you placed in your php.ini file and you use the domain associated with Bluehost. Without this account, none of the settings above will work.)
4. Test your CForm to make sure it gets emailed correctly.

That’s about it. I hope this helps you. If so, leave a comment below.

In a nutshell, I used Mephisto for the conversion. First I spent about a week mapping Mephisto’s DB to WordPress’ DB. I went straight into the Mephisto Rails project and created a new model that pointed to my newly created WordPress database. I then created a controller in Mephisto that looked exactly like this:

(note: if this is a pain to read, you can also view it here)

class MephistoController < ApplicationController
    def index
        start_time = Time.now
        logger.info 'querying mephisto articles'
        @articles = Content.find(:all, :conditions=>"article_id IS NULL")
                logger.info 'querying mephisto comments'
                @comments = Content.find(
			:all, :conditions=>"article_id IS NOT NULL")
        logger.info 'querying mephisto taggings'
        @taggings = Tagging.find(:all)
        logger.info 'querying mephisto tags'
        @tags = Tag.find(:all)
        logger.info 'processing terms'
        for tag in @tags
            @wp_term = WpTerm.new
            @wp_term.term_id = tag.id
            @wp_term.name = tag.name
            @wp_term.slug = tag.name.downcase.gsub(" ","_")
            @wp_term.term_group = 0
            @wp_term.save
        end
        logger.info 'processing term relationships'
        for tagging in @taggings
            @wp_tr = WpTermRelationships.new
            @wp_tr.term_taxonomy_id = tagging.tag_id
            @wp_tr.object_id = tagging.taggable_id
            @wp_tr.save
        end
        logger.info 'processing term taxonomy'
        for tag in @tags
            c = Tagging.count(:all, :conditions=>"tag_id = #{tag.id}")
            @wp_tt = WpTermTaxonomy.new
            @wp_tt.term_taxonomy_id = tag.id
            @wp_tt.term_id = tag.id
            @wp_tt.taxonomy = "post_tag"
            @wp_tt.parent = 0
            @wp_tt.count = c
            @wp_tt.save
        end
        logger.info 'processing posts'
        for article in @articles
            c = Content.count(:all, :conditions=>"article_id = #{article.id}")
            @wp_post = WpPost.new
            @wp_post.ID = article.id
            @wp_post.post_author = 1
            @wp_post.post_date = article.published_at-7.hours
            @wp_post.post_date_gmt = article.published_at
            @wp_post.post_content = article.body
            @wp_post.post_title = article.title
            @wp_post.post_category = 39
            @wp_post.post_status = "publish"
            @wp_post.post_status = "open"
            @wp_post.ping_status = "closed"
            @wp_post.post_name = article.permalink
            @wp_post.post_modified = article.updated_at-7.hours
            @wp_post.post_modified_gmt = article.updated_at
            @wp_post.post_parent = 0
            @wp_post.guid = article.published_at.strftime("http://blog.gillumiante.com/%Y/%m/%d/")+article.permalink
            @wp_post.menu_order = 0
            @wp_post.post_type = "post"
            @wp_post.comment_count = c
            @wp_post.save
        end
        logger.info 'processing comments'
                for comment in @comments
            @wp_com = WpComment.new
            @wp_com.comment_ID = comment.id
            @wp_com.comment_post_ID = comment.article_id
            @wp_com.comment_author = comment.author
            @wp_com.comment_author_email = comment.author_email
            if comment.author_url == nil
                comment.author_url = ""
            end
            @wp_com.comment_author_url = comment.author_url
            @wp_com.comment_author_IP = comment.author_ip
            @wp_com.comment_date = comment.published_at-7.hours
            @wp_com.comment_date_gmt = comment.published_at
            @wp_com.comment_content = comment.body
            @wp_com.comment_karma = 0
            @wp_com.comment_approved = '1'
            @wp_com.comment_parent = 0
            @wp_com.user_id = 0
            @wp_com.save
                end
        logger.info 'finished!'
        end_time = Time.now
        @lapsed = end_time-start_time
        render :layout=>false
    end
end

I then proceeded to visit the /mephisto/index page on my mephisto blog, which fired this baby off. It took all of about 9 seconds to complete.

I realize the irony of using Mephisto in order to abandon it. But in the end, I wasn’t switching from the Rails based app because of Rails, but because of the app. I am still in love with rails and as you can see, this project would have taken me a lot longer to accomplish had I attempted to write it in PHP, the language of WordPress.

<Directory /var/www/html/wordpress>
    Options FollowSymLinks
    AllowOverride all
</Directory>