ok still need some changes here, plus resolving the plural forms.

discovered some bugs. will tell when ready.

@andrepereiradasilva

I suggest to slightly change the constants for the plural strings, i.e adding _N_
from

+COM_INSTALLER_MSG_UPDATESITES_DELETE_UPDATESITES_DELETED="%s update sites have been deleted."
+COM_INSTALLER_MSG_UPDATESITES_DELETE_UPDATESITES_DELETED_1="1 update site has been deleted."

to

+COM_INSTALLER_MSG_UPDATESITES_DELETE_N_UPDATESITES_DELETED="%s update sites have been deleted."
+COM_INSTALLER_MSG_UPDATESITES_DELETE_N_UPDATESITES_DELETED_1="1 update site has been deleted."

Thanks @infograf768 that was what I had suggested before the N

I have tested this item successfully on 17db21e

Tested delete
Tested rebuild
Added fake updates sites in the db and rebuild removed them

All good (once the language string key is updated)

please don't test yet i has some bugs still.
i'm trying to solve them.

Really? Every test I could think of worked

problems still to solve (that i know of):

• the en-GB package, if somehow deleted, doesn't get the update (because it does not have an extension in the database ...).
• also had to do an additional check if the extension is only discovered or it's really installed.
• plural variables name

the en-GB package, if somehow deleted, doesn't get the update (because it does not have an extension in the database ...).

Accredited Joomla! Translations update site cannot be deleted.

In addition its a protected extension so cant be deleted

@brianteeman
After some investigation and with the help form @infograf768 the en-GB language problem is something not related to this PR.

Explaining, for what i know, and correct me if i'm wrong:

A language package install 3 extensions in the database:

• type = language | Admin
  • Manifest: /administrator/language/xx-XX/xx-XX.xml
• type = language | Site
  • Manifest: /language/xx-XX/xx-XX.xml
• type = package | Site
  • Manifest: /administrator/manifests/packages/pkg_xx-XX.xml

The en-GB language pack (comes by default) somehow only has two extensions in the database...

• type = language | Admin
  • Database Id: 601
  • Manifest: /administrator/language/en-GB/en-GB.xml
• type = language | Site
  • Database Id: 600
  • Manifest: /language/en-GB/en-GB.xml
• type = package | Site
  • Database Id: doesn't exist
  • Manifest: /administrator/manifests/packages/pkg_en-GB.xml

See https://github.com/joomla/joomla-cms/blob/staging/installation/sql/mysql/joomla.sql#L618-L619

Since the update servers are declared in the pkg manifest, if somehow deleted, will not be reconstructed in this PR.
Of course this is a wild scenario, since deleting it is not possible through the update sites view.

So this is not related to this PR, this PR does not readd the en-GB update site after "accidental" delete because, as said, the pkg_en-GB extension does not exist, by default, in joomla database.

But from a coherence point of view, if a manifest exists, the extension should exist in the database.

In other words, IMHO it should exist a blocked en-GB package extension in the database on joomla install and the udpate site should point to that extension (as all language packs do).

Remember you have blocked extension in the database for all other manifest files, including joomla core, joomla update, etc.

Not 100% sure I understand your last sentence but as for the rest it really is beyond the scope of this PR

@brianteeman
What @andrepereiradasilva says is that this PR will work perfectly if we add in our sqls the Database Id: for the en-GB fake pack (in _extensions).
If not done, this PR may let people delete the en-GB entry in updatesite by mistake. This would be an issue if someone has never installed a lang pack and does it for the first time after deleting it.
Just a matter of adding to joomla.sql and updates sql the fake pkg.
I guess :)

yes, it's out of the scope of this PR.

Remember you have blocked extension for all other manifest files, including joomla core, joomla update, etc.

Some examples:

Joomla Core: All logic

• Manifest
• Extension in db
• Update sites in db

Joomla Update: All logic

• Manifest
• Extension in db
• Update sites in db

en-GB language package: ?

• Manifest
• Extension in db: doesn't exist
• Update sites in db it's pointing to extension id 600 (en-GB site language) whose manifest doesn't have an updateserver ...

Something doesn't seem right ...

Put ok, let's concentrate in the PR and check that later.

What @andrepereiradasilva says is that this PR will work perfectly if we add in our sqls the Database Id: for the en-GB fake pack (in _extensions).

Yes, but in another PR.

If not done, this PR may let people delete the en-GB entry in updatesite by mistake. This would be an issue if someone has never installed a lang pack and does it for the first time after deleting it.

This PR doesn't allow to delete any update site that has update.joomla.org in the URI.
See https://github.com/andrepereiradasilva/joomla-cms/blob/update-sites-manage/administrator/components/com_installer/models/updatesites.php#L366

Just a matter of adding to joomla.sql and updates sql the fake pkg.

Not only, the update site extension id should be linked en-Gb package too (since it's in the en-GB package manifest that exists the update server URI).

As this PR does not allow you to delete that update site I really think its a non-issue

Yes, it's not an issue because of the special treatment that exists in en-GB, it's just an inconsistency i discovered in this PR.

I will not fix this is this PR. So let's concentrate in this PR.

Will do the rest of the changes and tell when is finished.

This PR has received new commits.

CC: @brianteeman

This PR has received new commits.

CC: @brianteeman

This PR has received new commits.

CC: @brianteeman

ok, now should be ok.

I dont understand the comment about a discovered extension not being installed. If I click on discover and install an extension then it is installed and if it has an update server in the xml it is added to the update sites

I realise now you meant not to parse the extensions that are listed in Discover but have not been installed yet

I have tested this item successfully on 4d26e51

I have tested this item successfully on 4d26e51

I have tested it successfully.
Installed an extension, deleted the Update Site and recreated it by using the rebuild function.
Afterwards removed extension and the Update Site was removed too.

RTC

I have tested this item successfully on 4d26e51

Installed components, plugins, and template with update sites.
Followed the test instruction, deleted the update sites. After rebuild the update sites were succesfully recreated.