[6.1] Plugin for category change when a transition is executed for article

[Dileepadari]

Summary of Changes

This PR introduces a workflow plugin that allows setting a category change when a transition is executed for articles.

Testing Instructions

• Confirm that the plugin is enabled by default in Manage Extensions.
• Enable Workflows, then go to any workflow and open its Transitions.
• Edit a transition -> go to the Transition Actions section -> you should now see a Category field.
• Select any category that the article should switch to when this transition executes.
• Open an article that uses the workflow you configured. Execute the transition.
  • The article’s category should update automatically.
  • The article’s category field will be disabled while the plugin is active.

Actual result BEFORE applying this Pull Request

In Extensions when searching for "workflow":

In the Transition Actions section:

Expected result AFTER applying this Pull Request

In Extensions when searching for "workflow":

In the Transition Actions section:

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]

The plugin needs to be added to the list of core extensions here libraries/src/Extension/ExtensionHelper.php

[Dileepadari]

Thank you @brianteeman for review, will update the pr soon with the changes.

[richard67]

It might be that we have to move this to 6.1 as soon as we have created a 6.1-dev branch necause 6.0 has already had feature freeze with 6.0.0-beta1.

[Dileepadari]

Thanks @brianteeman and @richard67 for the review. I’ve made all the suggested changes. I really appreciate your time and feedback.

[richard67]

@Dileepadari Now you have produced invalid SQL syntax in the update SQL scripts by using only a part of administrator/components/com_admin/sql/updates/mysql/6.0.0-2025-08-02.sql.

The correct syntax is (exmaple from the mentioned other SQL):

INSERT INTO `#__extensions` (`package_id`, `name`, `type`, `element`, `folder`, `client_id`, `enabled`, `access`, `protected`, `locked`, `manifest_cache`, `params`, `custom_data`, `ordering`, `state`)
SELECT 0, 'plg_schemaorg_article', 'plugin', 'article', 'schemaorg', 0, 0, 1, 0, 1, '', '{}', '', -1, 0
WHERE NOT EXISTS (SELECT * FROM `#__extensions` e WHERE e.`type` = 'plugin' AND e.`element` = 'article' AND e.`folder` = 'schemaorg' AND e.`client_id` = 0);

It is an INSERT INTO ... SELECT ... statement which should not have a VALUES key word.

Your statement has still VALUES but no SELECT.

This will result in an SQL syntax error.

So it seems you did not check your SQL e.g. in phpMyAdmin.

[bembelimen]

Thank you @Dileepadari this is a very nice addition to the workflow 👍

[Dileepadari]

Hi @richard67, sorry for that. Can you let me know how can i test with PhpMyAdmin. Should I replace the #__extensions with the table name including table prefix?

[richard67]

Hi @richard67, sorry for that. Can you let me know how can i test with PhpMyAdmin. Should I replace the #__extensions with the table name including table prefix?

That would be one way to test it on the current Joomla installation.

Another way would be to copy the CREATE TABLE statement from the base.sql and use it as it is to create an #__extesions table without the suffix to be replaced, then you could fiddle with SQL in that table without having to replace the prefix in your SQL statement and without messing up the table from the Joomla installation.

And when developing database stuff for Joomla it is a good idea to have a PostgreSQL database in addition to the MySQL (or MariaDB).

[Dileepadari]

Thanks for the info, it helps a lot in testing quickly.

[brianteeman]

thanks for adding the filter etc

[HLeithner]

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