10 ms·

CMS Trap

252 points by hakunin 13y ago

Breefield 13y ago
@rudyrigot and the team @prismicio http://prismic.io http://prismic.io really have a handle on this problem. They believe a github-esq content management system makes the most sense for content creators, and a content API makes most sense for engineers to distribute that content inside of a variety of platforms (mobile, a rails app, whatever). Saw Rudy speak at Zendesk/Rails meetup this month, it was a very good presentation (I am not affiliated with Prismic). I've been playing with their ruby-kit, so far so good, really liking this approach and plan to see awesome things ahead.
- icedog 13y ago
  The article is stating that developers should lean towards going static versus using any content management system. Would you like to provide a meaningful comment about how Prismic voids this author's argument?
  - Breefield 13y ago
    [edit] Apparently we may both be on the wrong page: https://twitter.com/hakunin/status/405874291100901376 https://twitter.com/hakunin/status/405874291100901376 Prismic allows you to "go static" for very little dev cost. Your content creators get a nice editor and can publish their content as needed, effectively making it static for you (the dev), as though it went through a build script (Jekyll or something "static"). The CMS gets out of your way, and you get to concentrate on making your app work, not getting into the complexities of building/maintaining a custom CMS. I mean, that's what the assertion that static is the way to go eludes to, unless I am incorrect about the entire point of the article. It's about not getting dragged into the bog of making a CMS. The author outlines various scenarios: do it yourself, to building your complex app on a CMS (ugh), or just going back to static because it is the simplest, hardest to fuck up option. I don't think he explored the idea of content management as a service fully, which is why I brought up Prismic—it is another option, and in my opinion, a very good one.
    - hakunin 13y ago
      I should've made it clearer, sorry. When referring to CMS in the article, I refer to the wider meaning of a content management system, the code that you write as a developer of your own site, which happens to manage your content. Not a CMS that one could download and install.
      - sdoering 13y ago
        Funny thing. I understood your analogy just great. I just remembered all the situations, where we as a company were/are trapped with the CMS we've got. So it worked for me as a editor gone code-writer as well as a editor gone conceptual project-lead.
SolarUpNote 13y ago
I think the key question is: At what point is building a user interface more expensive than hiring a full time developer?
- dreamfactory 13y ago
  or buying a product
bct 13y ago
Back in the old days (2005) we used to call this Do the Simplest Thing That Could Possibly Work.
- jsdalton 13y ago
  Or another way of looking at it: "You Ain't Gonna Need It" (http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)
- deleted 13y ago
  [deleted]
- gizzlon 13y ago
  Or KISS: Keep it simple, stupid http://en.wikipedia.org/wiki/KISS_principle http://en.wikipedia.org/wiki/KISS_principle
deleted 13y ago
[deleted]
kenster07 13y ago
Love of complexity is a programming disease.
- AsymetricCom 13y ago
  Complexity can signify a complex problem on a simple domain, or a simple problem in a complex domain. You simplify one place, you're just pushing the complexity somewhere else.
  - platz 13y ago
    That's why there's a distinction between 'accidental' complexity (poor architecture) and 'intrinsic' complexity (unavoidable)
  - jacques_chester 13y ago
    I optimistically called this Chester's First Law of Complexity: Essential complexity in the problem domain is a conserved quantity. The idea being that someone, somewhere, always has to pay the piper for any given architecture. It might be paid at write time, or at read time. By the server or by the client. By the programmer or the sysadmin. By the compiler guy or the programmer. By the code that defines the data structure or the code that relies on the data structure. But somebody always pays the toll. Then I found out that Larry Wall had beaten me to it with the pithier much pithier "Waterbed Theory". Kolmogorov partly so with the somewhat less pithy Kolmogorov Complexity.
