+JLIB_DATABASE_ERROR_MUSTCONTAIN_A_TITLE_UPDATESITE="Update site must have a title"
has to be added also in admin en-GB

Feature 2:
Disabling language packs update site
Then going to Update
Purge
Result: Purged updates****, 1 disabled site was enabled**
And then Find Updates works without going back to Update Sites to re-enable the language pack update sites.

The update site purge feature (InstallerControllerUpdate::purge) was calling InstallerModelUpdate::enableSites. That task was put in Joomla! long before this PR because there was no easy way to enable the already disabled update sites. However, now that we are giving our users the option of managing update sites it shouldn't be doing that.

You're right, it's a bug. And I just fixed it :) Can you please test this again?

@infograf768 One more thing. Could you please provide the URLs of the out of date package you are using? It will help other people with testing this PR. Thank you very much!

@test:
There is an untranslated string in the browser bar called COM_INSTALLER_TITLE_updatesites when I click on the update sites link.

There are 2 entries in the update sites list that are the same:

The 2 entries called Joomla CMS are actually the Joomla Core and Joomla Extension Directory, see here:

I think the name should be taken from the #__update_sites table.

When I try to sort the update sites table by Type column I get this error:

Column 'type' in order clause is ambiguous SQL=SELECT s.*,e.extension_id,e.name as extension_name,e.type,e.element,e.folder,e.client_id,e.state,e.manifest_cache FROM jos_update_sites AS s INNER JOIN jos_update_sites_extensions AS se on(se.update_site_id = s.update_site_id) INNER JOIN jos_extensions AS e ON(e.extension_id = se.extension_id) WHERE state=0 ORDER BY `type` asc LIMIT 0, 20

When I try to sort by Update Site ID, Status or Name it is not sorting by these columns but it is sorting by the Update Site column.

Testing the check for updates works as described.

That is all for now :)

I am confirming @roland-d test issues.

Thanks for your contribution, Nicholas!

Typo in the test instructions:

Feature 1: Purge button
... Click on Find Updates Purge. The updates list is cleared. Click on Find Updates. The update list is populated again.

Purging and finding updates works for me.

Feature 2: Update Sites

Enabling/disabling update sites works.

1. How about adding the Update Sites menu-item after the Updates menu-item in stead of the last in the list?
2. UX improvement: can you move the status column to the second column, right after the checkboxes?
3. Filter by status doesn't work. Ordering works fine.

Besides that I don't see anything wrong.

I've used Joomla 3.3.1 for testing.

Why reinstate the purge button. Why not just make Find Updates do an automatic purge

@test success for latest fixes. (great PR Nic!)
@test success for feature 1 & feature 2

One suggestion :
in Updates Sites, we have duplicated id (one for each language) for Accredited Joomla! Translations, but it's only one sever. Maybe having only one line, and replace name by "Translation Packs" ?

I agree too with Brian about an automatic purge (More convenient for the average user)

Tested on 3.3.1

When you Purge the cache you get two messages.
Purged updates and There are no updates available at the moment. Please check again later.

That is confusing and bad UX. Surely the correct procedure would be to immediately (and automatically) run the Find Updates. This way you will get two messages
Purged updates AND either There are no updates available at the moment. Please check again later. OR a list of actual updates.

Why make me press two buttons. If I am purging the cache then obviously I want to see if there are any new updates available as well

Not created by this PR but would be good to fix at the same time.

The Notice displayed in the Extension Updater is not great
Before updating ensure that the update is compatible with your Joomla! installation. If updating Joomla!, ensure installed extensions are available for the new Joomla! version.

The second sentence is irrelevant as you cant update Joomla here.

However the second sentence belongs in the Com_joomlaupdate screen where there is no notice

@jurianeven I moved the Status column. The Update Sites was made the last item on the list as it's supposed to be the least frequently used.

@brianteeman The Find Updates button must not purge the updates. Each update site has its own last time checked column. This means that Find Updates will only fetch the update information for the extensions for which updates were not retrieved within X hours, as configured in the Options page. If you purge before finding updates you have to retrieve all updates. This is problematic since when you have too many extensions on a bandwidth limited shared host you may hit the PHP timeout limit. I'm trying to prevent that – unless you really want Joomla! to do that and you click on Purge.

