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.

Same problem as with the original PR

#40172 (comment)

#40172 (comment)

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.

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.

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)

I have tested this item 🔴 unsuccessfully on 57f76ab

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.}

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?

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

That way.

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

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

@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!

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

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.

@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.

As the bug appears everywhere I would go for option 1

@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!

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.

@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?

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.

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.

@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?

@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.

@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.

@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.

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.}

@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.

I have tested this item ✅ successfully on dd35a3e

This issue is fixed. I had tested successfully.

@Vineet7875 Thanks

I have tested this item ✅ successfully on dd35a3e

I have tested with 2 articles
Articles that will be published in future and articles that are expired

@tekvishal Thanks

@HLeithner @richard67 @brianteeman

I posted some questions 2 weeks ago about the best implementation approach, but haven't received guidance yet. The PR is getting successful tests from the community, but I want to make sure the architecture is correct before proceeding.

Current status:

• 3 successful community tests (webmasterab, Vineet7875, tekvishal)
• All automated tests passing
• No breaking changes detected
• Awaiting architectural guidance

Question: Should I:

1. Keep the current opt-in approach (respectPublishDates option)?
2. Refactor to use table objects with getColumnAlias()?
3. Make it fully automatic without the option?

I'm happy to refactor based on your preferred architecture pattern. Just need direction on which approach aligns best with Joomla's standards.

The bug is real and affects users - I want to fix it the right way.

Thanks!

Question: Should I:

1. Keep the current opt-in approach (`respectPublishDates` option)?

No.

2. Refactor to use table objects with `getColumnAlias()`?

Yes.

3. Make it fully automatic without the option?

Yes.

@HLeithner Feel free to correct me if I did get something wrong.