View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000626 | OXID eShop (all versions) | 3.1. Design, GUI, UX | public | 2009-02-23 16:09 | 2009-10-23 15:57 |
Reporter | tjungcl | Assigned To | |||
Priority | high | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 4.0.1.0 revision 15990 | ||||
Fixed in Version | 4.2.0 revision 23610 | ||||
Summary | 0000626: The number of pages in $oView->getPageNavigation() is generated from all products, not only visible ones | ||||
Description | it seems, that especially variant-members that have a parentid and are therefore not visible in the list.tpl do count in, when calculating the number of pages. For example the oxidshop shows ten pages in category x, but the last two are empty. Deleting the cache does not help. Such case can be reproduced this way: 1. Set the option in Core settings -> System -> Variants: "Display Variants in Assignment Lists in eShop admin" = ON. 2. Create new article A (which will act as Parent-article). 3. Create two variants for article - A1 and A2. 4. Create new Category. 5. In Administer Products -> Categories -> Main - click Assign Products. In the opened AJAX list, there are articles listed: A A1 A2. Assign only one variant to Category, i.e. A2. So the parent article A and A1 is left not assigned to Category. 6. Go to Frontend and select newly created Category. The article list will be empty, thought amount of assigned products are = 1 (you can see it if have "Display Number of contained Products behind Category Names" set ON). So if you will assign 20 variants this way (but still Parent article and some variants left not assigned) - you will have 2 empty pages in Category list. In this case the problem occurs because assigned Variant articles are calculated into amount of assigned products for category. Only products, which can be displayed in the list, should be calculated (only parent products). | ||||
Tags | No tags attached. | ||||
Theme | |||||
Browser | All | ||||
PHP Version | 5.2.6 | ||||
Database Version | 5.0.33 | ||||
related to | 0001302 | resolved | rimvydas_paskevicius | The cache is not reset when any change made in admin using AJAX lists |
has duplicate | 0001039 | closed | Pagination isn't correct | |
related to | 0001312 | resolved | rimvydas_paskevicius | Incorect total articles count for manufacturers and vendors lists |
related to | 0001364 | resolved | dainius.bigelis | Possible to assign Variant-articles without Parent to the lists |
|
increasing severity because more people complains about same problem. |
|
yes, please hurry up with the solution. www.iced-out.biz the same problem!!!!!!!!!!!!!!!!!!!!!!!!!1 |
|
categories > no problem vendor > counting the variants also! |
|
Pls. increase the severity, how can it be that this bug is so long open? |
|
Reminder sent to: ecom-software-de, icedoutbiz, tjungcl I cannot reproduce this bug in 4.1.5 shop version. Possible, that issue gone together with some other fixes in eshop versions since 4.0.1.0. Could you please check this case on eshop 4.1.5 if this is still valid? If yes - can you give as the link to some shop where we can reproduce that? Or maybe you can reproduce it even on our demoshops (4.1.5) at: http://demoshop.oxid-esales.com/community-edition http://demoshop.oxid-esales.com/professional-edition http://demoshop.oxid-esales.com/enterprise-edition ? We would appreciate for any help reproducing this case. |
|
Reminder sent to: ecom-software-de, icedoutbiz, tjungcl Hi, We checked that case is still valid on some or your shops (which are version 4.1.5). Such behavior may occur also because some modules installed, or because some special circumstances, when the bug occurs (i.e. some set of various/special articles). In this case we would appreciate for any DB backup or data (i.e. product entries) from your shop, for possibility to reproduce it localy. Best regards, |
|
wow, 6 month to tell us that they can't reproduce the failure. really great. just take the categories and write the vendor the same way. thats all. I hope if will not take 6 month. |
|
Reminder sent to: icedoutbiz Hi, The description "just take the categories and write the vendor the same way" is not very clear. - Could you please describe step by step what to do to reproduce that? - Can you reproduce this case on our demoshops? ...as we tested different cases again and still cannot reproduce it. Btw, the Severity of the bug is Minor: displaying few more empty pages in the list is not Very dangerous issue and does not make big injury for the eshop. That's why it remained in the list of Open bugs for so long, as we are fixing more importants first. As more people started complaining about that - the Priority was increased to High, so we started working on this. And we would appreciate any help from you to reproduce that case and then fix it. Best regards, |
|
In the OXID demoshops this bug can not be reproduced. In one of our shops we use many variants. The number of displayed articles (the user can see) does not match with the article count which is generated in oxUtilsCount::setCatArticleCount() (that number is much bigger) and therefore OXID generates pages which does not contain any content. |
|
Reminder sent to: dominik_ziegler Yes, such is resuls of that issue. But question is - Why these numbers differs... should be some specific set of variants, to create such environment for issue. We tested several cases with variants - when these are active, disabled, only some of variants are disabled, all are disabled and one is activated, etc., but such cases does not triggers the problem. The best way to catch this problem - if somebody would give us access to some test shop on your side (where the problem exists), and we would debug it on your side... |
|
tell me your email, and I give you acceess |
|
Reminder sent to: dominik_ziegler, ecom-software-de, icedoutbiz Hi, We debuged this case on live shop. The problem was reproduced, but gone immediately after cache was cleared. In initial bug report there was written, that "Deleting the cache does not help". The behavior is active because there was other bug in caching 0001302. As quick solution - clearing cache will solve pagination problem in the lists. Best regards, |
|
Closed as "no change required" because this issue will be solved together with the fix for bug 0001302 |
|
One more bug was found related to incorrect number of articles in the Vendors and Manufacturers list. It is described in 0001312. |
|
Bug reopened, as found one behavior, how the case can be reproduced (description updated) |
|
fixed |
|
code snapshot in case you want to fix by yourself: Class oxutilscount { public function setCatArticleCount( $aCache, $sCatId, $sActIdent ) { $oArticle = oxNew( 'oxarticle' ); $sTable = $oArticle->getViewName(); $sO2CView = getViewName( 'oxobject2category' ); // we use distinct if article is assigned to category twice $sQ = "SELECT count(*) FROM ( SELECT count(*) FROM $sTable LEFT JOIN oxobject2category ON oxobject2category.oxobjectid=oxarticles.oxid WHERE oxobject2category.oxcatnid = '".$sCatId."' AND $sTable.oxparentid='' AND ".$oArticle->getSqlActiveSnippet() ." GROUP BY $sTable.oxid ) AS ox2cat"; $aCache[$sCatId][$sActIdent] = oxDb::getDb()->getOne( $sQ ); $this->_setCatCache( $aCache ); return $aCache[$sCatId][$sActIdent]; } } |