Mephisto

I recently received some code to translate certain non-ascii codes in your article titles into a more URL-friendly permalink. Though, at David Black’s suggestion, I decided to use Iconv instead. Seeing that I’m creating permalinks in several projects now, I’ve extracted this into a new rails plugin: permalink_fu.

Let me know how this works out. Hopefully iconv is available on your platform too. It’s my understanding that it’s in the ruby standard library, and included with the Ruby One-Click Installer for Windows users.

I just committed a change to Mephisto that makes Image Science the new default thumbnailer, instead of RMagick. What is Image Science?

ImageScience is a clean and happy Ruby library that generates thumbnails—and kicks the living crap out of RMagick. Oh, and it doesn’t leak memory like a sieve. :)

All I used RMagick for was thumbnailing. It seemed to wreak havoc with your memory, especially on shared hosts, so I commonly recommended disabling RMagick. In a few local tests, I watched the memory jump up to about 90MB from uploading < 1MB of images with RMagick. Yikes. ImageScience tears through them without much of a blip in memory usage.

Course, since no ruby host has ImageScience and FreeImage installed probably, you probably won’t see any benefits. Don’t worry, it should drop back to RMagick if it’s not installed, and should skip thumbnailing altogether if RMagick isn’t installed. You can customize this in environment.rb now too: ASSET_IMAGE_PROCESSOR = :image_science || :rmagick || :none (Only add :image_science, :rmagick, or :none).

Let me know how it works out. Also, I’d try hitting up your hosts and seeing if they’re up for installing FreeImage and ImageScience. I hope so, this covers probably the majority of RMagick usage, which is widely known to cause problems on shared hosts.

Day 1 – I added a way to customize the routes, include controllers, and add tabs to the Admin interface.

Day 2 – I added a way to customize the Mephisto application classes from plugin modules.

This is very experimental stuff in Mephisto trunk. Check it out if you’re a rails developer.

I found this article on Soaked and Soaped on protecting against spam with Akismet. It’s a pretty standard introduction to David Czarnecki’s ruby Akismet lib (the same one that Mephisto’s Akismet lib is derived from). I noticed he mentioned using an author of ‘viagra-test-123’ to test that Akismet was working. And, it wasn’t on this site, so I investigated further.

Apparently, Akismet started requiring the blog parameter sometime after I first integrated this support. David’s lib didn’t have it, so apparently Jordan Arentsen had to modify his to work. I did the same, while refactoring Mephisto a bit. Now, the comment_check method checks for a value of ‘true’ to approve a comment, instead of checking for a return that isn’t ‘false’. Had I checked that correctly, the broken Akismet lib would have marked all comments unapproved.

So, Akismet support should be working now. As a little bonus, the Approve/Unapprove links in the Comment Moderation Admin will make calls to Akismet to mark a comment as spam or ham. If Akismet steps out, correct it real quick, and remove the missed spam if needed.

Though the blog is quiet, the SVN commit log isn’t. Here are a couple things we’ve been working on.

• Better comment validation and error messages [contributed by Geoff Davis]
• Working Metaweblog API [contributed by Corey Donohoe and Patrick Lenz]. It’s still experimental, but retrieving and saving posts works fine.
• Completely rewritten Dispatcher. This was the oldest bit of code in Mephisto, and it has been completely refactored away. Sections now have their own archive areas available at /section_path/archives/yyyy/mm. Permalinks can now have completely custom URLs without modifying the Rails routes.

