Discover Error in J4.0.4 ? Topic is solved

[GreenDot]

Have serious problems with discovering and installing new modules, extensions or templates with Joomla 4.0.4.

After the extension is discovered (J4 compatible) and installed, the admin will show only text in plain HTML without any template or CSS styling. I have checked this a few times with a fresh installation and different extensions, each time the same error. Same issue when I install first a clean J4.0.3 and do an upgrade to J4.0.4, same bug when use discovery! In Joomla 4.0.3 I don't have any problem at all, so long I don't do an upgrade.

And yes, I have cleared the caches (include the browser), use different browsers and computers. All the same outcome, no template/CSS. Wrote over the files in the admin folder with the original files from the ZIP file, doesnt work.

Dont know or this is a bug or a miss-configuration, but it's typical that it only happens with J4.0.4.

[sozzled]

What is the name of the discovered extension? What happens if you disable it? If your website works after disabling that extension, have you reported the issue to the developer?

[ redacted ]

[GreenDot]

What is the name of the discovered extension? What happens if you disable it? If your website works after disabling that extension, have you reported the issue to the developer?

It's a template and module that I wrote by myself for J4. So I am the developer. Mostly when I have that kind of issue, I remove it from the database itself and its working again. But now, when removing the template or module from the database, both times, the problem still exist.

Only solution is to remove the entire Joomla folder and reinstall it over again. Did it a few times, with J4.0.4 each time the same problem after discovering with both extension but not with J4.0.4

thx for ur help

[sozzled]

This does not sound like a bug with J! 4.0 to me.

The usual way to uninstall extensions is to use the J! backend but, of course, if the backend looks like a dog's breakfast without the nice CSS styling, then navigation your way to http(s)://yourwebsite/administrator/index.php?option=com_installer&view=manage may prove difficult. Unless you really know your way around the database tables, "manual intervention" (i.e. deleting files and/or records in database tables) may leave extension remnants behind and those remnants can affect normal operations.

The discovery tool tries to repair the damage cause by "manual intervention" and it usually works. However, as I have not used your extension(s), nor tried the methods you've tried to patch things up, I can't really offer you any useful advice at this time, sorry. Good luck, though.

[brian]

Delete the file administrator\cache\autoload_psr4.php and then refresh the page. The file will be regenerated and everything will work.

[sozzled]

Good call, @brian. Discussed on GitHub at https://issues.joomla.org/tracker/joomla-cms/35545 and in other places there.

[GreenDot]

The usual way to uninstall extensions is to use the J! backend but, of course, if the backend looks like a dog's breakfast without the nice CSS styling, then navigation your way to http(s)://yourwebsite/administrator/index.php?option=com_installer&view=manage may prove difficult. Unless you really know your way around the database tables, "manual intervention" (i.e. deleting files and/or records in database tables) may leave extension remnants behind and those remnants can affect normal operations.
The discovery tool tries to repair the damage cause by "manual intervention" and it usually works. However, as I have not used your extension(s), nor tried the methods you've tried to patch things up, I can't really offer you any useful advice at this time, sorry. Good luck, though.

Have tried all those methods, nothing helps. Have written a quick small module to test it out and again with 4.0.4 same problem, and with 4.0.3 nothing. I uninstall the module from 4.0.3, upgrade it to 4.0.4, do the discovery and bang, same issue. Don't give up to find what it is. Thx for ur help

[GreenDot]

Delete the file administrator\cache\autoload_psr4.php and then refresh the page. The file will be regenerated and everything will work.

Also tried, not helping at all. Still only text without template. And the plugin namespacemap is enabled as it is a new fresh installation of J! 4.0.4. Still trying to find out what is the problem. Wrote a simple small basic module, and gives the same error in 4.0.4 and not in 4.0.3. Still trying to find what the problem is. Thx for ur help

[ceford]

I cannot reproduce this problem. Discover (a module) works fine for me on 4.0.4. Are you testing on localhost or a hosting service? Have you tested with something other than your own extensions? As a developer I don't think you should be using discover for installation. What developer tools are you using?

[GreenDot]

And its getting more weirder.

After trying out a new installation of J! 4.0.3 and 4.0.4 I noticed that both versions doesn't display the modules in the backend. Those are both clean vanilla installations without any extension added or the configuration changed. Straight out of the box! When I add a new module, for ex. the standard menu or breadcrumbs module, it's successful added to the database, shows in the frontend but not in the backend.

Template disappears (seems CSS files are blocked or something) when discovering new extensions. I have developed my own extensions (I develop them since my mambo-days ) and they are all working fine with 4.0.0. So I decided on the same server (hosted) to install a new installation of J! 4.0.0 and all the modules are visible from the beginning and I can discover my extensions without any problem. No templates that are disappearing.

