Choose one: "content" or "node"

My 2c, as a reasonably new person to Drupal is to go with Nodes. Why? (yes I have duplicated some of the comments in the OP)

• There is lots of Drupal specific terminology to learn already anyway
• Content is more than nodes
• Nodes are being made optional #375397: Make Node module optional
• Following above, it becomes conceivable that content will be made up of stuff other than nodes
• Changing URIs from node/x will not make people happy, without an automated 302 system

I think that is most of my reasons...

Subscribing.

So just tossing out some comments. These are not mandates on high from webchick, the D7 core committer; this is just webchick, the Drupal developer talking here. :)

Currently, the rule is "we don't mention the word 'node' in any user-facing text." And AFAIK, all of core follows this rule, even things like Actions (though I could be wrong; it's been awhile since I looked). The word "node" is spottily replaced with "content" and alternately "post" (a word which I personally hate with a passion :P).

If we were to flip-flop on this, and say that "now ALL mentions of the word 'content' or 'post' must be 'node'" you start to get some kind of funny things. Like the "Create content" link becomes "Create node" (what?). "Content management" becomes "Node management" (huh?) and so on.

"But webchick!" I hear you say. "Surely that's taking things too far! We would only change *certain* places to 'node' where it made sense, like 'Node types' and such. Duh!" Ok, but now we have three words to refer to the same thing. And we already know content/post screw people up. Content/post/node is going to do it even more, IMO.

Furthermore, "node" is such a Drupalism it's not funny. Pushing this more into the faces of people who need to use Drupal day-to-day and not hack on it for fun and profit strikes me as a step backwards for the kind of usability improvements we're hoping to do.

To address David and wretchedsinner:

* Nodes aren't just content, and content isn't just nodes

While I agree that you can use a node as something other than content, I would argue that that is a "power user" usage of a node, and not within the norms of what they're intended to support. I mean you can also make your menu based off of taxonomy, but we're not going to rename taxonomy terms "Menu items." That would be silly.

VERY true that content can be things other than nodes, most notably blocks (but also potentially things like user profiles depending on one's POV). But I think we're better off to leave the default assumptions in Drupal that nodes are primary content and blocks are auxiliary content, while keeping the flexibility to use either or both any way you want. It's a lot more natural to people to treat them that way.

* Most of the code/DB refers to "node types"
I'm fine renaming the table to "content_types" instead, and "node" to "content" (although that's a BIG change and needs thinking through carefully).

* Our URLs currently go to node/X
I'm 200% fine "in theory" of renaming this to content/X, although I worry massively about link rot so this would need to be dealt with very carefully if we choose to do so.

* Mostly just a UI change if we standardize on "node"
But UI affects all users, from the hardcore developers to the "what's a website?" first-time visitor. Database/function name changes affect only developers. I feel like developers are much more adept at handling this kind of change than users are.

* There is lots of Drupal specific terminology to learn already anyway
Or, what if we abolished the word "node" from the backend as well and got rid of one extra piece of terminology? :)

* Content is more than nodes
Addressed above.

* Nodes are being made optional #375397: Make node module optional
Even if that does happen, the vast majority of sites will have node module enabled by default and will be using it as their method of posting content. And even if they don't use the core node module, they will be using *something* that will be adding content to the system. I think it's fine to continue calling this word "content."

* Following above, it becomes conceivable that content will be made up of stuff other than nodes
I think this is true, and an inevitable (and welcome!) evolution, but UI should still be optimized for the end-user, not the developer, and assume "sensible defaults." But by all means, we should have tons of API docs and handbook pages to explain how to extend the basic stuff to do crazy things.

Content, I don't think I can argument it quite nicely as webchick - but I think in this case its good for common sense to rule the decision.

As I percieve this becomming a large thread, lets make sure we mark it won't fix - before that.

Node module is mentioned in the UI at least on the permissions and help index, so we currently do use at least three terms (node, content and post) in core. I also consider node/add and admin/content/node as 'in core'.

My main problem is with how we refer to individual pieces of content - there isn't a singular for 'content', which is why we have 'post' cropping up everywhere, and I hate it lots and lots.

What I think the majority of regular Drupal users actually use.
Singular: node
Plural nodes / content
Types: a content type (very rarely node type although I used to use that in 4.6/4.7 more)
(not consistent, but makes sense to me)

If we standardised on nodes:
Singular: node
Plural nodes
Types: node type
(ugly and weird but extremely consistent and little chance for confusion once you get the hang of it, but see below*)

If we standardised on content:
Singular: #%?!*& WTF?????
Plural content
Types: content type

Current singular usage in core/contrib/d.o:
one content, a post, a piece of content, content item, a $content_type (article, page), a node.

It's that singular usage which to me is the main issue with any kind of standardisation on content - if someone can come up with a word that won't be confused with individual content types (article, page, post), isn't a phrase (content item, piece of content) and isn't as obscure as node currently is, then let's kill 'post' and replace it with that. Otherwise I'd reluctantly vote for 'node'.

* To muddy this issue further, there's also the question of how much we expose the concept of 'fieldable' item to the UI - if I can eventually have different types of users for bundles, field bundles for taxonomy term vocabularies and stuff like that, then that starts to water down what makes node and node-types special - we end up with a lower-level concept which has types and fields attached to it, which in a way is what people always wanted in the 'make users nodes' discussion of old. And at that point we really want to be distinguishing nodes as specifically 'content' or a particular kind of content. And the generic term of node - which used to be so handy when you used it for user profiles or 1-1 taxonomy term via NAT for metadata starts to work against itself.

My general feeling is that if we could fix the singular usage of 'content', then that's probably our best bet, but I have very low expectations of that happening - so I'd actually keep the hybrid node/content|nodes/content type we have now in general usage and just remove 'post' and other ugly workarounds.

