MyBB

I'm no expert in SEO, how would you fix the issue? Header redirection?

Couldn't you just check if page-1 is in the URL and strip it out? Or just make it so if you can't find page-1 in the URL, it redirects to the URL with page-1 included?

Just make sure only one or the other is linked to. Either use "page-1" in all links to forum view or topic view, or stop the pagination from putting "page-1" in the links.

this also exists with non-seo urls. http://community.mybb.com/thread-79043.html

r5236 causes a little issue for some plugins which use multipage but have another kind of URLs than the default ones. For example: http://www.example.com/{page}/
The "{page}" was parsed for all numbers except the first page. The link to the first page wasn't parsed.
A possible fix would be to replace lines 963-969:

        $find = array(
            "-page-{page}",
            "&page={page}",
        );

        // Remove "Page 1" to the defacto URL
        $url = str_replace($find, array("", ""), $url);

        $find = array(
            "-page-{page}",
            "&page={page}",
            "{page}" 
        );

        // Remove "Page 1" to the defacto URL
        $url = str_replace($find, array("", "", $page), $url);

Would be nice to see this fixed in MyBB 1.6.2... :-)

Good catch...

This issue even affects MyBB. In private.php the parameter for multipage is not page= but read_page= and unread_page=. So if you go to your private message folder, and to page 2 of either the PM inbox or tracking folder, and hover over the link back to page 1, you see it literally points to page={page} instead of page=1 or nothing.

However you still end up in the right place :) because "{page}" evaluates to 0 and page 0 and page 1 both cause page 1 to be shown, usually... so most people wouldn't even ever notice this bug. Google SEO is affected by this as well (uses ?page= and not &page= - and before you get any ideas, you can't remove the ?), however it also removes the page parameter by itself so no one notices that one either...

The suggested fix solves this issue as it provides a fallback - it ensures {page} is replaced properly, if it couldn't be removed.

I'm not sure we should be fixing issues that occur from plugins adding extra pages, although if there are places in MyBB (I've noticed the breadcrumb still has it in, for example) where there is still page=1, then please report it.

If the page is not publicly viewable - as Andreas mentioned - then this issue doesn't really relate to it (unless it causes issues somewhere else). It was originally to fix duplicate content from search engines.

multipage() or more specifically fetch_page_url() produces broken links for example private.php?action=tracking&unread_page={page} - this is a new issue in MyBB (regression introduced by r5326). Fix provided above by Chris Köcher seems to work fine, please apply it. Thank you.

It was originally to fix duplicate content from search engines.

Yes, but the intention wasn't th breaking of plugins... :-P

As Andreas said, its only a fallback for the case where the {page} couldn't be replaced/removed. The fix doesn't cause any performance issues. It's only a little change of 3 lines which isn't a big amount of work... ;-)

Stefan, maybe you forgot to write some text? :P

Everything was explained in the comments above...

Thank you for fixing that! :-)

But I've found another little issue: On showthread the breadcrumb with popop links to forum-*id*-page-1.html instead of forum-*id*.html
I don't know if this is fixed since the release of 1.6.1. Maybe someone could check this...

In 1.6.2 package on repo this bug didn't fixed.

doesn't this turn page=123 to 23?