Revolution: Category IDs are not consistent

[pepebe]

Bug report

Summary

The numbers show on the right side of category names listed under templates, tvs, chunks, snippets and plugins are not consistent with the category ids stored in the database

Step to reproduce

Compare categories listed in the elements tree with the general category list.

Observed behavior

Category List at bottom of elements:

Example: Schneidscheiben (20) (identical to the value in the database)

TV List showing TVs ordered by category

Example: Schneidscheiben (15) and Produkte doesn't even has an ID

Expected behavior

The id shown should be euqal to the id used in the database.

Environment

I guess this effects all versions, tested on 2.7.1

[Ibochkarev]

@pepebe The value in brackets next to the TV indicates how many TV parameters are in the folder

[Ruslan-Aleev]

Although @pepebe is right, visually it is confusing, because for the remaining elements in brackets is specified id.
Perhaps it makes sense to change the brackets for category, for example:

[Jako]

To make it more obvious we could use [2 TVs], [2 Elements], [2 Children].

[pepebe]

Its the number of elements? Wow. I didn't even think about this.

From a consistency point of view I'd expect the number in brackets to be the elements id.

To be honest, I don't care how many elements are inside a category. If anyone does, please give a real world example that explains why this is important information.

[Ruslan-Aleev]

@pepebe Maybe to find out how the list will unfold? The information is not very useful, but let it be.
And if you want to know exactly the id categories - they are listed in the list of categories in brackets.

[pepebe]

Today I have learned the following things:

• name (id) = a category, may have subcategories or not. (id) equals number of total elements directly below it.
• name = a category, may have subcategories or not. Does not have any elements directly below it.

I still can't see the need to know how many elements are inside a category.

A single real-world example why this is useful would satisfy my curiosity.

I might be a bit biased because I spend an hour retrieving a list of TVs from the database looking for the wrong category id, but I don't see any reason why the consisent use of ids should be overruled in this case.

[JoshuaLuckers]

The amount of elements inside a category is useful to me. I use it as a quick indicator to make sure new elements are synced from a dev to a live environment.

[Ruslan-Aleev]

why the consisent use of ids should be overruled in this case

Not certainly in that way.
The element identifier (categories, for example) are listed in the list of elements (categories, for example), there is no change of logic.

But since the amount in categories and id indicated in the same way, this is confusing.

[pepebe]

Thats my point. The number should always be the id of the element. Categories does it right.

[sottwell]

It actually only shows the number of children. If some elements are in sub-categories they are not counted.

[Ruslan-Aleev]

Maybe it makes sense to display both the amount and the id so that there is no confusion?

For example:

Or simple:

[pepebe]

Before be find a solution for a problem nobody cares about. Let's find at least a single example why it is useful to know the number of direct descendants inside a category.

Somebody "might" find it useful is not a reason the break apart from consistency. By the very same reasoning, you could do the same thing to resources and I guess most of us will agree that although this would be useful in a few cases, it would be total overkill.

I'm aware that knowing the ID of a category has a very limited use case, but at least I have one and consistency would be another.

[JoshuaLuckers]

I am in favour of consistency and knowing the ID of resources, elements and categories is very useful.
Showing the category ID instead of the element count would be more consistent with how container and child resources are displayed.

However, I also think having numbers of how many elements are under a "leaf" is useful and should be visible somehow.

[Bruno17]

to have both could be useful, like @Ruslan-Aleev posted.
perhaps like this:

my category [id](count)

[JoshuaLuckers]

The tree(s) already look very messy and busy and adding more metadata would make it even worse.
Do we really want to show metadata like id's and element count all the time?

I wouldn't mind if the "number of elements" was only visible on hover/focus.

[Ruslan-Aleev]

Yes, a very good option with a tooltip of the count of elements on hover, as suggested by @JoshuaLuckers

[OptimusCrime]

I fail to see how the ID of a category is ever relevant. Can we just hide these IDs?

[Mark-H]

I'm with @OptimusCrime that category IDs are totally irrelevant and am inclined to reject #14605 in its current state.

[alroniks]

I am closing it as a wontfix. As it was discussed and seems it has some kind of conclusion. Please, open new proposal, if you want continues the discussion.

[Ruslan-Aleev]

The same designation of the number of elements within a category and category id in the form of brackets () is a bad decision for UX.
I would make in this form ([]), the difference is simple and noticeable (although the question is not important):

[JoshuaLuckers]

Can't we just add a text? E.g (2 sub-categories, 2 templates etc) and (ID: 1).

[JoshuaLuckers]

I find it very useful to have the amount of items visible, it makes it easier to compare between 2 environments (e.g to spot any missing items faster).

When debugging the element ID's are also useful, the ID is being is part of the cached element's filename.

[Ruslan-Aleev]

If we add text, then there will be too long category titles and lines for translations will be added (I tried to make a tooltip, see https://github.com/modxcms/revolution/pull/14605).
In general, I would just change the brackets, in my opinion the question is not important (MODX works with this behavior and there were no problems), and the brackets give a visual indication that this is not an id.