Another flat-file driven blog/ cms engine on the block

This post was written 1 year ago.
Sat, 24 Nov 2012
I've just been looking at Statamic, which is a markdown-driven CMS and blog, self-hosted and written in PHP. It's commercial rather than open-source, but at a reasonable price, like Perch. It looks reasonably mature and has support for add-ons and lots of cool stuff. I'll probably buy a copy just to mess around with.

If I ever need to build another PHP CMS-driven site, i'll certainly give this a go, as i'm still obsessed with the idea of having content as flat files under source control. I like the idea that you could set up a staging site using something like this, and the client/ project manager could be adding content, and you can periodically log into the server, commit the content to GIT and sync you local dev copy in both directions.

Also, with the end result still being a dynamic PHP site (unlike the static sites compiled by the likes of Jekyll), you can still develop dynamic features into the resulting site and integrate in other PHP modules, e.g. forums and shopping carts etc.

As for what this means for my own PHP text-file driven blog eatStatic, it re-confirms that I shouldn't be putting any effort into building any CMS features in, and to concentrate only on maintaining as a blog engine for my own stuff, and only adding the features I need. I haven't had a look at the blog functionality provided by Stamatic yet, but having built eatStatic to fit my own ideal travel blog workflow, it would probably need some work to make me happy!

I've also mentioned a Python port of eatStatic in the past, and would still like to do something in this area, but I can't help but think i'd be better off concentrating on a module to plug into another blog engine / CMS, to avoid reinventing the wheel yet again. Before I do anything else I want to experiment with all the current static-site generators - to see if there is some way to build on this - e.g. a python app that takes content set up for a Jekyll site and syncs it with content in a mezzanine (or other Django-based CMS).

A quick google around for "python static site generator" has thrown up this: http://ringce.com/hyde
Tags: eatStatic / blogging / CMS / WCM /

Sub-optimal web content workflow used by many agencies

This post was written 1 year ago.
Fri, 09 Nov 2012
I've worked at a fair few agencies in my time, and despite most agencies now using content management systems as standard, the content population and revision workflow is usually sub-optimal:-

  1. Designer inputs the content into a photoshop file
  2. PNG or PDF of the document is signed off by the client, or amends requested, which the designer deals with
  3. Developer copies the content into the CMS (they may need to create some custom content-types or templates to make this work)
  4. If the content needs to change - the designer is asked to change the photoshop document, and back to step 2
  5. At no point will the client touch the CMS, or entertain the idea of a few days training in basic HTML or markdown*

Yes, I think we can all see a flaw with this workflow - no need to point out how things could be done differently in the comments!

* I don't care if your CMS has a really good WYSIWYG editor - it's either too limited or too powerful, so an untrained editor at best will never really get the result that they want, at worst do some real damage!
Tags: cms / wcm / workflow /

More text file based CMS and Blog tools

This post was written 2 years ago.
Fri, 13 Jan 2012
If you were interested in my eatStatic text file-based blog engine, but thought it was a bit techie/immature to consider using yourself, you may be interested in Kirkby and Scriptogr.am.
Tags: blogging / cms /

Site building workflow challenges - keeping HTML in a database

This post was written 3 years ago.
Wed, 07 Sep 2011
I was reminded to today of one of my pet hates - coordinating a site build, or a site rebuild when the CMS you are using keeps content, often containing HTML markup from use of an editor such as tiny mce, in the database.

Consider the following scenario:-

  • You have a staging site where the client has been using the CMS to input content
  • Meanwhile, you make some changes to the database on your local version and want to push them to staging
  • You can use a migration script to push your changes to the live database but you find yourself wanting to also copy the new content back to your local database, so you can work on CSS on real content. You then would probably drop your local database and restore from a backup from staging, losing any test content you put in locally

It's basically a bit of a kerfuffle.

This is one of the scenarios that I hope could be avoided with a CMS based on eatStatic (if I ever develop it beyond a blog engine) - any content-types that contain bodies of text, whether thay are marked up with HTML or not, would be stored on the filesystem. This could be put under version control, so you can selectively synchronise your content with another instance of the site.

I can also see a case for some add-on for any existing CMS - an export function that routinely pushes text content from the db into text files to be kept under version control, and also allows import, allowing instances to selectively sync content.
Tags: eatStatic / sitebuilding / CMS /

What I did and didn't do in 2010 and Plans for 2011

This post was written 3 years ago.
Sun, 02 Jan 2011
It would be rubbish to stop a tradition after only two years, so following on from my posts in 2009 and 2010, here is a retrospective for 2010 and my plans for 2011. I'm changing the format this time, by dividing into "achieved", "carried over", "ditched" and "new".

