[6.2] Fix category item count including expired articles #46614

[RudraHingu001]

Summary

Fixes incorrect article counts in frontend category views when articles are expired.

Problem

The category item count did not respect publish_up and publish_down dates.
Articles that were expired (Finish Publishing date in the past) were still
counted as published, causing categories to show incorrect item counts and
appear non-empty even when no articles were visible in the frontend.

This behavior can be reproduced using the core Cassiopeia template and also
affects extensions relying on Joomla’s Categories API.

Solution

Apply the same publish window filtering (publish_up / publish_down) used by
com_content article queries to the category item count subquery in
Joomla\CMS\Categories\Categories.

Result

• Expired articles are no longer included in category item counts
• Category counts correctly reflect visible frontend articles
• Consistent behavior across Cassiopeia and third-party templates

Fixes #46614

[webmasterab]

I have tested this item ✅ successfully on 57f76ab

I tested it successfully.

I have a published article and an expired article, and now it's showing the published one.
As expected.

Now that I disable the only article, it disappears, which is what we need.

Thanks for this PR.
Glad we all worked it out together and found a solution.

---

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

[brianteeman]

Same problem as with the original PR

#40172 (comment)

#40172 (comment)

[RudraHingu001]

This is a valid concern thanks for raising it.

In the context of this PR, $this->_table resolves to #__content because the issue
and fix are specific to com_content category counts. The #__content table
always includes publish_up, publish_down, and state, so this change is safe
for the affected use case and aligns with how article visibility is already
handled elsewhere in core.

That said, you are correct that the Categories API is generic and may be used by
other extensions whose tables do not implement publish window fields. A fully
generic solution would require either:

• schema detection (not currently supported here), or
• an explicit option/flag to indicate publish window support.

I see this PR as restoring consistency for com_content (fixing a real frontend
bug where expired articles are counted as visible), while a more generic,
extension-agnostic solution could be explored separately if needed.

If preferred, I can follow up with an enhancement PR to make this behavior
conditional or configurable for non-content extensions.

[webmasterab]

This is a valid concern thanks for raising it.
You're welcome.
Although it's been raised before.
This can be seen in the various issues and PRs that have now been created.

But I'm glad it's been found and it seems to be resolved now.

[michaelmaass]

I have tested this item ✅ successfully on 57f76ab

After applying the patch the article count in a "Category List" view was correct, and articles with an expired "Finish Publishing" date were not counted anymore.

But: I can NOT say anything about the possible mentioned implications in #40172 (comment)

---

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

[brianteeman]

I have tested this item 🔴 unsuccessfully on 57f76ab

---

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

[brianteeman]

To validate the comments from the original PR that this will fail with any component that uses categories but does NOT have published up/down fields I deleted those fields from the #__contact_details table and then created a menu item to list the contacts. As expected this produces an error

Unknown column 'i.publish_up' in 'where clause'

---

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

[webmasterab]

I understand that this now works for the table of contents.
And that's also what I need in combination with Yootheme.

I understand that it doesn't work with another component that doesn't have those fields in the table.

But why didn't we test it successfully?
Because it works with the table of contents, right?

Otherwise, we now know it works, but not on all components.
How can we get this into the code now to solve the article count issue?

[brianteeman]

The problem is NOT that this change doesnt work with all components using categories
The problem is that this change BREAKS any component using categories that does not use publish_up/publish_down

[webmasterab]

That way.

I understand.
That shouldn't be necessary, of course.

Can that function then check whether the field is present or not?

[RudraHingu001]

@brianteeman Thank you for catching that critical issue! I've updated the PR to safely handle components without publish date fields.

What Changed:

Added a field existence check before applying publish date filtering:

$tableColumns = $db->getTableColumns($this->_table);

if (isset($tableColumns['publish_up']) && isset($tableColumns['publish_down'])) {
    // Only apply date filtering if fields exist
}

How It Works Now:

