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.
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
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".
vmloaderpluginupdate have an option to disable Joomla user registration.
Have you uncheck this option in the plugin settings ?
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);
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.
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
Have you tried the JRoute to Route? Is this J4?
What is the error backtrace?
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"
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...
Ahh that makes no fun. Let me take a look on it.
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
Interesting. Then I will wait for responses of the others. Maybe they also use this framework.
I'm not using any framework like t4
Quote from: T.A. Garrison, LLC on May 24, 2022, 23:03:38 PM
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.
Ah found it,... it has a redirect with message, which is not allowed in j4 anylonger. So the fast fix is in line 101 this
$app->redirect( $l,$msg);
becomes just
$app->redirect( $l);
Btw also one of the things,which they changed and it breaks old code unecessary completly. They could just have declared, it wont work any more, but not breaking old code by just leaving a dummy parameter.
indeed - that solves the issue :)
I don't know why I haven't had any update notifications from the forum, but I'm just now getting back to check several issues with J4 and VM, this being one of them with the (now) 57 updates from VM that need to be fixed in the database. I gave up on any hope for a fix using VM for registration.
That said, I have to add that I'm about ready to give up with VM.
I have fought all the problems - regardless if it was something for which J4 was responsible - and finally got a legitimate sale today through VM.
LITERALLY - 10 times I've received a confirmation from VM for the 1 sale. I checked everywhere to be able to assure my customer that they have not been charged more than once, and I am correct - only 1 time they were charged.
But the customer has received 5 invoices.
I've been sent 10, but the system continues sending them to me still! It's now been over 3 hours since the order was placed and I'm still getting confirmation messages. It started at about every 5 minutes, grew to roughly every 10 minutes, then to 30 minutes, and now it seems 40 minutes.
To make things more confusing, for the first time when using VM (old or new), "every" confirmation from this one order has a Subject of "=?utf-8?B?Wzc5TEEwM10sIENvbmZpcm1lZCBvcmRlciBieSBNciBFcmljIE1lemEsIHRvdGFsICQzNzkuNDA=?="
I have no idea what that is, but I think it's just that one thing to push me over the edge. Fixing the Subject is the least of my worries. If that were the only or most serious problem I would do as Max has mentioned - ignore them.
The point is, the confirmations continue to be E-mailed to me for now more than 3 hours. This is what I'm left with after all the other problems from VM since installation in January of this year.
Thus far I've had no response about how best to address any of the issues, so I'm very close to abandoning VM. The alternatives are horrible. But I can't have a site from which I stream weekly that has a very prominent part of the site causing issues.
Are there things I could just ignore? Maybe, but that's not really the point. When a customer purchases something they expect things to work as properly - not malfunction all over the place. Even if some of the malfunctions are things I could ignore, they are still added to the list of problems.
And when there are problems that customers see, that's where I have to make a decision about whether to allow that to happen, or change something so I no longer have "any" issues. I and my site are far too prominent as a developer to have the ongoing issues with my site.
what versions are u on?
The email subject thing was fixed a while back
the latest is https://dev.virtuemart.net/attachments/download/1336/com_virtuemart.4.0.7.10720_package_or_extract.zip released yesterday with a huge number of problems fixed
I'm using VirtueMart 4.0.6 10690
And, I'm still getting the E-mail notifications about the product purchase. The time between them has slowed dramatically. But still even if they continue once every 24 hours is too much. But they come through much more often than that. I got the last one about 45 minutes ago.
You've provided a link to the latest version, but you stated the E-mail was fixed "...a while back..."
That, plus the fact that I've had no notifications of any updates in the last few days prompts me to think that whatever was "supposed" to be fixed "...a while back..." and was not addressed since the issue is happening now to the version just prior to the latest, would indicate that the issue would not have "also" been addressed in this latest version because it would have been crossed of the "fix" list for this latest version as "already fixed".
Isn't that correct?
the number of versions between 4.0.6 10690 and 4.0.7.10720 is 29 dev releases and 2 months!!!! .. each one contains further bug fixes
It is pointless reporting bugs from a 29 versions, 2 month old release....
make a clone and test the latest is the way forward...
Dev versions can be found on http://dev.virtuemart.net/projects/virtuemart/files - if you find a bug it's a good idea to test the most recent RC release to see if that bug is fixed.
GJC - It would seem obvious that there are unreleased versions between 4.0.6 10690 and 4.0.7.10729
To the end user, if we have an update available, we don't know how many "other" versions are available. We're developing sites and providing SEO - not developing the software.
That leads me to understand there was a fix after "my" version and before the "latest" version which may well have addressed my issue.
I'll download the 4.0.7.70129, clone my site and see if that works.
there is constant development going on and generally new versions released every few days to the tester group and /or on http://dev.virtuemart.net/projects/virtuemart/files or mentioned in the forum somewhere.
These versions can hardly be released as stable updates until tested.
Software needs to be tested .. with a software as complex as VM that now has to run on 2 different versions of Joomla there are dozens of different configuration combinations and php versions -
with only a small number of testers it is a huge task to find every bug.
Therefore I don't think it is unreasonable for website builders who are using this free software to contribute something back to the project by getting involved in the testing process ... if VM lacks anything it is having enough testers..
It is simple enough to have a clone site, keep an eye on the forum or check http://dev.virtuemart.net/projects/virtuemart/files every so often, try the latest test version and report any bugs you find on your particular install.
This way bugs are found and fixed.
When reporting a bug it is pointless if the version you are reporting on isn't mentioned or if it isn't the latest ..
and of course a quick summary of how to recreate the bug and if a fatal etc a php trace. And mention the php version.