This is the same for the frontend and backend modules. Used different browsers on different computers. All the same problem.

See images attached below, both are taken of fresh installations without any extensions on the same hosted server...




thanks for any suggestion

[GreenDot]

I cannot reproduce this problem. Discover (a module) works fine for me on 4.0.4. Are you testing on localhost or a hosting service? Have you tested with something other than your own extensions? As a developer I don't think you should be using discover for installation. What developer tools are you using?

I am testing it on a hosting service. I like to use discovery for my extensions. Always done it on that way and has never been a problem until now. I am using Visual Studio to code and upload it with a FTP program. Works well for years...

Strange is that the modules are not appearing in the backend of 4.0.3 and 4.0.4, while on the same server it works flawless with 4.0.0

( I love a good mystery hahaha )

[toivo]

I cannot reproduce this problem. Discover (a module) works fine for me on 4.0.4.

I had the same outcome after uninstalling a back end component in development and then copied the extension folder with the .xml manifest to /administrator and the .ini files to /administrator/language.

The Discover function installed the component all right, with no side effects to the back end styling. The test was done using Joomla 4.0.5 RC with PHP 7.4.26 and repeated in PHP 8.1.0. Both tests were done on a localhost site in Wampserver 3.2.6.

Are you sure the .xml manifest is 100 percent correct? Can your extension not be installed normally as a .zip package from System - Install - Extensions?

There must be other way, too, but it is easy to compress the extension folder containing the .xml manifest into an installable .zip package by using 7-zip in Windows: first select the subfolders, right click and select 7-zip and then 'Add to archive'.

If the above does not help, please post the results from the Forum Post Assistant (FPA) by following the instructions at https://forumpostassistant.github.io/docs so that the configuration can be reviewed.

[ceford]

I suspect something amiss with your hosting service. Something came up recently related to Cloudflare. Does the document source tell you anything about the css and/or js files. Does the console log tell you anything? Have you tried using a live header tool?

[GreenDot]

I cannot reproduce this problem. Discover (a module) works fine for me on 4.0.4.

I had the same outcome after uninstalling a back end component in development and then copied the extension folder with the .xml manifest to /administrator and the .ini files to /administrator/language.

The Discover function installed the component all right, with no side effects to the back end styling. The test was done using Joomla 4.0.5 RC with PHP 7.4.26 and repeated in PHP 8.1.0. Both tests were done on a localhost site in Wampserver 3.2.6.

Are you sure the .xml manifest is 100 percent correct? Can your extension not be installed normally as a .zip package from System - Install - Extensions?

There must be other way, too, but it is easy to compress the extension folder containing the .xml manifest into an installable .zip package by using 7-zip in Windows: first select the subfolders, right click and select 7-zip and then 'Add to archive'.

If the above does not help, please post the results from the Forum Post Assistant (FPA) by following the instructions at https://forumpostassistant.github.io/docs so that the configuration can be reviewed.

Thanks for trying out. I am using Php 7.4.14 hosted and 7.4.3 localhost. ZIPping is not the problem, using that already for 30+ years . Just love to upload the folders on the right place, discover it and have it working. It's in fact the same process only a different way of uploading. Has never been a problem since day 1. XML manifest is working fine as it works fine under 4.0.0.

Strange is that I cannot see my modules in the backend of 4.0.3 and 4.0.4 after a new installation while with 4.0.0 is working fine. And that has nothing to do with my XML, ZIP, Discover or my Extensions. Just out of the box Joomla 4.0.4.

See below images.



When I install 4.0.4 on my localhost, then it's no problem at all. I can see all the modules after installation. So it must be a problem with the hosting service and not a bug of Joomla.

I suspect something amiss with your hosting service. Something came up recently related to Cloudflare. Does the document source tell you anything about the css and/or js files. Does the console log tell you anything? Have you tried using a live header tool?

Correct! It must be something with my hosting service. I am digging now deeper into it.
When checking the source code of the site without any styling, it seems that any CSS/JS file is blocked to be loaded.



- discover : 4.0.3 and 4.0.4
- no styling : 4.0.3 and 4.0.4, now with 4.0.0 too
- no modules : 4.0.3 and 4.0.4

Strange is that it is first working and then suddenly after a while, it stops and any template disappears. Now also 4.0.0 start to give same issues. Strange!

[ceford]

The ERR_CONTENT_DECODING_FAILED is mentioned here:

viewtopic.php?f=808&t=990322

It is in the .htaccess file and the suggestion is you might be inadvertently using gzip twice.

[GreenDot]

The ERR_CONTENT_DECODING_FAILED is mentioned here:

viewtopic.php?f=808&t=990322

It is in the .htaccess file and the suggestion is you might be inadvertently using gzip twice.

