vmloaderpluginupdate Blocks Joomla 4 Registration Page

[T.A. Garrison, LLC]

Yesterday, May 9, 2022, I got an alert from a site stating that my registration page was inaccessible. I almost just ignore that, but then decided it's simple enough to take a look.

Without a doubt, the registration page was NOT available - regardless of what I tried.
I've been through an extensive discussion in the Joomla forum with some of the main developers and it was just a few minutes ago that ceford "finally" found the problem. He suggested disabling "vmloaderpluginupdate" to see what happens.

Low and behold, the registration page appeared without any issues.

The plugin name is "VM Framework Loader during Plugin Updates" in the list of plugins. The "element" is vmloaderpluginupdate.
I would never have guessed that would be an issue. But, in fact, that plugin has now been disabled and my site is back working 100%.

I have plenty of data to provide, although nothing of the logs generated indicated that was the problem. But there were several lines pointing to VM.

I'm using Joomla 4, just updated today to v4.1.3, and I'm using VM 4.0.0 10645.

I was using Php 8.1, but after some discussion, I had to make a change to Php 8.0, and then I switched and am currently using Php 8.0.
In both Php 8.0 and 8.1, as well as Php 7.4, the registration page cannot be accessed. I get a 500 error.
After checking and rechecking all links, I was lost - even with Joomla developers who were also scratching their heads. But ceford asked today if I'd attempted to disable the VM updater. I had not, but did at his suggestion and "case solved".

Let me know what else you may need.

[GJC Web Design]

Which registration page are u discussing?  The Joomla one ->  option=com_users&task=registration.register

or VM's register  option=com_virtuemart&view=user

because the vmloaderpluginupdate plugin redirects J to VM registration if set in the plugin.. is this not working in J4 ( with what VM version?)

What is the full trace of the 500 error - I suspect it is redirecting but then getting a fatal error

[T.A. Garrison, LLC]

Hi there. It's been a minute.

Yes. The default Joomla registration page.

And no. There is a problem with the redirect.
I could not figure out the error eluding to a redirect until just now when you said that VM does a redirect.

So you nailed it. The redirect to "get" to the Joomla default registration page is not working right.

If I could provide you with more of the 500 error I would. But you know, 500's are as non-descript as it can get.
I've run every type of debug within J4, including switching to logging "Nearly Everything", but nothing provides enough information for any of "us" to figure out the issue.

Because you mentioned the VM redirect, that all makes sense now. The 500 error simply stated the HTTP header was malformed. At which point we just threw up our hands.
But ceford asked today if I had tried to disable the VM updater. So he must either have seen something in the logs or had a suspicion about anything that may try a redirect.

If you want, when you are available to review, I can enable the plugin long enough for you to see the 500 error.
This is the only thing that "I" could see made any sense, and makes a lot more sense now from what you stated:

0 You have not supplied a valid HTTP status code

That's in the 500 error and along with:
1 () JROOT/libraries/vendor/joomla/application/src/AbstractWebApplication.php:507
2 Joomla\Application\AbstractWebApplication->redirect() JROOT/libraries/src/Application/CMSApplication.php:993
3 Joomla\CMS\Application\CMSApplication->redirect() JROOT/plugins/system/vmloaderpluginupdate/vmloaderpluginupdate.php:101
4 plgSystemVmLoaderPluginUpdate->onAfterRoute() JROOT/libraries/src/Plugin/CMSPlugin.php:285
5 Joomla\CMS\Plugin\CMSPlugin->Joomla\CMS\Plugin\{closure}() JROOT/libraries/vendor/joomla/event/src/Dispatcher.php:486
6 Joomla\Event\Dispatcher->dispatch() JROOT/libraries/src/Application/EventAware.php:111
7 Joomla\CMS\Application\WebApplication->triggerEvent() JROOT/libraries/src/Application/CMSApplication.php:1121
8 Joomla\CMS\Application\CMSApplication->route() JROOT/libraries/src/Application/SiteApplication.php:820
9 Joomla\CMS\Application\SiteApplication->route() JROOT/libraries/src/Application/SiteApplication.php:228
10 Joomla\CMS\Application\SiteApplication->doExecute() JROOT/libraries/src/Application/CMSApplication.php:278
11 Joomla\CMS\Application\CMSApplication->execute() JROOT/includes/app.php:63
12 require_once() JROOT/index.php:32

And if you see line 3, that's where ceford got the idea to question that plugin.

