A CMS that uses MongoDb? WordPress
- SOLVED
This is really a PHP question, rather than a WordPress question.
I have a client who is thinking about how to maximize the flexibility of content handling, for a site that hopes to imitate some of the design freedom that print based magazines have. One problem with most CMSs is the fixed schema tends to lead to fixed templates that limit design freedom.
After some conversations, we focused in on 2 main strategies:
1.) Wordpress plus heavy use of custom fields, probably using the Pods framework for ease of flexibility
2.) Some CMS that breaks away from any schema and instead uses a schema that is deliberately ad-hoc. To this end, a schemaless database seems like the appropriate way to persist data. This lead us to examine MongoDb.
So I am curious, has anyone here worked with a CMS that uses MongoDb, and how much freedom of design is offered by that CMS?
Answers (5)
Francisco Javier Carazo Gil answers:
Lawrence,
I suggest to use something like it http://wordpress.org/plugins/supra-mongodb-manager/ to manage MongoDB collection from backend and do not use meta when you have a lot of features in one data type.
For example, you can include MongoDB in your theme/plugin and manage using WP API all which is light and use MongoDB (creating your own classes to do it).
Nowadays I think this is the best option. The problem is that you have to manage two differente DB.. but probably is the best option when you want to have at the same time: WP power and Mongo power to manage very big data.
Lawrence Krubner comments:
Francisco Javier Carazo Gil, that is an interesting option. supra-mongodb-manager does offer some flexibility. I am wary of relying on 2 databases, but I can see this as an option. Sadly, there seems to be no way to customize the forms that interact with MongoDb.
Francisco Javier Carazo Gil comments:
Lawrence, I know there is no way to customize the forms that interact with MongoDb (with that plugin really) but when you write your own plugins/theme you can change it.
Unfortunately, CMS like Calipso are harder to use and also there is no so many tools like there are in WordPress.
And yes, finally we have to code directly http://php.net/manual/es/class.mongodb.php but yes, I think that WordPress has a lot of "hashtables" inside him: wp_options, wp_user->wp_usermeta, wp_posts->wp_postmeta... and in a near future it can be done with MongoDB it would be great and really fast.
Lawrence Krubner comments:
Francisco Javier Carazo Gil, that is a very wise thing to say. WordPress has a lot of "hashtables" inside it. All of those are sort of a rebellion against the idea of SQL. Those hashtables are a rejection of the notion of a fixed schema. Almost any other database would be better for WordPress. Postrgre has arrays which formalize some of the usage that WordPress tries to stuff into "hashtables" inside of text fields. But MongoDb would be a better fit, since those "hastables" are really documents with an ad-hoc schema.
Francisco Javier Carazo Gil comments:
Lawrences, that's true, I never thought about it althoug I have used a lot of PostgreSQL.
Unfortunately, the "standard" is the one who order and MySQL is the selected.
It could be faster if we could assign PK->FK between those tables, but I don't know why WordPress core developers don't use it. It could be a first step.
Lawrence Krubner comments:
Francisco Javier Carazo Gil, about this:
"I don't know why WordPress core developers don't use it"
I feel that way about a lot of things related to WordPress. I am often surprised by where the core developers put their emphasis.
fuscata answers:
Lawrence,
I'd propose the reason there are few CMSes that use mongodb as a backend is web content is highly relational in nature.
Id suggest you read this article: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
I disagree with its title -- there are good use cases for mongodb -- but agree with its thesis: you should *probably* not use mongodb for highly relational data.
I have seen interesting arguments for a hybrid system to support high write throughput to something like mongodb on save, and later move to a relational database for retrieval and processing. That would be overkill for most applications of a CMS, I think.
-Chris
Lawrence Krubner comments:
Chris,
I enjoyed reading the article you linked to. But the project described there does sound highly relational: "Diaspora is a distributed social network". They might have been served well by a combination of a traditional SQL database and also a graph database such as Neo4J. Social networks are clearly in need of storing graph information.
They describe the problem like this:
<blockquote>With TV shows, each box in the relationship diagram is a different type. TV shows are different from seasons are different from episodes are different from reviews are different from cast members. None of them is even a sub-type of another type. But with social data, some of the boxes in the relationship diagram are the same type. In fact, all of these green boxes are the same type — they are all Diaspora users. A user has friends, and each friend may themselves be a user. Or, they may not, because it’s a distributed system. (That’s a whole layer of complexity that I’m just skipping for today.) In the same way, commenters and likers may also be users. This type duplication makes it way harder to denormalize an activity stream into a single document. That’s because in different places in your document, you may be referring to the same concept — in this case, the same user. The user who liked that post in your activity stream may also be the user who commented on a different post.</blockquote>
That is not the problem I face right now.
You have probably seen Wired magazine:
[[LINK href="http://www.ebay.com/bhp/wired-magazine"]]http://www.ebay.com/bhp/wired-magazine[[/LINK]]
The graphic design in that magazine is pretty wild. Every page has a different design. A designer is able to go crazy when designing for a print magazine. Web sites tend to be much more limiting: a website tends to have 5 or 10 or maybe 20 templates, and all the pages conform to one of those templates.
I have a client in New York who wants to do a website where the graphic design could be as free as with a magazine. After some discussion, we decided that one thing that tends to limit design on websites is that databases have a fixed schema. You might have a field like "title" and it always goes one particular place in the template. And you might have a field called "author" and it always goes one place in the template.
As an experiment, we wanted to try to get away from the fixed schema. One possibility is that an "article" in the website should be a document that itself contains multiple sub-documents, perhaps with embedded HTML and CSS making each sub-document unique. The code will probably involve different ways to deal with sub-documents. This should be data that denormalizes well, so I don't think we run into the problem that is described in the article that you point to.
We could start from the other way round: what if we invented a unique HTML page for every page on the site? Maybe the designer could work in DreamWeaver, or maybe in InDesign and then export to HTML. Then every page could have a unique design. From a design perspective, that is what we are aiming for. However, we want editors to be separate from the designers, and we want the editors to be able to update the text, while still leaving the designers as much freedom as possible. So that means bringing in some elements of a CMS.
I am open to suggestions about how to do this with a fixed a schema, but the freedom to jam documents together in MongoDb does suggest a way to also get a lot of design freedom.
Lawrence Krubner comments:
Chris, please also consider this line from the article that you link to:
<blockquote>Whether you’re duplicating critical data (ugh), or using references and doing joins in your application code (double ugh), when you have links between documents, you’ve outgrown MongoDB. When the MongoDB folks say “documents,” in many ways, they mean things you can print out on a piece of paper and hold. </blockquote>
I do think what my client wants is close to the type of article that you would print out.
Lawrence Krubner comments:
Chris, there is also the argument that "Joins are evil". I know Don MacAskill has made that argument for SmugMug. See his remarks down in the comments here:
[[LINK href="http://don.blogs.smugmug.com/2008/10/13/zfs-mysqlinnodb-compression-update/"]]http://don.blogs.smugmug.com/2008/10/13/zfs-mysqlinnodb-compression-update/[[/LINK]]
I assume they use highly denormalized data to avoid joins. Once you go that route, you might as well be using MongoDb.
fuscata comments:
Lawrence,
Not saying that your data will be highly relational, just that typical web content is, and that's likely why there are few/no mongodb-backed CMSes.
I disagree that "JOINs are evil" as a general rule.
-Chris
Lawrence Krubner comments:
Chris,
I think you might be right. Clearly, people are avoiding MongoDb as the backend to CMSs. I have done many Google searches over the last few days and I have found very little.
--- lawrence
Dylan Kuhn answers:
It's interesting to me that there's no obvious candidate. [[LINK href="http://mongopress.org"]]MongoPress[[/LINK]] piqued my curiosity when it appeared, but looks stalled. Node.js doesn't seem much further along with [[LINK href="http://calip.so/"]]Calipso[[/LINK]]. Not much help I know - but curious what others may offer and what you'll choose.
Lawrence Krubner comments:
Dylan Kuhn, I agree, I am surprised that there is no obvious candidate. I did a bunch of Google searchers and I found very little. I would have guessed that the flexibility of PHP (relative to static languages like Java) would have made good use of a flexible storage system like MongoDb, but the reality seems to be that I was wrong.
Ross Wilson answers:
It might not be best to store your entire CMS in mongoDB because of the expensive nature of creating relationships in mongo. You might be better off using mongoDB as a secondary content store on something like wordpress (or other cms), where you store an id in wordpress, and the unstructured data (with that id) in mongo. Then you could save/retrieve unstructured data to mongo after getting the id stored in wordpress.
If you go this route, couchDB might be a simpler choice, and it has a PHP library which would make the integration trivial.
Ross Wilson comments:
Not a PHP based CMS, but Plone [[LINK href="http://plone.org/"]]http://plone.org/[[/LINK]] uses Python and a NoSQL db
Lawrence Krubner comments:
Ross Wilson, I am confused by " it has a PHP library which would make the integration trivial". PHP also has a library for using MongoDb. What library are you talking about?
Did you see the article in the New York Times called "Snowfall"? See here:
[[LINK href="http://www.nytimes.com/projects/2012/snow-fall/#/?part=tunnel-creek"]]http://www.nytimes.com/projects/2012/snow-fall/#/?part=tunnel-creek[[/LINK]]
My client is looking to get away from templates and instead get to a point where it is possible to create a new design for every article, while still having some CMS-like controls. We have study the issue a lot and, and it seems that having a fixed schema tends to lead to fixed designs, or it leads to an explosion of complexity. After much talk, we thought an ad-hoc, open-ended taxonomy of tags might all more flexibility, for matching content in the database with tags that are put into what page is suppose to render the design. Tagging is one activity where NoSql seems easier than the SQL.
I think we could do all this with WordPress, custom fields and Pods, but I think it would be crazy complicated. MongoDb might offer an easier way to get that kind of flexibility, but I am surprised by the lack of CMSs that use MongoDb.
Pavel Petrov answers:
I`m not aware of any frequently supported MongoDB CMSs, but based on my experience with MongoDB I`d probably go for Symfony2 bundled with Doctrine MongoDB ODM. You can probably build the whole cms functionality in few days and you can have all the flexibility you want. Instead of the custom fields and Pods framework you can use the built in form-builder. When you need a new "Post type" you just create a new class with object document mapping metadata and you`re good to go. As for the templating part Symfony2 uses Twig which also gives great flexibility for your templates and is quite easy to get a grasp on, and you can define separate separate template for each action in your controller(or each post/article in your case)
Most of the trivial tasks you need to accomplish(like backend login and user management) have an already built Bundle you can use like FOSUserBundle for the login and security, etc..
Lawrence Krubner comments:
Pavel Petrov, I have worked with Symfony 2 since 2008 and I realize it can be powerful. But I would not characterize it as flexible. Any change to the schema requires a series of explicit actions: changing the schema.yml, if it is in use, or changing the Dcotrine definitions in the models, if they are use. Consider editing their examples:
[[LINK href="http://docs.doctrine-project.org/projects/doctrine-mongodb-odm/en/latest/reference/introduction.html"]]http://docs.doctrine-project.org/projects/doctrine-mongodb-odm/en/latest/reference/introduction.html[[/LINK]]
With this current project the client would like to experiment with an ad-hoc schema on the theory that an ever changing schema might be an important step toward enabling the kind of design freedom that designers have when they design print magazines.