Content modeling

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.
  • These can be put into groups – such as the ACF field groups. Then that group can be assigned to a given content type.

…