Allow Page Numbers isn't 404'ing when content doesn't exist...

[a-ok]

Hi folks,

I've set up some infinitescroll on manual trigger on a Journal section of my site, all fine and set up, but there's a slight issue that the 'Allow Page Numbers' isn't returning a 404 even when there isn't more 'pages'. So, the infinitescroll never fails... or stops.

For example, I have a /journal/page1 which is fine, and has posts, and a /journal/page2 but then, technically, /journal/page3 shouldn't exist as all the last post is on page2, but even if I put /journal/page99 it still returns a page, rather than a 404.

Looking at the tutorials, this is even the same for the tutorial: https://processwire.com/docs/tutorials/how-to-use-url-segments/page99

I know I need to build a throw new Wire404Exception(); into my template, but I am unsure how to manage this?

Any thoughts?

Thanks!

R

[Macrura]

your isotope implementation should have the max pages set in a data attribute, e.g.

<a href="#" data-pages="4" data-page="1" data-link="http://mysite.com/page2/">More Items...</a>

this may or not be visible if you are triggering the load at reaching the end of the page;

you would be able to reuse your pagination vars for the data-pages value (ceil items_per_page/total_items for example);

your script needs to be smart enough not to ask for another page after it has loaded the last page, the data-page value gets updated each time you load the next page's results;

[tpr]

So, the infinitescroll never fails... or stops.

That's why it's infinite

[a-ok]

Thanks for the replies but I think you're missing the point. The issue is not to do with infinite scroll, but rather Processwire and how it doesn't run a 404 page when there is no more content on Allow Page Numbers...

[Martijn Geerts]

The solution would be Javascript rather then ProcessWire. From the ProcessWire side you have to tell the javascript when to stop. I don't know Isotope, but if I were you I would follow the recommendations of Macrura. 

[LostKobrakai]

ProcessWire must leave it up to you to handle those 404 errors, as it cannot know when to throw that error. Maybe your result of find() will get pages added at a later stage of the process, which wouldn't get called if pw would throw an 404 error right after the find() call. 

$list = $pages->find("stuff=selected, limit=10");

// if list is empty and it's not the first page
if(!$list->count() && $input->pageNum != 1) throw new Wire404Exception();

[Macrura]

your infinite scroll will keep triggering unless you put a limit;

plus, even if you stop the load after it detects no more items, you would still have to load that 404 page to find out, so then you wouldn't be able to show the "no more posts to load" message at the right time;

[LostKobrakai]

@Macrura

But solely relying on the 404 error does account for pages, that may have been added after the initial page load, while setting the max pages limit previously isn't that flexible.

[Macrura]

@Macrura

But solely relying on the 404 error does account for pages, that may have been added after the initial page load, while setting the max pages limit previously isn't that flexible.

that's a good point, though the sites i'm using infinite scroll on are not updated that often and are cached - i would think it a somewhat rare occurrence for a viewer to miss out on an item that was added between their page load and when they hit the trigger for the last page...

[a-ok]

Hi @LostKobrakai, many thanks for this. This is the sort of solution I was after... however this doesn't seem to throw a 404 even when I am on /page7/ where only /page3/ was the last page that had any content.

<?php $journals = $pages->find('parent=/journal/, sort=-journal_date, limit=1'); ?>
<?php if (!$journals->count() && $input->pageNum != 1) throw new Wire404Exception(); ?>

I've actually worked out that it is bringing in my 404 template, but keeping the URL as /journal/page7/, for example, so infinitescroll is thinking this is just another page and not actually a 404...

[a-ok]

To reiterate my point above... if I go to the following URL...

https://processwire.com/docs/tutorials/how-to-use-url-segments/page99 it works, even though it shouldn't, but if I go to https://processwire.com/docs/tutorials/how-to-use-url-segments/dfdsfs it 404s. If I set up my code, like you suggested, and use throw new Wire404Exception()... it doesn't treat it like the second URL, it just shows my 404 template but keeps the same URL /page99

[tpr]

It's up to you what to do when you throw the 404 error. Probably you would need to do a redirect ($session->redirect...) but in case of infinitescroll, you may need to send a message (eg. "No more posts").

[a-ok]

So what exactly does 'throw new Wire404Exception()' do?

[a-ok]

I've had to do:

<?php $fourohfour = $config->urls->root . 'http404/'; ?>
<?php if (!$journals->count() && $input->pageNum != 1) $session->redirect($fourohfour); ?>

Which in my console shows:

XHR finished loading: GET "http://localhost/Freelance/5th-studio/journal/page3"
GET http://localhost/Freelance/5th-studio/http404/ 404 (Page Not Found)

So, this fixes things for me, but the issue still lies... why would it retrieve /page8/ when nothing exists on it? Surely the 'Allow Page Numbers' shouldn't work infinitely and eventually when it returns blank auto 404s? And why doesn't 'throw new Wire404Exception()' actually throw a 404 page but rather include it in the template rather than a full refresh like a normal 404 page should do?

[LostKobrakai]

As I tried to tell you above ProcessWire cannot know how to handle pagination pages, where the selector returns an empty set. Pagination isn't more than just limiting the returned set of pages. PW cannot guess what else you're doing on that page, or if maybe this empty set will be modified later. Blindly throwing 404 errors would make this system greatly more inflexible. You can always handle those things on your own just like you need it.

To iterate on your 404 problem: 404 errors do always respond directly on the requested url, no matter where in pw. Only the status-code will change to 404. 

[a-ok]

Thanks, this makes lots of sense now. Really appreciated and can understand why it's important that it is left as flexible as possible.