Is there a reason why the Virtuemart component sometimes returns "frontpage" as the Joomla View?
JRequest::getVar('view')
I am also getting URLs that are inconsistent. SEF is turned off, but sometimes the URL parameters disappear all the way back to the base URL. For instance when I add a product to the cart (any product), I get this url:
http://localhost/tdcoffee/index.php
Also, the Joomla "View" is returned as "frontpage" even though it isn't. But when I click on "Show Cart" in the Virtuemart module, I correctly get:
http://localhost/tdcoffee/index.php?page=shop.cart&option=com_virtuemart&Itemid=78
In this case the Joomla "view" returns NULL as it does on all the VM catalog pages. Both of these situations also happen on certain pages (but not all) during the checkout process. This poses a big problem for me as I am using PHP to put certain content on the Joomla frontpage using the "view" in an IF statement.
For instance I have my banner image that only shows on the front page:
<?php $fp=JRequest::getVar('view'); ?>
<?php if ($fp=='frontpage') : ?>
<h1 class="logo"><?php echo $mainframe->getCfg('sitename');?></h1>
<?php endif; ?>
This is working fine except in those couple of pages when everything falls apart. Is this a known problem, or should I submit a bug report? Or is this just the way it's supposed to work...?
I might also like to be able to use $_get statements to test for certain VM modes like checkout...although if anyone knows of a better way that will work with SEF turned on (when that comes available), that would be great.
Once again, many thanks. I hope you guys are taking some time off for the holidays and will get back to me when you can. Cheers!
Can any developers or experienced users take a minute to get back to me? This is a huge issue for the site I'm working on. To test this problem, I just did a clean Joomla 1.5 (rhuk_milkyway template) and VM installation, both latest builds. The results were the same. The url looses all parameters to become the base url at strange times:
*When you refresh or delete items from the cart (but not just by viewing cart).
*During the checkout process after the registration screen.
This situation also causes Joomla to think it is on the frontpage. Is this a temporary problem? Is there a work around?
As an alternative to JRequest::getVar('view') I've also tried:
<?php $menu = &JSite::getMenu(); ?>
<?php if ($menu->getActive() == $menu->getDefault()) { ?>
//frontpage code...
Same thing. Both methods work fine on all other pages.
VirtueMart 1.1 is in beta, we are handling one issue at a time.
Ok, that at least helps me to know that this is a known issue. I did check the tracker and didn't see it listed there. Do you want me to add it?
I hope I'm not asking the too many questions...or mentioning the obvious. I know the Virtuemart team is busy, not to mention that we just had the holidays (Happy New Year by the way!). Are you interested in my observations...someone with over 10 years HTML/CSS, knows Joomla, but somewhat beginning PHP skills?
I probably shouldn't have attempted a 1.1 site, but I'm too far along now. When I learned that VM stable was no longer supporting Joomla 1.5, I had already invested over six months learning Joomla 1.5 and was far along in designing a client's site. Basically I was forced to choose between going with the 1.1 beta or having to learn the fading Joomla 1.13. Since I didn't like the later idea much...I decided to take the gamble. I'm just going to hack my way through then update everything when it becomes stable. At this point it's all MOSTLY working great. Thanks everyone for your good work...Jason
I have looked & tested this but I cannot see a real problem except for the difference between going to cart from the info popup when product is added to the cart (cart1 attached) and going to the crt from the show cart link on the minicart (cart2). This second view is also seen if a product is deleted or updated from the info popup-cart. Is this what is being reported here?
[attachment cleanup by admin]
Jenkinhill, a big problem with this is that template designers right now don't have a way to use conditional statements based on Joomla views like frontpage. In your screen shots, I believe the reason the modules at the top appear is because Joomla thinks it's on the home page. If you like, take a look at my site:
http://tomanddave.web.aplus.net/ (http://tomanddave.web.aplus.net/)
Click on Shop or Order Coffee then add something to the cart. Next try to delete or refesh something in the cart. The whole layout collapses. Notice what happens to the url. The problem also happens during the checkout stages. If you want to test that, you can use "tester" and "lemmein" for a fake shopper. Actually the first screen is ok, but all the rest have the problem.
I have several reasons for designing my site this way, not the least for ease of admin (and confusion) for my clients. For instance the top menu has a different background image for the home page than all other pages. I could have two separate menus in two separate positions and assign their modules page by page within Joomla, but I'd rather not if I can help it. I hope you guys can take a look at this. I'm sure I'm not the only one who would benefit.
Just in case anyone is interested, I found a workaround to this problem. It's not exactly elegant, but it's pretty simple.
First, you must have a module position that is assigned only to the home page. There can be no other modules ever assigned to this position. If this isn't ideal, you can just use an empty position, assign a dummy module to it then in the CSS style it visibility:hidden. Then you simply test for a module being published in that position in your if statement. Here's an example:
<!-- in the head -->
<?php if $this->countModules('top')) {$fp='frontpage';} ?>
<!-- in the body -->
<?php if ($fp!="frontpage"){echo '<div id="bluebar">';}?>
<!-- close the div -->
<?php if ($fp!="frontpage"){echo '</div>';}?>
This creates a blue side bar on all pages that aren't the homepage. In other words, without managing two templates, you can have a different template for the homepage and other pages among other things. This also can make managing the site much less work, no need to constantly update the pages you have your modules assigned to whenever you add a new page (when you have more than one theme).
Still not sure and it seems kind of weird why this works while Joomla views do not. Even though Joomla thinks it's on the frontpage on certain VM pages, this method worked for me.
Hello,
i've got the same problem.
I'm using 2 different templates for my site.
when user goes through checkout process template changes.
however on step 2 (shipping method) the template defaults to the front page template.
im using joomla 1.5 and virtuemart 1.1.0 Stable.
I don't understand the workaround explained by unleash.it.
If anyone reads this who understands how the Joomla framework interacts w/Virtuemart, it might help all of us who are trying to vary our templates if you can explain this. Specifically, why does JRequest::getVar('view') sometimes return 'Frontpage' on certain VM pages (certain checkout and cart pages) that are not the front page?
Karlis, the workaround I have found has not been tested with assigning different Joomla templates in the back end as it sounds like you are doing. The problems you're having might be related to my problem or something different.
Instead of using multiple "templates", I created my template changes with conditional statements in PHP. I only have two "looks". One is for the front page (based on the Joomla "view" of 'frontpage'), and the other is all other pages (i.e. not 'frontpage'). If this is all you need, you may be able to achieve what you're looking to do w/my workaround for now.
I am having the same problem as Karlis. I use a different template for my commerce site than the rest of my pages.
My checkout process changes the template from the assigned Virtuemart template to the homepage template in step 2 of checkout.
Aravot, Do you know if this is a Virtuemart or Joomla bug? If Joomla, is someone working with Joomla folks to fix? This is a serious issue for us. Unleash-Its posted workaround doesn't apply in our our case as other pages in our site use the same template as the homepage.
thanks for your help.
Unleash.it,
I tried to do as you suggested but cannot get to the dev.virtuemart.net site. I get a "bad gateway" error when trying to go there.
Do you know if there is there another way to get to bug tracker?
thx.
Schafir
I'm having problems too. I decided to post the bug, but got an error message when trying to register:
HTTP Status 500 - java.lang.IllegalArgumentException: dto is needed to determine which listerens to notify
I get the same error when trying to confirm my registration. Very frustrating.
Unfortunately, I don't think that anyone associated with VM development really monitors these forums. I have posted a few questions over the last year with minimal, if any help or response.
Either the VM developers are very small in number, or their concerned with other matters. VM is not a plug and play extension and requires programming knowledge that many don't have.
Open-source is a double-edged sword for mission critical applications like Virtuemart. Low cost, but only voluntary support. It may be time to go somewhere else and pay for the solution, and get support for it.
Joomla 1.5 template switching is flawed. The solution is to use the default Joomla template for Virtuemart pages and assign the front page template to home. Works OK for me.
jenkinhill, thank you for your post but I am not sure I understand. My default template is for everything, including VM, BUT my frontpage, that that one is the assigned one.
helenbn - it worked for me but maybe the different templates I used don't have issues? Have not tried it again as I only use one template for my sites.
so, what's the scuttle butt on Joomla getting this template assigning issue resolved?
Soeren or Gregdev, can we get any help with this? Can you confirm that the problem is on Joomla's end?
By the way to those who didn't understand my posts earlier. If you assign templates in the admin, every time you (or your client) adds a new page to the site, you'll have to also go to the template manager and manually assign the page to the right template. Not a big problem for a small site that you maintain, but its a drawback if you have clients adding pages.
While my "hack" won't automate the process, it should allow you to have multiple templates now if you need them. Since my previous posts were maybe a bit fuzzy... and I'm about to do this thing again so it's a refresher for me... here goes again. It's not hard, but it will take some basic Joomla template/HTML/PHP knowhow.
STEP 1: In the admin, publish a module to an unused module position like user9. Assign it to whatever pages you want to theme differently. This module doesn't have to actually appear on the front end unless you want it to. One module allows for two "templates". If you need a 3rd look, publish a 2nd module, etc. Important: Make sure you publish each module to a position not occupied by any other module.
STEP 2: Use php If statements in your template to query for the module(s). If the module is published, you are on the page or one of the pages that you assigned the module to.
Something like this could go in the <head>:
<php
$mytpl=""
if ($this->countModules('user9')) {$mytpl='template1';} //change user9 to the module position you assigned the module
?>
This checks to see if your module is published. If it is, that means we are on a page(s) that you published it to. Next, wherever you want to vary the template, throughout your html you'd do something like:
<?php if ($mytpl=="template1") { ?>
<!-- your html/modules for template1 -->
<?php } else {?>
<!-- your html/modules for the alternate look -->
<?php } }?>
This code is set up for two different templates but you can modify it pretty easily to accommodate more. I've tested it in a couple of ways and it worked for me, but it may or may not distinguish the store properly. You might try assigning a module to all pages NOT the store and allowing the store to be the default.
Using this method, you would be doing your template switching using modules which is still manual. If there were only a variable within the Joomla framework to tell what category/component/frontpage we are on (and can be counted on), the process could be automated so no hack like this would be needed. Using the Joomla View DOES work when you're not using VM, which seems a bit strange (to me) that it's a Joomla problem...
I searched the joomla forum for this issue and I only found 1 post and it remains unresolved. http://forum.joomla.org/viewtopic.php?f=467&t=287369
Has anyone figured this out? I am not strong in php or any scripting language for that matter but it seems that if there is a way to pass through the url the option and checkout step, the correct template would display. Example, if you are on step 3, payment method, and you click the link under the second cart (to link back to step 2, shipping methods) the proper template appears. To a non-programmer like myself it seems possible to pass the '&option=com_virtuemart&checkout_stage=' through the url and still hide all the private data. Can someone tell me if this is even possible?? the link would be some variant of this for step 2 - shipping methods: https://yourdomain.com/index.php?page=checkout.index&option=com_virtuemart&checkout_stage=2
payment method would be the same only with '&checkout_stage=3', etc.
I am sure this is Joomla related, but I doubt it will be resolved anytime soon, just hoping for a workaround until its resolved completely.
unleash.it: I could not get your fix to work with my joomla/VM application.
Hi breezy, I made one change so far to my VM coding and it has fixed the correct template to load when you update the cart. I am not sure if it breaks anything else, but I know that it doesn't fix the coupon application so it probably will need to be used in other pages of code.
What I did was this:
in yoursitejoomla/administrator/components/com_virtuemart/html/basket.php
I searched for the section about half way down:
/* UPDATE CART / DELETE FROM CART */
$action_url = $mm_action_url.basename($_SERVER['PHP_SELF']);
this part 'PHP_SELF' calls for what page loads. I replaced with this:
/* UPDATE CART / DELETE FROM CART */
$action_url = $mm_action_url.basename($_SERVER['REQUEST_URI']);
Notice the 'REQUEST_URI'.See this site for a brief but layman's explaination:
http://php.about.com/od/learnphp/qt/_SERVER_PHP.htm (http://php.about.com/od/learnphp/qt/_SERVER_PHP.htm)
Now I imagine that I will have to follow this through the checkout into different pages to make it flow. I am not that far along in the setup, but if you get to that, please post whatever other pages you find that are in need of this change.
helenbd, that is a neat workaround. I am advised it will only work on Apache servers, though.
There is a code snippet (http://api.drupal.org/?q=api/function/request_uri/HEAD) seen elsewere that may enable REQUEST_URI to be used on Windows servers, but this would only be useful to those who use Joomla template switching.
http://api.drupal.org/?q=api/function/request_uri/HEAD
i have made some of this work by using this in your frontpage template index.php
<?php if (JRequest::getVar('option') == 'com_virtuemart' ){?>
try like this....
<?php if (JRequest::getVar('option') == 'com_virtuemart' ){?>
<div id="main"><jdoc:include type="component" style="xhtml"/>
<?php } else {?>
<div id="bottom-2"><jdoc:include type="modules" name="bottom2_vj22" style="xhtml" />
<?php }?>
you could leave the div after the "else" blank to just have the component included... this will work if your frontpage template is not completely different from you main template and just requires a few different elements... like a header image... for ex ample...
<?php if (JRequest::getVar('option') == 'com_virtuemart' ){?>
<img src="<?php echo $this->baseurl ?>/templates/<?php echo $this->template ?>/images/header2.jpg" alt="header" width="910" height="125">
<?php } else {?>
<img src="<?php echo $this->baseurl ?>/templates/<?php echo $this->template ?>/images/header.jpg" alt="header" width="910" height="346">
<?php }?>
hope this helps
Thanks jwnh... Definitely will give this a try when I have the chance. Have you tested it through checkout and in the account section? That's where 'view' conks out. Actually, if we can do this on any component, it opens up a whole world of automated templating.
On my first site, I only needed a couple variations so my code looked like yours, just do an IF statement when I needed a change. But what about the idea of just having two or more complete templates (one big PHP if statement), one after the other? Does anyone think that may cause a performance hit? I would imagine that the code only gets processed and sent to the browser when the IF is true?
Thanx helenbn. For the last two day i've been thinking how to fix that damn prob. i did like you said and it worked. You be blessed man!
Ah, tudor2004. I may be blessed, but my VM sure is not. I found that there were other pages that were also loading the home page template so I gave up. Totally.... :'(
If anyone figures out which other pages need code changes and where, please post back here.
helenbn,
Could you do a find and replace all ($_SERVER['PHP_SELF']); with ($_SERVER['REQUEST_URI']); or would that casue other problems futher down the track?
Cheers,
jonas
jonas,
Locally, I could do a find and replace. I am not real good at this, but when you unzip the component for VM locally, it doesn't build all the files. So something else must happen upon install. So I don't know how to do it on the server without downloading every dang file in the directory. >:(
But if someone knows another way, I'm all ears.
I don't know how to do the find and replace on the server - but I guess it is a good practise to have a local install of your site. You could download the whole site and set it up locally for testing etc.
Thanks
Jonas
In a perfect world...
Does anyone know how it would affect VM if I would do a find and replace for ($_SERVER['PHP_SELF']); with ($_SERVER['REQUEST_URI']); in the core files?
Would it completely stuff everything up?
Cheers
J
For the few who are following this that prefer to code their separate templates (rather than use the switcher), I've tried johnwasneverhere's method. I've tested on a local site with no SSL, but it appears to work fine through checkout and in the account areas, etc.
JRequest::getVar('option') returns the name of the component. In other words, if you are on the front page, or any normal Joomla page... you will get 'com_content'. If you are on a VM page you will get 'com_virtuemart', etc.
By itself, this is good if your design changes are segregated to your Joomla site (style #1) and your shop (style #2). However, it won't discriminate your front page, or any other particular Joomla page/VM/whatever page unless it uses a different component. One work around that seems to work for me (I like templates that have a different front page than the rest of the site ;), is to go:
<?php if (JRequest::getVar('option')=='com_content' && JRequest::getVar('view')=='frontpage') { ?>
the html
<?php } ?>
This combination seems to work and makes me pretty happy at least!
jonk: You should always try something drastic like that on a site that isn't live. With WAMP or XAMP, it's pretty easy to set up your own environment locally. If you get it to work, let us know. FYI, Dreamweaver has the ability to do a pretty good sitewide find/replace if you have it (it works on all PHP/HTML/XML files at least). If you make a backup before you do anything, you can easily restore if it fails.
Hi,
I did a find an replace for for ($_SERVER['PHP_SELF']); with ($_SERVER['REQUEST_URI']); but it didn't work for me. (The files changed were:basket.php savedbasket.php shop.savedcart.php )
I also tried the if statement but I must have done something wrong as it mess up the cart. When I press proceed (or next) the cart gets emptied. This works perfectlt on my localhost but when I uploaded the files it doens't work. Would it make a difference that I have shared SSL ie my URL change from http://www.mysite.com to https://www.webserver.sharedssl/mysite ?
Thanks
jonas
Hi Jonas, my guess is it might be the your ssl setup in the VM configuration, or something with your host. Try https://www.webserver.sharedssl/mysite/. That ending slash does make a difference if it isn't there already.
Also, if you're trying the IF statement, did you remember to make one template the default for all pages in Joomla? I doubt you'd be getting the problem because of some If statements. If anything, you'd see visual problems (i.e. your template changes didn't happen or reverted) if it wasn't working.
Using my old technique at least, works fine on live sites with SSL (but haven't tried w/shared).
I have now tried this a bit more.
I did a find and replace for ($_SERVER['PHP_SELF']) with ($_SERVER['REQUEST_URI'])
When I did that at first my links from the categories to the flypage didn't work - when I clicked the link it only reloaded the page.
I went back changed back most of them to ($_SERVER['PHP_SELF']) . Please see below for files that I did change. The number with in the brackets indicates how many instance it was in that file. I have tried it with coupons and it works. My site is not "live" (but I tried on the live server) as the payment gateway is not set up but it works up to that point.
The only problem I have is when I am at the checkout process all my links has the "prefix" of the Shared SSL (https://......) rather that the normal http. I am not to sure how to fix that and I don't know if that is how it is or if that is due to the changes I did. Any feedback regarding this would be appreciated.
Front End:
checkout\get_shipping_address.tpl.php
common\couponField.tpl.pnp
pages\checkout.thankyou.tpl.php
Back End
classes\ps_checkout
html\basket.php (3)
html\checkout.index.php (1)
html\ro_basket.php (3)
html\savedbasket.php (3)
html\shop.savedcart (1)
Cheers,
jonas
Just wondering if anyone found a solutions or a work-around that works?
Quote from: unleash.it on August 01, 2008, 04:46:30 AM
<?php if (JRequest::getVar('option')=='com_content' && JRequest::getVar('view')=='frontpage') { ?>
the html
<?php } ?>
THANK YOU... worked beautifully. :D
On my localhost setup johk's solution seems to work fine.
to johk, are you referring to the links in menus? If so, there is a setting in the menus through joomla that you can turn the SSL off for menu items, should fix your problem.
In response to hellenbn (post 26) you will also have to alter checkout.index.php line 96 with the following
$basket_html .= '<form action="'. SECUREURL.basename($_SERVER['REQUEST_URI']) .'" method="post" name="adminForm">
:)
Mkiehl
Hello,
This problem is mostly on VM's side. Joomla 1.5 has new way of resolving Itemid and option values. It uses JURI class to parse query string. VM passes 'index.php' instead of 'index.php?option=com_virtuemart&Itemid=<some id>' to JURI parser. So joomla just can't resolve correct option and Itemid values and uses default ('frontpage' with Itemid=1).
How to fix it? There are two ways. The first one is fixing all 'incorrect' VM's forms by changing tiny 'action="index.php"' to correct URIs with option and Itemid arguments. This solution is already provided by johk.
The second way to alter joomla code a little bit to support Itemid and option values from $_REQUEST. So here is my solution.
1. Find file named 'libraries/joomla/application/application.php'
2. Find these 2 lines (they are located somewhere around line #191):
// get the full request URI
$uri = clone(JURI::getInstance());
3. Just after these lines add this code:
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query .= ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query .= ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
The final result must be:
// get the full request URI
$uri = clone(JURI::getInstance());
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query .= ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query .= ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
That's all. I haven't tested it alot but seems it is working for me.
Pollar,
This one worked great for me. Fixed everything in one shot! I've been searching for hours and did not want to make all of the changes to my template with if statements.
Thanks,
Brick
mkiehl:
Those single line changes in basket.php and checkout.index.php fixed it for me.
J1.5.10, VM1.1.3, Apache.
The problem existed with and without the global SEF URLs, and it's fixed with and without them too (a lot of other threads suggest the problem is due to SEF stuff)
I suspect Pollar has the more correct solution - as already noted, REQUEST_URI won't work on IIS, and i've got a feeling it might cause trouble if you're using SSL. but for an easy fix that doesn't modify the J! core, i'm pretty happy.
thanks!
[a couple of edits for completeness]
thank you pollar it s work good with step2 but when you trie to add product in cart it's not work. i am redirected in my home page :-[ . if you have an idea thank you.
Ok it's work with john methode but when we can confirm order there is blank page do you have an idea ?
pleaseeeee
Okay, this was the closest forum that I found to help me solve my problem so I will add my solution too. I was wanting to use two templates one for the front page one for the rest. Every time i tried to access the store it would send me to the front page template which was just flash... After researching i started digging into the code..
in the ps_session.php file located in administrator/components/com_vertuemart/classes i changed the line 503
"$Itemid = "&Itemid=".$this->getShopItemid();"
to
"$Itemid = "&Itemid=1".$this->getShopItemid();"
This changes the item id to have an extra one in it which cause joomla to think that it is not the front page... I am not sure how good of a fix this is yet since i will only be using about half of the stores ability.
That seemed to mess a few things up so I also used dreamweavers ability to do a site wide replace and replaced all the virtuemart&Itemid=1 with virtuemart&Itemid=11.. looks to be working fine now..
NOTE: I am not using the cart or pay online just the CMS part of the component
Was this ever fixed? Well, that's a silly question because I'm using the latest stable version and the problem still exists.
Is there a "working" solution to this?
Thank you - this worked for me perfectly - tested live also.
Note to everyone that tries it - ensure file is saved with ANSI encoding!
Quote from: pollar on March 06, 2009, 02:09:56 AM
The second way to alter joomla code a little bit to support Itemid and option values from $_REQUEST. So here is my solution.
1. Find file named 'libraries/joomla/application/application.php'
2. Find these 2 lines (they are located somewhere around line #191):
// get the full request URI
$uri = clone(JURI::getInstance());
3. Just after these lines add this code:
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
The final result must be:
// get the full request URI
$uri = clone(JURI::getInstance());
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
That's all. I haven't tested it alot but seems it is working for me.
Brilliant Pollar!!
The solution below can screw up other mods.
I chased a problem with the Acajoom newsletter subscriber module (It did not work at all) that was solved when removing this hack.
So, back to square one I guess.
Quote from: pollar on March 06, 2009, 02:09:56 AM
Hello,
This problem is mostly on VM's side. Joomla 1.5 has new way of resolving Itemid and option values. It uses JURI class to parse query string. VM passes 'index.php' instead of 'index.php?option=com_virtuemart&Itemid=<some id>' to JURI parser. So joomla just can't resolve correct option and Itemid values and uses default ('frontpage' with Itemid=1).
How to fix it? There are two ways. The first one is fixing all 'incorrect' VM's forms by changing tiny 'action="index.php"' to correct URIs with option and Itemid arguments. This solution is already provided by johk.
The second way to alter joomla code a little bit to support Itemid and option values from $_REQUEST. So here is my solution.
1. Find file named 'libraries/joomla/application/application.php'
2. Find these 2 lines (they are located somewhere around line #191):
// get the full request URI
$uri = clone(JURI::getInstance());
3. Just after these lines add this code:
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
The final result must be:
// get the full request URI
$uri = clone(JURI::getInstance());
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
That's all. I haven't tested it alot but seems it is working for me.
thank you pollar!! i tried so many things and finally you solved it! i didn't encounter any troubles so far.
i changed the php_self to request_uri in some files before. is this causing any problems with your hack and should i therefore revert this change?
thank you
Hi.
I made a small modifaction in the ps_session.php and now I get the right item ids.
I made it becuse i have 2 different templates for 2 different categories but always when i clicked on a product the template changed back to the default.
This is my solution:
In ps_session.php go to line 463 and change the db SELECT to something else.
for example: $db->query( "SELECT category_id FROM #__vm_category WHERE category_publish=Y");
and than change the $db's value on line 465
for example: $db->f("category_id")
So it should look like this: function getShopItemid() {
if( empty( $_REQUEST['shopItemid'] )) {
$db = new ps_DB;
$db->query( "SELECT category_id FROM #__vm_category WHERE category_publish=Y");
if( $db->next_record() ) {
$_REQUEST['shopItemid'] = $db->f("category_id");
}
else {
if( !empty( $_REQUEST['Itemid'] )) {
$_REQUEST['shopItemid'] = intval( $_REQUEST['Itemid'] );
}
else {
$_REQUEST['shopItemid'] = 1;
}
}
}
return intval($_REQUEST['shopItemid']);
}
I know this is not the right way but it works and until now i didn't managed any error.
You have to manage that I don't have any extra functions turned on in the VM temlpate config so i don't have fetured products, or recently viewed products on category pages.
Quote from: tubaad on September 30, 2009, 09:37:04 AM
The solution below can screw up other mods.
I chased a problem with the Acajoom newsletter subscriber module (It did not work at all) that was solved when removing this hack.
So, back to square one I guess.
Quote from: pollar on March 06, 2009, 02:09:56 AM
Hello,
This problem is mostly on VM's side. Joomla 1.5 has new way of resolving Itemid and option values. It uses JURI class to parse query string. VM passes 'index.php' instead of 'index.php?option=com_virtuemart&Itemid=<some id>' to JURI parser. So joomla just can't resolve correct option and Itemid values and uses default ('frontpage' with Itemid=1).
How to fix it? There are two ways. The first one is fixing all 'incorrect' VM's forms by changing tiny 'action="index.php"' to correct URIs with option and Itemid arguments. This solution is already provided by johk.
The second way to alter joomla code a little bit to support Itemid and option values from $_REQUEST. So here is my solution.
1. Find file named 'libraries/joomla/application/application.php'
2. Find these 2 lines (they are located somewhere around line #191):
// get the full request URI
$uri = clone(JURI::getInstance());
3. Just after these lines add this code:
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
The final result must be:
// get the full request URI
$uri = clone(JURI::getInstance());
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
That's all. I haven't tested it alot but seems it is working for me.
Tubaad, I think I made a small misstake. Please try this code and tell me if it works for you.
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query .= ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query .= ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
'$uri->_query =' replaced to '$uri->_query .='
rian, I don't know if your modifications can be a problem. I run about 100 shops on virtuemart with this hack. No troubles so far too... :)
damnnn pollar I WANNA KISS you !! that worked perfectly thanks!!!
I second, pollar definitely deserves some lip love!
Worked perfect!!!!
Hey guys,
I have tried both of these solutions and I cannot get past the first step of the checkout process, it still just goes to a blank page.
I am using joomla 1.15 and the newest version of the vm component, any ideas why this still isn't working??
Love you Pollar. Here is a kiss from my side.
:) ummmmaah
The second method fixed it for me!!! Thanks Pollar!
I did have to disable SEF URL's and uninstall the "SEF Router for Virtuemart"
Hi all,
there's another discussion about another solution for this, over on http://forum.virtuemart.net/index.php?topic=65450.0
vannquish, I know your problem is already solved, but could you possibly try out the method on that page, and see if it works with SEF URLs and the SEF Router for Virtuemart?
I did a simple trickQuote
if(JRequest::getCmd( 'view' ) == 'frontpage' AND JRequest::getCmd( 'option' ) != 'com_virtuemart')
This worked for me
Because I'm on J1.0 something I make the change Change ($_SERVER['PHP_SELF']) with ($_SERVER['REQUEST_URI']) like said before and everything work well (multi-template and language). The only thing where isn't working it's the the Add to cart btn in the product page. Still bring to http://www.mywebsite.com/index.php
So I change in file /product_details/includes/addtocart_from.tpl.php around lign 21 <form action="<?php echo $mm_action_url ?>index.php" for the direct URL of the cart with all the parameter. (You can find this URL by using Cart Module).
work OK for me and the Joomfish switch don't "switch" to the wrong template.
hi,
i read that pollar used this hack to activate diferent templates for different VM categories. i patched my ps_session.php like pollar and also did that hack for the application.php (VM uri fix)
but now how can i set my templates that i installed for an categorie of VM?
perhaps someone can write an tutorial for that VM multi Template option, this would be great and post it in this forum?
thank you pollar, it worked for me too - after spending 2 days trying to work this out.
Appreciated
silentBob, that's not what we've been talking about here (at least as far as I've seen), but you might try metamod: http://extensions.joomla.org/extensions/access-a-security/frontend-access-control/3391
The idea would be to publish a custom HTML module with template markup only on certain virtuemart categories. Make sure to use JCE or something that doesn't strip it out...
Not the most elegant, but should work if you're not so great with PHP like me.
Quote from: pollar on March 06, 2009, 02:09:56 AM
Hello,
This problem is mostly on VM's side. Joomla 1.5 has new way of resolving Itemid and option values. It uses JURI class to parse query string. VM passes 'index.php' instead of 'index.php?option=com_virtuemart&Itemid=<some id>' to JURI parser. So joomla just can't resolve correct option and Itemid values and uses default ('frontpage' with Itemid=1).
How to fix it? There are two ways. The first one is fixing all 'incorrect' VM's forms by changing tiny 'action="index.php"' to correct URIs with option and Itemid arguments. This solution is already provided by johk.
The second way to alter joomla code a little bit to support Itemid and option values from $_REQUEST. So here is my solution.
1. Find file named 'libraries/joomla/application/application.php'
2. Find these 2 lines (they are located somewhere around line #191):
// get the full request URI
$uri = clone(JURI::getInstance());
3. Just after these lines add this code:
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
The final result must be:
// get the full request URI
$uri = clone(JURI::getInstance());
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
That's all. I haven't tested it alot but seems it is working for me.
Thanks a lot Pollar
This worked for me like a charm
Quote from: rgibbs421 on April 23, 2009, 21:37:22 PM
in the ps_session.php file located in administrator/components/com_vertuemart/classes i changed the line 503
"$Itemid = "&Itemid=".$this->getShopItemid();"
to
"$Itemid = "&Itemid=1".$this->getShopItemid();"
there is nothing at line 503 but at 548 :
// If we haven't found an Itemid, use the standard VM-Itemid
$Itemid = "&Itemid=" . ($tmp_Itemid ? $tmp_Itemid : $this->getShopItemid());
I have changed for
$Itemid = "&Itemid=1" . ($tmp_Itemid ? $tmp_Itemid : $this->getShopItemid());
but I still have a blank page when products are not found in search box
Quote from: rgibbs421 on April 23, 2009, 21:37:22 PMchanging application.php doesnt solve it for me
index.php?page=shop.browse&option=com_virtuemart&Itemid=9 gives a blank page when search box returns nothing
A big thank you Pollar!
Saved my weekend and many further hours of searching :)
Thank you Pollar! Great! I can now go to sleep (ok it's not too late 1:46)
Sheesh still no solution
this whole issue is ridiculous, i can tfind a solution that doesnt either work or stop something else working. virtuemart was working fine for me for many years and then this comes along. does this mean this problem will arise on my other virtuemart sites?
Quote from: pollar on March 06, 2009, 02:09:56 AM
Hello,
This problem is mostly on VM's side. Joomla 1.5 has new way of resolving Itemid and option values. It uses JURI class to parse query string. VM passes 'index.php' instead of 'index.php?option=com_virtuemart&Itemid=<some id>' to JURI parser. So joomla just can't resolve correct option and Itemid values and uses default ('frontpage' with Itemid=1).
How to fix it? There are two ways. The first one is fixing all 'incorrect' VM's forms by changing tiny 'action="index.php"' to correct URIs with option and Itemid arguments. This solution is already provided by johk.
The second way to alter joomla code a little bit to support Itemid and option values from $_REQUEST. So here is my solution.
1. Find file named 'libraries/joomla/application/application.php'
2. Find these 2 lines (they are located somewhere around line #191):
// get the full request URI
$uri = clone(JURI::getInstance());
3. Just after these lines add this code:
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
The final result must be:
// get the full request URI
$uri = clone(JURI::getInstance());
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
That's all. I haven't tested it alot but seems it is working for me.
fixed! thanks
A thumbs up for this. I still can't quite believe that this is an issue after reading threads of up to 2 years old with no fix.... finally stumbled on this. Thank you
thanks pollar :D
you just made my day :D
I'll append this link to the list of the
"joomla/virtuemart posts that made my day" in my signature
again, a million thanks :)
PS, i'm on VM1.5 joomla 1.5.21
no probs so far :)
I was not doing well with this... not after metamodguy posted his snippet. Then it dawned on me...
All these codes do fix everything... but then if you apply his to my situation
Quotethe pop confirmation dialogue pointed to some different cart. I made a menu link to this url. but this version of the cart still malfunctioned.
Well here is what happened.
All the fixes tell Virtuemart to get an actual Itemid or to at least try...
But then Metamod's snippet told the whole system to reference and redirect to Itemid=1 and that was still not working... one cart button brought up one page... and the tiny cart button in the pop up dialogue... pointed to another verion of the main storefront.... ODD!!! and this one was still broken
so I changed metatmod's code to make it a different number... and all is well
function getShopItemid() {
if( empty( $_REQUEST['shopItemid'] )) {
$db = new ps_DB;
$db->query( "SELECT id FROM #__menu WHERE link='index.php?option=com_virtuemart' AND published=1");
$ids = $db->loadResultArray();
if ( !is_array($ids) or count($ids) == 0 ) {
$_REQUEST['shopItemid'] = 18;
} else if ( array_search( $_REQUEST['Itemid'], $ids ) !== false ) {
$_REQUEST['shopItemid'] = $_REQUEST['Itemid'];
} else {
$_REQUEST['shopItemid'] = $ids[0];
}
}
return intval($_REQUEST['shopItemid']);
} Yeah so far so good. Thanks for everyone's help on this!
Your a genious Pollar, really saved my day. Those this file get overridden often when joomla updates its core files?
Thanks
Just want to add my thanks to pollar for his fix. It worked perfectly... :)
I don't understand why this would still be an issue with Virtuemart after all this time. :o Hopefully a fix can be built into future versions.
Cheers,
Chris
Quote from: vannquish on September 20, 2010, 17:58:12 PM
Quote from: pollar on March 06, 2009, 02:09:56 AM
Hello,
This problem is mostly on VM's side. Joomla 1.5 has new way of resolving Itemid and option values. It uses JURI class to parse query string. VM passes 'index.php' instead of 'index.php?option=com_virtuemart&Itemid=<some id>' to JURI parser. So joomla just can't resolve correct option and Itemid values and uses default ('frontpage' with Itemid=1).
How to fix it? There are two ways. The first one is fixing all 'incorrect' VM's forms by changing tiny 'action="index.php"' to correct URIs with option and Itemid arguments. This solution is already provided by johk.
The second way to alter joomla code a little bit to support Itemid and option values from $_REQUEST. So here is my solution.
1. Find file named 'libraries/joomla/application/application.php'
2. Find these 2 lines (they are located somewhere around line #191):
// get the full request URI
$uri = clone(JURI::getInstance());
3. Just after these lines add this code:
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
The final result must be:
// get the full request URI
$uri = clone(JURI::getInstance());
// VM uri fix
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid']) || !$uri->getVar('option') && isset($_REQUEST['option'])) {
if (!$uri->getVar('Itemid') && isset($_REQUEST['Itemid'])) {
$uri->_query = ($uri->_query ? '&' : '').'Itemid='.(int)$_REQUEST['Itemid'];
}
if (!$uri->getVar('option') && isset($_REQUEST['option'])) {
$uri->_query = ($uri->_query ? '&' : '').'option='.$_REQUEST['option'];
}
parse_str($uri->_query, $uri->_vars);
}
// end VM uri fix
That's all. I haven't tested it alot but seems it is working for me.
fixed! thanks
ditto, thanks from me too!
BIG THANKS!!
searched forums and tried hacking action_urls for 2 hours!
You saved my bacon!
David
I was stuck on this problem since last two days it really help full for me