Rename "node" to "content"

What is going to happen to people who have aliases that alias node/{nid} to content/{something}?

Updated issue summary.

@webchick Thank you for tackling this! The node thing never tripped me up, but on the whole this makes a a lot of sense.

I'm no expert on the technical intricacies, but your resolutions to the ones you mention seem generally sensible. The one thing that sounds awkward terminology-wise to me is the singular form 'a piece of content'. Partly it bugs me because it's long, partly because it… um, makes me think of 'a piece of ____'. What about 'content item'? Node : nodes :: content item : content. That way, you could even optionally rephrase as 'an item of content' in certain circumstances if the structure of a passage demands it.

While node is an English word, it is not in everyday use.
So for non-English sites, node is almost language neutral.
While 'content' works much better for English language sites, it screams out for translation in a non English site.
So while I've never got too bothered about changing /node to other languages, I'd need to translate /content.
So pardon my ignorance, but is that straightforward?

Ok that scenarios I am describing I am thinking only of system paths not alias
What happens to sites that already have Drupal path(system path) using '/content'(via custom hook_menu or page manager) and they use the current path '/node' (some people must use that core page right)?

Or even a site that uses a current /content/[numeric_id] system path for something other than nodes. Possibly having thousands of these paths. Maybe another custom entity. And they also have thousands of nodes. If they are not using url alias and have inbound links going to both /content/[id] and /node/[nid] this could be a problem, right?

I agree that it's good to think of alternatives for the word node. I'm not sure if 'content' is the ideal replacement.

The problem with the word 'content' reaches beyond nodes. What about other entities? I'd say that the content of a site is more than just nodes, it also consists of file entities, taxonomy terms etc. If our terminology tells users that files and terms are not part of the site content, aren't we introducing a new source of confusion?

I just checked you can exclude pretty much all JS files from the rename. node is an actual term used in js files, as in DOM nodes and that can't get changed. So yeah, the current patch is rewritting stuff in jquery, jquery ui, underscore and so on, not good :p

The only JS files that might need to be changed (because ids and class named got changed) are: block.js, comment-node-form.js, node.js (i guess the actual file needs to be renamed too), some doc in overlay-parent.js and translation.js.

Putting to NW to get the rest excluded from the rename.

Glad to see a core maintainer is on board with this (finally? :-P ). Go, Webchick, go!

For people interested in previous discussions about node versus content, see #544320: Rename Node to Content and #425478: Choose one: "content" or "node". Although content may possibly not be the best word, it's definitely better than node.

However, tedbow in #12 raises a valid point.

Although I agree that 'content' is not perfect like #13

I do think that IF this change is go through it should be word the 'content'. The main reason for this is because 'node' was already replaced in with 'content' in most of the UI in the change from D6 -> D7. This change would be to make the UI consistant and make code match the UI.

I think if we switch in the UI from 'content' to some other word. It would a barrier for some who were new to Drupal in 7 in making the jump to D8. It seems we are going to lose a lot of mainly site builders if we keep changing the UI wording.