YES! Thanks a lot! When disabling the GZIP in htaccess, the site (frontend & backend) is loading again properly with all the CSS/JS files. This solves also the Discover errors.

Sadly it doesn't solve the problem of the hidden modules.
When using J! 4.0.0 I can see the standard modules installed after installation, in J!4.0.3 and 4.0.4 they are hidden. All fresh installations out of the box on a hosting service. Also tried with installing J!4.0.0 first and upgraded to 4.0.4, and again, all modules disappeared.
See below images...

[ceford]

Sadly it doesn't solve the problem of the hidden modules.

Go to line 460 in administrator/components/com_modules/src/Model/ModulesModel.php and plant this piece of code:

Code: Select all

echo $query->__tostring();

In the list of modules I see this:

Code: Select all

 SELECT a.id, a.title, a.note, a.position, a.module, a.language,a.checked_out, a.checked_out_time, a.published AS published, e.enabled AS enabled, a.access, a.ordering, a.publish_up, a.publish_down,`l`.`title` AS `language_title`,`l`.`image` AS `language_image`,`uc`.`name` AS `editor`,`ag`.`title` AS `access_level`,MIN(mm.menuid) AS pages,`e`.`name` AS `name` FROM `#__modules` AS `a` LEFT JOIN `#__languages` AS `l` ON `l`.`lang_code` = `a`.`language` LEFT JOIN `#__users` AS `uc` ON `uc`.`id` = `a`.`checked_out` LEFT JOIN `#__viewlevels` AS `ag` ON `ag`.`id` = `a`.`access` LEFT JOIN `#__modules_menu` AS `mm` ON `mm`.`moduleid` = `a`.`id` LEFT JOIN `#__extensions` AS `e` ON `e`.`element` = `a`.`module` WHERE `a`.`client_id` = :aclientid AND `e`.`client_id` = :eclientid AND `a`.`published` IN (:preparedArray1,:preparedArray2) GROUP BY a.id, a.title, a.note, a.position, a.module, a.language, a.checked_out, a.checked_out_time, a.published, a.access, a.ordering, l.title, l.image, uc.name, ag.title, e.name, l.lang_code, uc.id, ag.id, mm.moduleid, e.element, a.publish_up, a.publish_down, e.enabled

We are looking for some anomaly in the list query criteria. If you see the same you will need to look at each individual parameter to find which one is at fault. This is assuming the modules really are there. What do you see in the list of Administrator modules?

[GreenDot]

Sadly it doesn't solve the problem of the hidden modules.

Go to line 460 in administrator/components/com_modules/src/Model/ModulesModel.php and plant this piece of code:

Code: Select all

echo $query->__tostring();

In the list of modules I see this:

Code: Select all

 SELECT a.id, a.title, a.note, a.position, a.module, a.language,a.checked_out, a.checked_out_time, a.published AS published, e.enabled AS enabled, a.access, a.ordering, a.publish_up, a.publish_down,`l`.`title` AS `language_title`,`l`.`image` AS `language_image`,`uc`.`name` AS `editor`,`ag`.`title` AS `access_level`,MIN(mm.menuid) AS pages,`e`.`name` AS `name` FROM `#__modules` AS `a` LEFT JOIN `#__languages` AS `l` ON `l`.`lang_code` = `a`.`language` LEFT JOIN `#__users` AS `uc` ON `uc`.`id` = `a`.`checked_out` LEFT JOIN `#__viewlevels` AS `ag` ON `ag`.`id` = `a`.`access` LEFT JOIN `#__modules_menu` AS `mm` ON `mm`.`moduleid` = `a`.`id` LEFT JOIN `#__extensions` AS `e` ON `e`.`element` = `a`.`module` WHERE `a`.`client_id` = :aclientid AND `e`.`client_id` = :eclientid AND `a`.`published` IN (:preparedArray1,:preparedArray2) GROUP BY a.id, a.title, a.note, a.position, a.module, a.language, a.checked_out, a.checked_out_time, a.published, a.access, a.ordering, l.title, l.image, uc.name, ag.title, e.name, l.lang_code, uc.id, ag.id, mm.moduleid, e.element, a.publish_up, a.publish_down, e.enabled

We are looking for some anomaly in the list query criteria. If you see the same you will need to look at each individual parameter to find which one is at fault. This is assuming the modules really are there. What do you see in the list of Administrator modules?

Hi, have added that $query and it displays the query.

I can see the modules in frontend and on the dashboard of the administrator. Only not in the modules manager of the administrator (site & admin). They are in the database so they should be listed as they are existing. When I add a new module, it will also not appear. When I add an article, it is saved in the database and listed in the admin.

Code: Select all