danso 13y ago
Wow. This should be a must-read for developers, especially ones working in the content field. I've made a few complex apps that use Google Spreadsheets as the backend...that is, to hold the public facing data and not, obviously, any proprietary data. This makes it very easy for those who have to maintain the app to enter in data. The downside is, of course, the inability to strongly enforce business rules and to denormalize things...but that forces me to reduce the data design to a bare minimum, which is often the best strategy in the first place. I hope I never have to be in a situation where I'm building a CMS-type system for a client. People who haven't dealt with data-modeling or relational-databases don't appreciate simplicity...in the end, most people want something that they can type a headline, some text, and attach a photo or two (i.e. a Tumblr). But if you give them reins to design the system, they will inevitably want you to build them something Drupal like. In my experience, I've found that all these different content-relations end up being unused, and the client ends up hacking around them just to get a simple post up.
Domenic_S 13y ago
Just because you use a CMS doesn't mean you have to use it for everything. If you're managing content (blog content?) use a CMS. If you're making PPC pages, host them statically somewhere. If you sell something, use ecommerce software for that part. The right tool for the right job.
- patio11 13y ago
  If you're making PPC pages, host them statically somewhere. I'd counter recommend this. In my limited experience with it, dynamic PPC landing pages are so effective as to be almost cheating. BCC's AdWords campaigns are not doing well in 2013 for what I believe are unrelated (and mysterious) reasons, but the ~20 lines of Rails code which make URL #1 and URL #2 roughly the same today but will automatically switch URL #1 to a different creative in a few days have been worth, guesstimating a number here, somewhere north of $20,000. (Bingo cards are a very seasonal market. For the last couple of weeks, most teachers have been in the market for Thanksgiving bingo cards. This will not be true in a few days. The #1 URL, which I use for many of my campaigns, uses some really dead simple heuristics to guess which creative to show people. The heuristic was worth > 10% lift in conversions versus alternatives like "Pick our most popular activity ever", "Pick an activity at random", and "Pick Patrick's guess at what would convert best." http://www.bingocardcreator.com/lp/try_online http://www.bingocardcreator.com/lp/try_online http://www.bingocardcreator.com/lpc/thanksgiving http://www.bingocardcreator.com/lpc/thanksgiving <-- There are actually about ~900 landing pages like this, which is a trick that few people manage if they do them in static HTML.
  - rfergie 13y ago
    Perhaps it would make more sense to say "you don't have to use the same CMS for everything"
  - ams6110 13y ago
    I didn't read the OP as advocating 900 static HTML pages... just using static pages as a first strategy, until reality, not your conjecture, tells you what you need.
  - 13y ago
maxk42 13y ago
I am SO sick of spending more time configuring the CMS than writing code. Oftentimes, I could've built a product from scratch in the time it takes me to Google the undocumented quirks of some stupid YAML file.
- ams6110 13y ago
  But the piece was not about using CMSs where code would be more appropriate. It was about turning your bespoke application into something like a CMS by architecting for maximum flexibility and configurability everywhere, building complex "admin" interfaces, and implementing data-driven runtime behavior before any of that is really necessary. You can do all of these things with 100% test coverage, but that doesn't relieve you from dealing with the weight of the architecture and extra work when you try to add or change functionality later.
- at-fates-hands 13y ago
  Agreed. I've almost given up on using a CMS. Developing on the Drupal platform (as mentioned by the author) was really painful. I've only found a few CMS' that get the heck out of my way and just let me write code. This days if I have a static site around 10 pages, I just use .Net MVC project and use partial views to store the content. Much easier than using a CMS and I still retain all the control I want.
- Pxtl 13y ago
  > Oftentimes, I could've built a product from scratch in the time it takes me to Google the undocumented quirks of some stupid YAML file. Replace YAML with XML and you've just described every enterprise software library I've ever used ever.
