[trendoman]

Hi!

I would like to discuss permanent links on websites with clonable pages.
The main reason for them to exist would be a comfort of user.
I have visited nice websites with many pages of interesting content. Looked for 2-3 pages and saved the page to bookmarks, to get back later. Once I get back - some new posts have been added and I'm lost, as the pagination has changed.

This does seem to be the typical method for providing pagination in list-view. Obviously, mysite.com/blog/?pg=2 will show a different set of stories as new pages are added to the template.

Instead, you could create a pagination routine that encodes the beginning post into the URL, like mysite.com/blog/?begin=12, where "begin" is the page id of the first post in the listing.

Changing how the URL is expressed is the only possible way to make a list-view into a permalink.

[trendoman]

Thanks for saving the thread, Tim! This way people can browse hundreds of pages of items and save intermediate state without fear of loss.

I went slightly different way - show beginning and end, as recent and oldest respectively.
Once a visitor comes to a clean url, he gets redirected to the url, containing all ids: recent=500&oldest=10.

Trick was to put pages-ids in url, but fetch pages with dates of those ids.

I went slightly different way - show beginning and end, as recent and oldest respectively

That was my first inclination as well, but then I started thinking about potential problems. What if a post is deleted, or has it's publish-date changed? There's really no need to encode the ending post, it only increases the potential for a malformed URL.

In your own attempt did you work in any protection in case posts are either deleted or moved? This seems like the biggest potential issue with this method.

[trendoman]

I went slightly different way - show beginning and end, as recent and oldest respectively

That was my first inclination as well, but then I started thinking about potential problems. What if a post is deleted, or has it's publish-date changed? There's really no need to encode the ending post, it only increases the potential for a malformed URL.

In your own attempt did you work in any protection in case posts are either deleted or moved? This seems like the biggest potential issue with this method.

Good point. KK always says similar thing - never trust user inputs. So far, I enjoyed his way of doing things and could put the burden redirect mentioned problem to his system code:

Code: Select all

<cms:pages id="<cms:gpc 'oldest' />" limit='1'>
  <cms:set first_page_date = "<cms:show k_page_date />"  scope='global' />
  <cms:set first_page_id   = "<cms:show k_page_id />"    scope='global' />
</cms:pages>

So, if 'oldest' is somehow corrupted - then page-id and page-date would not be fetched. Same applies to 'recent'.

If publish_date is changed, this is not tracked yet, as I don't fully rely on publish date, only on page-id. Same if posts are deleted or moved.

Now, coming to the next point: suppose, some parameter /or even both/ is not found or corrupt. So, page-ids are not set. The trick is, I set first_page_id twice. The above code was the second time. It changes the values upon reading user input from URL.

First one - I initialize the variable with my real oldest page:

Code: Select all

<cms:pages orderby='publish_date' order='asc' limit='1'>
      <cms:set first_page_date = "<cms:show k_page_date />"  scope='global' />
      <cms:set first_page_id   = "<cms:show k_page_id />"    scope='global' />
    </cms:pages>

Same with real recent page. First, let variables take proper values, then if user input is correct - amend proper values to those found in URL. It helps redirect user to the list view with correct values, embracing all existing pages.

I hope you like my solution. I really wanted to set up a future website with a system to my liking. I want to learn something trying to be happier with what I'm doing. Hope I could explain how I managed to solve adding the second parameter. Answer to your question about why code the second parameter is not formulated yet, but i feel it was a right move. Gives me calmness and probably will be used later.

This may come to another point - How to preserve id's in case of site migration.