Bug #23162 Duplicate

{page:pagination} in Template Routes stopped working after update to 3.5.9

Version: 3.5.9 Reporter: glawrie

This is an archived bug report. If you are experiencing a similar issue, upgrade to the latest release and if that does not solve the problem, submit a new bug report

Site runs with a handful of template routes that uses the {page:pagination} construct to allow routing of paginated output.

Worked fine up to 3.5.6.

Updated EE to 3.5.9, and while it generally has worked fine, I found all the routes that include {page:pagination} simply stopped working - generating 404 errors.

What seems to be happening is that the {page:pagination} term is working OK when there is a pagination term present in URL, but throwing a 404 otherwise. But if you eliminate the pagination element from the route, anything with a pagination term triggers a 404 (regardless of setting of ‘segments required’).

So I’ve created a simple test case and that fails too.

I have two identical templates. Both generate a simple text output.

I have created two routes in Template Routing to handle. “Segments Required?” is set to no for both.

Template Route
junk /junk
junk2 /junk2/{page:pagination}

A simple test setup follows:

Test URL Result
/junk correct test output
/junk/P10 404 page
/junk2 404 page
/junk2/P10 correct test output

You can try out these tests on the live site by using the links in table above.

I am perplexed as to what to try / do to fix this - nothing changed in the routing rules before / after the upgrade.

I am able to work around the bug on live site thanks to static caching - I manually created the right rules to get the ‘no pagination’ pages and put them in the static cache, and put the pagination term into the routes to generate the paginated cases - but this is not a viable solution even for short term.

  • Do you have steps to reproduce this on a clean installation? This site itself uses {page:pagination} in template routes, and is not throwing improper 404s. E.g.:



    Derek Jones
    23rd June, 2017 at 9:55am
  • Apologies - it seems the markdown handling of tables is not working for this message. But hopefully you can still work out from the ‘inline’ tables what they were meant to show.

    23rd June, 2017 at 9:55am
  • Apologies - it seems the markdown handling of tables is not working for this message.

    I corrected the syntax for you, your tables were missing the dash line to indicate a the table header.

    Derek Jones
    23rd June, 2017 at 9:59am
  • Hi Derek - short answer is no vis running a clean site to test - but completely understand why it would be helpful. Also understand that other sites are not seeing same problem. However it is also unexpected for an update to cause a previously working Template Route set to fail in this way - it would seem that the only issue is what happens to a route when {page:pagination} is included and the supplied route does not contain a Pagination term. EE3 Documentation on Template Routes is obscure at best, but these simple test cases appear to conform to required structures.

    23rd June, 2017 at 10:00am
  • Thanks for correcting tables - easier to see now. Also noticed a typo in first table, the route for junk2 route is /junk2/{page:pagination}

    23rd June, 2017 at 10:03am
  • Did you see the URLs I supplied above? Neither URL 404s, can you let me know what I’m missing? I agree that behavior changing for you on update is unexpected and frustrating, but that does not mean it is the result of a bug or the application itself at fault. I want to help you, whether it’s a bug or not, but I will need to be able to reproduce the behavior to do so. Thanks for any additional information that lets us see what you are seeing!

    Derek Jones
    23rd June, 2017 at 10:03am
  • Perhaps share an actual route and template that quit working for you instead of the junk/junk2 sample? I think what you may be seeing with your examples is a result of this issue which is not new (3.1.2) but the fix requires a backwards-incompatible change.

    Derek Jones
    23rd June, 2017 at 10:11am
  • I’m happy to provide you with whatever information is helpful - if I knew what would help I’d have posted it already.

    As noted, I can see that examples exist of this term working in routes as required (but to be honest I don’t know what kind of processing / routes you are using to generate the pages either, so who knows if they are comparable).

    Something happened during the update of versions that broke this functionality. It might be a bug, or it might be that the update fixed something else and that’s pushed this edge case from working to failing. But really that’s all I’ve got to go on.

    The test cases side-step all of the complications of the EE3 installation - the templates simply contain plain text - so unless there is some method of interfering with Template Routes that don’t involve any template tags at all.

    Behaviour is repeatable on test case pages and on live pages. But beyond that you’ll need to explain more about what else you need to see etc.

    23rd June, 2017 at 10:23am
  • OK - to help: have a look at these pages from the live site.

    https://2gc.eu/resources/public-sector https://2gc.eu/resources/public-sector/P5

    I’ve deleted the static cache page for the ‘no pagination’ URL, so you can see the effect of the bug. The template route that is used for this page is /resources/risk-management/{page:pagination}

    The first time you go for a paginated page (put in something other than P5 to generate) it will build from EE, subsequent visits to same URL will hit static cache. The 404 page is not static cached… so hit the no pagination page as much as you want!

    I’ll put the static cache version of the no-pagination page back in 1hr (live site - got to maintain some kind of standard…).

    23rd June, 2017 at 10:29am
  • The 404 on /junk2 is the bug I linked to above, but again that has been a known issue for quite some time. So I do not believe that your reduction test is reflecting whatever has happened to your routes in production. If you’d like us to take a look directly on your install and environment, feel free to put in a support ticket and one of our engineers would be happy to look. Aside from that I don’t know what we can do to help, can’t fix what we can’t see. 😊

    Derek Jones
    23rd June, 2017 at 10:29am
  • Looks like we cross-posted there 😊

    Thanks for the extra info. Not sure how that route is being used for those URLs though, risk-management vs. public-sector?

    Derek Jones
    23rd June, 2017 at 10:30am
  • Also - if it helps - I can Slack/DM you a log in to the CP. Let me know if so.

    23rd June, 2017 at 10:34am
  • Sorry - typo - the route is /public-sector/ - I was going to do risk-management but then realised that that page doesn’t actually paginate (not enough entries in category)

    23rd June, 2017 at 10:35am
  • Aha, ok I think I may have something reproducible, digging.

    Derek Jones
    23rd June, 2017 at 10:41am
  • I looked at your ‘other problem similar’ URL - but don’t quite see how it relates. Until the latest update the routes I had worked - the problem in URL appears to have never worked.

    I will have a go at putting in the duplicate template fix - but it seems totally at odds with how EE used to work and Template Routes documentation (such that it is).

    23rd June, 2017 at 10:42am
  • Created a second template in group that contains an embed to route to index template in same group.

    Tried to create a second route pointing to second template with same URL as before but without pagination term, and ‘require segments?’ set to yes. EE rejected the route as being same as first one… :(

    23rd June, 2017 at 10:54am
  • Ok I’ve gone all the way back to 3.4.0 and a route of /resources/public-policy/{page:pagination} is behaving the same (404ing if the pagination segment is missing). I think this is related to the bug I linked to earlier which relates to what’s required or not following static segments, but I do not see how this was behaving differently for you on 3.5.6 (which I also tried this route on).

    Regardless of what else may have changed, to restore your previous behavior, you can work around this by making that last static segment a dynamic variable. Using regex, you can still force it to only work with the static segment you desire:


    Let me know if that doesn’t resolve the route for you properly.

    Derek Jones
    23rd June, 2017 at 11:07am
  • Ace - that works!

    No idea what might have been going on. We migrated over to EE3 only in March 2017, not sure what version was current then (but would appear to be greater than 3.4.7) and routing was working fine from then through until 3.5.6.

    Thanks for your assistance in finding a fix.

    23rd June, 2017 at 11:22am
.(JavaScript must be enabled to view this email address)

ExpressionEngine News!

#eecms, #events, #releases