Regarding the messages, they are not both messages. The green one is a message (only displayed after the action). The blue one is status information. I disagree with the "There are no updates" being displayed in a blue message-like alert box, but this is how Joomla! has been doing it since 3.0 and I am not going to change this in this PR. Simply put, I DESPERATELY NEED the Purge button and Update Sites management features for the benefit of my paying clients and I'd be damned if I risked my improvements being rejected or talked to death because I also happened to change the layout of a message.

Same goes for anything else regarding the UX of com_installer. It's deliberately out of scope of this PR. This PR has the sole purpose of saving me 20 hours of senseless support and bad reputation after each and every single release of my software, all caused by Joomla! not allowing my paying clients to easily reset the update information without going into the database. Pretty selfish? Yes, indeed. Also works for everyone else publishing extensions for Joomla!? Darn right. Everybody wins.

If we are going to make changes (and we should) then lets get them right this time and not have to make further changes in the future

Thanks Nicholas. Can you also fix this please?

Filter by status doesn't work.

Why make me press two buttons. If I am purging the cache then obviously I want to see if there are any new updates available as well

You could rename the Purge button to Purge and find updates and then of course also find updates when that button has been clicked.

@nikosdion All the issues I reported have been fixed. Thanks
As for @jurianeven suggestion to rename the button, looks good to me :)

@brianteeman I vehemently disagree. My PR intends to fix a very specific thing: Joomla! updates get stuck and Joomla! silently disables the update site. Anything else is out of scope of this PR.

I agree that there are UX issues, that's why I proposed a rewrite of com_installer and drafter a whitepaper on how to do that. There's a WG on that and I'm a technical advisor and sort-of-coordinator. If you want to be the UX advisor, please drop me a line. But let's keep it outside this completely unrelated PR.

I agree with the PR in general here. It's something which was on my mind for quite some time as well. So huge + from me for that contribution.

From code review it looks mostly good. I wonder if it could be done without using the deprecated JError. I'd say either use exceptions or enqueue a message there. Or are they really needed? Sounds a bit wrong to use depecated classes and methods in new code

+1 for not adding back the purge button.
Purge should be done on 'Find updates' and should be done for ALL update sites (also the ones checked 2 seconds ago).

@Bakual I deliberately followed the design of other com_installer models / controllers even though I don't particularly enjoy using JError. IMHO everything should be moved to exceptions. However, for consistency's sake (and saving the sanity of whoever will be maintaining the code in 1-2 years), it should be an all or nothing approach.

@nonumber @roland-d @jurianeven @brianteeman I disagree with purging before fetching updates. Let me explain this in small words:

• You are a typical Joomla! user on a low-quality shared host with limited bandwidth, PHP maximum execution time and PHP memory time limit
• Being a typical user, you have installed 30 components, 50 modules, 120 plugins and six templates, each one with its own update site definition for a grand total of 209 update sites (including those shipped with Joomla!).
• Assuming an optimistic 1 second to contact each of those update sites and 300Kb of PHP memory required to parse them you need 209 seconds and just over 61 Mb of RAM
• Your host gives you 30 seconds and 32 Mb of RAM. You can only process up to 25-30 update sites at once.
• However, the last update time is committed for those first 25-30 sites.
• Therefore you can go back and hit Find Updates again. The next 25-30 sites are processed. The first ones have a last update time less than the min time between checks, therefore they are not checked.
• Rinse and repeat and you have all of your updates.
• If you purge before you find updates you will NEVER, EVER be able to fetch updates
• This happens AUTOMATICALLY in the main Control Panel page of Joomla!, thanks to the AJAX magic I had baked in Joomla! 1.7's "Extensions updates" icon plugin 2+ years ago. You're welcome.
• In realistic circumstances you only have around 20 update sites, but the time to download and process each one is in the 2-3 seconds territory. This problem is REAL, not imaginary. I left this bit of info in the end to see how many of you bothered reading this description.
• Oh, by the way, it's even worse when you are developing locally ;)
• Therefore, purging the updates before finding updates is a stupid idea, unless we consider Joomla! to only run on high-end dedicated hosts, with sites created by people who are not overloading their sites with useless crap (hint: neither holds true in our current target audience)

So, do you people REALLY want me to replace my extremely carefully thought out Purge feature (which I had contributed to Joomla! 1.7 and some random committer mindlessly removed) with something that doesn't really work in the real world? I hope you're joking.