paulftw 13y ago
Overengineered software systems are like sex - every generation thinks they invented it.
na85 13y ago
>A CMS Trap is a state of a web-application in which the development of content management systems is obstructing the development of the content. I think this pretty neatly summarizes my experience working with Drupal.
foz 13y ago
From an architecture point of view, I'm convinced that the CMS is better treated as a service, and not as part of your web application. This is especially true in a larger organization where content needs to be collected and managed in different ways (via import, or where people edit or curate content). At the start of this year, the company I work at had about six different CMS platforms. Many of the applications that used them were built on top of CMSs, and were tightly coupled to them. As for static content generators, we tried that. It really didn't scale, especially for dynamic content. Too many hacks, deploys, and hard to train people. As of today, our team has switched nearly all public content for our company to LocomotiveCMS (http://www.locomotivecms.com/ http://www.locomotivecms.com/), and deployed a centralized multi-tenant system. In many cases, we use our Locomotive instances as an API, pushing content via the API or the command-line tool, wagon. The CMS then renders HTML templates (or even JSON), which are consumed by our applications via HTTP. Sometimes it's just a tiny part of a page, or sometimes entire mini-sites. As a result, most of our apps don't need to know about a database. Whenever there's a change that requires a new model, or the addition of a field, it can be done quickly through the LCMS back-office UI (or the wagon CLI tool). We update the application(s) affected, and re-deploy. Non-techies can edit the content using the admin web UI in a familiar way. In any case, it's been working really well for us. The CMS has become an API, a service, and a separate app, shared by many applications. We've become more flexible and efficient as a result, our web applications are no longer burdened by CMS frameworks or admin interfaces of their own. And we dont have to struggle with Sharepoint or Wordpress or any other nonsense. It's been a fundamental shift in how we think about the CMS, and has scaled well across multiple projects.
- cseelus 13y ago
  I had LocomotiveCMS on my radar for quite a while as it looked very promising, but lost track as development staggered for a year or so. Do you use their hosted solution or do you host it on your own servers? Do you have any information if the version on Github[1] differs in significant ways from the hosted solution? It seems like they are really pushing the hosted solution now, their website doesn't make it very clear that you can install it by yourself too. [1] https://github.com/locomotivecms/engine https://github.com/locomotivecms/engine
vinceguidry 13y ago
I wrote an app for my company to extract data from the database and form xml feeds for various e-commerce services. I took the opportunity to learn OO principles and read through Object Oriented Design in Ruby. What I eventually came up with was pretty much exactly what this post is advocating for. YAGNI was the rule, I was new and wanted to demonstrate results quickly. Instead of classes, I put constants in modules, realizing that all that a class I'd written was holding was basically a hash, and since that data wasn't changing anytime soon, they might as well go in a constant. I caught the refactoring bug sometime around when I was tasked with adding a third service. I found turning the logic I'd created into proper classes incredibly easy, make changes, run rspec, rinse, repeat. The interfaces between the various pieces were surprisingly loose. So I could play around with different implementations of a piece of logic and at every point have something that could be made to work if I suddenly had to shift gears. I had two services and they were each slightly different. Waiting to build the abstractions until I had multiple implementations of them wound up being a big win. Now that I have a third, I can already tell that it's going to be an easy add. I spend much more time figuring out service-specific stuff than wrangling with my code. Hard-coding really does get a bad rap. You're not building a castle, you're fixing a pressing business need. If you do it well, then one day you'll be able to open-source your work, because your company will want to add more and more to it because of how badass it is. Not because your delusions of grandeur led you to over-abstract everything to the point of uselessness.
prottmann 13y ago
You're talking out of my soul! I see this behavior many many times in the last 10 Years, i admit, i do the same long time ago ;-) The problem for the mass of developers is, that they "fall in love" with their CMS and that make them blind for obvious things. We shift away from CMS as central point for web and web-application. CMS is only a tool to maintain simple static data in various languages for many people. For everything else (like shops) we use other systems, that are NOT a integrated part of a CMS. If interaction between CMS and ohter systems is needed, implement a separate and clean API.
Udo 13y ago
This is basically the same phenomenon that happens with frameworks. At first, the framework gives you a ton of functionality for the (initially) low price of living with its abstractions. As you want more custom functionality, you find yourself either fighting the framework with increasing levels of desperation, or simply coding around it. I'd argue that the best frameworks are such that you can code around them without causing huge overhead or resorting to objectionable tricks. The same goes for CMSes. Many CMS customers would probably be better off if they took the CMS editor interface as a separate component and wrote the actual page renderer as a custom development separately. The trouble is of course, content systems make it very hard to do that. Having to make things work with the native mechanisms (and the often horrific underlying data model) is what makes huge CMS projects fail or at least perform miserably for everyone involved. On the very top of the list of abhorrently convolute CMSes would probably have to be Typo3, followed after some distance by Drupal. But the more you work with the initially-liberal Wordpress the more you discover it's not that far behind either. This reminds me of a bygone era: my startup (now long gone) had its own CMS. Sadly, that wasn't our actual product as we were a pure service company and the CMS was only a tool for us. In hindsight, we should have done it the other way around. Our CMS wasn't perfect, but it shone in a few areas that made the life of both developers and content editors very easy: a simple, accessible data model and an easily extensible page renderer. Unlike many other solutions it was designed to get things done, not to bill a lot of consultant hours. I've yet to come across an open source (or commercial for that matter) CMS that works equally well.
- brazzy 13y ago
  The article is NOT about building systems on top of a regular CMS. It's about starting to build a specialized system and ending up building a generic CMS because of an urge to make everything runtime-configurable.
  - Udo 13y ago
    From the article: "It’s the passion that makes us lose sight of the danger looming ahead, the trap we’re edging towards thanks to our subjective assumptions and vague speculation, the trap of building a overdesigned and overcomplicated system for its own sake. A CMS trap" and, to address your objection: "When you are asked to build an app with something like Drupal, you are in a whole different realm, where the CMS trap is pretty much your perpetual state of being." As I said I would broaden the discussion even further. Over-design and over-complication is very much the hallmark of pretty much any CMS I have come across. The system becomes the biggest hinderance in respect to the realization of content and functionality. This IS pretty much what the article is about. It deals at length with unsuitable customization decisions.
lifeisstillgood 13y ago
I am going to look so silly : - all content served as json through a REST interface - all content created in best way possible and reduced to either static json or Dbase backed templates - content has metadata to keep it indexed
mavhc 13y ago
ie. Don't write a programming language when you're supposed to be writing an application.
ThinkBeat 13y ago
If there is a reasonable need for content editors to be able to update content in web site allowing them to do so in a quick and easy manner is a good idea. Seeing this as easy, and building a custom application to handle it, will quickly become a bad idea, and an artifact of "not build by me, I can build better" mentality. Being able to leverage a tool that is both proven and easily available to solve this problem makes sense. Expecting the cms to solve every problem and be the only tool used is also a big problem. As to whether to provide the users with a means to define new pricing models and change current models, depends on how frequently it needs to get done, how much dev resources are needed to keep up with demand, and what the release process is like. If you are in an enterprisy place. First an issue must be created to update the pricing model or create a new one. This probably goes under change control, and it will be addressed in the next meeting of the governance committee. If all is approved there it will be passed on to the project manager who will create a backlog item for it. Then once the current sprint is completed, a new prioritized list of tasks are distributed and in the best scenario the issue is handed off to a developer with a high priority. The developer will analyze what changes are needed, design the new pricing model, implement it, create and run unit tests, ensure it goes through CI. Then he will write the test cases for the new functionality and move on to the next issue in the back loc. In 2-4 weeks when the sprint is over the worst case is that the dev branch is promoted and the test team is assigned an issue to test and regression test everything. Once their sprint is done, it will be promoted to Staging and more tests and sign offs and then after a month or two the new pricing model will hit the shelfs and the executive who requested it might already have forgotten why it was an issue to begin with, or the client he created it for has long gone with a different company All of that to say sometimes it makes very good sense to create a decent way for the end users to be allowed to modify and create new pricing models. Just like its easier to allow the end users to edit the content of web pages. It would in my opinion be absurd to create an ecommerce system where the pricing and products require code to be updated. Much better to leverage an existing product or worse case write the logic to allow the users to make changes on their own.
- hakunin 13y ago
  I agree, what you are describing sounds like what I pointed out about bigger companies in the article. They not only can afford this, but they pursue this intentionally. > It would in my opinion be absurd to create an ecommerce system where the pricing and products require code to be updated. Much better to leverage an existing product or worse case write the logic to allow the users to make changes on their own. This I disagree with. An e-commerce system that deals with limited number of products (like a printing shop) could easily start with hardcoded base prices, it will be months of growth and rare pricing tweaks in code before this starts becoming an issue (based on my own experience).
nevvvermind 13y ago
Oh, c'mon. I was currently doing the exact same thing the blog post advices against. I was designing, centralizing, decoupling. Then some changes came about. I implemented them, then watched them fluently rippling throughout the system. "How cool is that?". It was some time ago when I was an OOP-design junkie (I think it's analogous to puberty: exaggerating). I think I passed that, as I frequently wonder if I'm over-designing and get back to using plain strings, constants etc. I once read that, designing a plugin (be it a pattern or an actual plugin), try no less than 3 different implementations. He's right, though. I work with Magento. Try adding a new backend form in that beast.
fiatjaf 13y ago
Ok. Here's an idea: Imagine a code editor (probably embedded in some online where the developers would also work/code) that would show all the application code. For developers, everything would be editable, so they could change logic, add logic, database calls, anything. On the other hand, for content editors, only strings (and arrays and numbers) would be editable. So the whole page would be freezed except for the parts between quotes. The developer could then hard-code these possibly-editable-values at code time (or leave them blank) and the non-developers edit them: categories, text content, values.
- fiatjaf 13y ago
  Hmm, there's those cases in which, to make use of database data, the code has to run into loops, checking and getting data from fields in which it was stored. This can be a problem, as developers using this metodology I'm describing would have to organize their code to handle static values just as if the values were being fetched from a database, but this problem must have a solution. I'll think about it.

