Rob Reed, creator of the Ode blogging system has released a new theme for Ode that you can see at his site.

I have a lot "invested" in the current Ode theme, but this looks so good that I really should deploy it on my site.

While I will still be starting most of my microblogging-style (i.e. social-media-style) posts on this site, I will be moving them to my updates site so this site will be a lot less cluttered and feature "full" entries only, for the most part.

Also, the social updates will not be on both sites, also for the most part.

Every couple of days or so, I will move the new social posts from this site to the updates site.

At some point, I will modify my current scripts to post directly to the updates site, and Frugal Technology, Simple Living and Guerrilla Large Appliance Repair will not be flooded with those short entries, which will have a permanent home at Steven Rosenberg's Microblog of Short Posts..

If you want to try the Ode blogging software that powers this site, it comes in two parts. First is the Ode system itself.

There are also a bunch of addins.

Here is what is available from project leader Rob Reed:

• The Ode software (use this to get started)

Addins:

• Disqus (Add comments)
• EditEdit (Create and edit posts with a web form)
• Indexette (Give posts date stamps in metadata instead of using file time)
• Jumper (Add a tag that puts a post preview in the index with a link to the full entry; included in main Ode package)
• Mrkdwn (Use Markdown to simplify the HTML tagging in posts; included in main Ode package)
• Shyposts (Hide some posts from indexes)

Some Ode themes can be found here.

I've been thinking for a while about breaking out my social/microblogging posts and putting them on a separate site mostly because the number of these short entries quickly outpaced the number of "regular" posts.

They're different kinds of content, and I think having them on separate sites works better.

I now have a live microblogging site, also based on Ode, and I'm experimenting on how to tweak the Ode theme(s) to better accommodate what are traditionally considered social posts, meaning they don't have a title and are just a block of short text.

Read the rest of this post

There is plenty of documentation that comes with the Ode software, but Rob Reed has written a lot more about how the Ode blogging system works.

I first learned about highlight.js while trying out the Go-based Hugo blogging system, where it is a popular choice for adding syntax highlighting to blocks of code displayed on web pages.

Another solution is Pygments, but I didn't want to wade into Python, and a pure JavaScript solution like highlight.js seemed easier all around.

I had already used highlight.js successfully in a couple of Hugo themes, one in which I did the installation myself and another that had it built-in.

So it was only a small leap to do the same on this Ode site.

The instructions are clear (and easy), and the highlight.js developers allow you to create a custom download via check-boxes to include only the languages and markup you want to use on your site. That same page has info on using two separate CDNs (content delivery networks) to deploy highlight.js on your web site, but I opted to create my custom bundle and host it on this site as part of my main Ode theme.

Once you have the Javascript and CSS on your site and are calling it into your web pages, everything between <pre><code> and </code></pre> will benefit from highlight.js' syntax highlighting.

And as you can see, it works.

The only time this kind of syntax highlighting gets problematic is when displaying HTML, where you need to replace < with <, > with > and so on.

Here's a small bit of Ruby so you can see what the syntax highlighting looks like without leaving this post:

Dir.glob("X16*") do |file|
 File.delete(file)
end

I originally coded the categories listing as part of the overall Counter addin to Ode early last year, and Ode project leader Rob Reed lent his expertise to the addin, optimizing the code and squashing a few bugs in the process.

I had the categories listing in my right-hand column for a while, but since this Ode site has a LOT of directories/folders in it, that display made the right side of the page super long.

So I wanted the ability for readers to show/hide that listing. I didn't want to use jQuery, but I was very open to using vanilla JavaScript to make it happen.

