Let’s say you have a new web project you’re working on. Sure, you could setup a web server on your local machine and develop locally. For some reason you don’t want to do that though. Anyway, with this setup we’re going to assume you have some kind of landing page at the URL – why not? And you have a development directory dev. Now, as things get more complicated with this project, it would be nice if you could just point your browser at the root of the domain instead of a development directory. After all, eventually that’s where it’s going to live. Luckily, the solutions lies in .htaccess.

RewriteEngine on
RewriteCond %{REMOTE_ADDR} ^12.345.678.90
RewriteRule (.*) /dev/$1 [P,L]

Assuming your IP address is 12.345.678.90, this will forward the root of the domain to the /dev/ directory and your browser won’t know the difference. P means this is a proxy, so the URL won’t change. R would be a redirect which reloads the page at the URL – /dev/ in this case.

Since anyone could potentially spoof their REMOTE_ADDR, security is up to you.

Note: You’ll need mod_rewrite for apache installed for this to work.

I actually doubt Dan Benjamin¹ uses WordPress or cares about custom fields. The point is, your average client shouldn’t have to know or care about custom fields. I’d be happy if they were disabled by default — as long as I have an option to enable them by defining a constant in the wp-config file.

With a bit more work on your end as a developer, you can create a custom meta box that points directly at a custom field. If you’re really crazy about it like I am, you could even use a hidden key for you custom field by starting the name of the key with and underscore.

I think the ideal situation is if you happen to be working with a custom post type. It’s easy enough to turn custom fields on or off for any post type you create. So you can do all your testing with the custom fields turned on and turn them off when you get everything set and ship the theme off to the client. In the scenario, I don’t even bother using hidden keys, since there’s no way to access them directly through the custom field boxes anyway.

Advantages

There are a few advantages to doing things this way. The most obvious is that the client sees a nice clean interface with inputs that can be customized, explained, and show on every edit screen. You don’t have to teach anybody about adding custom fields or any of that. It’s just another box you can type stuff into.

The second major advantage that I see is that it doesn’t just have to be an input box. On a recent project I used a checkbox because it was an on/off thing and saved it directly to a custom field. I suppose it’s easy enough to explain to somebody that they have to type “1″, or “true”, or “Fdsfjje4jjfdsa9F#(d8df” into the custom field box; but if I can make something dead simple to use, I feel like it’s usually worth it in the long run.

So custom fields are fine for me, or you, or maybe Dan Benjamin, but don’t make your clients learn what they are. It can be, and should be, easier than that.

Background

It’s interesting watching the web and its technologies develop. A project that I’m currently finishing up is for a website that I’ve seen through a few iterations now. I did the first design for them a little over four years ago as a sophomore in high school.

At the time, I had already been using WordPress for awhile. It didn’t really even seem like an option for this site then though. As crazy as it seems now, Dreamweaver templates were what we decided on and that kept everything fairly sane — at least by the standards at the time. Managing it today would be considered a nightmare.

The next redesign was a couple of years later. Again, we went with Dreamweaver templates. While it probably would have been possible to switch to WordPress this time, it definitely didn’t seem like a first option for us. I was managing the few pages that were involved in my personal site through WordPress, but I think Dreamweaver was really the only thing we considered for the project. I still remember the process of converting the old templates to the new ones – most of which was done by Travis Wetzel.

At that time, I managed to get WordPress in the door by setting up a blog. It doesn’t seem like a big deal now, but I think it had a pretty big impact in how a large site like that was updated on a daily basis. It was getting obvious where the friction in the process was. And let me just say, I don’t think anyone involved had a strong attachment to the application with the little green icon by the end of this.

Federated Systems

Last summer we setup a multisite install of WordPress along side the preexisting website and blog. The steps started to become clear and the process of federating an entire website of html files plus two WordPress installs into one singly hosted website had begun. No more Dreamweaver templates or weird blog sub-directories or having to do something more than one way. WordPress was going to be the core of this site and make management a dream compared the the past.

Now, the transition.

Converging on WordPress

Even before setting up a second copy of WordPress, I knew that eventually we’d want to get all the information that had been kept in html files across a number of sub-directories into a CMS. And I knew that CMS was most likely going to be WordPress.

Moving it all

Moving everything went over pretty smoothly. I setup a new server, which was extremely helpful.

Moving the multisite install of WordPress involved downloading the entire database as a sql/text file since there’s no good way built into WordPress to export that – yet. Then I tarred the entire WordPress directory and downloaded it to the new server with “a little wget magic”. Setup the database, change some configuration files and that’s done.

Next, I exported the main WordPress blog that I still had to move through the WordPress dashboard. Imported it as the main site and copied over some assets and that was done as well. I’m simplifying this a bit, but you get the idea.