252 points by hakunin 13y ago

@rudyrigot and the team @prismicio http://prismic.io http://prismic.io really have a handle on this problem. They believe a github-esq content management system makes the most sense for content creators, and a content API makes most sense for engineers to distribute that content inside of a variety of platforms (mobile, a rails app, whatever). Saw Rudy speak at Zendesk/Rails meetup this month, it was a very good presentation (I am not affiliated with Prismic). I've been playing with their ruby-kit, so far so good, really liking this approach and plan to see awesome things ahead.

icedog 13y ago
The article is stating that developers should lean towards going static versus using any content management system. Would you like to provide a meaningful comment about how Prismic voids this author's argument?
- Breefield 13y ago
  [edit] Apparently we may both be on the wrong page: https://twitter.com/hakunin/status/405874291100901376 https://twitter.com/hakunin/status/405874291100901376 Prismic allows you to "go static" for very little dev cost. Your content creators get a nice editor and can publish their content as needed, effectively making it static for you (the dev), as though it went through a build script (Jekyll or something "static"). The CMS gets out of your way, and you get to concentrate on making your app work, not getting into the complexities of building/maintaining a custom CMS. I mean, that's what the assertion that static is the way to go eludes to, unless I am incorrect about the entire point of the article. It's about not getting dragged into the bog of making a CMS. The author outlines various scenarios: do it yourself, to building your complex app on a CMS (ugh), or just going back to static because it is the simplest, hardest to fuck up option. I don't think he explored the idea of content management as a service fully, which is why I brought up Prismic—it is another option, and in my opinion, a very good one.
  - hakunin 13y ago
    I should've made it clearer, sorry. When referring to CMS in the article, I refer to the wider meaning of a content management system, the code that you write as a developer of your own site, which happens to manage your content. Not a CMS that one could download and install.
    - sdoering 13y ago
      Funny thing. I understood your analogy just great. I just remembered all the situations, where we as a company were/are trapped with the CMS we've got. So it worked for me as a editor gone code-writer as well as a editor gone conceptual project-lead.

