@BrainforgeUK Could you apply my change suggestions to fix PHPCS? It can be easily done by going to the changed files of your PR on GitHub here https://github.com/joomla/joomla-cms/pull/46054/files and for each suggestion using the button to add it to a batch, and then apply that batch with the button at the top.

@BrainforgeUK Three more suggestions, then I think PHPCS should be ok.

in case you missed it: #46045 (comment)

@BrainforgeUK Code style is ok now. But PHPStan reports errors. You can see them when checking the changed files on GitHub https://github.com/joomla/joomla-cms/pull/46054/files .

@BrainforgeUK It is best practice to create a pr in a branch of your fork. This way it is easier for you to create multiple independent PR to the same branch of Joomla. Just a note for the future

Re - in case you missed it: #46045 (comment)

I agree requiring an extension developer to write installer plugin(s) in order to handle special events returned by their update server is limiting. Hence I have now provided the capability for the update server to return the package in JSON data together with messages and any other useful information.

The Joomla! code changes I propose provide basic handling for this JSON data. If they wish an extension developer can still capture after events and process them in any way they wish. Handling of existing update servers is unchanged. Above I have provided plg_installer_generic.zip which illustrates how these events can be handled.

I called it generic with the view that it may form the basis of something which could be shipped with Joomla! core and enabled or replaced with something developer specific as need arises. Although if, in the unlikely event that, all update servers respond with JSON data such a generic event handler would be redundant!

If the JSON handling part of this proposal is rejected then please leave the events in as I have a use case for them.

Re: https://github.com/joomla/joomla-cms/pull/46054#issuecomment-3271070728

What should I be doing about the PHPstan error - eventawareinterface ?

Re: https://github.com/joomla/joomla-cms/pull/46054#issuecomment-3271070728

What should I be doing about the PHPstan error - eventawareinterface ?

@BrainforgeUK I don’t know the right solution.

@Fedik Could you advise?

Can ignore that, $app->getDispatcher() will stay. The deprecation is triggered for EventAwareInterface wich also have this method. I think PHPstan got confused.

Aside that, the PR have many other code issues. But before I start complaining we need to agree if this PR is needed. Maybe in some other form as @Ruud68 commented.

I have responded to @Ruud68 comments above.
https://github.com/joomla/joomla-cms/pull/46054#issuecomment-3271808514

Re - in case you missed it: #46045 (comment)

I agree requiring an extension developer to write installer plugin(s) in order to handle special events returned by their update server is limiting. Hence I have now provided the capability for the update server to return the package in JSON data together with messages and any other useful information.

The Joomla! code changes I propose provide basic handling for this JSON data. If they wish an extension developer can still capture after events and process them in any way they wish. Handling of existing update servers is unchanged. Above I have provided plg_installer_generic.zip which illustrates how these events can be handled.

I called it generic with the view that it may form the basis of something which could be shipped with Joomla! core and enabled or replaced with something developer specific as need arises. Although if, in the unlikely event that, all update servers respond with JSON data such a generic event handler would be redundant!

If the JSON handling part of this proposal is rejected then please leave the events in as I have a use case for them.

Thanks for your detailed response. My question was based on your first PR but I see now, walking through the code, that you have altered it, I think this is indeed an improvement and adds value not only to extension developers, but also to 'customers' giving them more detailed information on why a download didn't succeed.

Aside that, the PR have many other code issues. But before I start complaining we need to agree if this PR is needed. Maybe in some other form as @Ruud68 commented. (@Fedik )

One of my extensions is for selling subscriptions and providing downloads using download keys acting as a update server.
I think this is, from an end-user perspective, a valuable functionality. But that said: so I thought where the introduced change logs, but there are not many update servers providing these. When I look at all the extensions I have installed from different suppliers, only my own provide the change logs: others provide that information in different ways or not at all.
but even with that taken into consideration I would say: go!

Thanks Ruud68 for your comments. I am obviously 'small fry'! This pull request came out of an overdue upgrade to my update server and thoughts on where a project in the pipeline might go ...

Why is PHPstan failing?

See lines 91 and 131 in InstallerHelper.php
Refer to:
https://api.joomla.org/cms-5/deprecated.html#repos/joomla-cms/libraries/src/Application/EventAware.php

@BrainforgeUK PHPstan fails because you added another call to the deprecated getDispatcher, so the count for the exclusion in the phpstan-baseline.neon file does not match anymore.

You can fix that by running ./libraries/vendor/bin/phpstan -b on your branch (after having run composer installso that phpstan is available). This will re-create the phpstan-baseline.neon file. Then commit and push the changed file.

P.S.: If you don't have a development environment so you can't do what I recommended in my previous comment, then let me know here and I will do it later.

P.S.: If you don't have a development environment so you can't do what I recommended in my previous comment, then let me know here and I will do it later.

** Yes please, can you do that for me. Thanks.

P.S.: If you don't have a development environment so you can't do what I recommended in my previous comment, then let me know here and I will do it later.

** Yes please, can you do that for me. Thanks.

!! Help have the same issue with #46413 !!

@BrainforgeUK I have checked the PHPstan error message. You can do that, too, by checking the changed files on GitHub.

Maybe you should not use Joomla 3 code in your PRs?

@HLeithner Could you maybe advise here what can be done instead of using the deprecated interface "Joomla\CMS\Application\EventAwareInterface"?

Could you maybe advise here what can be done instead of using the deprecated interface

I am not Harald, but it as i already wrote. Ignore it.
The Application implements 2 interfaces which shares getDispatcher() method:

DispatcherAwareInterface::getDispatcher()

and

EventAwareInterface::getDispatcher()

The EventAwareInterface is deprecated and will be removed, however DispatcherAwareInterface will stay and the getDispatcher() method also will stay.

I think PHPStan cannot distinguish this race condition 😉

I see. Will update phpstan baseline tomorrow.

I've updated the phpstan-baseline.neon file to make PHPstan pass. Basically it is a false alarm by PHPstan, see Fedir's comment above .

Changes in downloadPackage():

I think changes in downloadPackage() method is unnecessary and over complicated.

As I understand the aim is to show to User the error.
This can be done near:

Here we can show server message when it return 403, kind of:

if (200 != $response->getStatusCode()) {
   Log::add(Text::sprintf('JLIB_INSTALLER_ERROR_DOWNLOAD_SERVER_CONNECT', $response->getStatusCode()), Log::WARNING, 'jerror');

  if (403 === $response->getStatusCode()) {
    $body = (string) $response->getBody();
    // Show response message, but ignore default server error pages
    if ($body && !str_contains($body, '</body>')) {
        //Translate JLIB_INSTALLER_ERROR_DOWNLOAD_SERVER_MESSAGE="Error downloading the packge: %1$s. %2$s"
        Log::add(Text::sprintf('JLIB_INSTALLER_ERROR_DOWNLOAD_SERVER_MESSAGE', $url, $body), Log::WARNING, 'jerror');
    }
  }

  return false;
}

Nothing special, if the key is wrong Developer just throw 403 on their server and show any text they want to show.
In theory should work simpler than magic JSON.
(We also can check for some response header kind of X-JOOMLA-PACKAGE-MESSAGE, but that can be another "magic" for developers.)

AfterPackageDownloadFailedEvent

This event does not really make sense on first look. If it also just to show message, then probably can be also unnecessary after changes in downloadPackage() method

Added 403 handler as suggested.

Kept JSON response handling and onInstallerAfterPackageDownload event.
Looking at my update server I prefer that flexibility.