Forward to development dir, mod_rewrite

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`.
(more…)

Custom Fields are fine for Dan

I actually doubt Dan Benjamin1 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.
(more…)

Converging on WordPress

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.
(more…)

Todo.txt to Omnifocus

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.

Update

After David Sparks linked here on his MacSparky blog, one user suggested a shorter version of the script:

set p to "<Path to todo.txt>"
set l to paragraphs of (do shell script "grep . " & p)
do shell script ">" & p

tell app "OmniFocus" to tell document 1
repeat with v in l
make new inbox task with properties {name:v}
end repeat
end tell

Thanks for that and thanks to David for linking here.