• Home
  • Get help
  • Ask a question
Last post 5 hours 5 min ago
Posts last week 81
Average response time last week 4 hours 29 min
All time posts 67934
All time tickets 10501
All time avg. posts per day 20

Helpdesk is open from Monday through Friday CET

Please create an (free) account to post any question in the support area.
Please check the development versions area. Look at the changelog, maybe your specific problem has been resolved already!
All tickets are private and they cannot be viewed by anyone. We have made public only a few tickets that we found helpful, after removing private information from them.

#1237 – Virtuemart 3.0.10/Save Cart Plugin error

Posted in ‘sh404SEF’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Thursday, 29 October 2015 18:13 UTC
abpdjs
In the VM account settings area, this save cart plugin creates a tab to recall shopping cart data. If sh404sef is disabled, it works exactly as it should. When I enable it and then go to account setting for VM, it doesn't crash, but the page render is all mess up and unusable. If i disable the saved cart plugin, the render of account settings is fine.

It may be because they are still using some deprecated methods, but that shouldn't cause the screen to not render correctly when 404 is enable if it is working with 404 disabled. I'm not sure where to turn and their support is not great. I need to have this 3rd party for cart recalling but I want to continue to use 404 as well.

The problem is in this area of code. If I comment out the last line, everything renders, but the tab disappears, but ultimate doesn't cause the page to render incorrectly:

protected function onProfileFE() {

		$db = JFactory::getDbo();
		$user = JFactory::getUser();
		//load CSS
		$this->loadCss();

		//load JS
		$this->loadJs();

		//get upload widget
		$content = $this->loadView();

		// get output buffer
		$buffer = JResponse::getBody();

		//process DOM
		$xml=new DOMDocument();
		$xml->loadHtml($buffer);
		$xpath = new DOMXPath($xml);
		$tabs = $xpath->query('//*[@id="ui-tabs"]')->item(0);

		//insert widget
		if($tabs) {
			$node = $xml->createElement("foo");
			$tabs->appendChild($node);
			$buffer = str_replace('<foo></foo>',$content,$xml->saveHTML());
		}
		//$buffer = $xml->saveHTML();
		// set output buffer
		JResponse::setBody($buffer);

	}



I've tried:

JResponse::setBody($buffer); >>> JFactory::getApplication()->setBody();


and

JResponse::setBody($buffer); >>> JFactory::setBody($buffer);


But neither fix the issue, if I comment out:

JResponse::setBody($buffer);


The page will load correclty

Any ideas?

Thanks,
Chris
Thursday, 29 October 2015 18:27 UTC
wb_weeblr
Hi

Is this plugin a system plugin? If so, have you tried making sh404SEF system plugin before then after this one?

Their method is a bit dangerous, as there can be issues if the previously existing HTML (in the response object) is fully well formed.

but that shouldn't cause the screen to not render correctly when 404 is enable if it is working with 404 disabled.
That's not the problem. They are manipulating the page content (just like sh404SEF is doing also). This comes with risks sometimes. The fact that it "works" when sh404SEF doesn't mean the method is valid, only that when nobody else touches the result it's ok but if more processing is required, it's not.

Also note that problem could be the result of prior transformation by sh404SEF; Which is why it's interesting to see if changing the order of the plugins helps.

Rgds
 
Thursday, 29 October 2015 18:44 UTC
abpdjs
Hello,

Yes, it is a plugin.

I did go ahead and move it "down" the list to near "last" location and it works fine now.....good catch!

So, I am willing to send you the plugin if it will help "solve a greater issue". The plugin in bought and paid for so there is no issue there.

I just bought 404 to help my site with SEO and such and just noticed that links were "bad", I'll deal with that later, my primary concern is to understand if I we should look for a way to "fix" what I have, or will be it "ok" with 404 as it stands going forward?

Thank you for you immediate response, it seems your service is everything people said it would be.

Best,
Chris
Thursday, 29 October 2015 18:51 UTC
wb_weeblr
Hi

Glad that it worked out and thanks for your nice comments. It's a big advantage for support if the actual developers are directly involved.

As for testing, just having the plugin is probably not going to be enough, or rather not efficient. I'll need to spend an awful lot of time just setting up a VM site, see of this plugin works, set it up, do some testsing etc. In addition, there's are 50% chances I won't have any problem on my local test bed, as this kind of things depends also a lot on PHP version, PHP modules loaded and their parameters, gzipping or not, whether Gzip is done by Joomla or the server, etc
Most likely, I won't manage to go through all of that.
If you were to make an akeeba backup of your development site, experiencing the problem, and make that available to us, we could work on it, at leasts, we'd save a lot of time. This is how we usually do when there's a problem that's not "obvious".

and just noticed that links were "bad", I'll deal with that later, my primary concern is to understand if I we should look for a way to "fix" what I have, or will be it "ok" with 404 as it stands going forward?
I'm not sure I entirely get what you mean, but I can comment that "cool URL don't change". So what you don't want to do is launch your site, have some of it indexed by Search engines and start ranking, and then modify some of your URLs. That's bad, and worse than having "bad" URLs.

Hope this can help.

Rgds
 
Sunday, 01 November 2015 15:29 UTC
abpdjs
The reordering solved the issue and it seems fully operational, I'll say we can close this for now. Thanks your help.

Chris
Monday, 02 November 2015 09:26 UTC
wb_weeblr
Hi

Closing this ticket now, feel free to open a new one as needed. If you do so, please mention this ticket number in the new one.

If you created any superadmin account for us, be sure to delete or block it now to avoid unecessary risk in the future.


Rgds
 
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.