V4 Pagination Error

[Guest njgreen1984]

Hi all,

Wondering if anybody can shed any light on this.

I recently went live with a site for a client running cubecart v4.4.5.

I am aware that there has been a bug discovered previous to this version of cubecart involving the breakdown of the pagination when 'SEO Friendly' URL's are enabled, but from what I have read, this should be fixed in my version. It doesn't however appear to be.

Pagination works fine when 'SEO Friendly' URL's are disabled, however this is not an option - this feature is very necessary to this site.

I am also aware that a quick fix could be to display more results than needed in the categories, meaning the pagination links would never need to exist. I would prefer however to fix this problem and enable pagination, as would my client. (After all, it *should* really work)

I have taken a look at all of the 'fixes' for this bug and they do appear to have been implemented already in this version, so I am unsure as to where this problem stems from.

The pagination links just point to (eg) 'index.php?_a=error&code=404&page=1'. Where is this 404 error coming from? Unless I am missing something, it doesnt appear to be the paginate(); function.

You can check what I mean here: http://www.solar-test-equipment.co.uk/solar-test-equipment/cat_2.html

Thanks in advance

Nate

[bsmither]

Welcome njgreen1984! Glad to see you made it to the forums.

That's an interesting result. I will definitely be looking at the code. In the meantime, please state if you have modified your store. I don';t need to know what mods as yet, just if you are running the core code.

[Guest njgreen1984]

Welcome njgreen1984! Glad to see you made it to the forums.

That's an interesting result. I will definitely be looking at the code. In the meantime, please state if you have modified your store. I don';t need to know what mods as yet, just if you are running the core code.

Yep, I very much have. My client needed a lot of custom features adding to cubecart in order for it to suit their purposes. I am pretty adept with php and the structure of v4, but this has baffled me. (Obviously) I cant think of anything I have changed which would affect this though. I am currently only using the standard 'SEO Friendly' URL's functionality pre-built into cubecart. This is not something I have modified.

Cheers,

Nate

[bsmither]

In the file /includes/functions.inc.php (paginate function), http_build_query($newParams) is what gets us the returned querystring. Broken down, it is:

_a => error (wrong)

code=>404 (wrong)

page=>1 (right)

$newParams is built up from $params (line 433) and $params comes from parse_str($QUERY_STRING, $params). $QUERY_STRING comes from (line 429) $_SERVER['QUERY_STRING'] (if you are not running under Zeus server).

If you're using .htaccess to spoof pages in any type of application, then $_SERVER['QUERY_STRING'] is going to be blank. (Instead, $_SERVER['REDIRECT_QUERY_STRING'] will hold the actual query string passed by user. Use this function to parse this variable.)

If you start with this address:

http://site/index.php?_a=viewCat&catId=2

the pagination gets converted to SEF URLs:

http://site/solar-test-equipment/cat_2.html?page=1

If I recall, it was decided to not allow SEF URLs in the pagination string because of "problems".

In the file viewCat.inc.php, did you make any mods that would post-process $pagination to SEF URLs?

But this doesn't answer why the problem even exists as the paginate() function is used elsewhere and there doesn't seem to be any problems. (Well, actually, the only other non-admin page is the listing of reviews in the viewProd code. So I guess the approach to the fix was to just not deal with it, and to just not enter a viewCat page with SEF URLs. I could be wrong about this.)

[Guest njgreen1984]

In the file /includes/functions.inc.php (paginate function), http_build_query($newParams) is what gets us the returned querystring. Broken down, it is:

_a => error (wrong)

code=>404 (wrong)

page=>1 (right)

$newParams is built up from $params (line 433) and $params comes from parse_str($QUERY_STRING, $params). $QUERY_STRING comes from (line 429) $_SERVER['QUERY_STRING'] (if you are not running under Zeus server).

If you're using .htaccess to spoof pages in any type of application, then $_SERVER['QUERY_STRING'] is going to be blank. (Instead, $_SERVER['REDIRECT_QUERY_STRING'] will hold the actual query string passed by user. Use this function to parse this variable.)

If you start with this address:

http://site/index.php?_a=viewCat&catId=2

the pagination gets converted to SEF URLs:

http://site/solar-test-equipment/cat_2.html?page=1

If I recall, it was decided to not allow SEF URLs in the pagination string because of "problems".



In the file viewCat.inc.php, did you make any mods that would post-process $pagination to SEF URLs?



But this doesn't answer why the problem even exists as the paginate() function is used elsewhere and there doesn't seem to be any problems. (Well, actually, the only other non-admin page is the listing of reviews in the viewProd code. So I guess the approach to the fix was to just not deal with it, and to just not enter a viewCat page with SEF URLs. I could be wrong about this.)

Nope, I haven't knowingly modded anything that would post process $pagination to SEF URLs. To be honest I just left all of the SEF functionality alone & switched off whilst the store was under development. I only turned it on when the store went live (risky I know!). I have noticed a couple of other things that may be of interest. The 'sort' links at the top of the product listings do not work. The query string they generate also includes the code=>404 variable, but do not change the _a variable to 'error' ( _a=viewCat&code=404&catId=2&sort_by=price&sort_order=low). As far as I can see, the variables necessary for sorting are there, but are not effective. I.e they have no effect on the order of the products shown. Another thing I have noticed is that when a search is carried out for something like 'solar' (which will bring up enough results to generate pagination links) both the pagination and the sort links work perfectly. On these search results pages however, I have noticed that SEF URL's are not implemented. Here are the rules setup in my htaccess for your reference, although these were dynamically generated by cubecart, they do look right to me...

Thanks for your help with this,

Nate

## Activate the mod_rewrite Engine



RewriteEngine On



RewriteCond %{QUERY_STRING} (.*)$

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule cat_([0-9]+)(\.[a-z]{3,4})?(.*)$	index.php?_a=viewCat&catId=$1&%1 [NC]



RewriteCond %{QUERY_STRING} (.*)$

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule prod_([0-9]+)(\.[a-z]{3,4})?$		index.php?_a=viewProd&productId=$1&%1 [NC]



RewriteCond %{QUERY_STRING} (.*)$

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule info_([0-9]+)(\.[a-z]{3,4})?$		index.php?_a=viewDoc&docId=$1&%1 [NC]



RewriteCond %{QUERY_STRING} (.*)$

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule tell_([0-9]+)(\.[a-z]{3,4})?$		index.php?_a=tellafriend&productId=$1&%1 [NC]



RewriteCond %{QUERY_STRING} (.*)$

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule _saleItems(\.[a-z]+)?(\?.*)?$		index.php?_a=viewCat&catId=saleItems&%1 [NC,L]

	  	



ErrorDocument 404 /index.php?_a=error&code=404

[Guest Roger Huston]

Hello,

I wanted to take a look at the problem, but the link above does not show any products on the second page. We have SEF Urls and the pagination work as bsmither describes and we run 4.4.5. I do have one change from the original code in my function paginate in the functions.inc.php

$currentPage = sanitizeVar($_SERVER['PHP_SELF']);

I use: 

$currentPage = ((bool)$config['sef']) ? sanitizeVar($_SERVER['PHP_SELF']) : sanitizeVar($_SERVER['REQUEST_URI']);

This was before the bug was officially fixed: http://bugs.cubecart.com/view.php?id=1596

As you can see the bug had the conditions reversed. I am not sure if this will work for you, but it has worked for me for over a year.

- Roger