SolarUpNote 13y ago

I think the key question is: At what point is building a user interface more expensive than hiring a full time developer?

dreamfactory 13y ago
or buying a product

bct 13y ago

Back in the old days (2005) we used to call this Do the Simplest Thing That Could Possibly Work.

jsdalton 13y ago
Or another way of looking at it: "You Ain't Gonna Need It" (http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)
deleted 13y ago
[deleted]
gizzlon 13y ago
Or KISS: Keep it simple, stupid http://en.wikipedia.org/wiki/KISS_principle http://en.wikipedia.org/wiki/KISS_principle

deleted 13y ago

[deleted]

kenster07 13y ago

Love of complexity is a programming disease.

AsymetricCom 13y ago
Complexity can signify a complex problem on a simple domain, or a simple problem in a complex domain. You simplify one place, you're just pushing the complexity somewhere else.
- platz 13y ago
  That's why there's a distinction between 'accidental' complexity (poor architecture) and 'intrinsic' complexity (unavoidable)
- jacques_chester 13y ago
  I optimistically called this Chester's First Law of Complexity: Essential complexity in the problem domain is a conserved quantity. The idea being that someone, somewhere, always has to pay the piper for any given architecture. It might be paid at write time, or at read time. By the server or by the client. By the programmer or the sysadmin. By the compiler guy or the programmer. By the code that defines the data structure or the code that relies on the data structure. But somebody always pays the toll. Then I found out that Larry Wall had beaten me to it with the pithier much pithier "Waterbed Theory". Kolmogorov partly so with the somewhat less pithy Kolmogorov Complexity.

danso 13y ago

Wow. This should be a must-read for developers, especially ones working in the content field. I've made a few complex apps that use Google Spreadsheets as the backend...that is, to hold the public facing data and not, obviously, any proprietary data. This makes it very easy for those who have to maintain the app to enter in data. The downside is, of course, the inability to strongly enforce business rules and to denormalize things...but that forces me to reduce the data design to a bare minimum, which is often the best strategy in the first place. I hope I never have to be in a situation where I'm building a CMS-type system for a client. People who haven't dealt with data-modeling or relational-databases don't appreciate simplicity...in the end, most people want something that they can type a headline, some text, and attach a photo or two (i.e. a Tumblr). But if you give them reins to design the system, they will inevitably want you to build them something Drupal like. In my experience, I've found that all these different content-relations end up being unused, and the client ends up hacking around them just to get a simple post up.

