[6.2] Include archived categories in edit and batch dropdowns

[hiteshm0]

Pull Request for Issue #46701

Summary of Changes

This PR fixes issue #46701 where archived categories were not selectable in article edit and batch operation dropdowns. And prevents category from resetting to first available non-archived category when editing articles assigned to archived categories.

Testing Instructions

First Test:

1. Create an article.

2. Verify that archived categories can be assigned to the article.

3. Assign a archived category to the article.

4. Edit the article

5. Verify that the category of the article has not been auto assigned to the first available non-archived category.

Second Test:

1. Select 3-4 articles -> actions -> batch
2. Verify that archived categories are present in the 'copy or move to category' dropdown

Third Test:
Verify that categories can be assigned archived categories as their parents

NOTE: If a published/unpublished category is assigned an archived category as its parent, then those categories also become archived.

Actual result BEFORE applying this Pull Request

1. When editing an article assigned to an archived category, the category dropdown did not show the archived category.
   If the category of an article was archived then, it would be changed to an available non-archived category upon editing the article.

2. Archived categories were not listed in the batch "Select Category for Move/Copy" dropdown

3. Cannot assign archived categories as parent to other categories.

Expected result AFTER applying this Pull Request

1. Category drop-down when editing an article shows archived categories. Archived categories assigned to articles don't get swapped for non-archived categories

2. Archived categories are listed in batch "Select Category for Move/Copy" dropdown.

3. Archived categories can be assigned as parent to other categories

Link to documentations

Please select:

• Documentation link for docs.joomla.org:

• No documentation changes for docs.joomla.org needed

• Pull Request link for manual.joomla.org:

• No documentation changes for manual.joomla.org needed

[brianteeman]

i wonder why we have never been able to do this before. As far as I can tell the behaviour has been this way for at least 8 years and probably longer

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46706.}

[hiteshm0]

@brianteeman
It is definitely possible that the BEFORE of this PR was intended, considering the archived = finished / don't assign anything more here philosophy.
And this PR solves the problem of not being able to assign archived category for a new article( or as parent to a different category ) , which might be a very small use case while introducing new dropdown elements ( confusion ) to every user.

But it fixes the bug where an archived category would get swapped out for the first available non-archived category which is an improvement.

Would be glad to hear some advice on how to progress with this further.

[chmst]

I have two categories:
jobs (alias: jobs-archived)
jobs (alias: jobs)

The user does not see which category to choose.

In category edit view, the archived category is marked with [..].

[peterhulst]

@chmst In category edit view [jobs] means: unpublished instead of archived. Archived categories are not visible in this view. Archived categories are also not visible in batch process of categories.

[peterhulst]

@hiteshm0 I have tested 5ced8fa
it succesfully in Joomla 5.4.2.

[chmst]

@peterhulst you also have to think about side effects. For batch process, the result is not acceptable.
@hiteshm0 could you enclose archived categoriesl in brackets also in the dropown for batch process?

[hiteshm0]

@chmst yes, i am working on it right now.
both unpublished and archived categories will be enclosed in brackets in the dropdown for batch process ( same as category edit view )

[hiteshm0]

@chmst non-published categories should now have brackets around them in the batch operations dropdown.

[chmst]

Thank you @hiteshm0 for the change, but this is not what we do in Joomla. We separate data and presentation layer.
No database queries in layouts.
You could add the published field into the categories (this means change the categries model) so it is available in the layout.

Another solution would be: Let the code as it is now, filter = 0, 1.
Then make an new select with filter = 2. This gives the arcived categories.
Build the final drop down in two parts - first the published categories as it is now,

then append '- archived categories -' (use a language key)
and the all the archived categories.

This seems less confusing than having prublished and archived categories mixed in a dropdown.

[peterhulst]

@hiteshm0 and @chmst 👍

I have checked e580fa5 and it works as expected.

