@richard67 what does the drone not like?

look at https://ci.joomla.org/joomla/joomla-cms/62199/1/8

Thanks @sergeytolkachyov for making the suggested changes. There are feedback from others (like change @SInCE tag to DEPLOY_VERSION instead of hardcode to 4.0.0 as how you do at the moment. Please check and make these suggested changes, too.

Thanks @sergeytolkachyov for making the suggested changes. There are feedback from others (like change @SInCE tag to DEPLOY_VERSION instead of hardcode to 4.0.0 as how you do at the moment. Please check and make these suggested changes, too.

Changed to DEPLOY_VERSION

No, the last commit was wrong. Please revert it. The change we were talking about is from this comment https://github.com/joomla/joomla-cms/pull/39931/files#r1119700978 in file Dispatcher.php

In that file, there are several @SInCE 4.0.0 instance. You need to change it, not in the xml file.

No, the last commit was wrong. Please revert it. The change we were talking about is from this comment https://github.com/joomla/joomla-cms/pull/39931/files#r1119700978 in file Dispatcher.php

In that file, there are several @SInCE 4.0.0 instance. You need to change it, not in the xml file.

@joomdonation Should it also be changed in provider.php here https://github.com/joomla/joomla-cms/pull/39931/files#diff-44e083459f57dc01e5ef3c667f23b5f68b004118d1c817ba4d9eef82782cb80dR24 and here https://github.com/joomla/joomla-cms/pull/39931/files#diff-44e083459f57dc01e5ef3c667f23b5f68b004118d1c817ba4d9eef82782cb80dR34 ?

@richard67 Yes please because that is new file/class.

@laoneo @joomdonation In this case the follow exception is trigger, because the module container do not register the HelperFactoryInterface and is expected by the container. What should be a workaround? create a empty helper class?

Exception has occurred.
Joomla\DI\Exception\KeyNotFoundException: Resource 'Joomla\CMS\Helper\HelperFactoryInterface' has not been registered with the container.

@carlitorweb I made PR #40017 to address that. Maybe you can help testing that PR together with this one? This PR depends on #40017 to work.

@joomdonation on it

Okay, that fixed all the problem. The rest look good for me.

I have tested this item ✅ successfully on f1ce9ce

Step 1) I have installed with the patchtester this module.

• Result the error message above. Test NOT successfully

Step 2) I have installed with the patchtester #40017.

• No error message. Test is successfully.

Question: How can I test the operation of the service provider in a simple way for completeness?

@sandewt You can mark your test as success. As this PR depends on #40017 , there is no simpler way to test.

there is no simpler way to test.

With Postman ?

@sandewt Sorry, I don't understand your last question. I don't think Postman is related here, how it could be used to test a PR ?

Sorry, I don't understand your last question.

I thought I could test the functionality of provider.php and the dispatchter.php that way.

@sandewt I don't use PostMan but I think that tool allows sending http requests and receive response. It could not be used to test Joomla PRs.

I don't use PostMan but I think that tool allows sending http requests and receive response.

This is correct.

Actually, I don't understand the advantage of these two files of the new Joomla structure. I would like to know.

[EDIT can I find some documentation?]

Actually, I don't understand the advantage of these two files of the new Joomla structure. I would like to know

That belong to a module with new structure. Unfortunately, we do not have documentation for that at the moment. It takes sometime to read the internal code to understand exactly how it really works (not easy, I must say). So if you want to develop a module using the new structure, the easiest way would be copy code of an existing module and modify it.

Hope we will have detailed documentation for developer in some days.

I have tested this item ✅ successfully on f1ce9ce

RTC

Note the order!

NOT common in Joomla, applied here in this PR

// phpcs:disable PSR1.Files.SideEffects
\defined('_JEXEC') or die;
// phpcs:enable PSR1.Files.SideEffects

use Joomla\CMS\Dispatcher\AbstractModuleDispatcher;
use Joomla\CMS\HTML\HTMLHelper;

Common in Joomla: use first

use Joomla\CMS\Dispatcher\AbstractModuleDispatcher;
use Joomla\CMS\HTML\HTMLHelper;

// phpcs:disable PSR1.Files.SideEffects
\defined('_JEXEC') or die;
// phpcs:enable PSR1.Files.SideEffects

The question is whether this should still be corrected here?

Sorry, I also noticed that within Joomla it is common in the default.php file to use defined('_JEXEC') or die;

The question is whether this should still be corrected here?

That belong to a module with new structure. Unfortunately, we do not have documentation for that at the moment. It takes sometime to read the internal code to understand exactly how it really works (not easy, I must say). So if you want to develop a module using the new structure, the easiest way would be copy code of an existing module and modify it.

I wrote an article about How to create a Joomla module with new structure. In Russian. https://habr.com/ru/post/684534/

@sergeytolkachyov Would be great if you could contribute to module development documentation at https://github.com/joomla/Manual/blob/main/docs/building-extensions/module.md

@sergeytolkachyov Please rebase for v4.4. Thanks.

See comment: https://github.com/joomla/joomla-cms/pull/39931/files#r1133200382

I have tested this item ✅ successfully on f1ce9ce

@sergeytolkachyov It doesn't make sense to mark a test result for your own PR because that will not count. It is required that the author of a PR has tested his code changes, and the 2 human testers have to be someone else.

Ok

@sergeytolkachyov thank you for your help converting the modules. What would be awesome is when you can add a system test like we did for the other module pr's. Something like I did in #40114. How to get started with system tests can be found in this article https://github.com/joomla/joomla-cms/blob/4.4-dev/tests/System/README.md.

As only code style issues are fixed since the tests and the new custom module system test is passing. I'm going to merge this one. @sergeytolkachyov thank you very much for your contribution. Just a small remark. In the future I would do an independent branch for your next pull request and not directly the 4.3-dev (or any other -dev) branch.

As only code style issues are fixed since the tests and the new custom module system test is passing. I'm going to merge this one. @sergeytolkachyov thank you very much for your contribution. Just a small remark. In the future I would do an independent branch for your next pull request and not directly the 4.3-dev (or any other -dev) branch.

Hello. Thanks for remark. So, how will I do: create fork, then create branch?

Yes, create a branch from the 4.4 branch, which must be identically to the one from this repository.