Domenic_S 13y ago

Just because you use a CMS doesn't mean you have to use it for everything. If you're managing content (blog content?) use a CMS. If you're making PPC pages, host them statically somewhere. If you sell something, use ecommerce software for that part. The right tool for the right job.

patio11 13y ago
If you're making PPC pages, host them statically somewhere. I'd counter recommend this. In my limited experience with it, dynamic PPC landing pages are so effective as to be almost cheating. BCC's AdWords campaigns are not doing well in 2013 for what I believe are unrelated (and mysterious) reasons, but the ~20 lines of Rails code which make URL #1 and URL #2 roughly the same today but will automatically switch URL #1 to a different creative in a few days have been worth, guesstimating a number here, somewhere north of $20,000. (Bingo cards are a very seasonal market. For the last couple of weeks, most teachers have been in the market for Thanksgiving bingo cards. This will not be true in a few days. The #1 URL, which I use for many of my campaigns, uses some really dead simple heuristics to guess which creative to show people. The heuristic was worth > 10% lift in conversions versus alternatives like "Pick our most popular activity ever", "Pick an activity at random", and "Pick Patrick's guess at what would convert best." http://www.bingocardcreator.com/lp/try_online http://www.bingocardcreator.com/lp/try_online http://www.bingocardcreator.com/lpc/thanksgiving http://www.bingocardcreator.com/lpc/thanksgiving <-- There are actually about ~900 landing pages like this, which is a trick that few people manage if they do them in static HTML.
- rfergie 13y ago
  Perhaps it would make more sense to say "you don't have to use the same CMS for everything"
- ams6110 13y ago
  I didn't read the OP as advocating 900 static HTML pages... just using static pages as a first strategy, until reality, not your conjecture, tells you what you need.
- 13y ago

maxk42 13y ago

I am SO sick of spending more time configuring the CMS than writing code. Oftentimes, I could've built a product from scratch in the time it takes me to Google the undocumented quirks of some stupid YAML file.

ams6110 13y ago
But the piece was not about using CMSs where code would be more appropriate. It was about turning your bespoke application into something like a CMS by architecting for maximum flexibility and configurability everywhere, building complex "admin" interfaces, and implementing data-driven runtime behavior before any of that is really necessary. You can do all of these things with 100% test coverage, but that doesn't relieve you from dealing with the weight of the architecture and extra work when you try to add or change functionality later.
at-fates-hands 13y ago
Agreed. I've almost given up on using a CMS. Developing on the Drupal platform (as mentioned by the author) was really painful. I've only found a few CMS' that get the heck out of my way and just let me write code. This days if I have a static site around 10 pages, I just use .Net MVC project and use partial views to store the content. Much easier than using a CMS and I still retain all the control I want.
Pxtl 13y ago
> Oftentimes, I could've built a product from scratch in the time it takes me to Google the undocumented quirks of some stupid YAML file. Replace YAML with XML and you've just described every enterprise software library I've ever used ever.

paulftw 13y ago

Overengineered software systems are like sex - every generation thinks they invented it.

na85 13y ago

>A CMS Trap is a state of a web-application in which the development of content management systems is obstructing the development of the content. I think this pretty neatly summarizes my experience working with Drupal.

foz 13y ago