Proposal:
To overcome the comment of @chmst instead of [] for both unpublished and archived categories, the archived categories can be enclosed with {} instead [] (or something else: - archived categories -' (using a language key))

The code change in the latest modification is easy:
in item.php
if (isset($publishedStates[$catId]) && $publishedStates[$catId]->published != 1) {
$option->text = '[' . $option->text . ']';
}

Change to:

if (isset($publishedStates[$catId]) && $publishedStates[$catId]->published == 0) {
    $option->text = '[' . $option->text . ']';
}

if (isset($publishedStates[$catId]) && $publishedStates[$catId]->published == 2) {
    $option->text = '{' . $option->text . '}';
}

And in components\com_categories\src\Field\CategoryeditField.php:

        if ($option->published == 1 ) {
            $option->text = str_repeat('- ', !$option->level ? 0 : $option->level - 1) . $option->text;
        } 

Change to:

        if ($option->published == 1 ) {
            $option->text = str_repeat('- ', !$option->level ? 0 : $option->level - 1) . $option->text;
        } 			
		elseif ($option->published == 0) {
			$option->text = str_repeat('- ', !$option->level ? 0 : $option->level - 1) . '[' . $option->text . ']';
		}
		elseif ($option->published == 2) {
			$option->text = str_repeat('- ', !$option->level ? 0 : $option->level - 1) . '{' . $option->text . '}';
		}

        // Displays language code if not set to All
        if ($option->language !== '*') {
            $option->text .= ' (' . $option->language . ')';
        }

Regards,
Peter

[hiteshm0]

@peterhulst your proposal definitely works but as mentioned by @chmst it is not in joomlas practice to do database queries in layouts, so the solution will become quite complicated.

[chmst]

@hiteshm0 The proposal of @peterhulst means that you can remove the database access. You need only the extra line for archived categories.
But then we have two or three database queries instead of one.

Layout: At the moment, there is no difference for published and unpublished categories - but could be interesting.
What would you expect as administrator if you have hundreds of categories?
Would be nice to have more opinions - @brianteeman

[brianteeman]

if we dont display any difference between published/unpublished categories then I wouldnt expect any visual difference with archived

[brianteeman]

If archived is going to be displayed in the select lists then should it also be displayed in the list views. Currently archived is only displayed in the status filter is set to all

[brianteeman]

i dont understand why this is labelled a b/c break. Nothing breaks you just get extra functionality

[hiteshm0]

@brianteeman its most probably labelled as a b/c break, because in the batch operations dropdown there is no difference in the way archived and published categories are shown ( even unpublished categories are shown without any brackets ).
I am working on a fix for this right now

[brianteeman]

That doesn't constitute a breaking change

[hiteshm0]

quite a bit of duplicate code in CategoryeditField.php

[brianteeman]

a and u might make sense in english but who knows about all the other supported languages. The words might start with the same letter

[ot2sen]

a and u might make sense in english but who knows about all the other supported languages. The words might start with the same letter

Indeed that is the case for more languages. Danish would be (A) arkiveret and (A) afpubliseret.

[crimle]

I have tested this item ✅ successfully on 1dee2b8

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46706.}

[JeroenMoolenschot]

I have tested this item ✅ successfully on 1dee2b8

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46706.}

[HLeithner]

Please use a long language string for archived and unpublished in barracks, I think it could already exist.

[muhme]

I have tested this item ✅ successfully on 163c0fa

Tested with JBT all three test cases, seen the problems before and the correct behavier after applying the PR with POatch Tester.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46706.}

[krishnagandhicode]

I have tested this item ✅ successfully on 163c0fa

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46706.}

[muhme]

RTC

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46706.}

[richard67]

@HLeithner Could you check if your requested change (see #46706 (comment) ) has been implemented like you suggested, and if yes, either dismiss your change request or approve the code changes)? Thanks in advance.

[HLeithner]

I only checked the changed language string and since JARCHIVED has been used, it's the long version, so it should be fine. I think that can go into 6.2 @MacJoom @charvimehradu

[hiteshm0]

should i rebase this to 6.2 ?

[HLeithner]

This pull request has been automatically rebased to 6.2-dev.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[richard67]

@hiteshm0 I've allowed myself to fix the conflicts in file libraries/src/HTML/Helpers/Category.php, which were caused by the recently merged PR #47481 . That PR has removed duplicate code. Your PR made the same changes in 2 places, one of them was the code being removed by that other PR. This caused a conflict for git. The resolution was to simply completely accept the changes from the other PR.

[MacJoom]

Thank you!