Change name of 'Insert Content Entity' Event to 'Insert Entity'

But this action can be taken with ANY ENTITY. Why add the word 'Content' here?

Well, that's not the case. There are two types of entities: content entities and config entities. And all the actions from the eca_content module really only work with content entities and not with config entities. As it happens, users are indeed content entities, though.

Using the term content when we mean nodes is even more confusing in my view. There is so much content which is not nodes, that I always felt uncomfortable when I saw that happening.

Having said that, I can see how the knowledge about users being content entities is true in technical terms, but not to the site builder who is working on ECA models. However, removing "content" from the event plugin label doesn't seem to solve the problem. There are currently almost 20 events that fall under the same category, so it's not just that single one.

This looks like the issue is to be solved by documentation and other knowledge transfer means. But I'm of course open for other suggestions.

In any case, I spent a lot of time overlooking 'Content Entity' when wanting to work with a User. I just don't like the term 'Content' here. Sorry.

It's also probably worth adding that 'Content Entities' are outlined in current Drupal documentation → and Users are very much NOT considered a Content Entity in current documentation. I'd strongly suggest a change in wording that is consistent with Drupal documentation and standards.

I'm not sure how I should respond to this. I was providing you more information and why the situation is as it is. And yes, since Drupal knows about entities, users have been content entities.

All that ECA is doing is leveraging existing hooks and events from Drupal core. And the insertion of a new user dispatches hook_entity_insert. If we were calling this event just "Insert entity", then users will be irritated when they expect this to work when a config entity is being inserted, which won't work.

The link to the documentation in comment #6 is in fact making it pretty clear: the third entity type in the table is the "User profile" from the user module. And that is the user entity we're talking about. Yes, "User profile" may be confusing as one may relate this to the profile module. But it clearly states that it's about the user module. And the term profile also appears in the user menu, where each user can go to their own profile, which is nothing else than the content of their user entity.

Another indicator, but that's more for developers, is the \Drupal\user\Entity\User class: it is defined as this:

class User extends ContentEntityBase

Now, this discussion is about the technical facts. I already admitted that I can see the confusing part for an end user and asked for proposals on how to avoid the issue. Just removing "content" from the label isn't an option as explained above.

I'd strongly suggest a change in wording that is consistent with Drupal documentation and standards.

The terminology of "content entities" and "configuration entities" was introduced since the beginning of Drupal 8 and since then it is the current standard. It's a terminology that may not be perfect, but it is used since then. This post explains that terminology very well: https://drupalize.me/tutorial/entity-api-overview

Another official resource that users are content entities can be found here: https://www.drupal.org/docs/drupal-apis/entity-api/content-entity →
There is a cheat sheet that categorizes users as content entities.

In any case, I spent a lot of time overlooking 'Content Entity' when wanting to work with a User.

Any begin of using this ecosystem may have some hurdles at the start. For any beginning, it may be a good idea to have a look into existing documentation and examples. A lot can be found on https://ecaguide.org/

Terminology aside, we may always look on how to improve the UX. Maybe we could optimize the description of the event plugin by adding something like "After a new content entity got saved (persistently created), for example a node, user or comment."

Ok understood. I agree especially from a backend Dev Drupal/API perspective that Drupal considers the User object a Content Entity - but that's not necessarily my primary concern here. My primary concern is ensure that the UI is clear to the end user. It wasn't clear to me and I've been using Drupal since 2007 and I acknowledge that Drupal has historically been Dev-centric and is struggling with adoption and hemoraging usership to other CMS solutions. That is my primary concern here. Does the end user understand that a User is a 'Content Entity' and should we be using that terminology for the particular end user who is interacting with this module. I'm not sure the answer is 'yes' but I understand the developer perspective here.

I don't see this as an exclusive developer terminology. I had talks with various product managers, integrators, SEO and editors explaining which type of entities are part of configuration management (and so are shipped with deployments) by using that terminology. I've never had a problem of "perspective" on that. We do need a terminology to distinguish because of the arguments mentioned in #4. It doesn't make sense trying to "hide" or even introduce a new terminology, but it makes sense to use the official one.

I could argument saying the "Ambitious Site Builder" may also "Writes (some) custom code": https://ostraining.com/blog/drupal/ambitious-site-builder-in-drupal/ as I don't see a reasony why we'd need to separate "two worlds". This module is rather about combining "both worlds" and that makes it valid to use terminology from both.

I'd recommend to have a discussion with arguments that are resolvable for this specific issue here. Saying "Drupal has historically been Dev-centric and is struggling with adoption and hemoraging usership to other CMS solutions" is not bringing us forward for this particular issue.

Happy to see your thoughts on how we may concretely improve this, e.g. by giving feedback for the suggestion made in #8. Other suggestions are also welcome of course.

I actually like the idea of providing examples that might include node, block, user (as these are all core Content Entities), could really help here and provide some important context.