Sadly, development on Journler has really ground to a halt over the past year or so, and exciting new “cloud” centric applications like Evernote have sprung up, featuring handy smartphone applications and text recognition. I decided to migrate, but did not want to lose my hundreds of existing Journler records.

Here’s how I moved my Journler notes over. This approach will map Journler folders to Evernote notebooks, will preserve create & modification dates of your Journler entries, and preserves HTML formatting. The Journler category is NOT parsed out or mapped, nor are tags supported.

1. Export all Journler records, by Journler category and/or target Evernote notebook. For example, if you have a Journler folder called “Personal”, select all entries and then choose: File / Export Selected Entries. You need to export the entries as “Rich Text”, Include header, Set file creation date, Set file modification date, and “Save each entry … in its own file all in a single folder.” NB: The folder you save to will become the name of the Evernote notebook.

2. Launch Evernote, go into Preferences, and in the Clipping tab, temporarily disable: “Bring note to front”, “Bounce dock icon” and “Play a sound”. In the General tab, click on “Grown preferences” and temporarily disable Growl for Evernote. You can turn these settings back on after the import, but trust me — if you import > 10 Journler entries, you will want these off.

3. Load the applescript below into Script Editor.app, and run it.

4. Pick the folder you exported your Journler entries to. Remember: the name of this folder becomes the name of the notebook in Evernote.

5. Run the script.

6. Rinse & repeat for your remaining Journler categories / notebooks.

7. Done!

You may want to consider using the export process from Journler as a way to remap your categories. If you export multiple Journler categories into the same output Folder, they will end up in the same Evernote notebook after import.

Code for the applescript below. There is no error checking, and standard disclaimers around ruining your existing Evernote records and formatting your hard drive apply.

set listOfNames to {}
set theFolder to choose folder "Select the source folder"

tell application "Finder"
	set filelist to every file of the folder theFolder
	repeat with currentFile in filelist
		set currentFileName to (the name of currentFile)
		set nom to currentFileName
		if text -4 of nom is "." then
			set currentFileName to (text 1 thru -5 of nom)
		end if
		set currentFileDate to (the creation date of currentFile)
		set currentFileLocation to currentFile as alias
		set currentFileFolder to (the name of theFolder)
		tell application "Evernote"
			create note title currentFileName created currentFileDate notebook currentFileFolder from file currentFileLocation
		end tell
	end repeat
end tell

I’ve “made the switch” to os x since my last post over a year ago. Expect to see a lot of mac-centric content going forward, as I learn more. 

FAT/VFAT doesn’t support groups, and doesn’t support modified time recording to the second, only minute

1. instead of -a ( -rlptoDg) use just -rlptoD (removes the ‘g’)
2. add –modify-window 120 (seconds)

For backing up user dirs that do not match the external permissions, use “-rltD”. vFAT doesn’t do multiuser when mounted under linux

FAT isn’t case sensitive, so “Folder” and “folder” on the source will collide on destination. Avoid this naming on the source side

Debian does a decent job of it, if every blog has its own hostname, e.g.

• http://www.ajmani.org
• http://curtis.ajmani.org

But as soon as you want to do a second, separate blog underneath an existing one it all falls down. For example:

• http://www.ajmani.org/sub_blog

You can copy all the WordPress php files into the new blog directory, as outlined here, but then you lose all the advantages of Debian’s package management and centralization of the application.

My solution was to hack up the /etc/wordpress/wp-config.php file. The default Debian file looks something like:


/** WordPress's Debianised default master config file
Please do NOT edit and read about how the configuration
works in the README.Debian
**/
require_once('/etc/wordpress/config-'.strtolower($_SERVER['HTTP_HOST']).'.php');
define('ABSPATH', '/usr/share/wordpress/');
require_once(ABSPATH.'wp-settings.php');


I edited it to conditionally search for a pattern that matches the sub_blog string. This string needs to be unique of course, and specific to each sub_blog installation.


/** WordPress's Debianised default master config file
Please do NOT edit and read about how the configuration works in the README.Debi
an
**/
if ( strpos($_SERVER['PHP_SELF'], '/sub_blog/') !== false ) {
require_once('/etc/wordpress/config-subblog.ajmani.org.php');
}
else {
require_once('/etc/wordpress/config-'.strtolower($_SERVER['HTTP_HOST']).
'.php');
}
define('ABSPATH', '/usr/share/wordpress/');
require_once(ABSPATH.'wp-settings.php');


I will have to update the /etc/wordpress/wp-config.php file after each Debian update to WordPress, but at least everything else is centralized.

A simpler option, if starting from scratch, would appear to be WordPressMU (Multi User). Since I had a bunch of existing blogs, I didn’t feel like trying to retro-fit them into a new install.

Last week I installed Talisman/Basic v1.2, and from then on my wireless link would drop after 5-10 minutes and required a reboot of the router to restore. All my settings were lost during the upgrade, even though I followed the official upgrade path.

I’ve downgraded back to Talisman/Basic v1.1 which has been pretty solid for me over the past year. I might change back to the Linksys stock firmware, since all I use from Talisman is QoS and sshd.

There are a number of free WRT firmware solutions out there that are much more mature now than they were when I first purchased ($20) the Sveasoft firmware a few years ago. See the Wikipedia entry for WRT54G for more details.

I might talk about my life too, but it’s unlikely. I’m not that much of a narcissist.