From an architecture point of view, I'm convinced that the CMS is better treated as a service, and not as part of your web application. This is especially true in a larger organization where content needs to be collected and managed in different ways (via import, or where people edit or curate content). At the start of this year, the company I work at had about six different CMS platforms. Many of the applications that used them were built on top of CMSs, and were tightly coupled to them. As for static content generators, we tried that. It really didn't scale, especially for dynamic content. Too many hacks, deploys, and hard to train people. As of today, our team has switched nearly all public content for our company to LocomotiveCMS (http://www.locomotivecms.com/ http://www.locomotivecms.com/), and deployed a centralized multi-tenant system. In many cases, we use our Locomotive instances as an API, pushing content via the API or the command-line tool, wagon. The CMS then renders HTML templates (or even JSON), which are consumed by our applications via HTTP. Sometimes it's just a tiny part of a page, or sometimes entire mini-sites. As a result, most of our apps don't need to know about a database. Whenever there's a change that requires a new model, or the addition of a field, it can be done quickly through the LCMS back-office UI (or the wagon CLI tool). We update the application(s) affected, and re-deploy. Non-techies can edit the content using the admin web UI in a familiar way. In any case, it's been working really well for us. The CMS has become an API, a service, and a separate app, shared by many applications. We've become more flexible and efficient as a result, our web applications are no longer burdened by CMS frameworks or admin interfaces of their own. And we dont have to struggle with Sharepoint or Wordpress or any other nonsense. It's been a fundamental shift in how we think about the CMS, and has scaled well across multiple projects.

cseelus 13y ago
I had LocomotiveCMS on my radar for quite a while as it looked very promising, but lost track as development staggered for a year or so. Do you use their hosted solution or do you host it on your own servers? Do you have any information if the version on Github[1] differs in significant ways from the hosted solution? It seems like they are really pushing the hosted solution now, their website doesn't make it very clear that you can install it by yourself too. [1] https://github.com/locomotivecms/engine https://github.com/locomotivecms/engine

vinceguidry 13y ago

I wrote an app for my company to extract data from the database and form xml feeds for various e-commerce services. I took the opportunity to learn OO principles and read through Object Oriented Design in Ruby. What I eventually came up with was pretty much exactly what this post is advocating for. YAGNI was the rule, I was new and wanted to demonstrate results quickly. Instead of classes, I put constants in modules, realizing that all that a class I'd written was holding was basically a hash, and since that data wasn't changing anytime soon, they might as well go in a constant. I caught the refactoring bug sometime around when I was tasked with adding a third service. I found turning the logic I'd created into proper classes incredibly easy, make changes, run rspec, rinse, repeat. The interfaces between the various pieces were surprisingly loose. So I could play around with different implementations of a piece of logic and at every point have something that could be made to work if I suddenly had to shift gears. I had two services and they were each slightly different. Waiting to build the abstractions until I had multiple implementations of them wound up being a big win. Now that I have a third, I can already tell that it's going to be an easy add. I spend much more time figuring out service-specific stuff than wrangling with my code. Hard-coding really does get a bad rap. You're not building a castle, you're fixing a pressing business need. If you do it well, then one day you'll be able to open-source your work, because your company will want to add more and more to it because of how badass it is. Not because your delusions of grandeur led you to over-abstract everything to the point of uselessness.

prottmann 13y ago

You're talking out of my soul! I see this behavior many many times in the last 10 Years, i admit, i do the same long time ago ;-) The problem for the mass of developers is, that they "fall in love" with their CMS and that make them blind for obvious things. We shift away from CMS as central point for web and web-application. CMS is only a tool to maintain simple static data in various languages for many people. For everything else (like shops) we use other systems, that are NOT a integrated part of a CMS. If interaction between CMS and ohter systems is needed, implement a separate and clean API.

Udo 13y ago

This is basically the same phenomenon that happens with frameworks. At first, the framework gives you a ton of functionality for the (initially) low price of living with its abstractions. As you want more custom functionality, you find yourself either fighting the framework with increasing levels of desperation, or simply coding around it. I'd argue that the best frameworks are such that you can code around them without causing huge overhead or resorting to objectionable tricks. The same goes for CMSes. Many CMS customers would probably be better off if they took the CMS editor interface as a separate component and wrote the actual page renderer as a custom development separately. The trouble is of course, content systems make it very hard to do that. Having to make things work with the native mechanisms (and the often horrific underlying data model) is what makes huge CMS projects fail or at least perform miserably for everyone involved. On the very top of the list of abhorrently convolute CMSes would probably have to be Typo3, followed after some distance by Drupal. But the more you work with the initially-liberal Wordpress the more you discover it's not that far behind either. This reminds me of a bygone era: my startup (now long gone) had its own CMS. Sadly, that wasn't our actual product as we were a pure service company and the CMS was only a tool for us. In hindsight, we should have done it the other way around. Our CMS wasn't perfect, but it shone in a few areas that made the life of both developers and content editors very easy: a simple, accessible data model and an easily extensible page renderer. Unlike many other solutions it was designed to get things done, not to bill a lot of consultant hours. I've yet to come across an open source (or commercial for that matter) CMS that works equally well.

brazzy 13y ago
The article is NOT about building systems on top of a regular CMS. It's about starting to build a specialized system and ending up building a generic CMS because of an urge to make everything runtime-configurable.
- Udo 13y ago
  From the article: "It’s the passion that makes us lose sight of the danger looming ahead, the trap we’re edging towards thanks to our subjective assumptions and vague speculation, the trap of building a overdesigned and overcomplicated system for its own sake. A CMS trap" and, to address your objection: "When you are asked to build an app with something like Drupal, you are in a whole different realm, where the CMS trap is pretty much your perpetual state of being." As I said I would broaden the discussion even further. Over-design and over-complication is very much the hallmark of pretty much any CMS I have come across. The system becomes the biggest hinderance in respect to the realization of content and functionality. This IS pretty much what the article is about. It deals at length with unsuitable customization decisions.

lifeisstillgood 13y ago

I am going to look so silly : - all content served as json through a REST interface - all content created in best way possible and reduced to either static json or Dbase backed templates - content has metadata to keep it indexed

mavhc 13y ago

ie. Don't write a programming language when you're supposed to be writing an application.

ThinkBeat 13y ago

If there is a reasonable need for content editors to be able to update content in web site allowing them to do so in a quick and easy manner is a good idea. Seeing this as easy, and building a custom application to handle it, will quickly become a bad idea, and an artifact of "not build by me, I can build better" mentality. Being able to leverage a tool that is both proven and easily available to solve this problem makes sense. Expecting the cms to solve every problem and be the only tool used is also a big problem. As to whether to provide the users with a means to define new pricing models and change current models, depends on how frequently it needs to get done, how much dev resources are needed to keep up with demand, and what the release process is like. If you are in an enterprisy place. First an issue must be created to update the pricing model or create a new one. This probably goes under change control, and it will be addressed in the next meeting of the governance committee. If all is approved there it will be passed on to the project manager who will create a backlog item for it. Then once the current sprint is completed, a new prioritized list of tasks are distributed and in the best scenario the issue is handed off to a developer with a high priority. The developer will analyze what changes are needed, design the new pricing model, implement it, create and run unit tests, ensure it goes through CI. Then he will write the test cases for the new functionality and move on to the next issue in the back loc. In 2-4 weeks when the sprint is over the worst case is that the dev branch is promoted and the test team is assigned an issue to test and regression test everything. Once their sprint is done, it will be promoted to Staging and more tests and sign offs and then after a month or two the new pricing model will hit the shelfs and the executive who requested it might already have forgotten why it was an issue to begin with, or the client he created it for has long gone with a different company All of that to say sometimes it makes very good sense to create a decent way for the end users to be allowed to modify and create new pricing models. Just like its easier to allow the end users to edit the content of web pages. It would in my opinion be absurd to create an ecommerce system where the pricing and products require code to be updated. Much better to leverage an existing product or worse case write the logic to allow the users to make changes on their own.

hakunin 13y ago
I agree, what you are describing sounds like what I pointed out about bigger companies in the article. They not only can afford this, but they pursue this intentionally. > It would in my opinion be absurd to create an ecommerce system where the pricing and products require code to be updated. Much better to leverage an existing product or worse case write the logic to allow the users to make changes on their own. This I disagree with. An e-commerce system that deals with limited number of products (like a printing shop) could easily start with hardcoded base prices, it will be months of growth and rare pricing tweaks in code before this starts becoming an issue (based on my own experience).

nevvvermind 13y ago

Oh, c'mon. I was currently doing the exact same thing the blog post advices against. I was designing, centralizing, decoupling. Then some changes came about. I implemented them, then watched them fluently rippling throughout the system. "How cool is that?". It was some time ago when I was an OOP-design junkie (I think it's analogous to puberty: exaggerating). I think I passed that, as I frequently wonder if I'm over-designing and get back to using plain strings, constants etc. I once read that, designing a plugin (be it a pattern or an actual plugin), try no less than 3 different implementations. He's right, though. I work with Magento. Try adding a new backend form in that beast.

fiatjaf 13y ago

Ok. Here's an idea: Imagine a code editor (probably embedded in some online where the developers would also work/code) that would show all the application code. For developers, everything would be editable, so they could change logic, add logic, database calls, anything. On the other hand, for content editors, only strings (and arrays and numbers) would be editable. So the whole page would be freezed except for the parts between quotes. The developer could then hard-code these possibly-editable-values at code time (or leave them blank) and the non-developers edit them: categories, text content, values.

fiatjaf 13y ago
Hmm, there's those cases in which, to make use of database data, the code has to run into loops, checking and getting data from fields in which it was stored. This can be a problem, as developers using this metodology I'm describing would have to organize their code to handle static values just as if the values were being fetched from a database, but this problem must have a solution. I'll think about it.