@nikosdion As I understood there would be 2 buttons, Find updates and Purge + Find updates. This would also cover the scenario of not purging before updating. As writing that, I realize it will be confusing for users to have 2 buttons that say Find updates. The Purge button would only be needed if there are unpublished sites.

So yeah, let's stick with your original proposal, just a Purge button

Purge should only be needed in the very rare cases where Joomla! soils its pants, leaving ghost update records in the #__updates table. Yeah, it also has the side-effect of enabling update sites but the main reason of its existence is ghost update records. In some cases they're super-annoying: version 4.1.0 is out, the user installs it, Joomla! insists for two weeks that version 4.0.0 is the latest, user vents out to the poor developer. Been there, done that, now there's a button to cure this ;)

Based on @nikosdion's explanation, I'm a +1 for keeping the Purge feature as he explains it.

Yep leave it like that for KISS reasons (I think the UX idea of Purge and find updates is not bad, but then you have to split the requests with AJAX and so on to make it work, and even then it has to be fine tuned. Way too much hassle for something which isn't used often anyway.). Btw I've read your whole description, @nikosdion. Hopefully it'll ease the pain of explaining.

Now we can move the JC tracker to Ready for review?

I deliberately followed the design of other com_installer models / controllers even though I don't particularly enjoy using JError. IMHO everything should be moved to exceptions. However, for consistency's sake (and saving the sanity of whoever will be maintaining the code in 1-2 years), it should be an all or nothing approach.

I know we have that JError stuff still in many places. The goal is to remove them and the class is already deprecated in favor of native exceptions. So I fully agree with you that it should be exceptions where possible. If you can do it in that PR, it would sure guide others how to properly remove JError in other places. I would very much appreciate if you could do it

Very good PR, @nikosdion!

All right, there you go @Bakual Bonus code clarity improvement: eliminating redundant else-blocks, see Rafael Dhoms' keynote in JaB14/

@test OK

What should the user do when a component have several update sites? My testside includes now 3 update sites for JCE, with three different update sites ID. Is there an easy way to clean up the update sites?

I hoped this would fix issue 33482 (JoomlaCode). But it didn't. @nikosdion do you have a solution for this too? The trouble is with updating Akeeba backup and admin tools
Error: Package download failed: https://www.akeebabackup.com/component/ars/?view=download&id=2690&dlid=&dummy=my.zip

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33482&start=0

@kennst A single extension can define multiple update sites. Likewise, many extensions can all be updated from the same update site. This is not a bug or a problem, it's how Joomla! works. There's nothing to "do".

Regarding JC33842 you need to upgrade to Joomla! 3.3 and enter your Download ID in the component's Options page. However, this is out of topic. If you need support with our software please file a support ticket on our site, Monday to Friday and me or a co-worker will reply as soon as possible.

Thanks for getting rid of JError, much appreciated

@test
Works as expected, both feature 1 & 2.

@nikosdion Great work and good improvement !

Wondering if "Purge" button could have a less scary and clearer name ? like e.g. "Refresh entries" or "Reactivate updates" ?

@nikosdion

Still need to sync both lib_joomla.ini as stated in my first post.

Also, we have 2 "Purge updates" string values in core:
one in the installer, one in the library
en-GB.com_installer.ini:150: COM_INSTALLER_PURGED_UPDATES="Purged updates"
en-GB.lib_joomla.ini:491: JLIB_INSTALLER_PURGED_UPDATES="Purged updates"
en-GB.lib_joomla.ini:492: JLIB_INSTALLER_PURGED_UPDATES="Purged updates"

Looks like it is the library one used here; I suggest to change the value to something like:
"Updates successfully purged. Click on 'Find Updates'"

@infograf768 We are using both, in different contexts. The JLIB string is used in com_joomlaupdate, the COM_INSTALLER string is used in com_installer. I will remove the COM_INSTALLER strings to keep everything consistent.

Added a comment about removing an (in my opinion) unneeded function but here. I was very happy when the purge button was removed but I can understand why it's needed. Thanks for the explanation.

Just tested the functionality of the PR, seem to work as expected. Great job @nikosdion!

Merged into 3.4. Thanks all for testing and especially @nikosdion for coding!

w00t!