We have been testing out your platform for a while now and it’s really great. One gripe we have though is the limit on the number of content types that you can create. You have to spend $489/mth to get more than 24 content types which is very expensive for a small startup that wants to create a rich content model. The only option is to split the content into multiple spaces which isn’t ideal.
There should be more content types available on the Small tier so that you can incrementally move up the tiers rather than having to make big price jumps to get more content types.
I don’t pretend to know anything about your project, but I’ll say this: Every, and I do mean every single time I’ve seen people run out of content types, it’s the result of bad content modeling. Instead of going for more content types, I would recommend re-evaluating and re-designing your content types.
I’ve worked on plenty of projects with complex data models and hundreds of tables in a relational database. Contentful would be capable of supporting these models but completely impractical from a cost perspective.
We are currently considering using Contentful on a number of projects with some fairly complex data models that will require numerous content types to support the data relationships. You then add in extra content types to provide richer layout options for rich text fields and you quickly burn through the content types.
These tight restrictions on content types mean having to consider annoying workarounds like splitting the model across multiple spaces.
I realise that Contentful price things specifically to get you to move up to higher priced tiers but there are huge jumps in price just to get additional content types, e.g. an extra $450/mth to get more than 24 content types versus just $39 if you split the model into another micro space instead. I know which option we would be going with, but it’s an annoying limitation.
I would prefer to see a more flexible pricing model with a mix and match approach where you can pay extra to obtain more content types/records/roles/locales/sandbox environments, etc.
I want to second what @teemu.tammela1said above. Same as him, I’m not pretending to know anything about your project, but we have a semi complex content model, that we were able to implement using just 4 content types. You might want to have a 2nd look at your content model and see if you can consolidate some. Just a thought, again, you may actually need more than 24, but it seems like a lot for just one project.
I’m not sure we are talking about the same thing here. Sure, if you are creating a basic blog or marketing site, then you can survive with a handful of content types along the lines of Wordpress authoring as the data capture requirements are fairly simplistic and it’s mainly text content that you are capturing in the model.
But, if you want to create a more sophisticated application with complex data capture, multiple hierarchies & many relationships then you need a lot more content types just to store that data. For example, we can’t take a relational database with 200 tables and flatten that into 4 content types. The model is just way more complex than that.
We also need to be able to offer editorial staff more sophisticated ways to format articles beyond the basic formatting options in the standard rich text field, e.g. responsive grids, tables, review cards, callout boxes, floated images, etc. These need to be embeddable at any place within the rich text field.
So, we create additional content types to capture just the data for these embedded pieces of content and then use custom content renderers to render the rich text content as HTML in the web application with the appropriate layout & styling.
Are you able to share a link to the site you are referring to that is authored with just 4 content types?
So unfortunately, it’s behind the paywall, so I can’t. But again, I was not trying to assume your project was simple. Just a tip to maybe revisit your complex relationships and double check to see if you can “simplify” it a bit. Perhaps, in your case, it’s just not possible.
As it happens, I’m able to offer a reference project that uses just 4 content types. Granted, I’m not claiming it’s a very complex project, but a reference point nevertheless. The source code is publicly available, in case you wish to dig under the bonnet.
For another reference, I have designed the content models for terve.fi, apu.fi and meillakotona.fi (they all have the same content models and platform). The aforementioned sites are one of the most popular lifestyle sites in Finland. They are fairly complicated and content-heavy (entries counted in the hundreds of thousands). Those particular websites have about 15 content types, IIRC.
Thanks for providing the links. The sites look great by the way!
Looking at the source code for AuralCandy.net and from what I can tell from the other links that you sent, these sites all have very simplistic content models. There’s just not a lot of data to capture and they seem to be marketing sites rather than applications with rich interactivity.
I am talking about far more complex sites with a variety of product categories, complex price comparison and a rich & interactive user interface.
Anyway, it is what it is, so I think we might end up with either splitting our model into separate spaces or carving out some of the data into a standard relational database and using Contentful just for managing the editorial content, which is where it really excels anyway.
We’re also looking at other offerings such as Directus, which is really powerful, and as it’s open source so you can self-host with no limits on content types or records. I do prefer some of the features of Contentful though, so still undecided.
I agree, Contentful excels especially in editorial content. Building application-like, data-heavy functionality by using Contentful as the singular data storage may indeed prove impractical.
At the end of the day the biggest question is 1) what kind of editor interface do you need for your every particular piece data and 2) how often are they subjected to change and by whom.
On a related note, it might also be worth looking into JSON field type in conjunction with UI extensions. In the projects that I worked in in the past we found that to be a very effective way of both keeping the number of content types down and providing a better user experience than building everything with native reference fields.
Yeah, the JSON field type is interesting and we have been experimenting with that as it seems to be the only way to support tables within a rich text field. There are some useful extensions for that already and I can certainly see how powerful that could be for supporting any type of UI and content structure.
But…that doesn’t really help when you want to embed other content into a rich text field as you still need to create a content type to wrap the JSON field that you then embed into the rich text field. I guess you could create a multi-purpose JSON field with different UIs that you could select in your custom extension with different JSON data structures, but that sounds like a lot of effort just to workaround the content type limits.
The native support for embedding content types is so flexible and useful that it’s annoying to not have the freedom to use that more extensively.
Contenful have just announced the Community edition which replaces the Micro space and now offers double the content types (48) and other things like Graph QL. This is awesome news and removes a massive impedement to adoption for smaller businesses and startups with more complex modelling requirements. Well done Contentful!
I would like to say though that I do not think hitting 48 content types on a complex marketing website is unrealistic. I am starting development on a new website and we are close to 48 content types already scoped out, pre-launch. That includes globals like nav, footer, metadata, button, page templates (at least 5 unique page types needed), and a slew of page “modules” that can all be reused. Not to mention with the new Rich Text field, Article content type blocks, such as a content type needed for superscript/subscript which Rich Text does not provide out-of-the-box. Also, some of these bigger content types need several smaller reference content types, like a Navbar with a Nav Dropdown and or Nav Submenu sub-content type.
I struggle with the disconnect between Contentful being a CMS where you have the freedom to build these modular, component-esque content models, but then only limiting you to 48 of these on the Medium and Large plan. The only option to have more than 48 content types is to enter into an Enterprise plan which is a very large leap in price and can be difficult to convince a client. It is difficult to get very granular with your componentized content model setup because of this limit.
Is it possible for Contentful to consider an option to add more content types to your plan for an additional monthly fee? It’s awesome that Contentful raised the content type limit to 48 for the Community plan, but I still do feel that Medium and Large plans kind of get stuck with nowhere to go without a really large leap to Enterprise just for 1 feature.
I would love for Contentful addresses this issue. I believe we should model the content based on the site’s needs, not on this super low limit. I am already building 3 sites that have easily reached the limit; they are both very complex a super design rich.
Having to upgrade your tier to a ridiculous amount just to get more blocks (If you do not need the rest of the features) is a super hard and almost dishonest sale.
I don’t understand why contentful does not up that number to 150 or something when you are paying.
