IS this for front end article creation?

Currently you can create a menu item "Create Article" and set that to be restricted to a single specified category. I am guessing that something like that would work for you if this was a multiple category select and not a single category?

Yes, for frontend article creation. The particular site layout uses categories (one per date) for allowing low-experience planners to create tiny articles for activities that are scheduled for a particular date within a multi-day event; there can be multiple activities per day. The event defines the top-level category, and each date of the event is a subcategory. When creating a new article, it is desired to present the writer with the category from whence "NEW ARTICLE" was clicked and all its subcategories as the only options for saving (publishing) the article. Since most of these folks have permission to edit articles in many other categories, the list can be very long and it can be difficult to find the right "date" (in this case).

These writers only have category/subcategory list pages to work with. When nobody has entered an article yet, there is only the "NEW ARTICLE" button at the main category. So that's all they can click. In the editor then, they select the date (subcategory) into which they want their new article to be published.

As a temporary solution, all the date subcategory titles begin with the date in YYYY-MM-DD format, so they can just start typing the date to find their subcategory quickly. But that is the only way I could figure to make it somewhat easier for them. Having a dedicated "Create Article" menu item would result in many, many such menu items. So I consider that a sub-par solution.

Thanks!

If you have a create article menu item (even hidden) then as far as I remember this is used on ALL the new article links. not at my pc to check

Well, I don't consider that a good enough solution since the top-level category can change on a weekly basis and there may also be multiple such events being planned at any given time. So a single, very specific category-targeted link is not the answer IMHO.

Nonetheless, I will see if that works and maybe (just maybe) there's a solution in there somewhere. Perhaps what you mean is a menu item per such top-level category? If so, I can make that work. I'll post back here with my discovery.

Thanks, Brian. Always learning something new with Joomla!. :)

UPDATE: Nope. That did not work. At least its mere existence did not work. Perhaps there is a way to link that menu item to all those NEW ARTICLE buttons that is not automatic?

As a better or additional alternative, I am now showing empty subcategories, which means all the date subcategories do appear whether they have any activity (mini articles) in them yet or not. This should suffice, but I still think limiting the categories available for creating a new article in a category or one of its subcategories should be possible.

Might just be me but this sounds like a very unique and site specific requirement

At some point (pretty soon) there will be hundreds of subcategories for these inexperienced authors to choose from. It would almost be better to remove the ability to choose since saving their article in the wrong place would likely make it impossible to find. I don't think it's site-specific, but I certainly do need it for this specific site.

Here's how I resolved the issue. I consider this a workaround, but it's a decent one. This post may work more as a "food for thought" kind of message.

I created a category list module positioned in the left sidebar. This shows on the page for the top-level category list menu item. (Note that none of the articles in this category or its subcategories will ever be associated directly with a menu item.) I setup the category list menu item to show empty subcategories and not mention empty categories. It looks weird at first seeing the list both in the left sidebar and down the middle of the page, but that list remains in sight (on the left) even if the writer descends into one of the date subcategories and starts editing an article there. The negative aspect of this is it could tempt them to click on another date subcategory on the left before properly closing the editor.

Keep in mind that these folks should never create an article in the top-level category, and there's really no way to prevent that since making that category not-writable propagates into all its subcategories. Perhaps I could hide the NEW ARTICLE button just on that page with CSS? Wouldn't it be nice to have a feature that closes the editor if the user browses away from it within the same browser window?

Although this does not resolve the original issue, it creates an environment in which it is unlikely they would ever have to search that entire list of categories (on the Publishing tab) when creating their article. They will simply start in the right subcategory and not have to think about it as the editor will default to saving in that subcategory. This trickery is not without its faults, but I can't figure another way that would be.

Pull Request for Issue #46748

Summary of Changes

This PR implements a category visibility constraint feature that allows site administrators to limit the category dropdown in article editing forms to show only a specific category and its subcategories.

Changes:

• Add scope_root parameter to CategoryeditField for filtering categories using nested set model
• Update HtmlView to pass category scope from menu params to the article form
• Add limit_category_scope option to Create Article menu item configuration
• Add language strings for new parameter (en-GB)
• Implements nested set filtering (lft/rgt) for efficient category dropdown filtering
• Improves usability for sites with many categories

Files Modified:

• administrator/components/com_categories/src/Field/CategoryeditField.php - Core filtering logic
• components/com_content/src/View/Form/HtmlView.php - Pass scope parameter
• components/com_content/tmpl/form/edit.xml - Menu item configuration
• administrator/language/en-GB/com_content.ini - Language strings

Testing Instructions

1. Setup test environment:

   • Create a category hierarchy: "Events" (parent) → "Day 1", "Day 2", "Day 3" (children)
   • Create other unrelated top-level categories (e.g., "News", "Blog")

2. Create menu item with scope limiting:

   • Navigate to Menus → Main Menu → Add New Menu Item
   • Menu Item Type: Articles → Create Article
   • Set "Specific Category" to Yes
   • Choose "Events" category
   • Set "Limit Category Scope" to Yes (new option)
   • Save

3. Test frontend article creation:

   • Navigate to the menu item on the frontend
   • Click to create a new article
   • Open the Category dropdown
   • Verify: Only "Events", "Day 1", "Day 2", "Day 3" appear
   • Verify: "News", "Blog" and other categories do NOT appear

4. Test with scope limiting disabled:

   • Edit the same menu item
   • Set "Limit Category Scope" to No
   • Navigate to frontend and create article
   • Verify: All categories appear (default behavior)

5. Test permission interaction:

   • Create a user with limited category permissions
   • Verify: Both permission filtering AND scope filtering apply (intersection)

Actual result BEFORE applying this Pull Request

When creating articles via a "Create Article" menu item:

• The category dropdown shows ALL categories the user has permission to edit
• On sites with hundreds of categories, this creates a very long, unwieldy dropdown
• Users must scroll through many irrelevant categories to find the correct one
• High risk of selecting the wrong category
• Poor user experience for content editors

Expected result AFTER applying this Pull Request

When creating articles via a "Create Article" menu item with "Limit Category Scope" enabled:

• The category dropdown shows ONLY the menu item's selected category and its subcategories
• Significantly shorter, more manageable dropdown lists
• Editors can quickly find and select the appropriate category
• Reduced cognitive load and faster article creation
• Improved user experience, especially for sites with large category hierarchies

Backwards Compatibility:

• Feature is optional and defaults to disabled
• Existing menu items are unaffected
• No breaking changes

Link to documentations

Please select:

• Documentation link for docs.joomla.org: (Documentation PR to be created after merge)

• No documentation changes for docs.joomla.org needed

• Pull Request link for manual.joomla.org: (Manual PR to be created after merge)

• No documentation changes for manual.joomla.org needed

  ---

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