Rick Hurst Web Developer in Bristol, UK

Menu

Category: cms

My current tools and tech in 2019

Posted on by Rick Hurst

I try to avoid jumping on every new trend which comes along in the web world, especially over the last few years, where things seem to have moved very fast, with javascript frameworks becoming obsolete before i’ve even got round to trying them, but I also need to keep my skills and tech relevant. Here’s what i’m using as of late summer 2019.

Editor/IDE

I’ve been consistently using Sublime Text (Version 2 because I never got round to upgrading to 3) for years as my code editor, though i’ve never really taken full advantage of the extensions and customisations available. It just works and I saw no real need to change. One thing it has never done well is working over ssh, or rather from a mounted sshfs folder on a mac. I have occasional need to do this, when using the likes of nano in a terminal doesn’t feel good enough, and it’s one thing that I missed from Coda, when I used that for a while, years ago.

Then after spotting a tweet from an old colleague mentioning remote SSH editing in VS Code (via the Remote – SSH extension), I thought i’d take a look at it. Firstly, having used old-skool Microsoft Visual Studio in the past, I was surprised to see that Microsoft had built and released such a cool free editor, with builds for windows, mac and even linux. It’s already become my default editor – the intellisense and built-in terminal and git functionality is really good. There’s a lot there to explore and a ton of extensions. It also looks good.

Languages and frameworks

Most of my work is currently PHP. I no longer feel the need to apologise for that! PHP 7 is mature, stable and fast. I work on a couple of legacy PHP projects, one of which uses a combination of bespoke MVC code, an old fork of codeigniter (currently being refactored out) and Redbean ORM, and the other uses Zend framework, but is being re-built as a de-coupled app with Lumen (micro-framework by Laravel) on the back end and Vue.js on the front-end.

I haven’t done any web projects with Python recently (though i’m keen to try Pyramid), but I have been using it for a custom FTP server, using pyftpdlib (yes, FTP – for an old-skool EDI project – an old, but still very widely used technology where XML and FTP are used to exchange data – probably predating the invention of JSON and REST). I’ve also been using python for a raspberry pi datalogger project, reading serial data from microcontrollers via USB and then relaying it to a REST API.

JavaScript-wise, I still use bits and pieces of  jQuery to get stuff done while I learn Vue.js properly, which is happening as part of a current aforementioned web app rebuild. We settled on Vue.js instead of React because Vue seems to be a popular component in the Lumen/Laravel ecosystem.

For CSS, i’ve settled for now on SASS and Gulp. Sass is a keeper, i’m just using Gulp until I find something that I like better. I tend to use Susy for grid/layout.

Ansible is my go-to tool for devops – I use it to provision web servers and for formerly manual tasks such as migrations of websites, moving content between dev, live and staging on wordpress sites etc. For local development of any sort I almost always use Vagrant now, with an ansible provisioning script, which gives me a very portable set-up, provided I have enough RAM to keep multiple virtual machines running as I juggle projects.

During my last foray back into a day-job (back in 2016), working at an agency, I got a fair amount of experience using wordpress as a CMS, including for some fairly complex projects, relying heavily on the Advanced Custom Fields (ACF) plugin. Now, historically I haven’t always been a fan of WordPress, but it proved to be an excellent tool when used with ACF, making the creation of custom page types incredibly quick and easy compared to other Content Management Systems i’ve used, and even compared to using frameworks which would be my usual preference for custom content. Being able to create custom fields, included nested repeater fields via the WordPress admin, having the field definition saved to the filesystem and then versioned in GIT for seamless syncing to production is a game changer!

 

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

Posted on by Rick Hurst

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

Sub-optimal web content workflow used by many agencies

Posted on by Rick Hurst

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!

Site building workflow challenges – keeping HTML in a database

Posted on by Rick Hurst

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.

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

Posted on by Rick Hurst

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 kid 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

CMS strategies

Posted on by Rick Hurst

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