I'll weigh in on the "nay" side: I'm definitely opposed to the change. There are a couple of big issues, all of them semantic. (Which I'd normally put less weight on, but all arguments on this front are essentially semantic, so here we are!)

1. Its ambiguous pluralization results in awkward and inconsistent phrasing. For example, does "A site's content" refer to a single content or the collective content? We could insist on "A site's contents" as the proper pluralization, but this kind of singular/plural mixup is manifest in the code as well. Is the singular form of the word "content" or "content item?" If the latter, we're really using the word "item" to replace "node," and we've not gained much. "The contents of a node" is currently a useful means of distinguishing its actual data from the code-object that encapsulates it. With this change, "The contents of a content" or "The contents of a content item" are the best (?) options.
2. It confuses the role of other entity types that are, quite properly, "content" on a Drupal site. Comments, biographies and photos in fields attached to user accounts, Drupal Commerce products, and Media files are all definitely content, but with this change they'll be an ambiguous sort of "non-content content." This applies even to non-entity elements on the site: "content," properly, includes text and imagery that's embedded into template files, blog posts, user input forms, and more.
3. This is inconsistent with how other CMS's approach their terminology. Wordpress refers to its fundamental unit of user-createable content as a "posts," Joomla refers to them as "Articles," older CMS systems frequently refer to them as "Pages," many frameworks skip directly to the database and refer to "records", and so on. The terminology in those systems is simplified by making it more specific and precise, not more abstract.

When modeling content abstractly (say, as an information architect or a content strategist mapping out the plan for a site), words like "Units of content" or "Items" or "elements" may be used. When presenting terminology to users, whenever possible, we should refer to the proper, concrete names of our content elements: Blog entries, Press releases, Products, Blocks, and so on.

If we want to eliminate the moments of head-scratching new Drupal site builders face when confronted with the word "Node," we might consider alternatives -- but overloading a general term like "content" will cause far more confusion through its collisions and ambiguity than it eliminates.

I agree with eaton. One of the definitions of node in the dictionary is "a centering point of component parts" which is exactly what Drupal node is. The nodes are building blocks of the greater pieces of content. I would consider the "content" to be the overall piece of, well, content (I can't think of another term to use there), including any referenced nodes. So a news article including its referenced photo galleries, videos, etc. all together would be a piece of content (especially in the end user's mind), while each of those items alone would be nodes OF that content.

Well, starting with Drupal 7 nodes have become way less important in favor of entities in general, which are now our "centering points of component parts". With more and more node-level features, such as revisions, becoming entity-level features in Drupal 8, nodes are increasingly becoming a dumb general entity type without hardcoded features.

Until we reach the point where nodes aren't special anymore, the best description of them I've read so far is that they represent content that is authored entirely and collectively by users.

If we want to eliminate the moments of head-scratching new Drupal site builders face when confronted with the word "Node," we might consider alternatives -- but overloading a general term like "content" will cause far more confusion through its collisions and ambiguity than it eliminates.

I agree with this completely, however I fear that there is no word in the English language that properly describes the fundamental concept of what we no call a node that isn't equally confusing and/or loaded... or we would have found it already, no? We may be better off with a completely meaningless term that will be simple to explain (upon installation) or lookup, and differentiate from all other web-technology related terms: "goober" or "thingy" or "glob" or "droplet" or whatever. We may be better servered in simply making it glaringly obvious that this is a concept you need to learn instead of trying to name it something almost-kinda-sorta-close to what we actually mean or something so general (aka "content") that it can mean way too many things.

== my 2¢

I agree with #17 and #18. As an old programmer(but not a computer scientist) I recognized the word node as a token for the many different things composing a site, but most importantly that all these things are connected together, which is implicit in the word node but not the word content. So yes, I can easily view a CMS as a system to manage nodes, if indeed that is the generalized, overarching, term to be used. As pointed out above there are semantic problems with the use of 'content' as that term. A CMS also presents 'actions' as well 'content'. Yes, it does this by presenting a form, but somehow a 'login node' makes mores sense to me than a 'login content'.
There has been a great deal of discussion about making drupal easier for newbies. But I (still) fail to see how changing a single word will make drupal easier to understand by someone new to CMS's, never mind drupal. There has been a worthwhile effort to provide better tools and interfaces for such users. But if I undertake something new, I expect to learn something new, including new terminology. To me, an effort by drupal to better explain it's terminology would be more worthwhile than looking for one word magic fixes.

I'll also weigh in on the 'nay' side. I think it might be confusing to replace 'node' with 'content' for many of the reasons given above. As a site builder and themer, I've never really had any major issues with explaining the use of the term to my clients who are typically site editors / content creators and not especially ultra tech savvy. I simply say to them, when I say "node", think of that as a single piece of content you create.

In the content hierarchy, I think 'content' is above 'node'. If you read this page, "About nodes", if you were to think of substituting the word content for node it get's confusing pretty fast so I think it does show that 'content' is on a level higher than a 'node'. Would it not be true that a Views page with a path would also be 'content', yet it's not specifically a node in Drupally terms?

Just adding one thing to what I said earlier:
I have trained many of our clients how to use their new Drupal site. I always say "If you have to learn One word of Drupal-lingo, learn the word node". No one ever complained. If we cannot find a specific, common word, I think we should prefer specific jargon over ambiguous common words.

I was going to write some long missive here about why this is a horrible idea on many levels, but then I realized Eaton already said almost everything I was going to say. So, please just go back and read #17 again before continuing and pretend it's my voice saying it.

Didn't we learn our lesson with Category vs. Taxonomy?

"Everything is content except when it isn't" is going to confuse people more, not less. Inconsistency in the URLs doesn't matter to many people, since apparently no one reads URLs anymore. (Which is why people turn on pathauto with stupid settings and create 500 character URLs, but that's another story...)

