Support the ongoing development of Laravel.io →
posted 10 years ago
Session

Hello all,

First time here, as I usually spend hours (days!) searching for solutions, and usually find what I'm after... until now! So, I hope someone can offer some advice on my approach here...

I have a few pages which can be called from various other pages, and each of these pages have a 'Cancel' or 'Back' button to take them back to the previous page.

Now, I've been using the URL::previous(), and Redirect::back() for this, but I end up in a 'loop' in certain cases.

Example:

I have a 'Library' page, which lists a number of items which, when clicked, go to their respective show pages. This item show page has a 'Back' link, as well as an 'Edit' link to take it to the edit page, which also has a 'Save' and 'Cancel' buttons. With me so far? :)

So, once we come back from the edit (via a save or cancel) back to the item show page, we can no longer go back to the original 'Library' page as the URL::previous() now points to the edit page instead now. (As a side note, we can also go straight to the edit page directly from the 'Library' page, with the list of items (each also has an edit link). So, as you can see this can get a bit complex. There's a few other places we do this on the site too, but this example will suffice for now.

To get around this back issue, I have decided to use session variables to save the 'back' link for these pages. For this, I have created two helper functions in my Helper class:

    /**
     * Set a session variable with the url to the current route name, so
     * the back/cancel buttons can refer to this to get the route back to
     * the last page.
     *
     * Using this instead of the Redirect::back(), which wasn't playing nice
     * with subsequent redirects, etc.
     *
     * @param $sessionKey - The session key name to save the route under.
     * @param $params - Any parameters to pass to create the routes url.
     * @return void
     * @author
     **/
    public static function setNamedRoute($sessionKey, $params = null)
    {
        $url = route(Route::CurrentRouteName(), $params);
        Session::put($sessionKey, $url);
    }


    /**
     * Get the saved 'back' redirect route url.
     *
     * @param $sessionKey - The session key name containing the route url.
     * @return string - Link to route to redirect to.
     * @author
     **/
    public static function getNamedRoute($sessionKey, $default = null)
    {
        return Session::get($sessionKey, isset($default) ? route($default) : null);
    }

So, carrying on the above example... In the showLibrary controller, I now save the current routes URL for use in the item's 'Show' page, as follows:

    Helper::setNamedRoute('show.item.back');

and the item show controller would then have:

    Helper::setNamedRoute('edit.item.back', ['itemId' => $item->id]);

The back link in the items show view would then be:

    {{ link_to(Helper::getNamedRoute('show.item.back', 'library'), 'Back', ['class' => 'secondary button']) }}

and, of course, in the edit view:

    {{ link_to(Helper::getNamedRoute('edit.item.back'), 'Cancel', ['class' => 'secondary button']) }}

This 'show.item.back' session variable would be set from wherever the show page would be accessed from (either the Library page, or elsewhere on the site), so it would always know where to go back to. Similarly, for the edit page.

Now, this all does work fine, which is great; however, my issue is that it's kinda messy, as I need to keep tabs on all the different session variables for each page that has a back/cancel button.

I was wondering if there was a better (much nicer!) way of doing this. Should I implement an internal 'breadcrumb' type system, using session arrays? (Not sure how to use these), or is there something obvious I'm missing?

Any help would be appreciated!

Last updated 3 years ago.
0

is there more than one "library"? why not use a named route.

<a href="{{{ URL::route('library') }}}">Back</a>

and

Route::get('/library', ['uses' => 'LibraryController@dashboard', 'as' => 'library']);

Or is the library page dynamic? I am lost. This seems like it is quite simple as long as the library page url doesn't change.

Not really sure what the issue is :)

0

Hi,

Thanks for your reply.

The issue is that these pages can be accessed from a few places. The 'library' was just once example to illustrate. So, for instance, the item show page can also be accessed from a 'Story' page. So, a named route back isn't an option. I did do this originally, just so we went back to somewhere logical, but it ruins the flow for the user.

Also, as mentioned above, the item edit route can be access from either the item show or library (and, once I get round to it, from other 'archive' pages). So, it's quite complex.'

Oh, and yes, you can access from different 'library' pages - 'library' and 'userLibrary', as well as other pages.

FYI, the routes for these library pages are:

Route::get('library', ['as' => 'library', 'uses' => 'ItemsController@library']);

Route::get('userLibrary', ['as' => 'userLibrary', 'uses' => 'ItemsController@userLibrary']);
Last updated 10 years ago.
0

You could create a middleware or filter. Capture the http_referer Capture the current url including query strings

Compare them, if different put referer in a session e.g. RefererUrl Use this key on all your back or cancel buttons

0

Thanks for that Edwin.

I did try the filter idea, but the issue here was that the filter would get triggered each time I came back to the show page, from the edit screen too. So, the 'back' button on this page would then go back to edit, instead of the original referrer (library); similar to doing a URL::previous();, if you see what I mean.

This is why I placed the current URL in a session within the previous action (as shown above in my code), so that the url being used for the 'Back' would remain unchanged. The issue here is that I have to create 'named' referrers for each page with a 'Back' button, which is the solution I opted for. But doesn't seem entirely elegant!

Never done anything with middleware classes, so I'll check that out. Thanks for that... But I suspect, I'll have the same 'looping' problem as mentioned above.

So, it sounds like the best approach is to just carry on with my solution as it is, unless someone has any other ideas?

Last updated 10 years ago.
0

Sign in to participate in this thread!

Eventy

Your banner here too?

tnaseem tnaseem Joined 9 Jan 2015

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2025 Laravel.io - All rights reserved.