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.
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.
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.
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.
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.
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:
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
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
I've been having trouble with my Ode Counter add-in.
I have been using
File::Find to gather filesystem information and make it available to Ode, and I learned two things.
1) The Ode add-in framework allows the passing of scalar variable data from add-in to non-post areas of the site, but it doesn't allow passing of arrays. This is easy enough to work around. You just convert the array to a scalar. There is more than one way to do this, but I chose this one:
directory_list = join('', @directory_list_array);
2) Producing acceptable HTML out of the add-in is one thing, but for it to transfer properly to the Ode site, all the usual characters must be "escaped" on the server side:
<li><a href="/blog/programming/perl/">Programming > Perl</a></li>
It must be:
<li><a href=\"\/blog\/programming\/perl\/\">Programming > Perl<\/a><\/li>
Once I fix my regex, I'll be in business.
I've been working on and off on the next version of the Counter addin for Ode sites.
The last update added counts of photos in the blog's filesystem to the original counts of entries with breakouts for traditional blog entries and social updates (basically counting everything in the whole
documents directory and the
updates directory, then using a little math.
I used the
File::Find CPAN module as the backbone of the addin.
The next thing I wanted to do, also using
File::Find, was to crawl the blog's filesystem and generate a categories list that can be displayed on the site.
So I've been playing with
File::Find, Perl regular expressions and arrays.
I am able to generate an array made up of every directory that contains Ode posts, and I'm working on the regex to make the HTML and display text look exactly the way I want.
At this point I have a pretty good looking array, and I'm ready to move the
Categories code (which I'm developing in a local directory with a "dummy" filesystem) into the main
Counter addin code.
There are still some issues to work out, but as soon as I get the next version of the Counter addin ready, I will make it available for download and also hopefully have it on Github.
I've been meaning to get back into the Counter addin that I wrote for Ode with Rob's help, and over the past few days I added some functionality to the code and deployed it on my site, where you can see the results in the right rail.
The original Counter addin only counted posts, which in my case are files in the
documents directory with
Since I now create many of my social-media updates with Ode, I added some code to count those entries and report how many of the overall entries are "full" posts and how many are social updates.
While I was in there, I wanted to play around with regular expressions, so I also added a count for the number of
png images both in the entire
documents directory (which includes themes) as well as in my
images directory (where I try to keep all images that go into posts).
It's definitely fun to write a very little bit of Perl and have something happen on my live site. It's a nice feeling, for sure.
The addin uses the
File::Find CPAN module to crawl your filesystem and count the files.
The way the Counter addin works is that you download it (for now I'm hosting it here) and unzip it, stash the addin's directory/folder in your addins directory (mine is under
/data/addins), add some HTML with calls to the addin to your theme (generally in the sidebar area), and it should just work.
Once again, thanks to Rob Reed for creating Ode and helping me get off the ground with this addin.
If you missed the link above, download the new Counter addin from my site.
I still have some code cleanup to do, and I will probably add some documentation, licensing information and acknowledgments. But this version does work.
In the future, I can see this addin, or something like it, creating even more dynamic (or even static) content for the sidebar of an Ode site. It could help build a list of directories and certainly could provide more statistics on how many posts you have under any given directory.
But for now I can instantly see how many posts and social updates I have written (and you can, too).
I'm noticing this issue when using Ode's EditEdit in Fedora 23. It looks like the line spacing in the CSS for the "composing" windows is screwed up. See the screen grab above (click for full-sized image).
You can see that the top line in the "Title" windows is cut off on top, and the lines are a little cramped in the "Body."
I need to check this in Firefox to make sure it's not some kind of overall Fedora 23 issue (I just upgraded my OS from Fedora 22), and I'm sure I can adjust the CSS for EditEdit to make this problem go away.
Update: It looks fine in Firefox:
Update: This has something to do with the
Courier font. Rather than go crazy about it, I'm just going to knock it out of the EditEdit CSS.
Can you see this word?
Here it is with backticks:
Here it is on a line with backticks:
Can you see the ?
It begins as a dollar sign:
Here it is as a code block set off by a tab/indent:
And here it is at the beginning of a line with backticks:
I imagine this is a potential problem because of the way Ode passes data from the script to the HTML.
My question: Is there a way to "escape" the
$ so it appears on the live Ode site without resorting to backticks?
It seems that I can get a single
$ but not a
See the markup: Here is this file as plain text.
I just removed the social-sharing buttons for Google Plus and Twitter from this site.
Even though almost every http request for content on this Ode-powered blog is done via Perl CGI on shared hosting, the site is extremely quick.
And these two social-sharing buttons, which appear on every entry, were really slowing things down. (Instead of a third-party social-button service, I used embed code provided by Google and Twitter, respectively).
The question/dilemma I face: Is the reduced "performance"/speed of the site a fair tradeoff for what the social buttons have to offer?