Jump to content

Resolved - Orders List in Admin - Bad Pagination


bsmither
 Share

Recommended Posts

There may times when the pagination sequence in the admin Orders Summary listing does not appear, or may have the incorrect number of links (1-2-3 instead of 1-2-...-29-30). The following series of edits should fix that.

 

Unfortunately, while there is much in the Database Class to get the necessary info efficiently (that is, make one complex query instead of two), there is other database activity that gets in the way and pollutes that info. So, we must make two queries. (I really wanted to make all this function correctly using the tools in the class, but as I was working through it, it became evident I was building a very lengthy list of edits to make - more than I would reasonably ask anyone here to undertake.)

 

In the file admin/sources/orders.index.inc.php, near line 563, find:

 

$where = (isset($where) && !empty($where)) ? $where : false;

 

Make it look like:

 

if(isset($where) && !empty($where)) { $_GET['page'] = 'all'; } else { $where = false; }

 

Don't do the above edit. Instead do this, near line 578, find:

$page = (isset($_GET['page'])) ? $_GET['page'] : 1;

On the same line, after the existing statement, add:

if($where) $page = 'all';

This will get rid of the erroneous &page=all in the querystring that may appear after doing a search followed by editing one of the found orders.

 

Near line 596, find a statement that begins with:

$orders = $GLOBALS['db']->select(sprintf('`%1$sCubeCart_order_summary`

On the same line, directly in front of that statement, add this statement:

$orders_count = $GLOBALS['db']->count('CubeCart_order_summary', 'cart_order_id', $where);

Near lines 622 and 623, find:

$GLOBALS['smarty']->assign('PAGINATION', $GLOBALS['db']->pagination(false, $per_page, $page, 9));
$GLOBALS['smarty']->assign('TOTAL_RESULTS', $GLOBALS['db']->getFoundRows());

Make them look like this:

if (!$where) $GLOBALS['smarty']->assign('PAGINATION', $GLOBALS['db']->pagination($orders_count, $per_page, $page, 9));
$GLOBALS['smarty']->assign('TOTAL_RESULTS', $orders_count);

What this does is to drop pagination on results from a search. That is, if you have 600 orders over two years, and, for example, you search on dates from 1Jul2013 to 1Sep2013, all of only those results will be listed. So, don't be stupid. Keep your search parameters such that you can expect to get a tightly focused result.

 

This also uses the count of a query that is not restricted, otherwise having limited the results to 20 at a time, for the pagination (if appropriate) and Total Count at the bottom of the table.

 

Also, it should be noted that in the Orders Summary, Search Orders tab, you can search by Order Details, or by Order Date. But not both. (But I think that's an easy edit to fix.) (Edit: turns out the database class, where() function, is not written flexibly enough to do this.)

Link to comment
Share on other sites

I edited orders.index.inc.php - note your file name needs editing. Pagination works perfectly. I was not, however, able to search for all instances of our test account with a date range from 2012 designated. It instead resulted in all orders from that date range.

 

Debug info shows no sign of the customer info I entered:

GET:

'_g' => 'orders'
'page' => 'all'
'sort' =>
'order_date' => 'DESC'

 

 

This is not an operation I normally do, so I don't know if this search was working prior to the pagination edits or not. I'll test with our other store and see before I edit that one. No, inputting a customer AND a date range only provides the date range results, not specifically that one customer. So this is broken, too, in stock 5.2.2. I'll leave the Kurouto store alone, in case you want me to test edits to fix Search before we add Pagination edits to it.

Link to comment
Share on other sites

"Also, it should be noted that in the Orders Summary, Search Orders tab, you can search by Order Details, or then by Order Date. But not both. (But I think that's an easy edit to fix.)"

 

Hmm. I had it exactly backwards.

 

"Also, it should be noted that in the Orders Summary, Search Orders tab, you can search by Order Date, or then by Order Details. But not both. (But I think that's an easy edit to fix.)"

 

Order Date: From: and To: using a popup calendar. If any of these fields are used, searching by Order Details is ignored.

 

Order Details: Order Number, Customer Name, or Order Status ('All' = none). In order for these search parameters to be used, the Search by Order Date section must be blank.

 

In your Debug block, do you ever see a section for POSTed values?

Link to comment
Share on other sites

So I misunderstood what you were saying about limiting the search so the results would not need pagination.

 

POST results when attempting to find test customer orders for 2012:

POST:

'multi-status' => ''
'multi-action' => ''
'search' =>
'order_number' => ''
'search_customer_id' => '718'
'status' => ''
'date' =>
'from' => '2012-01-01'
'to' => '2012-12-31'
'token' => '4c779a1a6dd565c493bec5420fb317f5'

 

 

That looks to me like it TRIED to find only the customer I wanted. No?

Link to comment
Share on other sites

Bug #633 says that the statement near line 529 needs an edit so that searching by date will not cause the building of the pertinent where clause to fail.

 

Find this:

if (isset($_POST['search']['date']) && is_array($_POST['search']['date']) && (!empty($_POST['search']['date']['form']) || !empty($_POST['search']['date']['to']))) {

and change 'form' to 'from'.

 

This doesn't change anything in the manner in which the search parameters are processed, however.

 

Plus the fact that the calendar returns a date (which gets converted to a timestamp of Midnight, the morning of the date), but the search is made on the timestamp which was recorded at the exact second the order was transacted. So searching for a specific date does not work.

 

Date ranges probably do.

Link to comment
Share on other sites

Thank you Brian, the pagination problem is solved! Unfortunately, there is a new problem emerged after the execution of the adjustments. When you click on the "Save button" (left button) after changing a status of an order, I get a server error. This problem does not occur when you click the "Save & Refresh" button (right button). 

 

After clicking the "Save & Refresh" button, I will redirected to mysite.com/admin.php?_g=orders&page=all&sort[order_date]=DESC#order_summary. I think the page=all makes the problem. I have to many orders to show all on one page. 

 

Any idea how to solve this problem?

Link to comment
Share on other sites

Interesting.

 

Let's undo the edit at line 563. Fifteen lines later, find:

$page = (isset($_GET['page'])) ? $_GET['page'] : 1;

On the same line, after the existing statement, add:

if($where) $page = 'all';

This will get rid of the erroneous &page=all in the querystring.

Link to comment
Share on other sites

When you restore the edit at line 563, be sure to have the trailing semi-colon:

$where = (isset($where) && !empty($where)) ? $where : false ;

 

 

Please try clearing the SQL cache in admin Maintenance. I may ask you to attach a file to an email and send it to me.

Link to comment
Share on other sites

Product Inventory

 

In the file /admin/sources/products.index.inc.php, near line 1199, find the statement that begins with:

if (($where === false || strlen($where) > 0) && ($results =

Keeping the rest of the statement as it is, make what you see above look like:

if (($where === false || strlen($where) > 0) && ($results_count = $GLOBALS['db']->count('CubeCart_inventory', 'product_id', $where)) && ($results =

On the next line, change this:

$pagination = $GLOBALS['db']->pagination(false, $per_page, $page, 9);

to this

$pagination = $GLOBALS['db']->pagination($results_count, $per_page, $page, 9);

I have not yet determined how to best switch off the 'page=all' setting. At the top-right is a selector to filter on categories. Selecting 'Any" from this selector keeps the last 'page=x' setting.

 

Edit: Well, I think this is the best approach. In the file /js/admin.js, around line 144, find:

if ($('#cat_subset').exists()) {
  $('#cat_subset').change(function(){
    $location = document.URL;

Add this immediately after the existing statement on the third line, so that it looks like this:

$location = document.URL; $location = removeVariableFromURL($location, 'page');

Make your browser fetch this javascript file and to use this fresh copy -- not a copy cached by the browser.

 

When a category filter is changed, the javascript executes a location.replace() with the new cat_id, but this edit makes sure that there is no 'page=x' part in the URL so that the CubeCart code will default to page=1.

Link to comment
Share on other sites

  • 4 months later...

This was "fixed" in 5.2.5. However yesterday we discovered that it still failed on stores with a database prefix as the database "count" function had a syntax error. This is why it still didn't work on some stores. 

 

The 5.2.6 release should finally resolve this issue for everyone. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...