Did you mean to remove libraries/vendor/.htaccess ?

@nikosdion i will not touch you pr, thx for continuing

Btw. Yiu have a checkbox when creating the PR it can be changed by maintainers.

@brianteeman No, I didn't. The vendor folder is managed by Composer and is meant to be possible to delete completely (which is what I did when Composer barfed installing requirements). The correct approach would be adding a .htaccess and a web.config file in the libraries folder but I digress. I'll add the file back to the wrong folder.

@HLeithner The checkbox placing and text makes it sound like it controls whether maintainers can edit the PR description, not have access to my repo. That's terrible UX in GitHub. Microsoft took over and it shows. I'll now know to blindly check a box with a misleading label. Thank you!

@brianteeman I forgot to comment again about the .htaccess issue after looking at the actual directory tree. I can tell you that the .htaccess file in libraries/vendor is unneeded and removing it is correct. The parent folder does already implement the correct solution (using a .htaccess and web.config file to block all web access to libraries and all its subdirectories). So I'm not changing this again since it would ultimately be the wrong thing to do.

So, as far as I'm concerned this PR is ready to be fully tested.

Did you mean to remove libraries/vendor/.htaccess ?

I guess the answer then is yes you did mean to remove it without even realising it ;)

Yes :) I did what any sane developer would do (remove the vendor folder before retrying to install Composer dependencies). So by virtue of doing something reasonable and expected I corrected a weird and unnecessary implementation detail in Joomla :D

it looks like a file that was simply overlooked when the switch to composer was made

Remove the Save button for non-paid extensions.

I wanted to link to the Download Key page but the template's CSS was betraying me.

Try this <a href="#" class="badge badge-warning">Warning</a>

@Quy I will not remove the Save button for free extensions for two reasons:

1. It clears any lingering Download Key. Think about downgrading a paid extension to its free edition with the developer simply changing the Update Site's title and URL.
2. Saving an Update Site now also resets the last update check time which is of paramount importance when Joomla's updates are stuck. This happens seldom but when it does there's currently no other way to fix it than manual database surgery (or using regenerate update sites which cocks everything up and removes all download keys in the process). After this PR is merged you can tell people to simply click on the update site of the extension they are no longer receiving updates, save and then head back to Updates and click its refresh button.

As for the warning, in the process I realized that you may have multiple paid extensions missing a Download Key. The correct behavior is a warning at the top of the page (system warning) with a link to the Update Sites page filtered by extensions with missing Download Keys. This is what I already did.

I have implemented all suggestions from @brianteeman, @alikon and @Quy feedback. Please test the PR so I can subsequently work on bringing it up-to-date with the 4.0-dev branch. Thank you!

Is there a scenario where you would have a download key for an extension that isn't paid for? If so then we need to tweak the terminology.

Great question, @brianteeman. In theory nothing prevents a developer from requiring a Download Key for a free of charge extension. However, in the last 15 years Joomla's been around I have not seen any free extension which limits its downloads. I can't even think of why would anyone do that. So I prefer to add language implying that the extension is "paid" or "for a fee" rather than ambiguous language such as "limited distribution" or something to that effect.

If we wanted to be very precise here we could let the developer provide a language key to override or be appended to the default message, ideally giving better instructions to their clients about the Download Key (e.g. "Updates to Foobar require an active, paid subscription to Acme Corp. This is checked by means of the Download Key. Please click here to log in to your Acme Corp account to retrieve your Download Key and see the status of your subscription."). However, I don't consider this an MVP goal, unlike the other improvements already made. If this PR is accepted I can make a proposal for further improvements and put them up for discussion -- I am not the only extensions developer out there with paid extensions, after all :)

I was just thinking aloud and if I had come up with a meaningful alternative text I would have proposed it - but like you I couldnt ;)

Quickicon 1

The text says "Download Keys entered correctly"

This is confusing to me as I took it to mean "Download Keys are valid" when it actually means "all extensions that support a download key have something entered in the field"

I can't really think of any suitable text. I was wondering if as you don't display the quickicon at all if there are no extensions requiring it that we don't display the quickicon at all if all DK have been entered?

Quickicon 2

Some free extensions are identical to the paid for extension except for the presence of a DK and when you subscribe to the extension then they give you the DK to enter on your site. This would mean that any site using a free extension like this would have a big red warning on the home dashboard etc

@brianteeman Regarding item 1: Note that I am using the Download Key feature which was created as part of GSOC. I am not changing how it works. The way it determines a "valid" key is when the extra_query in the update site record kinda-sorta follows the prefix/suffix pattern specified in the extension manifest's dlid attribute. Therefore a non-empty extra_query in the update site record which kinda conforms to that format results in a "valid" Download Key. The final verification of the Download Key is of course determined when downloading the update.

I am against adding any kind of verifying the Download Key in any other way because it'd need a request to the developer's site. To cut a long story short, the amount of traffic generated would require a massive increase in software delivery infrastructure cost (we're talking about two orders of magnitude) which would mean that developers would simply not use Joomla's integrated updates because it's financially unviable.

If we were to solve this, it would make sense to expect developers to reply with HTTP 402 Payment Required when the Download Key is invalid and have Joomla report this differently, e.g. showing a message to the user that the Download Key for XYZ extension is invalid and they probably need to go to the developer's site to see what's going on. There are ways to improve Joomla's response after a failed download without screwing over developers but I think it's outside the scope of this PR. I could work on that separately but I'm not sure if the Joomla Project is interested in it. Not having a roadmap doesn't help here.

Regarding item 2: The free version of the extension does not have the dlid attribute in the manifest, therefore it does not participate in the Download Key feature. As a result it's not participating in the notification of the quick icon plugin. I can't rule out the possibility that a developer will stupidly add a dlid attribute in a free extension but that's a problem between the chair and keyboard at the developer's side, not something to address in the Joomla core -- I am saying this as the idiot who actually did that stupid thing while trying to figure out how to use the new Download Key feature.

I never said anything about doing a validation (I agree that is wrong) I was pointing out that the text used implies it is validated and therefore in the absence of better text I was suggesting

I was wondering if as you don't display the quickicon at all if there are no extensions requiring it that we don't display the quickicon at all if all DK have been entered?
ie we only show the icon when there are missing download keys.

As for the second - we both know that if allowed developers will always do something daft. I guess they will soon realise.

I know what you wrote, I just followed the idea to its logical conclusion. I know that if a bad idea is not said out loud with an explanation of just how bad it is and why someone will eventually think about it, believe it's a good idea and may go even as far as implement it in the core :)

To get back to this issue, I don't think that making the icon disappear if all is entered correctly is a good idea. The icon can serve as an indicator of whether paid extensions are installed. Maybe we can change the language string but I'm quite literally at a loss for words. How can we succinctly convey that the user has entered something for the Download Keys which may or may not be correct but can only be verified when updates are being downloaded? If anyone can come up with a better wording, please, by all means!

I have tested this item ✅ successfully on df7bb23

I have tested this item ✅ successfully on df7bb23

RTC

Thank you very much @nikosdion and @crystalenka

@nikosdion May I have permission to link to the Null file for a PR with Update Sites? Thanks in advance.

@Quy Yes, of course :)