Achieved
  • Attend at least one web conference - I had an extremely busy year, so didn't get to any of the generic web conferences, but couldn't turn down the international Plone conference, as it was happening in my own city. Although it was specific to a particular open source web content management system, the talks contained enough generic web technology goodness to keep me geeked up to overflowing.
  • Get further than "hello world" with Django - Having collaborated on a django project, i've got further than this now, and i'm also using it for some tools used for managing data and assets for Kudos/ Lightplanet
  • Use and understand some technologies that i've been ignoring - I'm going to claim that as achieved, on the basis of the points above - i've learned plenty about Django, and python in general. This bullet point will always be carried over though, as there is always something new to learn.
  • More on-site freelancing for agencies - It's always tricky finding a balance with this - I did a fair amount of on-site work, but it often got tricky trying to balance my ongoing client work, with the requirement to be on-site somewhere. I'm still open to this, but the other project work needs to take priority, and as such i've started renting a desk in a shared office again.
  • Keep Trading and survive the recession - No shortage of work again, so thanks to everyone who gave me work, but i'll keep my fingers crossed and carry this one over again..
Carried Over
  • Launch a web app - so close on this one, but the manic run up to xmas and self-enforced work-free xmas holidays stopped me releasing my pet project, working title: Eat Static CMS. The name, some may have guessed is a tribute to a 90's techno outfit, but also refers to the fact that the app uses text files rather than a database. It's a basic blogging engine with niche appeal, I will make it available as a beta ASAP this year, as soon as i've tidied it up.
  • Relaunch Too Old To Skate - The site is still in limbo, and still reflects how little i've skated again, which once again I intend to change
  • Attend at least one BarCamp - the Bathcamp BarCamp clashed with Plone conference this year, so I didn't go, but want to get to more grass-roots events this year.
  • Better Customer Service (By saying "No" sometimes) - I wanted to put this on the achieved list, but looking back I took on too much again towards the end of the year, and customer service suffered as a result, so once again i'll try to find the balance in 2011
Ditched
  • Get to grips with Plone 3 skinning - Plone has moved on and so have I, but this doesn't mean i've given up on Plone, but I don't plan to do any Plone 3 work. Plone 4 skinning/ theming is still on my list, but that's a whole new technology, and a technology that can be used independently of Plone.
  • Put up a proper portfolio - I just can't imagine having the time to do this - I think potential clients can find out whether I have the skills and experience they need by looking at this blog and my linked in profile. As i'm more of a programmer than a designer, a visual portfolio is less important to me. Maybe if I run out of work i'll rethink this one?
  • Fix on a PHP framework - until someone (me?) builds a PHP framework that is basically identical to Django, with it's production-ready admin forms and API as standard, i'll just use whatever seems right at the time, or no framework at all.
New
  • Buy a new Bass Guitar and play the hell out of it - I horrified some of my older friends by selling my one remaining bass last year. I sold it as I had completely stopped playing, and having it hanging on the wall just seemed a waste. Most people i've befriended in the last 10 years don't know I ever played. Playing bass in bands used to be an important part of my life - I've actually been playing bass for over 20 years and was once pretty good (if I say so myself!). I sense a mid-life crisis coming on in the next couple of years, so I need to get back in practice for when I inevitably decide to form another band!
  • More "work from anywhere" adventures - I spent 6 weeks touring in Europe with my wife and son this summer, working from my laptop to earn money as I went. It was brilliant, so hopefully more of these adventures, the same or different in 2011
  • More blogging! - including some personal blogging. I think i'll need to divide this site into "babble" and "techobabble" - not everyone who reads this site looking for a CSS hack will want to read my self-indulgent drivel and not everyone who reads the site wanting to know how I really feel about the experimental bass playing style of jaco pastorious wants to read about the new python module i've started using, so i'll provide the opportunity to follow from both a techie and non-techie viewpoint, although it will all still be one blog. Looking back through the archives of this blog, i've been doing this over the years anyway, going through phases of techie and non-techie content.

archived comments
What about skating the s**t out of Kennington and drinking beers in London with your mate a bit more...?

Henry Sanchez 2011-02-01 17:50:52

Problems your content management system will not solve and how to overcome them

This post was written 5 years ago.
Sun, 01 Nov 2009
Really informative and interesting article about CMS use over at Boagworld. (Hugely trivialised) summary: Content Management Systems don't kill websites - people do.
This post was written 5 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)
Tags: cms /

CMS strategies

