Content modeling
Introduction
Some notes…
messy for now – but working out the best cross-platform way to explain this
Listen to someone else
Marcello is obsessed with content modeling and headless CMSs: headlesscreator.com
You can sign up and watch those. Probably want to get through the WordPress lesson: first!
Maybe watch the first one?
Some clarification
- A headless or cloud CMS – is a CMS hosted somewhere else. It’s really not any different than a live WordPress instance, really. It’s a “Software as a Service.” So, you pay the company to host it – and then you don’t have to be responsible for maintaining it locally and deploying it. They can get pretty fancy. They can also be expensive. But are they more expensive than maintaining a custom CMS for years? (that’s a question for later in your career – of for the CTO to decide)
- You can just think of it as “a CMS,” OK? (it’s just a marketing angle)
- They are also neat because you can create any front-end you want and you aren’t coupled to a monolithic CMS/Admin panel framework. That’s the “headless” bit. But – not the best name (we think).
- (You can use WordPress as an API for a front-end app – that is built separately from the CMS / which is kinda like a cloud CMS in nature)
Here are some key concepts/terms
- Concept: “Resource type” “Content type” “Content model” “Post type” – these are the things you are going to create for your application. It can feel very abstract, but if you’ve created you PHP CRUD app and your WordPress projects – you will be on the right track already. Your website or app is going to have “stuff” – and those things need to be established. Each CMS or system is going to have its own terminology for these. So, don’t get tripped up.
- Page
- Product
- Person
- Film
- Actor
- Crust
- Sauce
- Cheese
- Topping
- Anything you need to define in most cases…
- Properties: Descriptive data points. “Fields” are the form them take for input, but the point is that you are planning out the various properties of the concept. It’s not unlike a PHP associative array or JavaScript Object – or a CSS rule. You only need to define the properties you need. Here’s a way to group them in your mind.
- Regular field
- text, number, boolean, email, password, textarea (mostly relative to the classic HTML form input elements)
- relationship / reference another content type (usually by associating the ID of the other content type)
- media: a way to access the images in the database etc. (which are likely their own content type behind the scenes)
- System fields (regular fields that are already defined based on your CMS conventions)
- the ID and other internal and possibly default fields or created/associated data. By creating a new “person” it might generate a unique ID and the time of creation and who created them.
- Single – or repeatable field?
- There may an “add topping” field for a “pizza” content type. This would be more like a list. It’s essentially a field – that is used repeatedly and creates an array of data that you can loop through.
- You can create a field that has field / and subfields and compose them however you’d like.
- There may an “add topping” field for a “pizza” content type. This would be more like a list. It’s essentially a field – that is used repeatedly and creates an array of data that you can loop through.
- These can be put into groups – such as the ACF field groups. Then that group can be assigned to a given content type.
- Regular field
…
It’s kinda painful to have to put this image here. The goal of this type of abstract layer of design and planning – is to NOT think about how things look.
The data is based on the users goals. If you have a site selling toy trains, well – you’ll need out outline the details of the toy trains. “Trains” would be the content type – and the details would be the properties of that train type.
Sometimes one of the properties of a content type – is another content type. A ‘band’ might have a ‘record.’ A ‘record’ will have ‘tracks’ or ‘songs.’ So, these things can be outlined independently – and then connected by their unique identifiers (ids).
movie studio
, actor
, producer
, film
, person
, role
, genre
– might all be “content types.”
Then, there’s a bunch of things to further describe them. People have name
s and films have a year
they were made. actors
might belong to a film
– and films will belong to a movie studio