Here’s what I did to discover it. I’m hoping someone else can verify this and make sure it’s not just my environment and that I’m not just plain crazy!

1. Create a fresh, new WordPress 3.3.1 instance on MAMP.
2. Turn on WordPress DEBUG logging in the wp-config.php file.
3. Turn on the permalink structure for “month and name” (http://localhost/fresh/2012/02/sample-post/)
4. Create at least one extra page than the already generated Sample Page. I called mine “About Us.”
5. Create a very simple plugin to track the $_SERVER["REQUEST_URI"] call and send it to the log.

<?php
/*
Plugin Name: mytest
*/

add_action('init', 'mytest');
function mytest(){
    if(!is_admin())
    error_log($_SERVER["REQUEST_URI"]);
}

6. Activate the plugin.
7. Tail the log file (tail -f Sites/fresh/wp-content/debug.log) in Terminal.
8. Visit your site and watch the log file. Visiting “Home” only causes the request to fire once, visiting the new About Us page only fires once. But, here’s the strange thing: visit the Sample Page and it fires both the Sample Page and the About Us page.
9. Create more pages. Watch the logs.
10. Wonder, “WHY??”

I did some trial and error of adding and removing files and realized that WordPress not only requires the style.css file to be present, but also the index.php file. I was missing the index.php file thinking I was only using page.php without a blog.

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]