Hello!
I can't make Virtuemart to language localize on Category and Product detail level.
Example:
English cat page: http://www.liponordic.com/index.php?option=com_virtuemart&view=category&virtuemart_category_id=20&Itemid=489&lang=en
Points at Norwegian associated cat page: http://www.liponordic.com/index.php?lang=no&Itemid=750&option=com_virtuemart
This however does not work and the user is routed to Norwegian shop front page.
The correct link should be: http://www.liponordic.com/index.php?option=com_virtuemart&view=category&virtuemart_category_id=20&Itemid=750&lang=no
I assume that this is a routing bug on the part of Virtuemart. Can you confirm ?
Cheers,
prokop
Hi,
Have you add a menu for each Virtuemart shop Main page in all your languages ?
If not, the Joomla language switcher don't work properly.
Hello Studio42
If you are asking if I have a "Front Page" Virtuemart menu in every language in my main menu module, then the answer yes.
They all point to: "index.php?option=com_virtuemart&view=virtuemart&productsublayout=0"
Can you think of other shortcomings or do I report this as a VM bug ?
Cheers,
prokop
Look in your template how the category view set links.
Perhaps your template don't set the itemId
your link for producdetails is : http://www.liponordic.com/index.php?option=com_virtuemart&view=productdetails&virtuemart_product_id=116&virtuemart_category_id=20
but shoud be : http://www.liponordic.com/index.php?option=com_virtuemart&view=productdetails&virtuemart_product_id=116&virtuemart_category_id=20&Itemid=489
vm 3.6 use this :
in YOURSITE\components\com_virtuemart\sublayouts\products.php
$link = empty($product->link)? $product->canonical:$product->link;
echo JHtml::link($link.$ItemidStr,vmText::_ ( 'COM_VIRTUEMART_PRODUCT_DETAILS' ), array ('title' => $product->product_name, 'class' => 'product-details' ) );
for info $ItemidStr is set before:
$ItemidStr = '';
$Itemid = shopFunctionsF::getLastVisitedItemId();
if(!empty($Itemid)){
$ItemidStr = '&Itemid='.$Itemid;
}
Hello Studio42,
Thanks for the speedy answer. It can't be my template as I test on default templates to make sure it is a cross-template issue.
I now believe, that this is a Joomla routing issue. See my ticket for an slightly different but related issue: http://forum.joomla.org/viewtopic.php?f=728&t=880294 (http://forum.joomla.org/viewtopic.php?f=728&t=880294)
You are right that my example is confusing. Here is a simpler example:
If I use the URL you suggest: http://www.liponordic.com/index.php?option=com_virtuemart&view=productdetails&virtuemart_product_id=116&virtuemart_category_id=20&Itemid=489&lang=en (http://www.liponordic.com/index.php?option=com_virtuemart&view=productdetails&virtuemart_product_id=116&virtuemart_category_id=20&Itemid=489&lang=en) and try to use the flags, they point me at:
da: http://www.liponordic.com/index.php?lang=da&Itemid=687&option=com_virtuemart
se: http://www.liponordic.com/index.php?lang=se&Itemid=712&option=com_virtuemart
no: http://www.liponordic.com/index.php?lang=no&Itemid=750&option=com_virtuemart
As you see, the "&view=productdetails", "&virtuemart_category_id=" and "&virtuemart_product_id=" are dropped from the routing URL's.
I suspect a buggy language switcher or core routing issues.
I made a Joomla new ticket here: http://forum.joomla.org/viewtopic.php?f=728&t=880554 (http://forum.joomla.org/viewtopic.php?f=728&t=880554)
Cheers,
prokop
This is not a Joomla language problem !
If you want switch correctly, then you have to associate the joomla menus per language and actiavte the plugin(if it's not done)
Virtuemart cannot make a language association with the joomla language switcher, because the joomla lang switcher, look only for menu(as i know)
Hi Studio42
Are you suggesting that I have to make a joomla menu in every language for every product in my shop, in order to correctly associate via the language switcher ?
Cheers,
prokop
I Wrote for some time a language switcher, but this not work in Virtuemart, because virtuemart router use an instance for all languages.
I have report it to valerie for 1 Year but this was never fixed(this is why you cannot buy it).
With a little change you can use it, but this need some core changes,
If you are interested, whe can look together to have a language switcher module for all your shop(product,categories ...). With a little change in the router file.
Quote from: prokops on March 22, 2015, 11:24:19 AM
Hi Studio42
Are you suggesting that I have to make a joomla menu in every language for every product in my shop, in order to correctly associate via the language switcher ?
Cheers,
prokop
Yes that is the joomla way. Shadow menus.
The problem probably is related to your menus not being identical in all your languages. In English you have a top menu plus one in the left sidebar. For Norwegian, Dansk and Swedish the sidebar menu and therefore the menu item ids Joomla uses for switching languages are missing. I would suggest to try adding the side menu also for the three other languages and check if the Joomla router works correctly afterwards.
Guys, to underline
I have no clue about the multilanguage stuff, but what I learned is "Create for any shit a shadow menu item". and j2.5 had a fallback, the new router strategy of Hannes Papenberg is even more strict, no itemid => fallback to home. That is a joomla decision, not ours
Hi Max and CIA the menu's and products not leading to the translated item but to the vm frontpage is something most of us learned to deal with. Not ideal of course but not a drama.
However I'm reading more and more people https://forum.virtuemart.net/index.php?topic=128604.0 with problems showing additional languages.
Is a bit strange that a joomla 3.x website appears perfectly translated and only fails in the vm shop pages: front, products and categories. This is happening to many of us recently so there is either and issue with the language switcher module, a cache issue or with the route file but there must be something causing this errors.
Regards
I think,it has something to do with the joomla languagefilter plugin. I had some issu with this plugin. Look the code inside,
Another to think, is the joomla $app->input vs jrequest, a time vmrequest does not work anymore, because jinput do not set anymore the jrequest internally.
I wonder if this Joomla patch would solve the problem: https://github.com/joomla/joomla-cms/pull/6569
Can't test myself, because I don't have the problem. Perhaps somebody who does have the language problem with Joomla 3.4.1 can test the patch with with a copy of the site using the Joomla patch tester extension: https://docs.joomla.org/Component_Patchtester_for_Testers
Quote from: jjk on March 26, 2015, 13:26:30 PM
I wonder if this Joomla patch would solve the problem: https://github.com/joomla/joomla-cms/pull/6569
Can't test myself, because I don't have the problem. Perhaps somebody who does have the language problem with Joomla 3.4.1 can test the patch with with a copy of the site using the Joomla patch tester extension: https://docs.joomla.org/Component_Patchtester_for_Testers
Just tested and solves an error with language code url being removed but the issue of vm remains.
Starting to think is more a problem with vm caching
Just another idea - what happens if you turn off the mobile and tablet display in your template (I don't know if that template has the option to turn off 'Responsive')?
Quote from: jjk on March 26, 2015, 19:27:53 PM
Just another idea - what happens if you turn off the mobile and tablet display in your template (I don't know if that template has the option to turn off 'Responsive')?
Here you touched the mindblowing thing.
If I disable what they call "mobile view" in the desktop version of the website I get the same issue but watching the website from a mobile device in desktop mode shows the translations.
And the reply of the company doesn't help much either:"unfortunately we do not have any clue what may cause this strange problem, yet. Our mobile theme works exactly as the desktop version and both use even the same files. So if the mobile views are translated then also the desktop view should be correct."
Hmm...
What cache setting do you use? Does 'Purge expired cache' make any difference?
If it's a router issue, there there might be a different behavior when SEF urls are set to off.
joomla cache is disabled.
Tried without SEF with same effect. And purge expired cache doesnt seem to have effect on this.
Regards
Next attempt :)
I think your Yagedoo image menu on the right side doesn't seem to switch languages correctly.
Using Firebug I can see the following:
<a class="yag_title" href="/es/tienda/artisan-products.html">
<span class="yagendoo_cat-image_cat_title">Artisan products</span>
</a>
<a class="yag_title" href="/en/shop/artisan-products.html">
<span class="yagendoo_cat-image_cat_title">Artisan products</span>
</a>
Note that it looks correct until 'tienda' or 'shop', but the link always seems to use the same image and alt attribute as a link (not a text link).
QuoteAre you suggesting that I have to make a joomla menu in every language for every product in my shop, in order to correctly associate via the language switcher ?
Cheers,
prokop
Yes that is the joomla way. Shadow menus.
If the idea is that every item in the shop must have a corresponding menu in order to function well in Virtuemart, then it presents a steep challenge if you run multiple shops with several hundred products.
Surely this process can be made automated ?
Quote from: jjk on March 28, 2015, 09:55:12 AM
Next attempt :)
I think your Yagedoo image menu on the right side doesn't seem to switch languages correctly.
Using Firebug I can see the following:
<a class="yag_title" href="/es/tienda/artisan-products.html">
<span class="yagendoo_cat-image_cat_title">Artisan products</span>
</a>
<a class="yag_title" href="/en/shop/artisan-products.html">
<span class="yagendoo_cat-image_cat_title">Artisan products</span>
</a>
Note that it looks correct until 'tienda' or 'shop', but the link always seems to use the same image and alt attribute as a link (not a text link).
Hi sir many thanks for the post, it opened my eyes. Sometimes is not enough to change to beez template while there is a framework from a template, plugins etc installed.
So I decided to backup my site on a test server and started removing the yagendoo modules, that had no effect, changing template neither but then I finally uninstalled their template and plugins and there we had beez showing up all translations perfectly. So time to write them... thanks for all!
Quote from: prokops on March 28, 2015, 12:57:31 PM
QuoteAre you suggesting that I have to make a joomla menu in every language for every product in my shop, in order to correctly associate via the language switcher ?
Cheers,
prokop
Yes that is the joomla way. Shadow menus.
If the idea is that every item in the shop must have a corresponding menu in order to function well in Virtuemart, then it presents a steep challenge if you run multiple shops with several hundred products.
Surely this process can be made automated ?
Yes I agree with you. Is non viable for most shops to create menu items for each single product manually. I always though the vm guys will find a way to deal with it but seems the Joomla system doesnt help them much in this sense.
In our case we resigned to redirect the user on language switch to the shop frontpage. Not ideal of course.
Regards
Quote from: prokops on March 28, 2015, 12:57:31 PM
If the idea is that every item in the shop must have a corresponding menu in order to function well in Virtuemart, then it presents a steep challenge if you run multiple shops with several hundred products. Surely this process can be made automated ?
In my bilingual shop I build menu items for the VM categories in each language and associate these. I do not associate individual products and therefore don't need a create a menu item for products. I think it is sufficient when the customers have the opportunity to switch languages on the homepage and in the categories. Customers who enter the shop from the homepage, will usually first select their prefered language before they open a category and a product details page. And those who clicked on a snippet from the search engines, are automatically directed to the language of the search engine snippet (which they were obviously able to read).
I'm not aware of any tool that generates and associated menu items for VM products automatically.
Is this your module Studio? http://extensions.joomla.org/extensions/extension/extension-specific/virtuemart-extensions/switch-language-in-product-for-virtuemart
Quote from: lindapowers on April 16, 2015, 17:48:34 PM
Is this your module Studio?
That belongs to Patrick in France. Member name 'Studio 42' here in the forum. (See page 1 in this forum thread)
Quote from: lindapowers on April 16, 2015, 17:48:34 PM
Is this your module Studio? http://extensions.joomla.org/extensions/extension/extension-specific/virtuemart-extensions/switch-language-in-product-for-virtuemart
Yes it's my module.
So this demanded for years was possible with a module!
Im happy there is a solution finally anyway, although this should be part of vm.
This is not possible in virtuemart, because a bug in the router.php for language switching, i reported it for more then 6 months to valerie in skype.
I don't know if someone reported it to the team.
Because no one wanted fix the bug, i decide to rewrite manually the links without the router.
Without doing this, it's not possible to switch language inside virtuemart.
Quote from: Studio 42 on April 17, 2015, 17:09:12 PM
This is not possible in virtuemart, because a bug in the router.php for language switching, i reported it for more then 6 months to valerie in skype.
You are really funny. The vm router is 95% your work. If you want to report a bug, then do it here.
Quote from: Studio 42 on April 17, 2015, 17:09:12 PM
Because no one wanted fix the bug, ....
Please stop bitching, lieing and implying. Why do you say that? All what needs to be done is to create a clone of the joomla language switcher and to use the current link, like we do with the search or currency switcher. Not even 2 hours.
No one told me that it is a problem. From my point of view the joomla module is just pathetic. and if you would be so cool Patrick, you would just donate it to the core and not sell it.
I have not a problem that you sell it, go ahead. But blaming us for not having it for free and to sell it at the same time is just dishonest.
and also very stupid from your point of view. If you damage the VM brand by this behaviour, what we are going todo? We add it to the core and then you destroyed your business.
Patrick, It makes a lot more sense to not blame joomla or VM while you earn money with it.
I think from what I read that it is very strange the whole situation
Patrick
It just does not natively provide the function.
If you have a module and sell it then fine - you have managed to possibly profit off the back of a gap in functionality
But you should not be in the forum shouting that there is something "wrong/bug" in VM. It is just functionality that is not currently in the core
And if you wanted the functionality in the core - you would possibly provide your fix to the project??
However as JJK notes
QuoteCustomers who enter the shop from the homepage, will usually first select their preferred language before they open a category and a product details page.
@Patrick (Studio 42): You did write most parts of the VM router and you blame others for problems with that? When you did develop the router there were already Joomla 3 versions available to test. You obviously did not care to much about. How do you explain for example that using Virtuemart advanced calculation rules by using hidden categories is partly broken since J 3? Did you test that too? The feature does not work for the VM start page in case of displaying related products, topseller or last visited products. It does not work together with any module displaying products in frontend. How do you explain that? You just get displayed products with a url like /tax1/.... or /tax2/... a.s.o.. Those categories are hidden but they get displayed in breadcrumbs and if you take a look in product details pages where it should say: go back to category xyz.. . Instead it shows the name of the hidden category!
Hi franzpeter,
Quote from: franzpeter on April 19, 2015, 11:50:01 AM
@Patrick (Studio 42): You did write most parts of the VM router and you blame others for problems with that? When you did develop the router there were already Joomla 3 versions available to test. You obviously did not care to much about. How do you explain for example that using Virtuemart advanced calculation rules by using hidden categories is partly broken since J 3? Did you test that too? The feature does not work for the VM start page in case of displaying related products, topseller or last visited products. It does not work together with any module displaying products in frontend. How do you explain that? You just get displayed products with a url like /tax1/.... or /tax2/... a.s.o.. Those categories are hidden but they get displayed in breadcrumbs and if you take a look in product details pages where it should say: go back to category xyz.. . Instead it shows the name of the hidden category!
I wrote the router in 2012.
you can see my stast here : https://www.openhub.net/p/virtuemart/contributors/19885698713752 and you can see my last change was the 10-May-2012
made 813 commits, and changed 80,714 lines of code and worked more then 2000 Hours for the project to make the MVC release of Virtuemart 1 !
I reported to valerie alatak(she was the main developper after milbo) some bugs, but this was never fixed and only because i had no lust to write a patch.(sometime this was only one line of code).
I am not responsible for the bugs that have not been fixed since
I can blame me, because i try to find some solution and not only blame me!
Each time i blame me, i try to get a solution, i not have the last word but max milbers and the developpers having write acces to the commits. If my solution are not approuved or tested and the bug persist, it's not my fault or ?
P.S: for J3 release date : https://docs.joomla.org/Joomla_3.0_version_history , and how i can fix a bug for something not existing ?
The point is, you created the router. The whole philosophy, the basic system is yours. We do not blame you. You did not posted your fixes, patches, ideas here.
and Just dont blame us. I am writing anyway a completly new router, because j3.4 creates a lot problems for nothing.
I wrote in skype some thinks in valerie in 2013.
I said that using one instance in the router helper cannot work in multilanguage and this since 2013.
I don't know if Valerie have send you the message, but at this moment. She had the rights to change the code and the change was never made.
I give the solution, you write the code. Why this is now my fault that noone changed this?
Quote from: Milbo on April 19, 2015, 13:14:43 PM
The point is, you created the router. The whole philosophy, the basic system is yours. We do not blame you. You did not posted your fixes, patches, ideas here.
and Just dont blame us. I am writing anyway a completly new router, because j3.4 creates a lot problems for nothing.
For the basic philosophy , the philosophy was from Joomla 2.5 core concept in 2012. Of course if no one update the code, this are now obselete.
But simply look in K2 or other main component. Many have problem with Joomla 3 and rewrote the router code for Joomla 3. But i have to repeat me, i have no acces to commits and code changes and since Joomla 3 is released.
for eg. Joomla3 use now class and not function anymore, to get the categories and articles(or items) they use now an helper.
What pisses me and probably most users is that this fix took less than 2 hours for studio, milbo or any other advanced dev.
There are hundreds of topics refering to this for years and no one decided to spend 1 hour for a basic thing for multilingual shops?
I dont like bitching in the forum but come on... There are topics from 2012 asking for this.
Make vm commercial and get motivated devs to improve the system please, free is becoming too expensive.
We have so many 3rd party plugins to do basic stuff like exporting orders, shipping, payments etc that updating vm becomes a nightmare. Now we also need this module for our multilingual shop?
Come on
QuoteWe have so many 3rd party plugins to do basic stuff like exporting orders, shipping, payments etc that updating vm becomes a nightmare. Now we also need this module for our multilingual shop?
So the other "free" shops come with everything free do they? - I think not!
VM has improved dramatically over the last few years in all areas - maybe you could sponsor the 1 hour and get it into core.
As i said some post before, the main bug for multilanguage is only a instance problem. But i cry this since 2013(when i had the problem for a site) but noone want change this.
A simple example:
public function getCategoryRoute($virtuemart_category_id){
$cache = JFactory::getCache('_virtuemart','');
$key = $virtuemart_category_id. VmConfig::$vmlang ; // internal cache key
if (!($CategoryRoute = $cache->get($key))) {
$CategoryRoute = $this->getCategoryRouteNocache($virtuemart_category_id);
$cache->store($CategoryRoute, $key);
}
return $CategoryRoute ;
}
in this code you have : $key = $virtuemart_category_id. VmConfig::$vmlang ; // internal cache key
but VmConfig::$vmlang is a fixed value ! then how to make the difference from one lang to other ?
I know exactly wat is wrong for mulitlanguage, but some said my code is bad, then sorry i don't spend time to make patch when noone see the current code is bugged for multilanguage.
And in all case Max has wrote " i write a totally new router".
Now the same with an instance
public function getCategoryRoute($virtuemart_category_id){
$cache = JFactory::getCache('_virtuemart','');
$key = $virtuemart_category_id. $this->vmlang ; // internal cache key
if (!($CategoryRoute = $cache->get($key))) {
$CategoryRoute = $this->getCategoryRouteNocache($virtuemart_category_id);
$cache->store($CategoryRoute, $key);
}
return $CategoryRoute ;
}
$this->vmlang is now an instance and can have different value depending the language instance.
A developer mentioned this to us, no clue how right or wrong he was:
virtuemart is not taking sef code=en , es etc es but instead it is taking language tag that is the problem also virtuemart is taking vmlang parameter from the url but this is not avaible we have lang the file i worked on is administrator\components\com_virtuemart\helpers\config.php
see line 918 and line 941
I addded below code to work with sef parameter**////
$sitesef=vRequest ::getString('lang',false );
$lang = JFactory::getLanguage();
$languages = JLanguageHelper::getLanguages('lang_code');
$l=$lang->getKnownLanguages();
foreach($l as $l2) {
$tag=$languages[$l2['tag']]->sef;
if($sitesef==$tag){
$siteLang=$l2['tag'];
}
}
Quote from: Hutson on April 20, 2015, 20:50:33 PM
QuoteWe have so many 3rd party plugins to do basic stuff like exporting orders, shipping, payments etc that updating vm becomes a nightmare. Now we also need this module for our multilingual shop?
So the other "free" shops come with everything free do they? - I think not!
VM has improved dramatically over the last few years in all areas - maybe you could sponsor the 1 hour and get it into core.
Wont be the first time Ill do that... and wont be the first time I report a bug and get completely ignored saying only me or 2 others have the problem so it must not exist.
And yes vm has improved a lot the last years, ill say the last year specially, no one denied that.
Excellent - so at least we are agreed that VM has really improved.
Now we can just hope that Milbo puts this on his list to have a look at.
Quote from: Studio 42 on April 19, 2015, 14:18:44 PM
I wrote in skype some thinks in valerie in 2013.
That is 2 years ago. Whatever you wrote to her. Typically for you is that you fix an error for you and create bugs for others. We had that so often. You are not working clean and your code idioms are horrible for most people to read. So it is very likely that we decided not to add new bugs to fix a problem of Patrick, which others do not have. It is always a matter of priorisation and categorisation. For me this is not a bug, it is a missing feature. Other multilanguage webpage developer dont see so critical as you.
Quote from: Studio 42 on April 19, 2015, 14:18:44 PM
I said that using one instance in the router helper cannot work in multilanguage and this since 2013.
LoL, this are the reasons I do not trust your code.
First we both decided together to use a lang constant. Seconed I changed that for VM3, exactly for the reason to be able to change the language while the code is running.
Quote from: Studio 42 on April 19, 2015, 14:18:44 PM
I don't know if Valerie have send you the message, but at this moment. She had the rights to change the code and the change was never made.
I give the solution, you write the code. Why this is now my fault that noone changed this?
Very often the theoretical solution is practically not useable.
Quote from: Studio 42 on April 19, 2015, 14:32:01 PM
Quote from: Milbo on April 19, 2015, 13:14:43 PM
The point is, you created the router. The whole philosophy, the basic system is yours. We do not blame you. You did not posted your fixes, patches, ideas here.
and Just dont blame us. I am writing anyway a completly new router, because j3.4 creates a lot problems for nothing.
For the basic philosophy , the philosophy was from Joomla 2.5 core concept in 2012. Of course if no one update the code, this are now obselete.
There is again a sign, I cannot trust your code. All your examples above show the caching added by me, proving that I adjusted the code. It was very slow before. You can check the forums, we had a lot problems with your restrictive router. We discussed a lot about that. But if you check the code, then you see that the 2 main functions are mainly the same and that we just added here and there more cases/fallbacks. The helper is also almost the same, except that I added caches to the functions. I mainly developed that for VM3 and just back ported the backward compatible ideas.
Quote from: Studio 42 on April 19, 2015, 12:47:11 PM
P.S: for J3 release date : https://docs.joomla.org/Joomla_3.0_version_history , and how i can fix a bug for something not existing ?
It took me some time to understand what you mean with it. But shows again the problem with you. You may remember the time when we adjust vm directly to j1.6 and j1.7? That we lost a lot time due changes which were changed for j2.5 again? So we decided to skip j3.0 and to wait for j3.4 and to be directly ready for next j3.5 LTR. Btw at that time, the roadmap was to release j3.5 in September 2013. So of course your code got ignored, we had enough trouble with vm2.0 and j2.5. Ironically we had a lot trouble with your code, mainly the router and the customfields.
Quote from: Studio 42 on April 19, 2015, 14:32:01 PM
But simply look in K2 or other main component. Many have problem with Joomla 3 and rewrote the router code for Joomla 3.
As I stated we do. Btw we also donated 250 euro (payed by the Memberships) to Hannes Papenberg. But it seems to be more complex than a Patricks think.
Quote from: Studio 42 on April 19, 2015, 14:32:01 PM
But i have to repeat me, i have no acces to commits and code changes and since Joomla 3 is released.
You dont need that to committ code. Just post openly your ideas, fixes, patches here in the forum. Then we can talk about it. But you know that at that time we would have answered you that j3.0 is not stable. None of the STR were stable by definition.
Quote from: Studio 42 on April 19, 2015, 14:32:01 PM
for eg. Joomla3 use now class and not function anymore, to get the categories and articles(or items) they use now an helper.
None of this changes describe how to handle the different sets. It is from my point of view mainly doing the same thing a bit different. As analogy before it was an engine with Benzine, now it uses Diesel. My idea for a router is more like using an electric asynchronous motor. Really new concepts behind it. The first goal was just to get the Benzine running with the Diesel and to have a solution.
and if you take a closer look. It does not really make sense to change now the router to the j3.4.1 system, if we get anyway a new router by Hannes Papenberg. So now it looks like it will take too long and we have to develop our own versions. But you cant know that before, impossible.
Quote from: lindapowers on April 20, 2015, 17:27:04 PM
What pisses me and probably most users is that this fix took less than 2 hours for studio, milbo or any other advanced dev.
No, there is no fast fix. I did not even know about the problem, because as JJK said, for him it is not a problem. For the real shopping experience it is quite unimportant. Just when you want to check your store and your are browsing it and you want to see if all translations are correct, then you get that problem.
Quote from: lindapowers on April 20, 2015, 17:27:04 PM
There are hundreds of topics refering to this for years and no one decided to spend 1 hour for a basic thing for multilingual shops?
Then show me. We had not a lot multilanguage router problems, except with j3.4.1. and if we had a problem, we fixed it.
Guys, we talk here about the problem that if you change the language in productdetail, that you fall back to the mainpage! Not that something really important does not work. You should first investigate how many real shoppers actually have the problem.
Quote from: lindapowers on April 20, 2015, 17:27:04 PM
I dont like bitching in the forum but come on... There are topics from 2012 asking for this.
Lol, but this is what you do. Since I said to you, that it would be correct that you invest in your wishes. I suggested that you buy a bronze membership at least. You were willing to pay to develop something just for you, but you was not willing to pay, when I said it is for the community. You said then, that you do not see the point to pay for something, what you get later anyway for free and it is unfair, because the others would not pay. Very barefaced. Also ignoring the fact that you use a lot features payed by other people that way.
Quote from: lindapowers on April 20, 2015, 17:27:04 PM
Make vm commercial and get motivated devs to improve the system please, free is becoming too expensive.
I suggest that you buy a bronze membership at least.
Quote from: lindapowers on April 20, 2015, 17:27:04 PM
We have so many 3rd party plugins to do basic stuff like exporting orders, shipping, payments etc that updating vm becomes a nightmare. Now we also need this module for our multilingual shop?
The solution is indeed to provide an own module, because the joomla one is not suitable, imho. Shipping and Payments, lol, you are really fair.
Quote from: Studio 42 on April 20, 2015, 21:21:28 PM
As i said some post before, the main bug for multilanguage is only a instance problem. But i cry this since 2013(when i had the problem for a site) but noone want change this.
A simple example:
public function getCategoryRoute($virtuemart_category_id){
$cache = JFactory::getCache('_virtuemart','');
$key = $virtuemart_category_id. VmConfig::$vmlang ; // internal cache key
if (!($CategoryRoute = $cache->get($key))) {
$CategoryRoute = $this->getCategoryRouteNocache($virtuemart_category_id);
$cache->store($CategoryRoute, $key);
}
return $CategoryRoute ;
}
in this code you have : $key = $virtuemart_category_id. VmConfig::$vmlang ; // internal cache key
but VmConfig::$vmlang is a fixed value ! then how to make the difference from one lang to other ?
Yeh, but 2013. VM3 was not there. You did not openly discuss your idea here in the forum.
The code in December 2013
public function getCategoryRoute($virtuemart_category_id){
$cache = JFactory::getCache('_virtuemart','');
$key = $virtuemart_category_id. $this->vmlang ; // internal cache key
if (!($CategoryRoute = $cache->get($key))) {
$CategoryRoute = $this->getCategoryRouteNocache($virtuemart_category_id);
$cache->store($CategoryRoute, $key);
}
return $CategoryRoute ;
}
is using a vmlang helper variable, set in the constructor and instancing by lang is possible. This kind of confusion is typical for you. Discussing about code of 2013 and trying to prove that with code from 2015, just lol.
Quote from: Studio 42 on April 20, 2015, 21:26:41 PM
$this->vmlang is now an instance and can have different value depending the language instance.
vmlang is not an instance. An instance is an object. vmlang is just a string. Regarding the flexibility, a constant has similar disadvantages like an instance. But again, you talk about code released November 2014. Not the one of 2013.
Quote from: lindapowers on April 20, 2015, 23:07:29 PM
A developer mentioned this to us, no clue how right or wrong he was:
virtuemart is not taking sef code=en , es etc es but instead it is taking language tag that is the problem also virtuemart is taking vmlang parameter from the url but this is not avaible we have lang the file i worked on is administrator\components\com_virtuemart\helpers\config.php
yeh and now ask yourself who added that. Imho Patrick. There wouldnt be any problem, if he would have written it directly according to the standards. But you are also funny. Looks like you payed another developer to fix it for you. Right? But you are angry on me, because I asked for. Really strange.
Quote from: lindapowers on April 20, 2015, 23:07:29 PM
see line 918 and line 941
I addded below code to work with sef parameter**////
$sitesef=vRequest ::getString('lang',false );
$lang = JFactory::getLanguage();
$languages = JLanguageHelper::getLanguages('lang_code');
$l=$lang->getKnownLanguages();
foreach($l as $l2) {
$tag=$languages[$l2['tag']]->sef;
if($sitesef==$tag){
$siteLang=$l2['tag'];
}
}
Ah thank you, there is the code, finally you share it. Why you just not come in and tell:
"Hey, I payed a developer to fix the lang problem, *description*. I am happy to share our fix with you."
This is the way an opensource project works. Despite that you just come in here and bitching around, since around a year. You pay someone else to write the fixes for you and keep to code. LOL and then you do wonder why I do not fullfil any of your wishes?
Quote from: lindapowers on April 20, 2015, 23:07:29 PM
And yes vm has improved a lot the last years, ill say the last year specially, no one denied that.
yeh and the more we improve, the more you bitch around. Yeeh, is crazy, we dont understand it also.
For all readers,
Why is the router so a big deal in virtuemart ?
In virtuemart you have 13 views and in this view you can have many layouts.
When you have to build the route, you have to check all situations.
Now if you build a single route, this is bad for nice SEF urls eg. site.com/shop/productdetails/45
The philosophy of Joomla is to say : if you are in a menu (and have a itemid) then the default path from this menu must be used.
In virtuemart you have links to cart, account,orders,vendor ...
If you want to follow the right way to set Joomla router. You have to set for all this views a menulink in Joomla. This is how Joomla set itself the routes and sef URLS !
BUt if you are in a product for eg., the menulink(or itemId) is already set. This is why using Joomla way you can have link site.com/shop/category/product/cart when you come from a product and want display the cart for eg.
But to not have to add all this menu, Virtuemart search for fallbacks to have nice urls. But in some case, this is bugged because a menulink does not exist or a condition is not tested in router.
Now for multilanguage.
A hope a simple answer : how you can get a route from another language using VmConfig::$vmlang. Please don't refer to my old poor code but give a simple answer.
@Studio 42
But what I do not understand is the following thing. You have products with different tax rates. A good way with VM is to create two categories, like VAT and Reduced VAT. Set both to unpublished. Now create the 2 tax rates with two calculation rules for tax, one with the normal vat rate, the second one with the reduced vat rate. Assign the two vat rates to the appropriate hidden category for the adequate vat rate. If you create a new product you can assign it to a display category and the hidden vat category. Works fine as long as you use J 2.5. With J 3 it is broken. Joomla 3 creates wrong url because it does not differ between a hidden category and the display category. If the hidden category has the lower category id (normal if you create the hidden categories before anything else) Joomla will not take care about that. It always takes the hidden category id instead of the one for the display category. The problem is visible inside the breadcrumbs, the url and the back to category of course. So if it works with J 2.5 and is broken with J 3, there seems to be something wrong with Joomla in case of url creation and routing.
So for me J 3 is far away from any acceptable stable state. In the described case, there is nothing wrong with the way VM creates the routing, it is a J 3 problem. And you have barely a chance to patch something in that case if Joomla is not even able to differ between something published or unpublished!
The new problem in Joomla 3.3.6+ is that the oriented way to do multi-language is to use menu association and joomla simple use the current itemid in other case.
But what is the right way?
Manually set itemid for category? but the time you change something in the Joomla menu links the route is false and at end you have more problems with the settings.
The current problem is that Joomla code is suite the need of the core components, but this have mostly 1 or 2 views only. All other components have some bugs with sef (and Joomla core, if you don't set the menu links). I do not think that the vm router is the most bugged compared to the work he have to do.
Thank you, YES, man.
The reason I think about to write a new router plugin. Which must be worked out as mathematical bijective function, converting between two exactly defined sets. And anything which is not defined must be done generically.
And then we think about the problem how to cache URLs outside of that. The itemId is either taking over the URL or not. Must be defineable by itemId and so on. And a well designed function to get the right itemId or to check the itemId. and all of that should be configurable.
@Max.
- You didnt offer any help when me and others reported the bug. When I wrote you in skype you invited me (yes with other users) to pay the insulting quantity of 500 euros to fix this. (Oh sorry this was for the child products redirect, for this case you didnt even reply)
My other option was paying an external programmer without knowing if the fix will be included.
But is not about the money Max, is about you having 0 interest in improving a system. I read vm project leader in your signature, If that was me and someone reported a bug Id like to improve my system.
- Yes I had a developer to check this and he replied what I copied here 2 days ago... sorry it took me so long to post it here!
I dont know Patrick whatsoever since the guy that checked this for us is and Indian programmer. Sadly I have no doubt that he reported the bug on skype 1 year ago and got completely ignored cause that happened to me dozens of times.
You have now released vm 3.0.8 and I see new features for multivariants etc etc
And there are 2 main bugs in vm currently:
- Child products stock issue that basicly affects all shops in j3
https://forum.virtuemart.net/index.php?topic=128777.0
Another of my crazy topics writing alone with another guy for a function that affects all the ***obscenity removed*** users of this software.
- In shop section /vendor tab switching languages only show the default one, again reported on forum, on skype to valérie and she told me that in the testing chat this was also reported.
So tell me where on earth we are supposed to report bugs?
Next time ill ask JJK directly and in case he doesnt have the issue ill asumme reporting it will become useless since you assume if it works for JJK there is a non existent bug.
If you were working in joomla 3 instead of 2.5 it would be a good start also, cause recommending us multilingual shoppers to use joomla 2.5... well...
If Hutson, Franz, JJK, Studio etc had not posted here this topic will have been lost and ignored as usual.
The fact that you and your team tell us that redirecting a language switch to the main shop is normal or common doesnt mean is the correct way.
We users learned how to deal with that since there was no other option but changing language from a product detail page should redirect to the same product detail page in the chosen language, I don't say this, logic does.
Ill pay the bronze when you listen to us vm shop owners instead of the guys that sell websites to us vm shop owners.
Quote from: lindapowers on April 21, 2015, 17:13:19 PM
- You didnt offer any help when me and others reported the bug. When I wrote you in skype you invited me (yes with other users) to pay the insulting quantity of 500 euros to fix this. (Oh sorry this was for the child products redirect, for this case you didnt even reply)
You mix really a lot things. I said writing the feature, that the multivariant do not directly redirect you to the product detail costs 500 euro at least. I cannot change that. You can fool someone else. It is not my fault that the world is complex. If you find someone who does it for less, you just do not pay what it is worth and actually not even the 500 euro reflect the worth. I said fundraise the money, give me 500 and I do it. As long others give me money todo their features, but you dont give any,.. then do not complain, blame and spread lies.
Quote from: lindapowers on April 21, 2015, 17:13:19 PM
My other option was paying an external programmer without knowing if the fix will be included.
Yeh because it has to follow open stated rules, my experience with doing this since 5 years is that there are not a lot people able to deliver the quality.
Quote from: lindapowers on April 21, 2015, 17:13:19 PM
But is not about the money Max, is about you having 0 interest in improving a system.
Interesting, and why we have not vm2.0.0 then? Without me there wouldnt be any vm2 assumingly. So why the heck do you say that? ah I get the idea, you want to be accepted as serious person. The problem is, it makes you just ridicolous. You know very well that I am interested to improve the system. I worked hours if not days for FREE FOR YOU! and you never noticed that. For you it was normal that we did bugfixing for free. You do not understand that I fix some bugs for free, and others not. It depends on how much people are affected by it and on complexity. So why I should fix a bug for a person which
- insults me
- spread lies
- and imply evil behaviour
??
Quote from: lindapowers on April 21, 2015, 17:13:19 PM
I read vm project leader in your signature, If that was me and someone reported a bug Id like to improve my system.
Yeah and then just look at the amount of versions released by me http://dev.virtuemart.net/projects/virtuemart/files.
Quote from: lindapowers on April 21, 2015, 17:13:19 PM
Sadly I have no doubt that he reported the bug on skype 1 year ago and got completely ignored cause that happened to me dozens of times.
Yeh you even refuse to read what I wrote, useless. I wrote why it got ignored. And I give you a little tip, I kicked Patrick out of the team. Others would have just banned him, period. over and out!
Quote from: lindapowers on April 21, 2015, 17:13:19 PM
- In shop section /vendor tab switching languages only show the default one, again reported on forum, on skype to valérie and she told me that in the testing chat this was also reported.
I have no clue what you are talking about. Write here in the forum. have in mind we are all humans, have limited time and ressources, quite easy. and if someone is so nasty like you both guys, dont wonder that you are ignored.
Quote from: lindapowers on April 21, 2015, 17:13:19 PM
If you were working in joomla 3 instead of 2.5 it would be a good start also, cause recommending us multilingual shoppers to use joomla 2.5... well...
yeh you are really intelligent. Yeh just ignore any facts I told before, just ignore any answer, ignore reality, stick with your dreams man. Really. There is no need for a serious shop owner to use j3, no single advantage.
Quote from: lindapowers on April 21, 2015, 17:13:19 PM
The fact that you and your team tell us that redirecting a language switch to the main shop is normal or common doesnt mean is the correct way.
We users learned how to deal with that since there was no other option but changing language from a product detail page should redirect to the same product detail page in the chosen language, I don't say this, logic does.
and again implying. Man, you are really disgusting and full of falsehood. I cant say it different. Where did I say it is "normal" or "common". I never wrote that. I wrote something with the meaning of "it does not hurt a real shopper", that is something completly different. And of course it is nice that changing the language keeps the URL, of course it was meant like that. But somehow, I never got a report about this bug (except for j3 and I explained already, why we ignored it).