Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By StMario on
Hello everybody,
having developed small to middle size websites using mainly WordPress, TYPO3 and Joomla as a base for roughly ten years I recently stumbled upon Drupal (again). What intruiged me about the system was the (apparently) great flexibility in regards to content display using nodes and views.
Essentially what I want to do, is a system that
a) allows editors to first create bits of information (text, video, images, galleries, sounds OR combinations of these for ex. headline+video+small explaination) and then
b) assemble these bits into "articles" (maybe in a drag and drop system?) which
c) display different according to context (depending on the media which is used to access them and other variables)
From what I understood so far about Drupal, this fits well with the idea of views and nodes, but as far as I understood a node is more like a complete article, or a complete product description and not as atomic as I would like it to be which also restricts the flexibility that I can reach in displaying parts (nodes) in different views.
So, I'm a bit unsure, if what I plan to do is possible and if Drupal therefore is worth the investment of time.
I would be happy to hear your advice.
Thanks
M
Comments
Four days and no reply, maybe
Four days and no reply, maybe one or two of you could give me a quick hint on why. Is my request not understandable? Did I miss some crucial info or docs already out there? Or is it just hard to tackle?
Thank you for your time
M
You can find some tips as to
You can find some tips as to why you aren't getting a response in this thread, or potentially in future threads here: https://drupal.org/forum-posting
I usually don't reply to threads that seem to be looking to be sold on Drupal, as I feel it sells itself. Also, Drupal can be really hard to learn, frustrating a lot of people. So if they are convinced to use it, then get frustrated when they start using it, then they may feel like they were duped into it and get angry and down on Drupal overall (we get angry threads somewhat regularly by people who think Drupal sucks because it doesn't fit in with their expectations). I think it's better if someone decides they want to use it on their own, as they will be more likely to put in the effort required to learn it to meet the goal they have chosen for themselves.
Anyways, the flexibility concepts you are looking for do exist in Drupal, but not necessarily in the way you are looking for. Rather in Drupal you create nodes, then you can use parts of those nodes in various different views. Or you can create various entities and reference them in a node.
Trying to force Drupal to work the way you expect it to usually results in headaches. It's better to learn how Drupal works, then adapt to that, rather than trying to force it to be something it's not.
First of all thank you for
First of all thank you for answering. I'm a bit puzzled though in regards to your advice, because that is exactly what I tried to do: Reading docs, search for similar questions and tried to put in some time in structuring the question... but, I'll take that as a feedback that I have to present things in a different way.
Back to business: I understood that there are nodes and that I can display different parts of nodes in different contexts using views. What my question was about was: How flexible is the system of nodes in regards to two factors: How "small" can a node be, as to what minimal information does it have to hold and is it possible to "collect" / "embed" (at a lack of words here, emedding is not what I want to do) other nodes within a node?
I do not intend to force any system to work the way I expect it, I rather try to understand how different systems work in order to pick the right system for the job. That is exactly why I was curious about the system of nodes and views, it is this system that makes Drupal stand out versus the rest of the CMS world which is way more.
I'm willing and capable to help myself with the details, for the general viability of the idea/concept I thought it better to ask some advice than to spend weeks trying to build something that simply is not a good idea to build in Drupal.
Thank you for your response and time!
How flexible is the system of
Let's take a step back. In Drupal 6, there was only one data type - the Node. In order to allow for multiple data types, the node was then divided into sub types called 'content types'. Nodes had 'properties', that were common to every node, a few being created (date), updated (date), uid (author ID), published (a boolean flag) and sticky (a boolean flag). The Node API allowed for the addition of additional properties.
On top of this, a popular module, named CCK, allowed users to attach new fields (which are like properties, only more dynamic) to different content types. A CCK field was a dynamic property type, that consisted of three parts:
* The storage (how the data was stored)
* A widget (a field element used to collect the data)
* A formatter (a method of displaying the data)
In Drupal 7, the system was expanded, bringing in the concept of Entities. A Drupal Entity is an abstract data type that ties in with the Drupal API. The entity itself cannot be used as-is, it needs a Bundle (see below). Entities can have properties attached to them, and all Bundles of the Entity will have these properties. The D6 equivalent of an Entity was 'Node'. Node was an Entity type, though in D6 the concept of Entities did not exist, so no one actually knew that at the time. D7 core provides a few Entity types, including Node, User, Taxonomy and Comment.
A Bundle is a concrete data type, that can have Fields attached to it (see below). Every bundle will have all of the properties that the parent Entity has. The D6 equivalent of a Bundle was 'content types', though again, the concept of Bundles didn't exist at the time. Drupal 7 also uses 'content types', and these are Bundles of the Node Entity.
A Field is the D7 equivalent of the CCK fields. CCK was integrated into core, becoming the Field API. Fields in D7 are essentially the same as CCK was in D6. They contain a storage engine, a widget, and a formatter. Fields are attached to bundles, and can also be shared across different bundles, making them very flexible.
Once a user has created an Entity type (which may or may not be a Node), they can then create Bundles (which will be called a 'content type' if the Entity is a Node), and attach fields to the bundles. After this has been done, users can then create instances of these data types - an example being the forum topic you have started here.
So to answer your question, Nodes cannot be that small, as there is a full API around them, and they all come with basic properties that cannot really be changed. They are really good for article-like data types, as they have an author ID, an updated date, and come with a Body Field by default (though it can be removed through the admin interface). But if you are creating a different data type that is not very article-like, then a different type of Entity is preferable.
An Entity, unlike a Node, can be as small as you want it. In fact, you could create an Entity type that has zero properties, and then create a Bundle and not assign it any Fields. Of course, you'd be left with a data type that doesn't do anything, since it doesn't store any data, and therefore just exists. Conversely, you could attach as many properties as you want to the Entity, then a whole lot of Fields to the bundle.
There is a module named Entity Reference, that has been integrated into Drupal 8, that allows for the referencing of entities to another. AKA embedding. So I can create a content type, say 'class', and then add an Entity Reference Field named 'Students', and reference a number of User Entities to the Class content type, creating a one to many relationship. And since other content types could reference the same student, its actually possible to create many to many relationships.
Finally, Views. Views at its core is a GUI for creating SQL queries. It allows users to pull various Entities, Fields and/or Properties, and create a display (aka view) for them. You can also use relationships between referenced entities that have been referenced using the Entity Reference module. The Views module also adds more functionality than just SQL queries, as it adds formatters, and created pages or blocks with the data, and allows for the addition of dynamic filters so that users can change the query on the fly by using various form elements.
So there it is, that's a basic overview of the Drupal data system, that hopefully answers your questions.