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

Chimpadeedoo

If you want to use a transparent PNG in MailChimp’s Chimpadeedoo iPad app, the file must be saved, not synced. In other words, if you try to transfer a png to your iPad by syncing it with iTunes, it’s going to get flattened and the transparency removed. But, if you email it to yourself and save it from the iPad, the transparency will be preserved.

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.

Is caused when JQuery javascript doesn’t load before the plugin js. To fix it, you just need to go into the jquery.easing.1.3.js file and wrap it with

$(document).ready(function() {
...
});

Coda by Panic

I’ve recently abandoned Dreamweaver as my primary web development platform. I know what you are thinking, “what took you so long?” Well, the truth of the matter is, I think Dreamweaver gets a bad wrap, just because of the WYSYWIG stigma. Frankly, I rarely if ever, was using the Design view in Dreamweaver and I mostly used it as a text based editor. I really love the shortcuts they’ve built in and found myself developing rather quickly because of them. So much so, that it has taken me quite some time, and quite a bit of trial and error, to actually end up leaving it behind.

There are several features that Dreamweaver has that I was always very particular about when looking for a new tool. Some of the requirements I have are:

• Built in SFTP (many editors only have FTP, if anything at all)
• Rich HTML, CSS, and Javascript support with good shortcuts and autocompletion. (Many, like Eclipse, are really good for back-end dev, but downright suck at front-end. I’m a front-end developer.)
• Synchronization feature, or at least some way of tracking which local files are different than those on the server (surprisingly few editors have this as a feature).
• Quick access to projects (The ability to save “Sites” and jump between them without ever using the “Open” dialog).
• Subversion integration was a plus, but not a requirement.

Frankly, Eclipse is a huge, bloated piece of nightmare for installing and running. Slap Aptana on top of that and you’ve got yourself a mess. Granted, Dreamweaver is also bloated, but not nearly as bad. As mentioned above, I also feel that Eclipse is really great for back-end programmers, but falls short for front-end. Same feeling about Textmate. Only Textmate is missing even more of the features listed above. After giving these, and others a shot, I would always find myself switching right back to Dreamweaver just to get the job done in an efficient matter. There are other programs I gave a shot, but it just seemed like they were all doing some things really well, but others really bad.

Enter Coda.

I learned about Coda from another web developer/designer that I follow on Twitter, @cliftonite. Obviously, I was skeptical at first. But I decided to fire up the 14 day trial. If I was going to ask my employer to purchase a license for me, I was going to have to make a good case, so it had to be really convincing. So I started keeping a list of things I liked about it, and things I missed from Dreamweaver.

Within a week I was sold. Here’s the list I came up with:

Coda’s strengths over Dreamweaver

• Remembers which files were open from site to site, even after closing the app
• Remembers and displays which files have been edited and need to be published
• Can publish each file with a single click
• DW sync takes *forever* – the 2 points above are the better solution
• Subversion integration
• Terminal integration (very cool)
• Much more robust CSS editor
• Much faster startup time (not bloated)
• Image Previews (!)
• Show change marks
• split file editing (edit more than one file at a time, or reference the one while working on the other.)
• Awesome visual representation of my Sites.

Dreamweaver’s strengths over Coda

• WSYWIG / Split screen editor
• common task dialogues
• Find/replace is cleaner
• Better and more helpful predictive code hints

At first, I’ll admit, I was still running over to Dreamweaver to accomplish certain things that, at the time, I didn’t realize Coda could do—or more importantly, I didn’t realize there was a better way to do it. For example, I’ve since learned to love Coda’s Find/Replace, it’s just a whole different paradigm.

I’m sure there are other things to add to this list, but it’s the list I sent my employer. I think it’s pretty obvious I felt that Coda had many more strengths. I’ve been using Coda pretty heavily now for several months and haven’t opened Dreamweaver for a very long time.

In a nutshell, I LOVE CODA! It’s the editor I’ve been holding out for. If you are a Mac user, head over and give it a whirl.

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

mkdir src
cd src
wget http://subversion.tigris.org/downloads/subversion-1.6.15.tar.bz2
wget http://subversion.tigris.org/downloads/subversion-deps-1.6.15.tar.bz2
tar -xvjpf  subversion-1.6.15.tar.bz2
tar -xvjpf  subversion-deps-1.6.15.tar.bz2
cd subversion-1.6.15
./configure --prefix=$HOME --without-berkeley-db --with-ssl LDFLAGS="-L/lib64"
make
make install

Note: I did get one error during the make install process, but it didn’t seem to matter. SVN works great for me.