even though from an abstract, semantic POV we could surely argue that really anything with a URL (and even some things without, like blocks) in Drupal is "content."

That's one of the biggest arguments against this rename. As Eaton said, "content" is more than what we call nodes right now. If anything, it's misleading to call nodes "content". Those two words are not synonymous. A simple swap-out assumes they're synonymous already, when they very very much are not.

And then there's the roughly 1 billion new SQL records you'd need to create for all the URL aliases to not break a few zillion Drupal sites on the Internet, including a million or so just on this site. And I hate to think what that would do to those sites' SEO and Google ranking for duplicate content...

Renaming node to content *may* make the "first five minutes" of Drupal a little easier, but I doubt by much. But it will hamstring understanding for the next 5 months of Drupal usage, since it's more misleading than not. That's a bad trade.

But realize that Drupal already has this user-facing terminology that calls nodes "content" and other things not content, and has for several releases now (I think the "thou shalt not talk about nodes" rule was introduced in ~Drupal 5).

That's correct. And the problem that has gotten us into with user training is non-trivial: in training, users are often confused that only one kind of content is listed under 'content.' Renaming nodes to 'Content' or 'Contents' or 'Pieces of content' will exacerbate that problem rather than simplifying it. Today, there are also a number of third-party modules that provide new Entity types and list them under the 'Content' section of administration section. Would they be allowed, or would the 'Content' section be reserved, then, for things-that-are-now-nodes?

People in the real world also seem generally un-fussed that "People" are different from "Content" and different again from "Structure" that makes up your site, even though from an abstract, semantic POV we could surely argue that really anything with a URL (and even some things without, like blocks) in Drupal is "content."

People in the real world also seem to be able to manage their Drupal sites despite the horrible, terrible, unacceptable presence of the word 'node'. If we feel that the word is so terrible that we should eliminate it from the UI, the database, the codebase, and the documentation, then we certainly can. My only point is that 'Content', by virtue of its ambiguity and its already-overloaded meaning is a very bad replacement.

Naming a navigation category 'Content' and renaming nodes themselves to 'Content' are not equivalent actions from a semantic or a UX perspective.

I second #17 as well - the current UI of Content/Content vs Content/Comment is already confusing enough :P

I like referring to nodes as "content nodes", while in code or if repetitively used it can stay "node".

I'm so happy that Eaton wrote up #17. Thats my position too. This is 'Won't Fix', IMO.

Agreed with won't fix too

Agree with #17. While "node" may be cryptic, it does have appropriate meaning. Though maybe we can better distinguish it from other systems by using the prefix "flexi-."

Not sure if #32 was a cross post or not, but won't fix anyway on flexi-. :-)

Hehe, love how we won't fixed an issue that was already largely implemented anyway :P. I am sure there are confusing area's but honestly I have not seen it come up in testing anymore. So, I am happy :D

Fun to read this thread.

One thing that did come to mind - if we were going to change it, I would support using the term "post" or "submission". With the mention that nodes are essentially authored content (where as commerce products, blocks, etc have a higher potential to be programmatically created) and to a lesser extent based on Crell's recent blog post about "put" vs "post" in the REST interface, it would seem either other these might work better to "node".

Don't want to contribute to bikeshedding though, so feel free to ignore.

The guys from NodeOne wouldn't like this, you have just deprecated an entire company, ContentOne just doesn't sound the same... :-)

Updated issue summary.