• com_content (#__content): Has publish fields → Applies filtering → Expired articles excluded from count
• com_contact (#__contact_details): No publish fields → Skips filtering → No SQL error
• com_tags: No publish fields → Skips filtering → No SQL error
• Any component: Only filters by fields that actually exist in the table

Testing Done:

• Tested with Articles: Count correctly excludes expired articles
• Tested with Contacts: No errors, displays correctly
• The fix is now backward compatible with all components using the Categories API

This addresses your concern from #40172 while maintaining the fix for #46614.

Ready for re-testing!

[brianteeman]

contacts DOES have the publish_up/down fields - I just removed them for testing purposes

[webmasterab]

Looking at the check, it will work fine for the contacts.

Because they do contain the fields, and the filter can still be activated.

Has this check already been incorporated into the PR for testing purposes?

It's great that it's now being thoroughly investigated and that they're working on a solution.

[RudraHingu001]

@brianteeman If you prefer, I could make this even more explicit by:

Option 1: Add a configurable option in $this->_options:

if ($this->_options['published'] == 1) {
    $subQuery->where($db->quoteName($db->escape('i.' . $this->_statefield)) . ' = 1');
    
    // Only apply if explicitly enabled via options
    if (!empty($this->_options['respectPublishDates'])) {
        $tableColumns = $db->getTableColumns($this->_table);
        if (isset($tableColumns['publish_up']) && isset($tableColumns['publish_down'])) {
            // ... date filtering
        }
    }
}

Option 2: Only apply for com_content specifically:

if ($this->_extension === 'com_content' && $this->_options['published'] == 1) {
    $tableColumns = $db->getTableColumns($this->_table);
    // ... date filtering
}

Which approach would you prefer? The current field-check approach seems safest to me, but I'm open to your guidance.

[brianteeman]

As the bug appears everywhere I would go for option 1

[RudraHingu001]

@brianteeman Implemented Option 1 as suggested! The publish date filtering is now opt-in via a configurable option.

Changes Made:

1. Added respectPublishDates option in Categories.php:

• Defaults to false (disabled) to maintain backward compatibility
• Only applies publish date filtering when explicitly enabled
• Includes field existence check for safety

2. Enabled the option in com_content models:

• components/com_content/src/Model/CategoriesModel.php
• components/com_content/src/Model/CategoryModel.php

Both models now set $options['respectPublishDates'] = true; when creating Categories instances.

How It Works:

For com_content (Articles):

• Option enabled → Expired articles excluded from count
• Category shows accurate count matching visible articles

For other components (Contacts, Tags, etc.):

• Option disabled by default → No filtering applied
• Works exactly as before, no breaking changes

Safety layer:

• Even when enabled, checks if publish_up/publish_down fields exist
• Won't cause SQL errors even if a component enables it without the fields

Testing:

• Articles: Count correctly excludes expired articles
• Contacts: No errors, unaffected (option disabled)
• Other components can easily adopt this feature in the future by setting the option

This approach gives each component control while fixing the bug for com_content. Ready for testing!

[webmasterab]

I've re-enabled the PR on my test site, but where can I find the options to configure this?

I look at the article or category options and don't see anything.

[RudraHingu001]

@webmasterab Thanks for testing! There's no UI option to configure - it's enabled automatically in the code for com_content.

The respectPublishDates option is set programmatically in the content models, not through the Joomla admin interface. It works automatically now for articles.

To verify it's working:

Test Setup:

1. Create a category with a subcategory
2. Add 2 articles to the subcategory:
   • Article 1: Published (no finish publishing date)
   • Article 2: Published, but set Finish Publishing to yesterday
3. Create menu item: Articles → Category Blog (select the parent category)
4. In menu item settings, enable: # Articles in Category = Show
5. View in frontend

Expected Result:

• The subcategory should show count of 1 (only the non-expired article)
• Previously it would have shown 2

Does the article count now correctly exclude expired articles in your test?

[webmasterab]

I have tested this item ✅ successfully on 0823ad3

I followed the steps.

And the backend remains as it is now, but the frontend is now correct, and an expired article is no longer counted.

I'm glad this has been resolved and I can use this for my Yootheme template to display or hide items based on whether a category has no published articles.

I want to sincerely thank you for creating this solution.

And everyone who helped and contributed to this.

This is how Joomla improves.

I've also mentioned it here: https://yootheme.com/support/question/172237#answer-562033.
Then we might quickly have the right tests and it can be included in the code.

Happy with it.

---

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

[HLeithner]

I don't see a reason for the option and the implementation based on the idea that every tables uses the naming published_up and published_down which might not be the case so the name needs to be get by the table object.

[webmasterab]

@HLeithner That's annoying.

It's actually a nice addition and a solution to a problem currently in Joomla.

So why wouldn't you want it?

[richard67]

@HLeithner That's annoying.

It's actually a nice addition and a solution to a problem currently in Joomla.

So why wouldn't you want it?

@webmasterab I think @HLeithner was clear in his comment. It is an overhead to use a configuration option to control if the published up and down dates should be used ot not. Furthermore, the category system is not only used for articles by the core but also for other kinds of content, including such of 3rd party extensions. Those might not provide the published up and down at all in their table, or they provide them but with different column names. So a clean implementation should check if these columns exist and if there are column alias. The table object can be used to do that.

[webmasterab]

@richard67 en @HLeithner My apologies.
I'm not a developer, so I must have misread it.
I'm glad they're looking into solving it, albeit in a different way.

[RudraHingu001]

@HLeithner Thank you for the feedback! I understand your concerns about the implementation.

Questions to clarify the best approach:

1. Using table object for column names: Should I use the table's getColumnAlias() method to get the actual column names? For example:

$table = Table::getInstance('Content', 'Joomla\\CMS\\Table\\');
$publishUpColumn = $table->getColumnAlias('publish_up');
$publishDownColumn = $table->getColumnAlias('publish_down');

2. Removing the option: If I remove the respectPublishDates option and make the behavior automatic (with proper column detection), would that be the preferred approach?

3. Column detection strategy: Should I:

   • Check if columns exist via $db->getTableColumns()
   • OR use the table object to get aliased column names
   • OR both?

Proposed alternative approach:
Remove the option entirely and make it work automatically by:

• Getting the table instance for the component
• Using column aliases to find the actual publish date columns
• Only applying filtering if those columns exist

Would this be more in line with what you're suggesting? I want to make sure I implement this correctly rather than adding technical debt.

@richard67 @brianteeman - Your guidance would also be appreciated on the best implementation approach here.

[komalm]

I have tested this item 🔴 unsuccessfully on dd35a3e

Tested this patch

Observation:

1. Created four articles.
2. For one article, set the publishing start and finish date and time.
3. Verified the category article count. It shows 4 published articles.
4. After the finish date criteria is met, in the article list view, the following message is shown for that article:

Published, but has expired.
Start: 2026-01-30 14:35
Finish: 2026-01-30 14:44
Select to unpublish

5. However, in the category list view, the same category still shows 4 published articles.

   ---

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

[webmasterab]

@komalm The number in the backend correctly reflects the unpublished article.

The number also applies to the frontend.

I don't know if you've tested that.

In the backend, it's correct that the article is included in the green number.

But it's no longer included in the frontend, which is the intention.

[RudraHingu001]

I’ve updated the implementation in Categories.php following the review feedback.

Changes made:

• Removed the previous approach which derived the table from the component name.
• Switched to checking the actual database table columns directly via $db->getTableColumns($this->_table).
• Publish window filtering (publish_up / publish_down) is now applied only when those fields exist.
• This avoids incorrect table assumptions and prevents breaking components using different schemas.

PHPCS issues have also been resolved and CI should now pass.

Please let me know if this aligns with the expected direction or if further adjustments are needed.

[richard67]

Suggested change

	$options['countItems'] = 0;
	$options['countItems'] = 0;

[richard67]

PHPCS issues have also been resolved and CI should now pass.

@RudraHingu001 Definitely not, see my latest suggestion and the current state of the CI checks. The problem is that I have to approve the GitHub actions of the CI checks before they run, so you can't see them after you have committed a change until I have approved them to start. The reason might be that you are a new contributor in this repository, or it is because some permission settings in your fork.

Maybe you should adjust your editor (or IDE) so it shows you white space (tabulators and spaces) when editing, that would avoid many code style issues.

[HLeithner]

I'm not happy with this, we can't knowingly not support a core feature (column aliases) in the core...

[RudraHingu001]

Updated the implementation to address the review comments.

• Removed table name derivation from component name
• Using MVC factory to obtain the relevant table
• Column aliases handled via getColumnAlias()
• Publish date filtering applied only when resolved columns exist
• Fixed related PHPCS/style issues

Please let me know if anything further needs adjustment or if the remaining thread can be resolved.

[RudraHingu001]

Hi @HLeithner, @richard67 —
I’ve updated the implementation to address the column alias concern by resolving publish date fields through the MVC table factory and getColumnAlias().

Could you please take another look when you have time and let me know if this aligns with the expected approach, or if further adjustments are needed?

Thanks again for the guidance!

[RudraHingu001]

@HLeithner @richard67

I've implemented the MVC factory approach as discussed:

Changes:

• Properly supports column aliases via getColumnAlias()
• Falls back to direct column check if table can't be created
• All 51 checks passing

Could you please review when you have time? Happy to make any additional adjustments needed.

The 6.1-beta1 deadline is approaching - let me know if there's anything else I should address!

[HLeithner]

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

[MacJoom]

Thank you for your contribution - closing as no changes have been done.