The small problem with the main blog is that the permalinks include /blog with the base url and no way to remove it. They add that to avoid collisions, but I couldn’t think of a scenario where that would be a problem in this instance so that doesn’t concern me and I didn’t really want everything to have /blog before it so I found a fix. Somewhere, probably in wp-config.php or maybe your functions.php file you can put define( 'BLOG_ID_CURRENT_SITE', 1 ); where “1″ is the ID of the main blog.

With all the WordPress stuff moved, we had to create some pages that didn’t already or wouldn’t exist as their own sites. Pretty standard stuff from here on.

The Future

I’m sure it will be nice for them to have everything in one database, in one WordPress installation, running on a theme that has to be designed once.

I did a new theme for the site as well that I’ll post up as a portfolio item when I get some time after the transition is complete.

For a long time now, I’ve been trying to figure out the best way to get stuff into my todo list on my Mac from my Android phone. I should say that I belong to the crazy group that uses OmniFocus, which is obviously a Mac app. They have wonderful iPhone and iPad apps, but I don’t have an iPhone. Sure I could carry an iPod touch around with me everywhere I go and for the most part I do, but my HTC Hero is with me 24/7.

This may not be obvious to everyone, but the best todo list app for Android is Todo.txt Touch by Gina Trapani. This thing almost made me drop OmniFocus, but I really like what I’ve got going in OmniFocus so instead I’m using Todo.txt Touch as input.

I’ve written an AppleScript that will look at my todo.txt file stored in my Dropbox and send everything over to OminFocus:

tell application "Finder"
    -- readFile
    set TodoTXT to "<Path to todo.txt>"
    set foo to (open for access TodoTXT with write permission)
    set txt to (read foo for (get eof foo))
    set eof foo to 0
    close access foo

    set Names to paragraphs of txt
    repeat with nextLine in Names
        if length of nextLine is greater than 0 then

            tell application "OmniFocus"
                set theDoc to first document

                tell theDoc
                    make new inbox task with properties {name:nextLine}
                end tell
            end tell

        end if
    end repeat
end tell

Beware, this is my first iteration of this script. That doesn’t mean I’m promising future versions. I’m only using the Android app as input at this point. It will import all of your todos to the inbox and then blank the file.

Running it

First, Hazel is setup to watch the folder in my Dropbox with a rule that watches for the Created Date to be the same as the Modified Date. This basically means that the file is brand new. It might not be obvious at first why this works. Basically, when the todo.txt file syncs from Dropbox it is replaced with a new version, thus creating a new file in place of the one that was there. When the script then goes and updates the file, either by blanking it or, maybe in the future, updating it with todos from Omnifocus, it is modified locally and not recreated so the two different dates would be different.

The other way I can run the script is from within OmniFocus itself. The script lives in ~/Library/Scripts/Applications/OmniFocus/, which let’s you add it while customizing the menu.

Feedback

If you find this useful, let me know. If you go on to modify it and make it even more useful than it already is, I’d love to hear about that too.

It’s been quiet around here. I’ve been busy, but I couldn’t let this one slip past no matter how much else I have to do.

Matt and company surprisingly released a new plugin for us .org users today. He actually hinted at a new project abbreviated JP in his new years resolutions, but who guessed it would be called Jetpack?

So, what exactly is Jetpack?

Jetpack supercharges your self-hosted WordPress site with the awesome cloud power of WordPress.com

Really, it provides a reason for me to stop second guessing myself about whether or not to host my blog on WordPress.com. Not that I would ever have actually done it, but I’ve often considered the advantages of using Automattic’s managed WordPress solution.

Besides practically bullet-proof servers, WordPress.com users have always had a few shiny things that have made the service tempting – even for people like me who want control over every single aspect of what is my website.

What do we get?

Initially we’re getting updates to WordPress.com Stats, the Twitter Widget, Gravatar Hovercards, WP.me Shortlinks, Sharedaddy buttons, LaTeX, After the Deadline, and Shortcode Embeds. And it looks like there’s more on the way. This is all packaged in one, nice plugin and updated and currated by Automattic.

Now, I won’t be using all of the extras, but right away the Stats and Sharedaddy links seem quite useful. I definitely won’t be using the Twitter Widget or WP.me Shortlinks, as I’ve got custom solutions that solve both of these problems in a way that I like. I haven’t been a fan of shortcodes lately, so I probably will skip that one as well. After the Deadline is something I’ll probably turn on for awhile and I’ve already got some ideas for ways to implement Gravatar Hovercards.

The Future

More than anything, this has me excited for the future of what this could mean for self-hosted WordPress. The additions that they’ve decided to ship with are cool, but I see a ton of potential for this product.

One thing that I’d really like to see is tighter integration into the WordPress.com network with a “WordPress bar” for users who are currently logged in to their WordPress.com accounts with subscription options, random post, shortlinks buttons, and the like. At this point, I can’t see anything stopping them from implementing these features. It would make that network instantly larger and more valuable.

Go get it

I definitely recommend everyone with a self-hosted blog go check out Jetpack. You can get it from the dashboard by searching for “Jetpack” in plugins or go to their website at jetpack.me