SELECT a.id, a.title, a.note, a.position, a.module, a.language,a.checked_out, a.checked_out_time, a.published AS published, e.enabled AS enabled, a.access, a.ordering, a.publish_up, a.publish_down,`l`.`title` AS `language_title`,`l`.`image` AS `language_image`,`uc`.`name` AS `editor`,`ag`.`title` AS `access_level`,MIN(mm.menuid) AS pages,`e`.`name` AS `name` FROM `#__modules` AS `a` LEFT JOIN `#__languages` AS `l` ON `l`.`lang_code` = `a`.`language` LEFT JOIN `#__users` AS `uc` ON `uc`.`id` = `a`.`checked_out` LEFT JOIN `#__viewlevels` AS `ag` ON `ag`.`id` = `a`.`access` LEFT JOIN `#__modules_menu` AS `mm` ON `mm`.`moduleid` = `a`.`id` LEFT JOIN `#__extensions` AS `e` ON `e`.`element` = `a`.`module` WHERE `a`.`client_id` = :aclientid AND `e`.`client_id` = :eclientid AND `a`.`published` IN (:preparedArray1,:preparedArray2) GROUP BY a.id, a.title, a.note, a.position, a.module, a.language, a.checked_out, a.checked_out_time, a.published, a.access, a.ordering, l.title, l.image, uc.name, ag.title, e.name, l.lang_code, uc.id, ag.id, mm.moduleid, e.element, a.publish_up, a.publish_down, e.enabled

[ceford]

Try this on line 460:

Code: Select all

		var_dump($clientId, $state);

I get values of 0 and '' (empty string).

Next, take the previous SELECT result and
change :aclientid and e:clientid to 0;
change :preparedArray1,:preparedArray2 to 0,1
change #__ to your database prefix
try the query in phpMyAdmin / SQL

I get a list of 22 results. If you do too I would start looking at the View files.

[GreenDot]

Try this on line 460:

Code: Select all

		var_dump($clientId, $state);

I get values of 0 and '' (empty string).

Next, take the previous SELECT result and
change :aclientid and e:clientid to 0;
change :preparedArray1,:preparedArray2 to 0,1
change #__ to your database prefix
try the query in phpMyAdmin / SQL

I get a list of 22 results. If you do too I would start looking at the View files.

Did follow your steps and I dont get any results but an error....

#1038 - Out of sort memory, consider increasing server sort buffer size

[GreenDot]

Try this on line 460:

Code: Select all

		var_dump($clientId, $state);

I get values of 0 and '' (empty string).

Next, take the previous SELECT result and
change :aclientid and e:clientid to 0;
change :preparedArray1,:preparedArray2 to 0,1
change #__ to your database prefix
try the query in phpMyAdmin / SQL

I get a list of 22 results. If you do too I would start looking at the View files.

Did follow your steps and I dont get any results but an error....

Code: Select all

#1038 - Out of sort memory, consider increasing server sort buffer size

have no control over my.ini as my server is hosted

[ceford]

You need to find out from your hosting service what the sort buffer size is set to. It should be 512K or more.

With phpMyAdmin, go to Home / Variables / sort buffer size. On my localhost it is 256K. On my cheap shared hosting site it is 512k.

[GreenDot]

You need to find out from your hosting service what the sort buffer size is set to. It should be 512K or more.

With phpMyAdmin, go to Home / Variables / sort buffer size. On my localhost it is 256K. On my cheap shared hosting site it is 512k.

Thanks for that. My localhost is 256K and my hosting 128K.
That means I have to contact my hosting provider to change it to 512K.

[GreenDot]

An update...

Emailed my hosting provider to change the MySQL setting... they replied that I should upgrade my plan to a VPS which is like 800% more expensive with them. As my plan is shared they cannot change it.

Of course I don't accept that. Most cheap providers put that setting on 256K or 512K and not a louzy 128K. So emailed them back that other cheap providers have standard a higher value. They advertise that their shared hosting plans are able to host Joomla!. Yeh older versions but not the latest version of 4.0.3 or 4.0.4. Told them it is important that a developer is able to upgrade their CMS to the latest version for security reasons. If they dont let me run J! 4.0.4 on their servers, they do false advertising and comprise the security of my website.

Let see what they answer...

[GreenDot]

Just to check. My Hosting Provider is refusing to change the sort buffer size setting to 512K instead of now 128K. Emailed them already a few times that Joomla 4.0.x sites cannot work proper without that setting. They say they cannot change it for a shared server. So far I understand it is just a MySQL setting and it's not hardware related. Other hosted sites on the same server will not be effected and only prevents issues with other customers. Is that correct? Is there another way to change it from my side? Really pissed on the hosting provider but still trying to convince them....

[brian]

For reference the default on mariadb is 2mb
the default on mysql is 256kb

However I really cant see any reason that you would need to increase the sort buffer size for such a simple query.