findLanguages doesn't work after upgrading from Joomla 3.5.1 to 3.6.0

[danielsmink]

Steps to reproduce the issue

Use InstallerModelLanguages to find an extension ID for the en-GB language E.g.

    $model = \JModelLegacy::getInstance('Languages', 'InstallerModel');
    $model->findLanguages();
    $items = $model->getItems();

Expected result

the en-GB language is returned

Actual result

0 items are returned

System information (as much as possible)

PHP 7.0 mySQL 5.5

Additional comments

Seems to be caused by a database change that isn't updated by the database migrations. Apparently language extensions are no longer of the type language but of the type package. And the element changed from 'en-GB' to 'pkg_en-GB'. It works fine on a fresh install.

[infograf768]

/**
     * Method to find available languages in the Accredited Languages Update Site.
     *
     * @param   int  $cache_timeout  time before refreshing the cached updates
     *
     * @return  bool
     *
     * @since   2.5.7
     */
    public function findLanguages($cache_timeout = 0)
[...]

The method already exists in 2.5... It specifically fetches the update server to install/update language packs. It is not designed for anything else. No db change.

If you look at the _extensions table you will see that a specific language has 3 entries: One for site, one for admin and one for the package.

[brianteeman]

There was a change with the en-GB language though if i remember correctly to make it a package see #9835

---

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

[infograf768]

Indeed.

[danielsmink]

Ah that clears it up! The method was changed though. If you look at tag 3.5.1 you'll see it looks for element 'en-GB' and type 'language' instead of 'pkg_en-GB' and 'package'

Anyway once #9835 is fixed this should be fixed as well I guess.

[infograf768]

Why would it be fixed? Why do you try to look for a language id through InstallerModelLanguages?

[danielsmink]

If the en-GB language is in the table with the above values it should work correctly. As it says in #9835 the en-GB language lacks the third db entry.

We use a CLI tool to deploy Joomla on our servers https://github.com/picturae/joomla-cli the install language part of it uses to retrieve the update id to request in this case the Dutch language pack from the correct update server.

[andrepereiradasilva]

@danielsmink https://github.com/joomla/joomla-cms/pull/9835 is already merged.

if you don't have the pkg_en-GB extension is because somehow your update didn't complete with success.

[danielsmink]

It did complete successfully. I think the issue is that the record in the DB isn't added upon upgrade (for the en-GB package). There are no pending database migrations. Re-installing the language might fix it as well I haven't tried that although I doubt it could be installed as it would use the same code I use for installing the Dutch language.

[Bakual]

@danielsmink You most likely din't upgrade using com_joomlaupdate. Did you update using a CLI script and running database fix maybe? That would be an unsupported upgrade path. The database fix doesn't apply the needed SQL changes (like the insert statement here: https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_admin/sql/updates/mysql/3.6.0-2016-04-08.sql) and thus you would miss the package entry.

[danielsmink]

@Bakual yep that's exactly how we do it using the same CLI tool previously mentioned. This has never been an issue with any prior upgrades. Or maybe not as apparent.

I guess we can fix it by running the SQL files in that directory. Thanks for the clarification I'll close the issue.

[ggppdk]

I confirm that if you extract the new files and use database fix then the entry in the extensions table:

English (en-GB) Language Pack

is not created and thus the Find languages screen (that depends on it) is empty

(e.g. my local git joomla repositories (which are several months old), did not list "available" languages , i had to run the query manually)

[Bakual]

Or maybe not as apparent.

That one :)

The database fix never runs the insert (and I think delete) stuff. It just runs the SQL commands that alter the structure of the tables.

If you only use database fix, you will also miss the new installer plugins (install from folder/package/url).

[ggppdk]

Did you update using a CLI script and running database fix maybe? That would be an unsupported upgrade path

@Bakual sorry to ask, what does the above mean ? That sites should not be upgraded like that ?

[andrepereiradasilva]

if i'm correct @mbabker sometime ago made a script to finish the upgrade process to solve those issues when upgrading manually. See https://gist.github.com/mbabker/d7bfb4e1e2fbc6b7815a733607f89281

[danielsmink]

Wowa thanks for that link @andrepereiradasilva :-) @mbabker is it ok to integrate this in our cli tool? I'll gladly mention it's yours. The tool itself is opensource.

[andrepereiradasilva]

don't thank me, thank @mbabker

[brianteeman]

Closing as this is a user error not a core joomla issue

[Bakual]

sorry to ask, what does the above mean ? That sites should not be upgraded like that ?

@ggppdk It's not an official supported upgrade path and thus it is not considered a bug if something breaks due to it. The only supported way is using com_joomlaupdate.

[danielsmink]

Happy to report that our CLI tool now works with some added lines from @mbabker thanks a lot!