User tests: Successful: Unsuccessful:
SEO impovement for views with pagination.
Add an option to not generate/build URL with empty limitstart - &limitstart=0
I added a few changes in com_content component to show how it can work.
Changes in pagebreak plugin:
&showall= - if someone will see a problem then I will revert it.&limitstart=I encourage to review the code. Any improvement is welcome.
You can test a new pagination option on article/category/featured/archive views.
No more &limitstart=0 or &start=0 in com_content component
Every 3rd party extension can enable this feature in model or view by adding:
// Flag indicates to not add `&limitstart=` or `&limitstart=0` to URL
$pagination->hideEmptyLimitstart = true;| Status | New | ⇒ | Pending |
| Category | ⇒ | Front End com_content Libraries Plugins |
| Labels |
Added:
?
|
||
| Category | Front End com_content Libraries Plugins | ⇒ | Front End com_contact com_content com_finder com_newsfeeds com_search com_tags Libraries Plugins |
| Category | Front End com_content Libraries Plugins com_contact com_finder com_newsfeeds com_search com_tags | ⇒ | Front End com_contact com_content com_finder com_newsfeeds com_search com_tags Libraries Plugins Unit Tests |
Please apply to Tagged items.
| Labels |
Added:
?
|
||
Done
Notice: Undefined variable: page_prev in \plugins\content\pagebreak\pagebreak.php on line 374
Fixed
I have tested this item
| Title |
|
||||||
@csthomas Technically it's a new feature and thus can't go into 3.8.x. It has to go into 3.9.0.
The code related to the pagination itself looks fine to me. I barely know the pagebreak plugin so I can't comment much there.
If it works for all affected views and that plugin, then it's fine
This PR requires one more human test.
I have tested this item
Tested with Category Blog menu option, tested page break plugin, too
| Status | Pending | ⇒ | Ready to Commit |
Ready to Commit after two successful tests.
Can we consider milestone Joomla 3.9.0 once again?
| Labels |
Added:
?
?
Removed: ? |
||
OK, merged
Be aware that $this->assertEquals(); is not a strict comparison (== vs ===), and both ...->active = '' or ...-> active = false will pass unit tests.
IIRC that's why $this->assertSame(); is the recommended approach (it does do (more) strict comparison).
Yes, obviously.
Travis passed.
Javascript error is not related to this PR.
One more human test please if needed.
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-08-02 22:32:10 |
| Closed_By | ⇒ | mbabker |
Now all should work as expected without any B/C break.
Affected views:
Every 3rd party extension can enable that option in model or view by adding: