Marked as draft as will require conflicts to be resolved once the great work from @Bakual in #33288 is merged.

I'll revisit it after that.

Ok I have now refactored this to use the new layouts from @Bakual and its ready for testing again. Thanks.

You've beat me to it. But the solution you have chosen is the one that came to my mind as well ?

When testing the categories part with my component, I've got a few issues due to the fact that my categories have sections (eg "com_sermonspeaker.sermons"). You've assumed that "$extension" is always the component.
I'll see if I can fix that and do a PR to your branch.

Good catch - thanks. This is why Categories is slightly different to say Articles, as the db table is "reused" for many different reasons.

Did a (messed up) PR with some discussion points in it.
I'll have to go watch a movie with my wife now ?

Thanks - I'll merge it then Im off for the night too - thanks for your help on these blank slates... next week we can work on the FTP Layer together hahhahahahahhaahhhahah

Rebased on 4.0-dev and force pushed to resolve conflicts :)

Tags, private messages, news feeds, etc. are missing titles.

This PR is only for Tags and Categories.

Im marking this as draft as it makes no sense to test it until the rename of the feature is merged.

Lets get #33334 merged and then I will revisit this PR, to change everything to make it mergeable with the new names.

PR rebased on 4.0-dev and force pushed after rename from Blank Slate to Empty State globally. Ready for test/merge again now

Final screenshots.

The Rebuild button is not disabled and clicking it displays the following warning:

yup on that currently -thanks

Now like this, and I'll work through the others.

I actually wouldn't hide those buttons with this PR.
It's unrelated as they also are not hidden when there are no items shown due to active filters or because they're trashed.

So you can hide it, but don't do it with this PR to keep it on one topic.

Its a blank slate - empty state - EVERYTHING should be hidden except the NEW and Learn more tasks - everything else goes against the concept of an empty state design.

So you can hide it, but don't do it with this PR to keep it on one topic.

Give me 5 mins to complete it :) but this one in this PR can stay as the categories/tags views have not yet been merged :)

If you want to hide all buttons, just hide the toolbar completely (like done in modals). The new button is redundant anyway ?

If you add more to this PR, chances get lower that it gets merged soon. The more is in it, the more work is it to test and review.

If you want to hide all buttons, just hide the toolbar completely (like done in modals). The new button is redundant anyway

The tool bar looks crap without a New button and just nothing. I did consider hiding the whole tool bar.

If you add more to this PR, chances get lower that it gets merged soon. The more is in it, the more work is it to test and review.

All the other changes are in a different PR - this PR is done and I plan no more changes here.

The tool bar looks crap without a New button and just nothing. I did consider hiding the whole tool bar.

Forget that suggestion. Hiding it would also hide the "Options" and "Help" buttons, which would be bad.

Actually, the "Rebuild" button works also for cases where Empty State is active. Because it works on the whole table, not only for the selected extension. So I would not hide it.

Actually, the "Rebuild" button works also for cases where Empty State is active.

Move that commentary to #33380, but let me check if rebuild is the whole table, or a subset of the table.

edit: rebuild seems to "rebuild the entire nested set tree" gulp.

But again, its an EMPTY STATE, you are trying to guide the user to their next step. A users next step on seeing an empty state is NOT to think "I need to rebuild"... so it makes sense to hide it to fulfil the purpose of the state.

On an EMTPY STATE, Options Help and New are all I believe are valid buttons.

I actually don't care much about the buttons. I just fear that this PR will get delayed if you pack more stuff into it.

Feel free to test it :) Im not adding more to it now

Maybe tomorrow, to tired for today :-)

I have tested this item ✅ successfully on 4895ce5

I've tested this PR successfully also with my own component. So the categories view also works fine with 3rd party extensions and also with categories that use the component.section format.

Also the tags view works fine.

There are two things I think could still be improved, but it's not a bug by itself.

• This PR already partly (for com_categories, but not for com_tags) contains changes from #33380. This should be in the scope of the other PR so in case the change doesn't get accepted or delayed we still have a consistent behavior.
• The messages on the categories view are not consistent with the messages on other views. Where the title for other views is like "No Items have been created yet.", it is "Item Type: Categories" here. And for the message it is the same: While for other views it is a description about the purpose of the item type, for categories it's just "There are currently no categories for this extension."

This PR already partly (for com_categories, but not for com_tags) contains changes from #33380. This should be in the scope of the other PR so in case the change doesn't get accepted or delayed we still have a consistent behavior.

Im actively working on all Empty States and see no reason why they should be delayed. It would be stupid of the maintainers now to start rejecting them now that some have already been merged, because we have been working fast you are right, there is some overlap so that each PR can stand alone and be merged alone. As each is merged, I revisit all the others to ensure al the merge conflicts and dependancies are met.

Where the title for other views is like "No Items have been created yet.", it is "Item Type: Categories" here.

This is because we reuse the language strings - for example for your extension we would not know what to put as the title so its kept generic and reuses the existing language strings.

While for other views it is a description about the purpose of the item type, for categories it's just "There are currently no categories for this extension."

Again this was left generic, because I dont know why you are using categories in your extension. I could say "Categories are a way of categorising your articles" but then it would be wrong for User Notes for example.

So generally totally agree with you - but with the above notes the PR is acceptable I think.

I have tested this item ✅ successfully on 4895ce5

RTC

This is because we reuse the language strings - for example for your extension we would not know what to put as the title so its kept generic and reuses the existing language strings.

Yep I know, but since we already load language strings from the 3rd party component now, we could as well check for a new string instead of the ones we check now. And fall back to a generic one if none is present. It doesn't necessary has to be the existing one.
The same applies to the message strings.

As I wrote, it's not a bug. Just some thoughts how it could be improved further ?

Thanks