I have tested this item ✅ successfully on faeced0

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

Should I test again?

@TobsBobs at "Show all checks" no Test is shown so is suggest to retest to be on safe side.

I have tested this item ✅ successfully on faeced0

Having full CRUD for update sites seems like a bad idea. True, there may be instances where a user needs to modify these records temporarily for some reason (testing a vendor update, updating an old extension and the server used in that version no longer available, etc.) but I feel like this is core providing the shotgun if someone decides they want to shoot themselves in the foot.

How does having a full CRUD interface for managing update sites interface with the installer API and the plugin that processes the updateserver element from extension manifests (WTF that is still in a plugin and not moved to the installer library makes no sense)? What happens when updating an extension after you've modified the update server?

How does having a full CRUD interface for managing update sites interface with the installer API and the plugin that processes the updateserver element from extension manifests

Not sure I understand the question. At the moment, it only edits the URL. Once you rebuild, things are back to what they were. The same way the Delete button works.

If we want full control, we should not keep reading the info from the manifest field and make a proper table. Perhaps that will happen in the future when we need keys added to the the update server for signed packages.

(WTF that is still in a plugin and not moved to the installer library makes no sense)

This is rethorical I hope :)

What happens when updating an extension after you've modified the update server?

The data is taken from the new update server.

Not sure I understand the question. At the moment, it only edits the URL. Once you rebuild, things are back to what they were. The same way the Delete button works.

I'm not understanding though what the intent and use case here is that requires that end users have full control to define where they are receiving extension updates from. Why do end users need to be able to say "I do not want my updates for (insert extension name here) to come from that vendor's update system but some other random system which does not guarantee I am getting either the latest version or an unmodified build"?

What happens when updating an extension after you've modified the update server?

The data is taken from the new update server.

For that update, yes. Remember, the plugin parses the manifest and ensures the URL(s) in the manifest are stored in the correct table. So, basically a user is going to update from their custom source and unless that custom source has a custom build that changes the update server URL to that user's preferred URL, the end result is going to be there are now multiple update servers for that extension. No good.

This is an area of the CMS that a very strong case for "end user has full control" needs to be justified. This type of control makes it too easy for an end user to screw up royally and easily install hacked versions of their extensions, or not receive update notifications, and those same end users will be able to come back and say "this feature of Joomla is the reason my site was hacked, you all let me change where I get my updates from to https://update.ihavehackedjoomla.org". If anything, as an extension vendor this feature would make me want to remove support for the core update system and go back to an extension level implementation core can't touch.

I fully agree with @mbabker

I'm not understanding though what the intent and use case here is that requires that end users have full control to define where they are receiving extension updates from. Why do end users need to be able to say "I do not want my updates for (insert extension name here) to come from that vendor's update system but some other random system which does not guarantee I am getting either the latest version or an unmodified build"?

To me this sounds really non-sense and even worst potentially dangerous. Only the extension developer should be able to set this kind of informations and URLs, not the user.

Only the extension developer should be able to set this kind of informations and URLs, not the user.

By that definition we must remove the Custom URL for the update server we can set for a Joomla update.

Why do end users need to be able to say "I do not want my updates for (insert extension name here) to come from that vendor's update system but some other random system which does not guarantee I am getting either the latest version or an unmodified build"?

There are not many use-cases. One is when you switch update servers, from domain A to domain B. Joomla will add a second update server and always look for the update server from domain A. So users will not get the right update server. Only way to change it is to either ask the user to change it manually in the database or have the user install the update manually and write code that changes the updateserver table.

I don't see how this is more dangerous than the custom URL for a Joomla update.

I don't see how this is more dangerous than the custom URL for a Joomla update.

That option is limited scope (you can only change the core server). And honestly it was a badly designed option, there should have been servers set up for nightly builds and non-stable release track (alpha/beta/RC) and be done with it. If you ever actually needed another update server for something, it would probably be a thing that at most JBS members would need and they could just edit the database to run with it (because if end users are being asked to use a custom URL for updates on their production systems then something has gone wrong).

One is when you switch update servers, from domain A to domain B. Joomla will add a second update server and always look for the update server from domain A.

Hence the half snarky half serious comment about the update server code still living in a plugin and not being a proper feature of the core installer library. If you look at that plugin's code, all it is doing is validating every URL in the current manifest exists in the update sites table and adds it if not present. It doesn't have any "smart" capabilities to remove old servers, as an example, which leads into the scenario you've listed above.

Point taken.