"/ajax.php" adds itself to the navigation history

Steps to Replicate:

1. Add an item to the shopping cart.
2. Visit shopping cart page.
3. At this point "Back to Shopping" returns the URL to the last page.
4. Refresh the shopping cart page (or update the quantity of a product).
5. At this point "Back to Shopping" no longer returns the URL to the last page.

It appears when "/ajax.php" is loaded via JavaScript, the contents of the navigation history are being updated to add ```
"/index.php?main_page=index&act=ajaxPayment&method=setNoscriptCookie"

Perhaps not the correct fix, but adding the following line to "/ajax.php" may be a workaround:

require ('includes/application_top.php');
$_SESSION['navigation']->remove_current_page(); // Remove page from navigation history
$language_page_directory = DIR_WS_LANGUAGES.$_SESSION['language'].'/';

See if this works better:

$_SESSION['navigation']->set_snapshot();

NOTE: this appears to work when coming from product_info page but more work is needed for when coming from the Product Listing ...

When changing from "$_SESSION['navigation']->remove_current_page();" to "$_SESSION['navigation']->set_snapshot();" the issue is once again present.

Currently testing under PHP 5.4 and PHP 5.5.

Interesting ... it does fail ...

What worked was testing your method then changing the code with what I posted ... but what I posted does not work on a clean session ... :blink:

Can someone test whether this works reliably?

/includes/classes/navigation_history.php
Around line 32 add the highlighted lines:

  function add_current_page() {


[B]    // don't put the ajax handler calls into nav history[/B]
[B]    if (preg_match('|ajax\.php$|', $_SERVER['SCRIPT_NAME']) && isset($_GET['act']) && $_GET['act'] != '') return;[/B]


    global $request_type, $cPath;

And also test on a Windows server too?

DrByte:

Can someone test whether this works reliably?

/includes/classes/navigation.php
At line 80 add the highlighted lines:

[B] // don't put the ajax handler calls into nav history[/B]
[B][/B][B] if (preg_match('|/ajax.php$|', $_SERVER['SCRIPT_NAME']) && isset($_GET['act']) && $_GET['act'] != '') $set = 'false';[/B]
[B][/B]

if ($set == 'true') {
  if ($_GET['main_page']) {

> 
> And also test on a Windows server too?
Apologies, but what was wrong with lhungil's initial proposal?  That implementation allows the ajax.php module to "take care of" itself, rather than muddying-up the navigation class.

I kind of like the page / script itself handling itself... But I suspect there is a possibility for a race condition when someone has multiple tabs open (actually loading)... Potentially causing the wrong page to be removed (with the code I posted).

Perhaps a long term solution would be to change the code where a page is added to the navigation? Perhaps only adding the page to the history inside application_bottom (instead of application_top). Then we could set a "flag" in the page / script indicating it should not be added to the navigation history?

I've not dug into the core code far enough to see if this is already the way things work, but if not already implemented as above... I would recommend something along those lines...

DrByte:

Can someone test whether this works reliably?

/includes/classes/navigation.php
At line 80 add the highlighted lines:

[B] // don't put the ajax handler calls into nav history[/B]
[B][/B][B] if (preg_match('|/ajax.php$|', $_SERVER['SCRIPT_NAME']) && isset($_GET['act']) && $_GET['act'] != '') $set = 'false';[/B]
[B][/B]

if ($set == 'true') {
  if ($_GET['main_page']) {

> 
> ...
Appears to work for me under Windows x64 (PHP 5.4, 5.5, and 5.6) and Linux (Debian 7 - PHP 5.4.36).

lat9:

Apologies, but what was wrong with lhungil's initial proposal? That implementation allows the ajax.php module to "take care of" itself, rather than muddying-up the navigation class.
Simple: it didn't work properly.

lhungil:

Perhaps a long term solution would be to change the code where a page is added to the navigation?
That's basically what my proposed change does.

I agree that a better solution is desirable, but the goal of any fix to share for v1.5.4 needs to be as brief and simple-to-implement as possible. Any broader architectural changes would go into a new version. I know you understand this. I'm just writing it for the sake of others who read this discussion.

At present the class is instantiated via the auto-loader system, and there's no interception option there to say "do or don't do based on XYZ conditions".

I personally never use those "go back to the previous page" navigation buttons, because I always just use the browser's "back" button ... it's a lot faster than having to find something to click on. If I had my way I'd remove all such buttons from all templates, as I feel they just clutter the page. But, I know some people swear by them and don't even realize that the browser has a "back" button. Sigh.

DrByte:

Simple: it didn't work properly.
I tested the initial "dirty workaround" against the same environments I listed above (suPHP is used on the Debian box). Can you share which environment(s) it did not work in (so I can add it to my test environments - if possible)?

DrByte:

... But, I know some people swear by them and don't even realize that the browser has a "back" button. Sigh.
:hug: And there is my smile for the day! Currently communicating with a hosting provider who managed to get on one of the mx blacklists (and somehow I found out before they did - which is unusual).

lhungil:

I tested the initial "dirty workaround" against the same environments I listed above (suPHP is used on the Debian box). Can you share which environment(s) it did not work in (so I can add it to my test environments - if possible)?
We tested several environments, including developer machines and live hosting servers:
Debian/Mac with PHP 5.6
Ubuntu with PHP 5.5
CentOS with PHP 5.3

It started removing the wrong things the more we clicked around and added/removed things, and visited other pages, and logged on and logged off, etc, in various combinations, and then finally would just leave the navigation array completely empty, making the button do nothing.

DrByte:

We tested several environments, including developer machines and live hosting servers:
Debian/Mac with PHP 5.6
Ubuntu with PHP 5.5
CentOS with PHP 5.3
Thank You!

Time for me to add a CentOS box to my list :)

I changed the line number, the regex pattern, and added a return ... in my updated earlier post: http://www.zen-cart.com/showthread.php?215823-quot-ajax-php-quot-adds-itself-to-the-navigation-history&p=1269499#post1269499

DrByte:

Can someone test whether this works reliably? /includes/classes/navigation_history.php Around line 32 add the highlighted lines: ```
function add_current_page() {
[B] // don't put the ajax handler calls into nav history[/B]
[B] if (preg_match('|ajax.php$|', $_SERVER['SCRIPT_NAME']) && isset($_GET['act']) && $_GET['act'] != '') return;[/B]
global $request_type, $cPath;

      Works fine on my local development server:
    
    Linux Mint 17.1
    
    Server OS: Linux 3.16.0-28-generic        Database: MySQL 5.5.40-0ubuntu0.14.04.1
    Server Date: 14/01/2015 18:46:51       Database Date: 14/01/2015 18:46:51
    Server Up Time: Disabled/Unavailable     HTTP Server: Apache/2.4.7 (Ubuntu)
    PHP Version: 5.5.9-1ubuntu4.5 (Zend: 2.5.0)
    
    Clicked around, back/forward button (Firefox), added to cart, updated cart items, logged out, logged in again, back/forward etc - all without problems....
    
    Cheers / Frank