Fields on non nodes indeed raise the question of "what is content / what is a node" to new philosophical heights.
If nodes, users, taxonomy terms, files, comments, blocks, or some contrib "entity" can have fields (and thus carry "content" in its broad sense), + if taxonomy, comments become "fields", a number of previously reasonably sharp lines are blurred.

While seasoned Drupal users can probably rely on the mind model they developed with D6-/CCK and reach new heights from there ("no more NAT, no more Content Profile, no more Comment as node, cool !"), I suspect this will be a challenge for D7+ newcomers : "OK, everything can hold data, so which tools should I pick ?"

The challenge with "Fields in D7" is to make the lines sharp again somehow.

I think one possible answer is to define those entities by what they do *besides* holding content - a little like how you differentiate between a block display and a page display in a View :
A node is a piece of data that is versionable, has an author, a creation date, "published" and "promoted" status, has its own page, can be commented on by other users. It is Drupal's primary mechanism to store your site's content.
A term can be used to tag your site's content into categories, and generates listing pages
A block etc...

To relate more specifically to the point discussed here, and give my 2 cents, I'm not sure that hiding what makes the 'node' animal special behind the generic and common-language word of 'content' helps us draw sharp lines again. That's where lingo is precious : it is unambiguous once you understand what's behind the term, and can be used to build clear UI sections, help texts, etc. It is important to give newcomers a way to quickly embrace the lingo - and I'm not sure what's the best way to do that. But in a world with Fields, 'content' is doomed IMO.

Side note : node module moving to CCK's 'content' namespace would be... ironic ;-) - and quite possibly a nightmare. /me remembers CCK's 4.7 -> 5 migration struggle over namespace.

Side note : node module moving to CCK's 'content' namespace would be... ironic ;-)

Not really; this is how it was always intended, which is why JonBob and John VanDyk were always adamantly opposed to calling any data tables, menu items, hooks, URLs, etc. in CCK module "CCK". What I don't think they counted on was it taking 5 releases to get it into core, so it might indeed cause some upgrade troubles these days. :P

@catch: If the main complaint is "what is a single piece of content called" let's just standardize on "piece of content." Why can we not use a phrase?

Maybe I'm naive, but I'm not that overly concerned about the fact that our APIs are crazy awesome now. I feel like that's a solvable UI problem. We keep the UI geared toward the "typical" case where content is the primary thing on the page, blocks are auxilliary content, users are users, menus are menus, etc. Leave the fact that you *could* make your entire site with just fieldable taxonomy terms and aggregator items and zero nodes or blocks something for a nice academic study in the handbook.

webchick: if we could have a separate issue just replace 'post' and similar with 'piece of content' I'd be +1 to that - then we can see if using a phrase causes many issues - if we decided to switch back to node then it'll make a huge find and replace easier later on anyway.

If the main complaint is "what is a single piece of content called" let's just standardize on "piece of content." Why can we not use a phrase?

We already use "piece of content" in some places, so that's not that outrageous. In translation.module we say "Translations of a piece of content are managed....", for instance.

We use "post" in a few very short phrases like "make post sticky" or "promote post to front page". Those could probably just be "make sticky" and "promote to front page".

In some places, we use "post" because we want to use a content-type-neutral name. "The post has been added to the selected book." Using "This piece of content has been added to the selected book." sounds unnecessarily long.

The best thing about not using post as a noun is that, presumably, we can use it more clearly as a verb. There are lots of places where we say stuff like "You are not authorized to post comments.", or, somewhat redundantly, "Users with 'post comments' permission can post comments."

It seems like we'd just have to run with reworking some of these instances and see what problems come up.

Edit: Oops -- I crossposted with catch's comment above. A separate issue would work as well.

Using "This piece of content has been added to the selected book." sounds unnecessarily long.

That's true, but we could also just shorten it: "Content added to the selected book." :) There are probably lots of other opportunities like this as well.

And +219379283479235 to being able to use "post" as a verb consistently, not ambiguously as a noun sometimes and a verb other times. I think "post" as a noun originally started because we were trying to be WordPress, but Drupal is a lot more rich than deciding between "posts" and "pages" and our vocabulary should reflect that IMO.

Opened an issue just for 'post' removal #431612: Stop using post as a noun.

I support "content." Some may have dissed content above because of confusion between content and content management. Even if you remove/make optional content management features, the product still manages web content.

This might not be helping the discussion, but I think a new word would be a good idea. Could there be another term that means "material provided by a user" that is not post or content? I got out my handy thesaurus that predates the internet entirely and found some other interesting ones.

Submission, submissions, submission type
Work, works, work type
Piece, pieces, piece type
Record, records, record type. (This one has been in many an application since this book was written.)

subscribe

Reverting spammer in #16. Will report him to site admins.

EDIT: The issue changes made by the spammer were assigned to #17, but that user did not make those changes.

my opinion: "A node contains content!"
I also agree with #7

A node is a piece of data that is versionable, has an author, a creation date, "published" and "promoted" status, has its own page, can be commented on by other users. It is Drupal's primary mechanism to store your site's content.

also, the terminology "node" is the best term there is, read for example:
en.wikipedia.org/wiki/Node_(computer_science)
en.wikipedia.org/wiki/Node_(networking)
en.wikipedia.org/wiki/Node_(graph_theory)
each and every of them defines it as a basic unit, a single point.

I would even go one step further, with fields in core, even a view can be a node (or better, a field in a node).

Our database should cater for advanced use(r)s, while our interface should be catering the beginners.

Downgrading all D8 criticals to major per http://drupal.org/node/45111

Not major. Important, but not something that should block work on other features.

See #1818278: Rename "node" to "content".