I would actually handle this the same as an any empty list, not differing if it's empty because of filters or empty because no items exist at all. So either hide it always when $this->items is empty (as it's useless then as well) or always show it.

But that is a personal opinion. I can see why you want it differently. In the end it's a UX question where I have no clue to begin with ?

Joomla had a UX Project at one point ... hahahaha

not differing if it's empty because of filters or empty because no items exist at all

I would say the complete opposite :) :) It should differ, that's one of the reasons we changed what's in the body of the page to make it more user friendly, so that it DOES differ

The rebuild button can be helpful if you don't see any categories in the backend for whatever reason to repair the database table. For me it's not useless in all cases.

The same for menus.

to make it more user friendly

Pure matter of opinion, just BTW. A disabled button shows a possible feature that is not active at the moment. Instead of seeing it you send the people to complicated and/or endless docs pages. How many people used these for newbies confusing help screens in the past?

Pure matter of opinion, just BTW. A disabled button shows a possible feature that is not active at the moment. Instead of seeing it you send the people to complicated and/or endless docs pages. How many people used these for newbies confusing help screens in the past?

You totally miss understand the concept and application of an empty state. Please go and do some research on the subject.

How many people used these for newbies confusing help screens in the past?

The quality of the Joomla documentation is outside the scope of this PR, and while I agree in some areas it is shocking, its best to provide somewhere where a journey can start, than nothing at all.

Most of Joomla is confusing and undocumented, there are lots and lots of tiny switches and options that have big effects on a site that are undocumented. Again outside the scope of this PR.

The rebuild button can be helpful if you don't see any categories in the backend for whatever reason to repair the database table. For me it's not useless in all cases.

The rebuild button is TOTALLY USELESS in the case when an empty state is shown.

The empty state for CATEGORIES will ONLY be shown if there ARE NO CATEGORIES in the database table (checked by running SQL) for the filtered extension.

No matter how many times you press the Rebuild button - It will never "repair the database" and show a category in this instance because, to get the Empty State to show THERE ARE NO CATEGORIES in the db (edit: for the filtered extension) - checked by running a SQL query.

You cannot magically "find" categories by pressing rebuild, because NO CATEGORIES EXIST in the database for the filtered extension.

The rebuild button is only useful if there are actually db rows for the given extension filter - but then an Empty State would not be showing, because there are "some rows"

Factually untrue. There are rows in the db just not for that extension

There are rows in the db just not for that extension

Correct. This is what I said. This is what is meant by the phrase "for the filtered extension." in the sentence:

The empty state for CATEGORIES will ONLY be shown if there ARE NO CATEGORIES in the database table (checked by running SQL) for the filtered extension.

and

You cannot magically "find" categories by pressing rebuild, because NO CATEGORIES EXIST in the database for the filtered extension.

The rebuild button is TOTALLY USELESS in the case when an empty state is shown.

If you were to use a Rebuild button on an Empty State it would only be messing with Categories for other extensions, and would never change the empty state for this filtered extension. It would be more confusing, as the changes it makes would only be reflected if you went to those other extensions categories pages (which would not be empty states) to see the changes.

No matter how many times you press Rebuild button on an empty state category view, you will NEVER see a change and the empty state will NEVER change magically to show categories for that filtered extension.

With no categories or 1 unpublished category, do you know why there is no New/Add button? It is happening with News Feeds too. Is it dependent on another PR?

Thats a problem because you do NOT need to have an existing category before you can create a banner

This is a bug in the original com_banners empty state PR, and not in this PR.

A category is required to create a new banner.

A category is required to create a new banner.

Correct. This is totally unrelated to my work on empty states.

The code clearly states a cateogory needs to be there before the Add button in the toolbar will show.

	if (count($user->getAuthorisedCategories('com_banners', 'core.create')) > 0)
		{
			$toolbar->addNew('banner.add');
		}

Therefore this was a preexisting issue with Joomla.

@Quy a category does NOT need to be created before you create a banner. It is created automatically. Just as it is with all similar components that use categories

If I revert my code to the last Beta Issued of Joomla 4 and delete my banner category - I get no new button. Thus confirming nothing to do with Empty State :) - phew :)

@Quy a category does NOT need to be created before you create a banner. It is created automatically. Just as it is with all similar components that use categories

No. it. is. not. Please test and you will see. The NEW button doesn't even show if there are no categories.

Change this line of code https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/components/com_banners/src/View/Banners/HtmlView.php#L144 to

if ($canDo->get('core.create') || count($user->getAuthorisedCategories('com_banners', 'core.create')) > 0)

will fix the problem.

You CAN create a NEW category when saving a NEW banner - but you cannot get to the NEW Banner Edit page if there are ZERO categories.

That line 144 has been there for 10 years , this "bug" has been dormant for 10 years. LMAO

That bug is now fixed in #33399

If you're up for it, news feeds has the same issue. Thanks.

@PhilETaylor

1. After deleting all articles the Empty Trash-button is shown . Cause it was the last filter set and creating now a new article give them status "trashed":

2. These 9 views are to test?

1 thanks I'll fix that today
2 I forget how many empty states have been merged already - but all of them probably need the empty trash button fix and all need testing

If you're up for it, news feeds has the same issue. Thanks.

Done #33405

After deleting all articles the Empty Trash-button is shown . Cause it was the last filter set and creating now a new article give them status "trashed":

This is now resolved and only effected Articles, Featured, Messages and Notes view models. Thanks

I have tested this item ✅ successfully on 35cde2e

@infograf768 always objected in the past to removing buttons and any attempt at progressive disclosure of toolbar functions

Joomla has a long history of bad UX decisions. It's time to move on.

Empty state design is now a part of joomla 4. It should minimise everything on the screen to guide a user to a CTA, which is nearly always to create something with a new button, or to get help/documentation on what the future is

It is not really progressive disclosure, because as soon as you have one of an item, the empty state is removed revealing the full interface. If we really did have progressive disclosure of toolbar patterns, then there would never be any grayed out buttons, they would appear when they could be used in context

I have tested this item ✅ successfully on 35cde2e

RTC

@PhilETaylor This PR here has now a merge conflict in file administrator/components/com_tags/src/View/Tags/HtmlView.php after your other PR #33286 has been merged. I could try to solve that, but I think it's better if you do that since you are author of both PR's, this here and the other one.

No worries - I was expecting conflicts as each PR was designed to be standalone and contain everything they needed to function, for ease of testing and acceptance. I'll fix this one up now.

Previous tests and RTC are still valid since the 2 commits after the tests were only a clean update of the branch to the upstream 4.0-dev branch plus a code style fix.

Thanks