Update: I completely forgot about the new Liquid include support that Geoff Davis added. Create a template named _foo.liquid in the design area (or themes/site-#{n}/templates), and use this to include it: {% include 'foo' %}.

It looks like Mephisto: Noh-Varr is shaping up to be a solid release.

• Use ActionController::AbstractRequest.relative_url_root for sites under a root path like /blog
• fix odd timezone bug when saving articles
• fix bug with <typo:code> macro
• bad feed urls raise ActiveRecord::RecordNotFound, and return 404 in production
• dont bomb out on comment events without an event body
• fix bug where you’re unable to delete an empty comment
• Ignore drafts and articles published in the future when searching.
• sanitize posted comments
• Fix bug where atom feed content from textile was double encoded
• sanitize atom feed content.

We (well Rick mostly) have been pretty busy getting Mephisto ready for 0.6. Our goal with 0.6 was to get basic asset management in and we've done that for the most part. There is much more to come in this area though.

Rick and I have talked about ways to integrate, rather, let you integrate, custom services such as Flickr, You Tube, etc, into the asset management area. These third party services wouldn't be going into the core, but we'd like to give you the opportunity to pimp your Mephisto with whatever bling you deem necessary if you so choose. I'll talk about this more later, but here is an overview of what we've managed to get done in preparation for the 0.6 release, probably due out early next week or so.

Asset Management

I've talked in detail about assets already. In addition to what's already been said, we've added tagging support. I've still got some house cleaning to do in this area, but it'll be complete before 0.6.

Article Tagging, Filtering, and Improvements

Articles got some basic tag love. You can now filter articles by section, tags, title, or body. We've also made some minor improvements to the paging links, printing out the page numbers instead of just 'Next Page' and 'Previous page'. You can also jump to an article on your site from the admin now.

Template Liberation

We didn't have this planned until 0.7, but Rick beefed up on milk and cookies and managed to get the templates completely moved to the file system instead of the half and half mix we have in 0.5. This is great because it means that you no longer have to upload every image file you use in your design/css. I'm probably gonna rework the UI here in the future because the sidebar has real potential to run away from you fairly quickly depending on how many assets you have.

Small fixes and improvements

In addition to some of the major upgrades I've listed, we've also fixed numerous bugs and made tiny improvements here and there.

• Liquid gets {{ ifchanged }}, {{article.excerpt}}, {{ unless }}, and {{ format_date: 'mdy' }} for month, day, and year.
• Filters have been improved
• Awesomeness increased by at least 30%.

Stay tuned for 0.6!

How? <macro:flickrshow set="1135391" />, using the FlickrShow macro, courtesy of the actual FlickrShow javascript generator. (more after the jump).

We've been hard at work implementing some of the remaining high-priority features in Mephisto. The most notable missing feature is Asset/File management. Well, we've started hammering away at getting this implemented the past couple of days and have the basics of it working, with that said, it's no where near finished.

Update: Major progress has been made in the trunk, check it out!

From the screenshot you can see we're gonna be sporting an OS X style search feature. Also, the last 5 or so images you upload will be shown on the new article page allowing you to quickly have access to these files.

When we were discussing how we wanted to implement assets, I didn't want to implement it like other systems have: Files are attached to articles. There really isn't any benefit of having a file belong to an article. If you want to use a file system wide, why shouldn't you be able too? Of course, other systems never prevented you from direct-linking these files (I suppose), but that defeats the purpose of attaching files to articles. Files belong to a site, they are merely used in articles or the design.

I would speculate the only reason files have always been attached to articles is because you can upload files directly from the same interface from which you create the article. I guess it only seemed right that the files belonged to that article. Not true--this is just the most natural process for publishers working with assets. You don't want to have to leave the article page to go to some separate assets area just to upload an image.

Although you can't see it in the screenshot above, we plan on also having an upload form on the new article page that allows you to do just this. But what if you like to prepare before you write? Lets say you would rather upload your assets from the separate assets area. It wouldn't be all that intuitive if you couldn't access those images you just uploaded from the interface which you write your article. Having the assets area open in one tab while having the article form open in the other tab is far from ideal. We're gonna solve this problem by showing the last few files you just uploaded on the new article interface so you can quickly access these images.

It can be assumed that if you just uploaded a few files, you plan on using them. But, what if you don't? What if you've uploaded a bunch of files, and the files you want to use in your new article are a month old? Well, we're gonna solve that problem too. We're also planning on implementing a search interface in the new articles area so you can quickly find the files you've lost long ago. I also have another really cool idea on how to handle these situations too that I'll talk about more once I get the details hammered out.

Your probably wondering with all this stuff going on the new/edit article interface, won't it be cluttered? Well, it sure sounds like it could be, but I've thought about this one myself and have come up with a fairly simple solution. Tabs. Simple, effective, and it works well.

With all that said, it should be noted that none of this is complete and the SVN trunk is under heavy development. You will run into bugs under Mephisto edge. It's only recommended you run edge if you're wanting to help bug hunt, you're really brave, or you don't mind the occasional hiccup.

If you didn’t notice, I had a major bug in paged sections where the URL would include the ruby object instead of the section’s url. Great job rick, way to use that unit testing! Anyhow, I ripped out that custom block that I never liked so I can just use the pages variable:

{% for page in pages %}
<p>{{ page | link_to_page }}</p>
{% endfor %}

I also made some major additions regarding site and asset stuff. Stay tuned.

I made a few small tweaks that I wanted to cover:

Listing sections

The original version of the default Hemingway theme used the old method of listing sections:

{% for section in sections.list %}

This has been changed to:

{% for section in site.sections %}

Also the template had no way of listing the article count. You can now use {{ section.articles_count }}.

Installing on Edge

Thanks to ‘anonymous’, we have some nice Installation docs. I added some extra notes regarding Capistrano deployments. You’ll notice though, that I mention that revision 4727 is required. The reason is that the new Rails autoloading class was committed. Things like the Reloadable module are now deprecated, and plugins are reloaded in dev mode. This is causing a few weird errors that need to get nailed down. Revision 4727 runs great, however.

Edge rake task

I’ve been using the ‘edge’ rake task to freeze Mephisto after deployment. However, I just realized there’s already an ‘edge’ rake task that rails uses. I’ve renamed it to deploy_edge so it doesn’t conflict.

I’m starting this section on the Mephisto site to talk about breaking changes as I develop. There are certain things (regarding the liquid templates especially) that are rapidly changing. The first big change is the loss of the sections variable.

Until now, you could use {% for section in sections.list %} to enumerate through the sections. I’ve started converting everything to LiquidDrops and decided to create a ‘site’ drop instead. Change the above to {% for section in site.sections %}. There are a few odd cases that I’ve added:

• {% for section in site.blog_sections %} lists only blog sections.
• {% for section in site.page_sections %} lists only paged sections.

(Each article is a liquid drop too and now has the same methods)

If you want to do something else like, list all but home sections, this is how we’re doing it now:

{% for section in site.sections %}
  {% if section.path != 'home' %}
    <li><a href="{{ section.url }}">{{ section.name }}</a></li>
  {% endif %}
{% endfor %}

I’m still experimenting and looking for the best option. Let me know if you have suggestions.

What is a Liquid Drop?

Here’s a quick Liquid Drop crash course. By default, it lets you set up variables used in the templates as hashes. When you do {{ article.title }}, it converts that to article[‘title’] basically. Sometimes though, you don’t want to preload everything. If selecting an article always selected the comments and sections every time, the site could get pretty slow.

So, here come Liquid Drops. They are basically a blank slate liquid variable. It can wrap around a liquid variable’s existing keys, and provide custom methods that load data. Something like {{ site.sections }} will now load all the sections the first time they’re accessed.

This gives us the possibility of performing some custom operations in the future, like {{ site.find_section('foo').articles }}. This also lets someone make a Flickr plugin, for instance, with: {% for image in flickr.recent_images %}. Wouldn’t that be cool?