However, these strings are product names and do not need to be translated; they just need to be copied verbatim into language files by the translation teams.

In most cases this might be right, but in some languages like e.g. Chinese there might be transcripts of product names in their writing system, so I think it's good to have them translatable.

@richard67 They are language strings already, as I said. If a language needs to transliterate the product names, they can.

@richard67 They are language strings already, as I said. If a language needs to transliterate the product names, they can.

@nikosdion Yes, I understood that. I only wanted to say why I think this PR is really useful. Am preparing for tests now. Will create some own updatesite for that extension and modify it to use that so I can play around a bit with the supported_databases values.

@richard67 Oh! Sorry, I misunderstood what you wrote before. All clear now :)

Unfortunately the extension linked in the description doesn't have 4.2 yet in the targetplatform tag of the update site https://raw.githubusercontent.com/lucid-fox/social-magick/main/update/socialmagick.xml , so on a 4.2-dev the test will not work as described with that extension. So I have to create an own update site anyway.

So I have to create an own update site anyway.

or modify the version number of your install. One file to edit. Very quick

So I have to create an own update site anyway.

or modify the version number of your install. One file to edit. Very quick

@brianteeman For that purpose only yes, but I also want to play with the supported_databases values of the update site.

@richard67 You can download the update XML and host it locally, amending the supported platforms. Then edit your DB to point its update site to your local file and Bob's your uncle.

@richard67 You can download the update XML and host it locally, amending the supported platforms. Then edit your DB to point its update site to your local file and Bob's your uncle.

@nikosdion Yes, I'm doing it that way, change the URL of the update site in the db and also in the manifest XML of the plugin.

What I found out up to now is that your PR works as described, but I did not get the version check work up to now here

I had a mysql="9.0.0" in the supported_databases for the 1.0.2 version of the plugin, but I was offered the update.

When I removed the "mysql" completely with <supported_databases oracle="10.1" /> for plugin version 1.0.2, then I got the expected message telling that my database type "MySQL" is not supported anymore.

Am investigating what the reason could be. Will let you know soon.

@nikosdion The problem is that the array keys of $supportedDbs are in uppercase for whatever reason, while $dbType is lowercase. You catch that well in line 159, but in line 161 the $minimumVersion = $supportedDbs[$dbType]; fails.

If we can rely on the keys always being uppercase we could just change that to $minimumVersion = $supportedDbs[strtoupper($dbType)];, but maybe it would be better just to map or copy the $supportedDbs so it has lowercase keys?

P.S. What we should not to is to change $dbType to uppercase.

Hmm, it is an XML element attribute ... if we can rely on it always being made uppercase by the XML parser, we can just use $supportedDbs[strtoupper($dbType)]; in line 161.

@nikosdion In addition to my 2 previous review comments, I found that it needs to change the error message also here

For testing I have created a few update sites:

• For testing as described on 4.2-dev https://test5.richard-fath.de/test_pr-38121.xml

• For database type being not supported https://test5.richard-fath.de/test_pr-38121_test-2.xml - This has <supported_databases oracle="12.0" />, so you can test with whatever you have and it will not be supported.

• For database version being not supported https://test5.richard-fath.de/test_pr-38121_test-3.xml - This has <supported_databases mysql="10.0.0" mariadb="20.0" postgresql="20.0" />, so you can test with whatever you have and it will be a too old version of a supported type.

Just change the location column of the record with name 'Social Magick Updates' in the #__update_sites table to the mentioned URL, and to be sure it survives an update site rebuild change it also in line 637 of file "plugins/system/socialmagick/socialmagick.xml" of your testing site.

Another thing I found is that there is very similar functionality here https://github.com/joomla/joomla-cms/blob/4.2-dev/libraries/src/Updater/Update.php#L357-L388 . I'm not sure, but I think that's used for the core update. It would make sense to use the new language strings also there when this PR here has been merged. I could make a follow up or for that in this case.

Finally, as the language strings are only used for reporting the current database type on which Joomla is running, and not the supported one from the update site, and Joomla 4 runs only on MySQL or PostgreSQL, we currently do not really need the language strings for the other database types (Oracle, MS SQL, SQLite). But as the drivers support to connect with them, I think it is good to have them for future use at other places. But that's just my opinion, others might disagree.

@nikosdion If you want I can make a PR for you in your repo to apply my above suggestions.

Yup, please do a PR.

As for the lang strings, best to have all keys than ending up with an untranslated string 5 years down the line if, say, we decide that a site can have multiple DB connections and people write integration plugins which talk to the secondary database which might be of a different technology than what is supported for the primary database.

Yup, please do a PR.

@nikosdion Done, see https://github.com/nikosdion/joomla-cms/pull/10 .

Regarding the language strings I fully agree with you. I just mentioned it in case others may disagree.

Thank you! I merged your changes.

I have tested this item ✅ successfully on a4be380

I have tested as follows.

I have created 3 update sites for 3 tests:

1. https://test5.richard-fath.de/test_pr-38121.xml for testing the PR as currently described in the instructions on a 4.2-dev.
2. https://test5.richard-fath.de/test_pr-38121_test-2.xml for having no supported database type.
3. https://test5.richard-fath.de/test_pr-38121_test-3.xml for having a supported database type but with unsupported version.

Then I have installed the plugin linked in the description.

Then I have updated the location column of the record with name 'Social Magick Updates' in the #__update_sites table to the URL of the particular update site and then have used the "Check For Updates" button.

I've done this for all 3 sites without and with the PR applied.

Results will come with screenshot in my next comment.

Other testers please follow my inscrutions above.

Here the details to my test results for the 3 update sites I've mentioned in the comment to my test.

Without the PR applied, I get with all 3 update sites the same result as described in the issue:

With the PR applied, everything is as expected:

When using the first update site, an update is found:

When using the second update site, I get a message that the database is not supported anymore:

When using the third update site, I get a message that the database version is not supported anymore:

I have tested this item ✅ successfully on a4be380

RTC

thanks