[#19303] - Adding CSS classes to pagebreak.php and other improvements
- Closed
- 16 Apr 2018
- Medium
- Build: staging
- # 19303
- Diff
- AndySDH:staging
User tests: Successful: Unsuccessful:
Updated Pull Request for Issue #14670, now that I got more knowledge on how a PR is made correctly.
Since the navigation for multi-page articles (plugins/content/pagebreak.pagebreak.php) can't be template-overridden (unlike the article navigation in pagenavigation.php, which can), we should make some basic improvements to it in the core. This is what I did for my site and would be beneficial in general:
Summary of Changes
This PR:
-
Adds CSS classes to the prev/next links, so they can be stylized via CSS (currently they have no class)
-
Adds a pagenavcounter also at the bottom of the page.
-
Changes behavior so that the "Previous" Link is not shown when we are on the first page, and the "Next" Link is not shown when we are on the last page. When we are on the first page, there is little point in showing a blank unclickable "prev" link. Sites don't show that. Same thing for when we are on the last page, the "next link" should not be shown.
-
Adds a different language string for these next page/prev page links, as they are not the generic next/prev article links, but they represent next page/previous page. By having a different language string we can individually value these as "PREV PAGE" and "NEXT PAGE".
Documentation Changes Required
None.
| Status | New | ⇒ | Pending |
| Category | ⇒ | Administration Language & Strings Front End Plugins |
Instead I think the HTML markup should be moved to a layout so it can be overridden and changed by a users if need be.
^^ That
Not sure about others but I dont agree with this. I don't see the point in adding classes if they're not actually going to be used in core.
Note that this doesn't just add classes but also makes a lot of other improvements, including change to if conditionals when on first/last page, and new language strings specific for the occurrence.
But feel free to turn it into a layout or to do something different if you wish!
| Labels |
Added:
?
?
|
||
It's not necessarily that the changes here are bad, but if you've got a situation where you need to adjust the markup the only option is to duplicate the plugin and maintain it all because the markup is hardcoded into it.
Although to be honest this is one of the plugins I just want to get rid of in 4.0 and just merge all the logic into com_content. Because this plugin literally only supports the article view of that component.
Besides the question if the plugin should be removed, the markup has to be in a layout and not hardcoded within the plugin
| Closed_Date | 2018-04-16 03:08:10 | ⇒ | 2018-04-16 03:08:11 |
| Closed_By | Quy | ⇒ | joomla-cms-bot |
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-04-16 03:08:10 |
| Closed_By | ⇒ | Quy |
Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/19303
Closing for reasons as stated above.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19303.
Not sure about others but I dont agree with this. I don't see the point in adding classes if they're not actually going to be used in core.
Instead I think the HTML markup should be moved to a layout so it can be overridden and changed by a user, if need be.