Live data from Hacker News

CMS Trap

hakunin.com

61–65 of 65 posts

Re: CMS Trap

#61
post #46
post #38

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 th…

So you need to re-deploy for a simple typo fix?

No we normally never need to re-deploy the app for new content or edits. We treat Locomotive like a service: it provides us a customizable content API. So only in the case of breaking schema changes would we need to re-deploy.

Re: CMS Trap

#62
post #13

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.

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

Re: CMS Trap

#63
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.

Re: CMS Trap

#64
post #63

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 p…

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.

Re: CMS Trap

#65
post #48
post #46

Earlier quoted context omitted.

So you need to re-deploy for a simple typo fix?

hey @kiro, I'm Didier, creator of LocomotiveCMS (www.locomotivecms.com). You do not need to re-deploy for a simple typo because the structure of your site and the content are definitely separated. You or your content editor will use the user back-office to fix that typo. However, if you want to change the layout or tweak the style, you have to use Wagon and its frontend tools (SASS, Compass, Less, Compass), make your…

Thanks for the answer! I will give Locomotive a try next time I need to install a new CMS.
Post reply on HN