One of the things I miss about my previous non-static blog was that it would automatically display the time of the last update. Since I store my site documents in a way that preserves file modified dates and timestamps across the replication I started to poke around how Octopress handles the concept of updates to existing posts. A little bit of digging revealed that including “updated:
With a little digging, it was obvious that neither of those keys were being generated in the original Jekyll source or by Octopress plugins (in the plugin directory). A little bit of Google foo, however revealed the octopress-date-format gem and exposed how octopress was creating those pieces of data. The gem that was being loaded for me was in the 2.x branch as I am running Octopress 2.x (This was a major pain point for me as I was pulling my hair out trying to resolve why the modules I was looking for didn’t exist or were different. It turned out that Octopress 3 is in development and I was looking at the source of the plugin for that. Oops! Doh!). This Octopress date-time plugin works by attaching to the init hooks for pages and posts and dynamically generating the the html content for both the original date and updated fields.
Because the plugin works by attaching to the init hooks and I could find no way to guarantee an order to what is called by the hooks, I had to scrap the plan to also attach to init and simply populate the field if it didn’t exist. Instead I went the route of creating a generator that retroactively visits all the posts, evaluates them for an existing updated field. If the updated field doesn’t exist it then evaluates the modified time on the source file and uses that as the updated value. Now, becuase all of the init hooks have already run, we need to finally trigger an update so that the octopress-date-time plugin does it’s magic (Otherwise nothing will get displayed, because the ‘date_time_updated_html’ field won’t exist). Instead of looking into how to trigger a specific hook, I simply looked into the source code for the date-time plugin and made the ‘hack_date’ call against the post to update those fields. The major negative for approaching updated values this way is that the evaluation for populating the fields produced by the date-time plugin will be run twice on every post that doesn’t have an updated field already in the YAML front matter.
Below is the UpdatedGenerator.rb source code that automatically adds an updated date to all my posts dynamically.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
If you use storage that maintains the modified time stamps on your source files, this will also work for you. (Hint! Git repositories do not maintain the modifed file timestamps and using this with them will cause indeterminite behavior.)