Change Archive-Page-behaviour for better caching

[onli]

Something I read somewhere some time ago and still think to be a good idea:

Currently, in most blogs (including s9y), we treat archive-pages the wrong way. At the moment, we have:

Code: Select all

startpage, page 2, page 3, ..., page n-1, page n

Because of that, whenever a new entry is published, all those pages changes, because the last entry from the startpage moves to page 2, the last from page 2 to page 3, and so on (or, to think of it in another way: n increments, so the last page has always the same entries, but gets again and again a different URL).
I know that we don't save those pages explicitly, so it's not about work we could get rid of - apart from that we maybe do that in templates_c. But we for sure make it harder for people to find old entries, because google will locate entries on the wrong archive-pages, especially on not so popular blogs which thus get indexed not so often but which are filled actively.

So, I suggest the following structure:

Code: Select all

startpage, page n, page n-1, ..., page 2, page 1

That way, only the startpage will change, but archive-pages would stay the way they are after they got filled.

Garvin, do you agree (is the logic sound?)? Is that easy enough to do? I didn't try to patch that yet, first wanted to discuss this.

[garvinhicking]

Hi!

I'm not sure how to achieve that technically. Also, this might be a reason why spiders actually do rate s9y higher because it's content changes. So for some people, that might actually be a preservable idea, so if it gets implemented, we should have an option switch to revert that. Also, for existing installations we might set this setting to false by default, so that existing blogs indexing won't change that much.

Regards,
Garvin

[onli]

I commited a patch (no clue why it's marked as from simdock, it's from me and simdock one of my projects).

I honestly doubt there should be any seo-drawback. Even if a crawler would be dumb enough to not realize that only internal entries were shifted and saw that as activity, because of the additional users who are now registered as "found what they searched" - which should be one of the oldest and the most important metrics - this should be a huge win in those terms.

On the blog, it really feels like the way it should be, especially with one entry per page. Hope you think the same after you try it out - I made it optional, but activated by default. I see no harm in activating that for existing blogs, as this would lead to only one last big change in a before everchanging sea of pages (and i'm anyway not sure how to do that).

[yellowled]

(no clue why it's marked as from simdock, it's from me and simdock one of my projects).

Actually, simdock seems to be (technically) an organization you're a member of (most likely because you gave collaborators access to said project). I'm not sure how, but there is some way in GitHub to work in an organization's "namespace". If you submit a patch while being in said context, it will probably be committed by the organization, not by your personal account.

YL

[Don Chambers]

Is this change implemented live somewhere to see it in action?

[onli]

Don: No, I don't have an online-testblog. But it's part of master, so in s9y 1.7.

YL: Thanks, if you stumble upon how to control that namespace - i founded that organization, but s9y should be in no way connected - please send me a notice. Haven't found anything so far.

[yellowled]

if you stumble upon how to control that namespace - i founded that organization, but s9y should be in no way connected - please send me a notice.

Got it – it's hidden very well.

Log in, go to http://github.com (not your profile page). Right beneath the github logo there's a select box which states your current "account context" (that's the proper github term for it). You can switch the account context there as well.

I assume the account context switched to your organization when you created it or something. Very hard to even notice.

YL

[onli]

Sadly no, I know that dropdown and "onli" is selected. Always has been - and I don't realize how that option on the webpage could mess with commits coming from my system (s9y was cloned from onli). I just sent a support-request. Thanks.

Someone already tested the new archive-pattern?

Edit: Regarding the github-avatar: The support told me that they simply compare the email-adresses. I did indeed add my github-email to the organization, that's why it was chosen. Changing the adress there and adding it to my user-account seems to fix it.

[garvinhicking]

Hi!

I just tested it; IMHO this makes no sense as its currently implemented.

When I call garv.in/serendipity/ and click on "next page" it goes to page 133, and shows a page with my oldest entries. What I would expect is going to the next page that shows the entries before the current ones.

Regards,
Garvin

[onli]

When I call garv.in/serendipity/ and click on "next page" it goes to page 133, and shows a page with my oldest entries. What I would expect is going to the next page that shows the entries before the current ones.

It should go to page 133, good so far, but on this page should be the newest (before the current). I'll test that again, but thought that worked on my system. Maybe a different sql-syntax for ordering ("ORDER BY timestamp ASC")? Which db was used?

[garvinhicking]

Hi!

Seems like your commit could be broken? I was already wondering where the actual change would happen? Check the git diff...?

I am using mysql. I'll leave my blog in the current state, tell me if I should change any variable that could help you.

[Don Chambers]

I am not currently running the latest from github, so cannot easily test this.... has anyone tried this new behavior with bulletproof's pagination?

[onli]

Thanks Garvin. Indeed, i forgot to add genpage.inc.php to the commit. In there, the order by is changed.

Don: No, I havent tried that yet with bp. If it works in general, I could try to look into that, if no one else does that. Was the URL-order there hardcoded?

[garvinhicking]

Hi!

That makes things a bit better, but still also confusing.

When you go to my blog on the first page the most recentt entry comes first; this is good. Now you paginate to page 133, but there the first entry on the page is the oldest of those articles; it should be on the bottom of the page, not at the top.

Also, when I go to the "previous page" I expect the most recent article on top, but now it's also at the bottom.

Regards,
Garvin

[Don Chambers]

Don: No, I havent tried that yet with bp. If it works in general, I could try to look into that, if no one else does that. Was the URL-order there hardcoded?

Latest version of it looks like this:

Code: Select all

    {if $template_option.show_pagination == 'true' && $footer_totalPages > 1}
        <div class="pagination">
            {assign var="paginationStartPage" value="`$footer_currentPage-3`"}
            {if $footer_currentPage+3 > $footer_totalPages}
                {assign var="paginationStartPage" value="`$footer_totalPages-6`"}
            {/if}
            {if $paginationStartPage <= 0}
                {assign var="paginationStartPage" value="1"}
            {/if}
            {if $footer_prev_page}
                <a title="{$CONST.PREVIOUS_PAGE}" href="{$footer_prev_page}"><span class="pagearrow">&#9668;</span></a>
            {/if}
            {if $paginationStartPage > 1}
                <a href="{$footer_pageLink|replace:'%s':'1'}">1</a>
            {/if}
            {if $paginationStartPage > 2}
                &hellip;
            {/if}
            {section name=i start=$paginationStartPage loop=$footer_totalPages+1 max=7}
                {if $smarty.section.i.index != $footer_currentPage}
                    <a href="{$footer_pageLink|replace:'%s':$smarty.section.i.index}">{$smarty.section.i.index}</a>
                {else}
                    <span id="thispage">{$smarty.section.i.index}</span>
                {/if}
            {/section}
            {if $smarty.section.i.index < $footer_totalPages}
                &hellip;
            {/if}
            {if $smarty.section.i.index <= $footer_totalPages}
                <a href="{$footer_pageLink|replace:'%s':$footer_totalPages}">{$footer_totalPages}</a>
            {/if}
            {if $footer_next_page}
                <a title="{$CONST.NEXT_PAGE}" href="{$footer_next_page}"><span class="pagearrow">&#9658;</span></a>
            {/if}
        </div>
    {/if}