This post was written 5 years ago.
Sat, 19 Sep 2009
When it comes to Content Management Systems (CMS's), i've been "round the block a few times" so to speak, having spent the last ten years mostly working on CMS driven sites - starting with bespoke classic asp/ MS Access (shudder) back in 1999, before moving onto bespoke php/mysql systems, wordpress, drupal, zope/plone and dabbling in countless others. My conclusion: there is no holy grail, because the people developing and maintaining the code and content vary, and there are other important factors. Therefore I always take time to decide on the best approach for each project.
It is rare that I get a "greenfield" project where I am free to start from scratch. Without getting right down to weighing up the pros and cons of individual systems, here are some of the factors that help me (and my clients) make a decision:-
  • Will I be starting from scratch or building on something else?
  • Am I working alone, or with one or more other developers?
  • Does the client have a preferred technology i.e. if they already have an intranet written in a particular technology, it makes sense to use the same for their website. (Unless of course they hate their other systems - it might be a good bargaining point to go a different direction altogether!)
  • What's the content like? - is there a large amount of text content, categories and pages or is it "snippets" of text that need to be editable, amongst otherwise highly graphical content?
Commercial Content Management Systems I'm not going to talk about the "big" commercial CMS's - the only people they are useful to are the people who's job it is to go and buy a CMS license, companies who own or sell the software and companies who have made the investment to become specialists in such systems. That counts me out, and as i've never heard a developer, designer or content manager singing the praises of such a system (entirely the opposite), i'm going to presume they are all overpriced rubbish, and talk about what I know! I know that sounds flippant, but I refuse to believe that any of the vendors of the expensive, closed commercial systems have solved problems that a community of thousands of people working on competing open source systems haven't. Also money saved on an expensive license can be spent on support, maintenance and customisation of a system with no license costs. Which brings me onto...

Off-the-Shelf open source CMS's One obvious route is to use one of the mature, all singing and dancing systems like Plone (zope/python) or Drupal (php/mysql). They are easy to install and have a comprehensive feature list, but usually one other thing in common - voodoo. By voodoo I mean a whole load of essential code deep down in the architecture that your average web developer (counting myself here) isn't supposed to touch, and can spend hours/ days working out how to hook into it to make seemingly simple changes. For someone who becomes an expert in the system, they have full access to the code, so become familiar with the hooks and this isn't a problem. For the charity/ company/ organisation where the development budget has run dry, it can be tricky finding anyone (available) who can work on it. If the content maintainer likes the admin interface these can work out really well, if they don't it can be a ton of reverse engineering to make it "work" for the content manager.

Bespoke CMS's On the other extreme you have a bespoke CMS written from scratch giving the developer fine grained control over everything they need to do, and easily picked up by another developer, provided that it is sensibly written. However, as developers usually have their own way of doing things, it may take another developer time to learn how the system works before they can make changes, or they may want to re-write it altogether! The downside of any bespoke system is that it can take months to build features that you get for free in an off the shelf system. I often build a bespoke CMS where I need to bolt new functionality onto an existing system, where there isn't enough budget to start from scratch.

Bespoke CMS built on a framework In between are bespoke systems built on a framework (such as Cake PHP, Ruby on Rails, Django), so much of the repetitive coding work (such as user management and admin forms) is handled for you, but it's still a bespoke system. The downside of these is that you need a developer who already knows, or is willing to take the time to learn the framework. The upside is that new functionality can be added quickly and in a consistent manner by someone familiar with the framework.

"In-House" CMS
By which I mean a bespoke CMS which isn't written from scratch each time, but a mature "tried and tested" bespoke CMS built and maintained by an agency or developer, then reusued or repurposed for each new project. The advantage of this is that the developer/ agency have a high level of familiarity with the system, so are able to make fine-grained changes as required, that they may not be able to make with other systems. The disadvantage is that these can be the trickiest systems to be picked up by another agency or developer, and their may be IP issues (see below)

Intellectual Property / licensing I've already said that i'm not going to talk about the commercial CMS's, but one consideration when choosing which way to go, particularly with a bespoke CMS, is what happens if you were to move to another developer or agency? Will the source code and database files for your CMS be handed over along with the website or are you going to have to license it /buy it/ start again? Also what would happen if you wanted to sell the website and CMS on at a later date?

Standalone vs Retrofitting This refers to the last of my bullet points above - not all websites are the same. Some (like news or university websites) are text-content heavy, with hundreds or maybe thousands of pages and categories, and some websites have highly designed (as in graphic design) content.

In the latter scenario it is often better to build the site as static HTML first and retrofit a simple CMS later. The bulk of the work in building such a site will be in getting it looking and behaving correctly, and their may need to be lots of fine tuning to the layout, which is easier if you aren't reverse engineering a theming system. Moreover, the text content may be confined to small snippets of text, or a simple news blog, which can easily be plumbed in later.

The former scenario would suit an off-the-shelf system that works standalone - i.e. one that allows content editors to start populating content before the templates are finished, which are then applied as a skin/theme later - it may even be the case that the site can't really be designed properly until the architecture and content are in place.

archived comments
Great post Rick, and it really rings true with me. Certainly the bit about taking ages to do a simple change.

I'm sure if you invest a lot of time with a framework/CMS system then it will pay dividends however, my concern is that, if the only tool you've got is a hammer then everything looks like a nail...if you catch my drift!

Joel

Joel Hughes 2009-09-19 18:43:28
This post was written 5 years ago, which in internet time is really, really old. This means that what is written above, and the links contained within, may now be obsolete, inaccurate or wildly out of context, so please bear that in mind :)