I think this is somewhere that highly adapted mini-frameworks could take hold.. something like Padrino for Sinatra, yet slightly more publishing friendly.
The CMS Is Broken.
41–50 of 57 posts
Re: The CMS Is Broken.
#42Earlier quoted context omitted.
I don't know about Drupal - I would tend to agree it's a little too cumbersome to the point where I would rather write something with a good framework like Django. But WordPress is really nice, aside from PHP, and my once-off design-a-simple-website projects that use it would be a lot simpler if there were something similar that had a better language. PHP does add a significant amount of gymnastics that make plugin d…
The problem you see with these applications is that they are bad PHP, not that they are PHP. If you would, go take a peek at the Symfony2 framework. It's positively brilliant code, and it's PHP--Fabian Potencier and friends are excellent programmers, and they write excellent code in PHP.
I'm currently in the process of building a migration path from our two different older PHP frameworks (MidCOM and Midgard MVC) to Symfony2, and I've really been impressed by the community.
They seem to be very receptive to new ideas, and passionate about code review. I've received lots of GitHub comments on my bundles even though the commenters probably would never actually use them.
And when I found an issue in Symfony2 itself that made integration with AppServer-in-PHP harder, Fabien fixed it within the hour of getting reported.
Re: The CMS Is Broken.
#43I find this interesting because TPM's solutions reminds me of the classic UNIX "pipes and filters" strategy - a series of small components with well-defined inputs and outputs that can be strung together to produce a sophisticated result. (Of course, "small", "well-defined", and "sophisticated" could be relative terms.) The pipes and filters "API" was plain text transmitted through stdout. It also strikes me as an ex…
I think the natural next step of "UNIX pipes and filters" is Flow-Based Programming (http://en.wikipedia.org/wiki/Flow-based_programming). Processes can have multiple named input and output ports, and data flowing between them can be objects and other data formats.
In currently building an Open Source FBP tool called "NoFlo" on top of Node.js, and at least the initial results of building websites with it are promising.
Re: The CMS Is Broken.
#44Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API: http://www.gethifi.com/blog/first-we-built-an-api-then-we-bu... That said, I didn't buy everything he said. We've built a farily agnostic API, very much like he described. That said, it's not Mongo, it's not MySQL and it's not CouchDB. It's impossible to build something that is 100% free from constraint…
For the content management API, have you looked at Content Repositories? There are pretty good specs for standard content management APIs for Java (JCR), PHP (PHPCR) and Node.js (NoCR).
The REST API alternative, CMIS, is unfortunately a bunch of committee-designed mess.
Re: The CMS Is Broken.
#45I like the feature-as-app paradigm, but the article says nothing about the underlying API. I have used a CMS the last couple of years at work, where documents are stored as JSON files on the server using WebDAV protocol, which off course is totally REST based. Access control is done using the PROPPATCH verb. The CMS is named Vortex, developed at the University of Oslo and has an open sourced license. Too mee this API seems to function better than the usual custom made REST based API.
Re: The CMS Is Broken.
#46Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API: http://www.gethifi.com/blog/first-we-built-an-api-then-we-bu... That said, I didn't buy everything he said. We've built a farily agnostic API, very much like he described. That said, it's not Mongo, it's not MySQL and it's not CouchDB. It's impossible to build something that is 100% free from constraint…
The simplest way to design an API, is to use an existing one. I work with a CMS where JSON documents are posted using the WebDAV protocol. Settings for documents and folders are all set with the PROPPATCH verb. The WebDAV protocol has defined API's for ACL, versioning and namespace management like delete, move, copy.
Info about Vortex CMS (in Norwegian): http://www.uio.no/tjenester/it/web/vortex/
Re: The CMS Is Broken.
#47Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API: http://www.gethifi.com/blog/first-we-built-an-api-then-we-bu... That said, I didn't buy everything he said. We've built a farily agnostic API, very much like he described. That said, it's not Mongo, it's not MySQL and it's not CouchDB. It's impossible to build something that is 100% free from constraint…
The simplest way to design an API, is to use an existing one. I work with a CMS where JSON documents are posted using the WebDAV protocol. Settings for documents and folders are all set with the PROPPATCH verb. The WebDAV protocol has defined API's for ACL, versioning and namespace management like delete, move, copy. Info about Vortex CMS (in Norwegian): http://www.uio.no/tjenester/it/web/vortex/
Sounds very good. Would the DAV (REST) APIs be accessible for something like https://github.com/bergie/VIE ?
Re: The CMS Is Broken.
#48"Drupal, Wordpress and Joomla use PHP. — the plugin model aches at scale: popular plugins become abandoned plugins, energies move elsewhere. Plugin A works great, plugin B too. However, they weren’t designed to know about each other, thus leading you down a rabbit hole of forking and mending. A few years of use later, you are left with an unmaintainable tangle of ad hoc code written by an all-but-unknown cast of prog…
I'm not sure the problem is necessarily Drupal, but I tend to agree with the post's authors that a Drupal written in something other than PHP would be a nice thing to have. Specifically Python would be really nice.
I tried to address the issues of the PHP CMS space here: http://bergie.iki.fi/blog/my_secret_agenda_for_php_content_m...
Re: The CMS Is Broken.
#49Earlier quoted context omitted.
The simplest way to design an API, is to use an existing one. I work with a CMS where JSON documents are posted using the WebDAV protocol. Settings for documents and folders are all set with the PROPPATCH verb. The WebDAV protocol has defined API's for ACL, versioning and namespace management like delete, move, copy. Info about Vortex CMS (in Norwegian): http://www.uio.no/tjenester/it/web/vortex/
Sounds very good. Would the DAV (REST) APIs be accessible for something like https://github.com/bergie/VIE ?
Yes it probably would. The API is also accessible from client side javascript. So you could create admin pages in 100% javascript like in HiFi.
Re: The CMS Is Broken.
#50Earlier quoted context omitted.
Sounds very good. Would the DAV (REST) APIs be accessible for something like https://github.com/bergie/VIE ?
Yes it probably would. The API is also accessible from client side javascript. So you could create admin pages in 100% javascript like in HiFi.
Admin pages are one thing, but with VIE you can make content also editable right where it is. See for example what we did with Midgard:
http://bergie.iki.fi/blog/introducing_the_midgard_create_use...