Possible to extend Middleman this way?

#1

I absolutley fell in love with MM over the last months using it in several projects.
After spending some time with it, I was wondering if Middleman could be extended with two features that would build up on one another and what you guys think about it.

First, I’d like to generate pages in Middleman from a database - a hierarchical representation of pages, each page record in the database would carry a “parent page” field, creating the hierarchical relationship that way. Every page would also optionally own configuration data that every rendered page would be given as local data and the is overridable with every subpage. This would allow for information usually given via YAML Front Matter, like the layout be overridden for branches of the pagetree.

Second, there is a missing link for my customers unable to write Markdown and using Git to enter content into MM pages. It would be interesting to have a frontend to MM, making it easy to add content to pages in a database like described above.

Is there such a project already? Does it make sense?
And if so - what could a proper solution look like from a technical perspective, e.g. Rack middleware and all. (I’m no Ruby pro yet, still trying to really understand proper ruby solution from an architectural point of view)

Cheers & thanks to everyone having contributed to this great software,
Thomas

Dynamic Stateless Sites Using Semantic Web Annotations?
#3

Oops, accidentally hit delete on that last post. Let’s try that again:

It is indeed possible to generate pages from Middleman using a database, although I would question the appropriateness of using Middleman to do so. A Middleman extension could provide a database connection and provide pages using the resource_page_manipulator.

Personally, I’d go with Rails to implement something like this. It just really doesn’t seem a good fit for Middleman.

For the editor, I faced a similar problem a while back. I ended up writing a layer of Rack middleware that provided a simple editing interface with a file browser and form fields for specific pieces of YAML frontmatter. I used Ace for the editing area itself.

The editor ran in a separate editing environment that ran the editor and the Middleman preview server through Unicorn. All changes were recorded on a separate editing branch, that could be merged back in to the project as needed. I just wrote a couple of Capistrano tasks to sync when needed.

There’s a great GitHub-, Markdown-, and YAML-friendly editor called Prose.io which just authenticates with your GitHub account and lets you browse the files in Git and edit them. It even has a separate area for editing the YAML and Markdown parts of your template.

Hope that helps some. Best of luck!

#4

Thank you for your suggestions.
The editors look nice, especailly prose.io, will keep it in mind.

On the Rails thing: I definitely wanted to still generate static pages to deploy them to a server without scripting support or an S3 bucket. You would do that with Rails still?
I found no good CMS solution that does that, which I find rather odd. I remember back in 90’s most of the big brand CMS did it this way and some (Adobe CQ) still do. Wordpress, Drupal, Locomotive, most of those OS CMS propably have some static publishing plugin, but they look all rather buggy and not well maintained.
I’m looking for a customer friendly frontend and static publishing engine on the backend. Was hoping Middleman could be extended that way, since with development / publishing it is already there (with all the little goodies, live reload, various integrations). Just the database/gui part is missing.

I’ll keep looking around, getting the impression I’d have to quite a lot of plumbing to get there.
But thanks again for your input!

#5

On the Rails thing: I definitely wanted to still generate static pages to deploy them to a server without scripting support or an S3 bucket. You would do that with Rails still?

Well, based on what it seems you’d like to achieve, I wouldn’t bother with static site generation at all. The design doesn’t really fit that way of thinking. If it’s speed you’re after, just cache all your Rails pages. Rails will generate them when the request comes in, store the response as a static file, and serve the static file from then on. You’d get exactly the same performance. If you want the CDN, too, just set up a CloudFront distribution to talk to your Rails app.

#6

It’s not only about speed, also about security and maintenance by separating the editing frontend from the production system. An S3 bucket is not as likely to be hacked as e.g. a Wordpress Installation. And when a serious Wordpress/Drupal/Rails bug comes up, I could just power down the editing frontend and the site could still be up, completely separate from any dynamic scripting functionality.
I also find setups with Varnish and Cache invalidation for complex site hierarchies rather irritating, whereas with Middleman, a file is a file, period. Peace of mind and all that. Static file generation can become a bit addictive after years of dynamic CMS troubles, traffic spikes, hosting outages.

1 Like