View Issue Details

IDProjectCategoryView StatusLast Update
0000626OXID eShop (all versions)3.1. Design, GUI, UXpublic2009-10-23 15:57
Reportertjungcl Assigned To 
Status resolvedResolutionfixed 
Product Version4.0.1.0 revision 15990 
Fixed in Version4.2.0 revision 23610 
Summary0000626: The number of pages in $oView->getPageNavigation() is generated from all products, not only visible ones
Descriptionit 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:
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).
TagsNo tags attached.
PHP Version5.2.6
Database Version5.0.33


related to 0001302 resolvedrimvydas_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 resolvedrimvydas_paskevicius Incorect total articles count for manufacturers and vendors lists 
related to 0001364 resolveddainius.bigelis Possible to assign Variant-articles without Parent to the lists 



2009-06-25 12:23

reporter   ~0001117

increasing severity because more people complains about same problem.


2009-08-21 20:27

reporter   ~0001486

yes, please hurry up with the solution. the same problem!!!!!!!!!!!!!!!!!!!!!!!!!1


2009-08-21 20:28

reporter   ~0001487

categories > no problem
vendor > counting the variants also!


2009-08-23 23:30

reporter   ~0001488

Pls. increase the severity, how can it be that this bug is so long open?


2009-09-03 15:33

reporter   ~0001631

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 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:
We would appreciate for any help reproducing this case.


2009-09-03 15:57

reporter   ~0001633

Reminder sent to: ecom-software-de, icedoutbiz, tjungcl


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,


2009-09-03 16:10

reporter   ~0001634

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.


2009-09-04 10:02

reporter   ~0001644

Reminder sent to: icedoutbiz


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? 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,


2009-09-04 12:05

reporter   ~0001647

Last edited: 2009-09-04 12:07

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.


2009-09-04 13:14

reporter   ~0001650

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...


2009-09-04 13:43

reporter   ~0001651

tell me your email, and I give you acceess


2009-09-09 08:49

reporter   ~0001695

Last edited: 2009-09-09 08:54

Reminder sent to: dominik_ziegler, ecom-software-de, icedoutbiz


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,


2009-09-09 08:57

reporter   ~0001696

Closed as "no change required" because this issue will be solved together with the fix for bug 0001302


2009-09-17 10:52

reporter   ~0001767

One more bug was found related to incorrect number of articles in the Vendors and Manufacturers list. It is described in 0001312.


2009-10-02 16:54

reporter   ~0001873

Bug reopened, as found one behavior, how the case can be reproduced (description updated)


2009-10-23 15:56

reporter   ~0001967



2009-10-23 15:57

reporter   ~0001968

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];