BaseElementModel::getContent() will return the element’s ContentModel. It has two purposes:
To store the element’s data from the craft_content table table when fetching elements from the DB.
To store the POST data that should be stored in the craft_content table when saving an element to the DB.
In both cases, the ContentModel should not actually be ...
TL;DR: Let the content dictate how you model and architect it.
If the site is sufficiently small or sufficiently simple, I think either approach is ok. My team has used both approaches, and it really depends on the Client's needs.
An incomplete list of reasons to use separate channels and structures are:
Tagging/Categorizing things like Products is ...
I'm not familiar with ACF, but if you're looking for blocks-within-blocks, you could use the Neo plugin/fieldType. It allows you to define blocks, and then have nested blocks. It allows for decent management of blocks, too, so that you have children of specific parents.
You could have the following blocks/content types:
Hard to say if they're the 'best' tool, but I don't see anything here you can't do with Craft categories and they seem the logical and built in way to go about it. In essence you simply look at your url segments and use these as category filters when retrieving the products
I think so. It keeps the two separate data concerns nicely separated - but do be ...
setContentFromPost() performs an operation on the attached ContentModel, not on the element model itself.
When you initialize a BaseElementModel, its content attributes are set from the associated ContentModel. ("Content attributes" means attributes from custom field data, a.k.a. the stuff you'll typically find in the craft_content DB table for a given ...
getContent() will return the element’s ContentModel, NOT getContent()->merchant, which is just an attribute of the ContentModel—sorry for the confusion.
I’ve just posted a separate Q&A fully explaining what the ContentModel is used for here:
What is getContent() / the ContentModel, and how do I use it to get and set custom field values?
What you ...
As chapter numbers grow, will this be too many sections for Craft to handle?
Probably not. I suspect as your section list grows to the multi-thousand section range (if it will ever get that large), you'll start to run into MySQL/environmental limitations rather than any Craft ones. But if you do run into any UI/architectural limitations, we'd love to ...