Today I started joking that I’ll submit a WordCamp talk proposal called “RAMP, the fun never ends!” and it will be mostly me sputtering incoherently in rage and gesturing obscenely. I am sure it’ll be a hit, even if no one wants to use RAMP anymore because XML-RPC is so 2010. Developers always enjoy watching other developers in an apoplectic rage.
Whenever I work with RAMP, I then spend several days thinking about ways to not use RAMP and do something else instead.
I toyed with the idea of dispensing with a content staging server altogether and using toggles to hide content not yet ready for development. I even turned to Twitter…
does anyone know of a way to do content staging on a live site, with the staged content hidden except from authors / admins?
— Lisa Linn Allen (@LisaLinnAllen) March 25, 2016
… and was warned away from that approach. I have to concede that tracking and hiding revisions of existing pages would be a nightmare.
Maybe we can dark launch some content
Today I started thinking, though, that it would be useful to separate out some different content deployment cases. Maybe part of the problem with RAMP is that it tries to do too many things, and maybe there are simply situations for which it is not well suited.
RAMP is best when operating on pages that don’t have a lot of dependencies on other pages (eg, links to other pages on the site, when the links are saved as Post ID’s that then have to be translated, or parent-child relationships). It’s best when operating on small numbers of pages. The more dependencies a page has, the smaller the batch has to be. Even when pages have no dependencies, there are limitations of batch size. Although our job description pages don’t have dependencies, I wasn’t able to RAMP all 300+ of them in one batch. I got up to about 30 in a batch before I was done with them.
When we started discussing work on our next big section of content – Benefits, which is huge – I found myself asking the client how small the sections could be. Would they be tolerant of launching very small sections at a time? I asked because I couldn’t see how we could spend an entire day RAMPing 500 Benefits pages over to live, with live in an unpredictable state for an entire day. That’s what happened with our initial launch and it was (sort of) okay because no links were yet pointing to the live site.
It’s a shame, though, to ask the business to accommodate what is basically a technical deficiency. They really ought to be able to determine the size of a content launch that makes sense from a user experience and business perspective. Wouldn’t it be nice if they could move over pages as they are completed, but hide them until everything is ready?
Okay, so maybe toggles aren’t a good idea for stuff that’s in flux or really granular – revisions to existing pages, one-off new pages, and content creation, especially when a review and approval process is needed. Staging sites are probably the best way for those things. But keeping large, finished sections ‘dark’ on the live site by simply not linking to them might be feasible.
In a blog post from 2010, Martin Fowler writes this about Feature Toggles:
Toggle tests should only appear at the minimum amount of toggle points to ensure the new feature is properly hidden. There could be many screens in the pet survey feature, but if there’s only one link on the home page that gets you there, then that’s the only element that needs to be protected with the toggle tag. Don’t try to protect every code path in the new feature code with a toggle, focus on just the entry points that would lead users there and toggle those entry points.
Hm. Maybe we could do something like that on a content section with clean enough edges.
In much that is written about feature toggles, warnings abound not to allow toggles to grow stale and become forgotten, so the case for a dark, ‘toggled’ content section would have to be clear and there would have to be tools to expose the toggles and make them easy to get rid of when no longer needed.
This is just stuff I thought about today while doing dishes and stuff, but I think it holds some promise. We’d still be using RAMP, but could avoid a repeat of the nightmare day of 500 RAMPs.