Hello
Every time I «Save And Close» a product, the VM3.2.4 system drives me to the Products area, but it doesn't remember the sorting before the product creation. More specifically, it sorts the products by Product_Id in ascending ordering. So, every time I have to sort again the products by Product_Id in descending ordering, in order to find the last created one. Someone to help?
VM 3.2.4
Joomla 3.8.1
PHP 7.1.1
This is important and a time saver when you import many products -one after another- with clone process. You can't just keep changing the sorting. A penny for your thoughts ???
Anyone from the VM Developers Community?
With my tool https://shop.st42.fr/en/products/vm-be-pro-batch-product-edit.htm on clone, the new clone get append to the list directly with ajax, so no ordering problem
For Virtuemart, i think perhaps this is the problem in VirtuemartViewProduct:
if($cI = vRequest::getInt('virtuemart_category_id',false)){
$app = JFactory::getApplication();
//$old_state = $app->getUserState('virtuemart_category_id');
$old_state = $app->getUserState('virtuemart_category_id');
if(empty($old_state) or $old_state!=$cI){
vRequest::setVar('com_virtuemart.product.filter_order','pc.ordering');
$model->filter_order = 'pc.ordering';
$old_state = $app->setUserState('virtuemart_category_id',$cI);
}
}
If a VM core dev want to check ?
I wonder the sorting should be stored, as userstate, when you click on the order.
Hi Max,
no, I can confirm that the ordering is not saved.
We also have a customer with many products and he also finds it very tedious. The behaviour was different in earlier VM versions.
-- Petra
php 7.1.1? brave, hehe.
I cant reproduce it.
It's not the PHP version. I tried with versions 7.0 and 5.6 and the result was the same.
Hello
This is probably not helping, but I see the same. I often switch to latest ID when entering new products. After saving the Product the ordering is reset to order by SKU, starting with lowest SKU.
Uing php 5.6, Joomla 3.8.2 and VM 3.2.5.9677
regards
Jörgen @ Kreativ Fotografi
+1
The same problem.
PHP 7.0, J 3.8.2, VM 3.2.4
I think that the code before :
if($cI = vRequest::getInt('virtuemart_category_id',false)){
Is the problem.
because
vRequest::setVar('com_virtuemart.product.filter_order','pc.ordering');
is never called because in admin, the category is never set on returning from product edit.
Not that i dont have checked, because i dont want to provide any patch excluding github.
I think that was there to reset the ordering, when changing the category. Or better said, it should set the ordering to "ordering," when enabling a category. I think atm it is just outdated stuff and the whole if should be removed
Quote
if($cI = vRequest::getInt('virtuemart_category_id',false)){
$app = JFactory::getApplication();
//$old_state = $app->getUserState('virtuemart_category_id');
$old_state = $app->getUserState('virtuemart_category_id');
if(empty($old_state) or $old_state!=$cI){
vRequest::setVar('com_virtuemart.product.filter_order','pc.ordering');
$model->filter_order = 'pc.ordering';
$old_state = $app->setUserState('virtuemart_category_id',$cI);
}
}
Btw, you can also create with git a patch for svn. There absolutly no reason to block svn. As I said very often, you can work with git
Max, if VM is in github, you can fork and do pull request. Currently, you have to send a patch, no one can test it ...
For me svn is to many work(and for other contributors), it have nothing to do with SVN itself, but github is public and you can share anything with other user, so they can test your release or see directly your patch with diff... and why not participate to your current change and not send a patch, wait and hope a day a team member check it.
For Joomla, you have teams for each part of the code, they work on different fork and get time to time updates from main branch, when te patch is approved, the main branch manager simply add the pull request
BUt we have already discuss about this.
I found a trick, but dont know if it's the best way.
I simply added this for backend /administrator/components/com_virtuemart/models/product.php
in protected function populateState () {
before
$filter_order = strtolower ($app->getUserStateFromRequest ('com_virtuemart.' . $view . '.filter_order', 'filter_order', $this->_selectedOrdering, 'cmd'));
add
$task = vRequest::getCmd ('task',false);
if($task != false) return;
So the state get not populate, if you are in a task(i dont think that in back-end the task have to be populate, but perhaps for batch mf or category ?).
Just remove your fix please and also remove this here, (view.html.php)
Quote
if($cI = vRequest::getInt('virtuemart_category_id',false)){
$app = JFactory::getApplication();
//$old_state = $app->getUserState('virtuemart_category_id');
$old_state = $app->getUserState('virtuemart_category_id');
if(empty($old_state) or $old_state!=$cI){
vRequest::setVar('com_virtuemart.product.filter_order','pc.ordering');
$model->filter_order = 'pc.ordering';
$old_state = $app->setUserState('virtuemart_category_id',$cI);
}
}
That is old stuff, the populateState does it already and is just overwritten here.
Removing that old stuff doesn't change the ordering behaviour.
The patch by Studio 42 fixes the issue for me!
Do you open a product with child list tab?
I've tested a product with children (multivariant) and a product without children.
Or what do you mean?
Quote from: p.barg on November 28, 2017, 09:49:07 AM
Removing that old stuff doesn't change the ordering behaviour.
The patch by Studio 42 fixes the issue for me!
+1
It's the same way for me.
yeh, it fixes the problem here, but is just a quick and very dirty quick fix.
I found now the reason and Petra has already version to test for it. The reason was the list of "shoppers who bought the product" which has an own ordering, which overwrotes the ordering of normal product list. the product list got than an ordering for "email", which was recognised as wrong => use default.
The new core should now keep both orderings, the one of the standard product list and "customer who bought"
Max, in a task, the values have not to change, this is logic, so the code is not a durty fix, but the core code in this case is dirty(and do extra stuff for nothing with bad result).
If in some task, you need to set the ordering pagination in core, this should then be white listed and not simply set it in each case(and each time the product model is called, for a simple product this is set too and in a module...
At end perhaps using 2 model product + products is the best way to handel this case
Patrick, the fixes in the core now include many different details. Your quickndirty fix pointed on the task, which gave me a good grab. The core was a only bit dirty there. It is the code, which I meant already, which can be deleted. The problem here is that we have a list for child products and a list for "shopper who bought", but with sorting.
The sortfilter of the "shopper who bought" overwrote the userState. Any user states were just stored by option and view, no task. So I had to add tasks here.
I had to extend the sort function by the task and also to add this task to the sort calls in the list, and more stuff like that.
Add an extra value for ordering or other filters in case of other list then.It should solve the problem
Eg.
$filter_order = strtolower ($app->getUserStateFromRequest ('com_virtuemart.' . $view . '.filter_order', 'filter_order', $this->_selectedOrdering, 'cmd'));
to
$filter_order = strtolower ($app->getUserStateFromRequest ('com_virtuemart.' . $view .'.'.$task. '.filter_order', 'filter_order', $this->_selectedOrdering, 'cmd'));
Or better not use an instance but get a new model for your case. the constructor is not private and permit then to not destroy the value in the session