The VM version is 4.0.0 10645 (I believe that's the latest).

I suppose, now that I have more to work with, I could review the file mentioned and see what's happening. But that's not going to help others - so I've posted the "bug".

[Studio 42]

vmloaderpluginupdate have an option to disable Joomla user registration.
Have you uncheck this option in the plugin settings ?

[GJC Web Design]

my question exactly .. have u set no redirect?

line 101 is simply

$l = JRoute::_('index.php?option=com_virtuemart&view=user'.$t);
$app->redirect( $l,$msg);

in J4 JRoute has been changed to Route.. ( go figure.. )  maybe that's all that is needed?

$l = Route::_('index.php?option=com_virtuemart&view=user'.$t);

[T.A. Garrison, LLC]

Having used Joomla since it was Mambo, and Virtuemart since that same time, I have never had an issue with Virtuemart and never had reason to even consider that the updater plugin has options.

So no. Until I just now looked - after reading your question - I have not flipped to "No" redirect.

But my response to that is this. I know I've disabled the plugin, but that was simply to see if that was the problem. Now that I know I can disable the rerouting and not have to disable the entire plugin, I "can" do that, but if I had just done that and not posted here, how would that have helped the VM developers?

I'll disable the rerouting and enable the plugin and see if there are any issues.
Everything seems to function normally, so I'll leave the plugin enabled with the redirect now disabled.

[p.barg]

Hello,

I'm encountering the same problem with the redirection to VM registration. If I disable redirection in the plugin, the registration page (standard Joomla!) is shown, but If I enable the
redirect, I get the error page.

Any further insights here?

Petra

[GJC Web Design]

Have you tried the JRoute to Route? Is this J4?

What is the error backtrace?

[p.barg]

Hi,

yes, this is J4. The error trace is like the one described by LTCreations.

I've just tried to exchange JRoute by Route in the plugin. That results in Error "Class 'Route' not found"

[T.A. Garrison, LLC]

I just now tried a test, after updating Joomla (there was an update today to J4.1.4).
Part of that update was also for VM, and I'm now using 4.0.2 10661.
That version "did" update some of the template files - 6, in fact. I was able to check each of the files and the overrides were happy - except that the 55 overrides from previous VM updates is still indicated.

I flipped No to Yes (to redirect registration to VM), and it failed. The registration page is still blocked when the VM redirect is enabled.

Whenever I have updates for "anything", I get an error in admin that the "vmpayment" VM_Payment - eWay cannot be updated.
I've had that for quite some time with "every" update - meaning, I'm "not" updating VM - other components - and that error is blaring at me.

I thought it would be simple enough to just disable that plugin. But, that's not stopping the error. Even with eWay disabled I get the update error.

That plus the 55 Overrides to check drive me nuts - but none of that stops the site from functioning in any way. Although the site is new and I haven't had anybody attempt to purchase anything. I'll be doing some testing on that front to assure users have no problems.
The 55 Overrides will need to be addressed via the database. There is no way to check "anything" related to VM because none of the files updated are part of the admin functions, which are dealing with templates in the overrides.
I used the database method for updating the overrides a few files weeks back, but I haven't taken the time to go through and update the status in the db for the VM tables.
I was hoping there would be a "fix" for that with future updates.

Unless someone has a great idea of how to update the "Status" in the db, I'll do it manually, again, but 55 is going to take a while...

[Milbo]

Ahh that makes no fun. Let me take a look on it.

[Studio 42]

For information.
I had the problem on a website and the guilty was T4 frame + VIrtuemart
The file is /plugins/system/t4/src/t4/Document/Template.php
I do not checked what the T4 developper changed

[Milbo]

Interesting. Then I will wait for responses of the others. Maybe they also use this framework.

[p.barg]

I'm not using any framework like t4

[Milbo]

That plus the 55 Overrides to check drive me nuts - but none of that stops the site from functioning in any way. Although the site is new and I haven't had anybody attempt to purchase anything. I'll be doing some testing on that front to assure users have no problems.
The 55 Overrides will need to be addressed via the database. There is no way to check "anything" related to VM because none of the files updated are part of the admin functions, which are dealing with templates in the overrides.
I used the database method for updating the overrides a few files weeks back, but I haven't taken the time to go through and update the status in the db for the VM tables.
I was hoping there would be a "fix" for that with future updates.

Unless someone has a great idea of how to update the "Status" in the db, I'll do it manually, again, but 55 is going to take a while...

As I wrote in the other post. The joomla checker seems to be too sensitive. Maybe one "space" is all the difference.