And so I did. I looked at a lot of tutorials on how to hide the content of HTML divs (i.e. the stuff between a <div> and a </div>), and this one struck me as both simple and effective (meaning it's short and it works).

So now you can click Show / hide categories on the right to see the entire structure of the documents directory and drill down into topics that may be of interest.

Rob did a lot of work on my code, and I looked back at our e-mail thread from March 2016 and realized that I'm not even running the most recent version of the Counter addin on this site. Once I get that up and running, I will work on expanding the documentation on how to use the addin and then make it available to all.

Thanks go to Will Master for the JavaScript and Rob Reed for the Perl.

Once I figured out the concept of an addin (or, at any rate, my addin), I was off to the races. It was basically, "figure out what you want to display, figure out how to pull the information using Perl and the Ode addin structure, then drop tags into my Ode template to display the information."

Of course you can also say, "Here are things I can do in Perl, maybe it will be cool to put that on the web site." I guess I did a little of that, too.

However you slice it up, writing code and seeing results on a live web site is fun. In the Ode world, you can do that with HTML and CSS just like with any web site, and you can also write Perl addins. With this most recent hack (the show/hide), it was a matter of "appropriating" some vanilla JavaScript to add a feature I've been wanting for some time.

Ode runs Perl via CGI on the server. That doesn't mean it is slow.

Turns out it is very, very fast.

I can render an index page with previews of every post (all 900+) in about 20 seconds.

I'm exploring ways to take WordPress blogs and semi-automatically covert them into heaps of individual static files for use in blogging systems like Ode that take text files and convert them to HTML either on the fly or via a static-site engine.

I think it's going to take a combination of at least two existing tools plus some scripting on my part to take what those tools create and further process the files for Ode.

I tried two WordPress plugins that didn't work at all: WP Static HTML Output and Static Snapshot.

A third WordPress plugin, Really Static, did not look promising, and I didn't try it.

I tested the HTTrack Website Copier -- there's even a Fedora package for it -- and that pretty much downloaded the entire WordPress blog as a fully baked static site. But it didn't produce files or a file structure that is in any way compatible with any other blogging software.

Still, I think HTTrack will be valuable in terms of extracting the images from WordPress sites for use in other blogging systems.

I tried another method using wget (which HTTrack also uses) with a ton of command-line switches in a post titled Creating a static copy of a dynamic website.

In case the above site disappears, here is what you do:

The command line, in short…

wget -k -K -E -r -l 10 -p -N -F --restrict-file-names=windows -nH http://website.com/

…and the options explained

-k : convert links to relative
-K : keep an original versions of files without the conversions made by wget
-E : rename html files to .html (if they don’t already have an htm(l) extension)
-r : recursive… of course we want to make a recursive copy
-l 10 : the maximum level of recursion. if you have a really big website you may need to put a higher number, but 10 levels should be enough.
-p : download all necessary files for each page (css, js, images)
-N : Turn on time-stamping.
-F : When input is read from a file, force it to be treated as an HTML file.
-nH : By default, wget put files in a directory named after the site’s hostname. This will disabled creating of those hostname directories and put everything in the current directory.
–restrict-file-names=windows : may be useful if you want to copy the files to a Windows PC.

This is a cool exercise, and it pretty much produces what you get with HTTrack. Cool but not useful.

Along these lines but aiming for something that's actually useful, I could use wget and just target the images.

Here's where the good stuff stars

It's not all bad. I just tried a Ruby Gem called wp2middleman, which takes a copy of the XML that you export out of WordPress and turns it into individual static files (either HTML- or Markdown-formatted) with YAML-style title, date and tags.

You get the XML from the WordPress Dashboard (under Tools -- Export). Then you process that XML file with wp2middleman.

If you already have Ruby and Ruby Gems set up, getting the gem is as easy as:

gem install wp2middleman

Then you can produce a full filesystem with individually named files with:

wp2mm your_wordpress.xml

That gets you the files. Not the images. I'd use HTTrack or some similar tool to get those.

That I can work with. "All" I'd have to do is convert the YAML to Ode's title and Indexette date format, rewrite the image links to conform to whatever I have going on my Ode site and then convert the file suffixes from .html or .markdown to .txt.

I think I can do that.

Update: Getting the images from a WordPress blog with wget is easy. Stack Overflow has it: How do I use Wget to download all Images into a single Folder

There is enough info there to get them into a single folder, or into a directory/folder structure that could make it easier to call the images into your non-WP blog. I did both as a test:

wget -nd -r 2 -A jpg,jpeg,png,gif -e robots=off http://your-blog-here.com

wget -r -l 2 -A jpg,jpeg,png,gif -e robots=off http://your-blog-here.com