Skip to:
Content

BuddyPress.org

Opened 5 years ago

Closed 5 years ago

#6205 closed defect (bug) (fixed)

Notification counter vs. pagination

Reported by: danbp Owned by: r-a-y
Milestone: 2.2.1 Priority: normal
Severity: normal Version: 2.2
Component: Toolbar & Notifications Keywords: has-patch commit
Cc:

Description

When on a user's notification screen, the counter is showing, but nothing happens when clicking on page 2,3....

There is also an issue with the template. The notification table is pushed to the right. See screenshot. It seems to affect only my custom theme as this didn't happen with 2012,13,14 & 15. But another user mentionned the same issue on bp-fr support forum, also with a custom theme.

The problem seems to sit in the message Vieving x notices encapsuled in a div with pagination class. When simply renaiming the class in div id "pag-top", the issue goes away. But it's a weird solution, because it's also impacting the js.

<div id="pag-top" class="pagination no-ajax">	
	<div class="pag-count" id="notifications-count-top">
		<?php bp_notifications_pagination_count(); ?>
	</div>

	<div class="pagination-links" id="notifications-pag-top">
		<?php bp_notifications_pagination_links(); ?>
	</div>
</div>

Attachments (2)

notice-tab.jpg (85.2 KB) - added by danbp 5 years ago.
6205.01.patch (562 bytes) - added by r-a-y 5 years ago.

Download all attachments as: .zip

Change History (18)

@danbp
5 years ago

#1 @danbp
5 years ago

I solved the layout problem by adding

<div class="dir-form"></div>

above the form in read.php and unread.php template files.

Would be a good point to see this in a next release, to better separate floating div's ?

That said the notification pagination is definetly out of order.

#2 @danbp
5 years ago

Forgot to mention that i don't use a customized notification template.

#3 @hnla
5 years ago

Not a great solution though having to add an empty div.

I'll take a look at this to see where/what has gone wrong.

.pag-top is/was a class we always used and I would expect to have to retain it in templates so if missing that's bound to be a bad thing.

From the looks of your SC this is a mis-matched tag somewhere.

#4 @hnla
5 years ago

The notification table is pushed to the right. See screenshot. It seems to affect only my custom theme as this didn't happen with 2012,13,14 & 15. But another user mentionned the same issue on bp-fr support forum, also with a custom theme.

What templates are you using, bp-default or templates based on bp-default? I see no issues with the bp-legacy templates.

The other reason floated elements might be disrupted is if an overflow value is removed, the pagination parent element is floated, floats contain other floats, by default the float property naturally contains floats iif the float property is removed it may well impact on the following elements, and I think I've seen this happen with this template before and the table construct.

I this a live site, have you got a link to it?

Last edited 5 years ago by hnla (previous) (diff)

#5 follow-up: @hnla
5 years ago

The pagination in a WP default theme does appear to be working however there's one oddity after clicking through to next pages and then trying the return to initial page '<-' first link my browsers throwing a redirect error:
admin/notifications/&#038;/

#6 @danbp
5 years ago

Thxs @hnla
live site is bp-fr.net and theme is based on bootstrap by rachel backer. And the error is temporarly solved. Emty divs are a poor solution you're right.

Meanwhile, a smoother way to get rid of the issue was to use this CSS trick

.notifications #buddypress #item-body > div.pagination,
.notifications #buddypress #item-body > div.pagination .pag-count{
    float: none;
}

#7 @hnla
5 years ago

@danbp That 'trick' tells me it is the reason I stated above, the parent element is NOT containing the floated children as they drop through the parent - correctly as floats are meant to - they cause conflict with the table element, try adding 'clearfix' to the parent (you're using a framework so should have the class 'clearfix' available or add overflow: hidden to it see if that cures the issue.

The empty div was/is putting a block level element between the table and the pagination block effectively separating them and stopping the floated elements 'touching' the table, but it's really a very poor and also plain wrong, naughty, bad, thing to do ;) :)

#8 in reply to: ↑ 5 @danbp
5 years ago

Tested with 2013, i confirm that pagination doesn't work for notification page.

Yes, the page # is highlighted, the url seems correct, but nothing happen onclick. The only thing who change is the page number.

Going upward is ok, but when going from to 2 to 1 or using the arrow, the url is wrong
/notifications/&#038;/ and the content stays on page 1 in any case.

Commenting this bp-notification-template solved the #038 issue:

$this->pag_links = str_replace( '?'      . $r['page_arg'] . '=1', '', $this->pag_links );
$this->pag_links = str_replace( '&#038;' . $r['page_arg'] . '=1', '', $this->pag_links );

But not the content issue.

#9 @r-a-y
5 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 2.2.1
  • Owner set to r-a-y
  • Status changed from new to reviewing

Confirmed. Looking into it.

@r-a-y
5 years ago

#10 @r-a-y
5 years ago

  • Keywords has-patch added; needs-patch removed

danbp is right that removing those lines fixes the pagination issue on notification pages.

01.patch does this.

The other issue regarding attachment:notice-tab.jpg is not related to BP core.

#11 @r-a-y
5 years ago

  • Status changed from reviewing to accepted

This ticket was mentioned in Slack in #buddypress by r-a-y. View the logs.


5 years ago

#13 @boonebgorges
5 years ago

  • Keywords commit added

This is not really a regression, but r-a-y has pointed out that https://core.trac.wordpress.org/ticket/30831 makes it much more visible, so I'm fine with fixing it for 2.2.1.

I assume the str_replace() being removed in 01.patch was originally there just to make the pagination links prettier. If it fixes the bug to unprettify them, I don't have a problem with it.

#14 @johnjamesjacoby
5 years ago

In 9499:

Remove code responsible for removing "page=1" query string arguments in notifications pagination.

This code in an anomaly in our components, and is causing issues with pagination links not having accurate destinations.

Props r-a-y. See #6205. (2.2 branch)

#15 @johnjamesjacoby
5 years ago

In 9500:

Remove code responsible for removing "page=1" query string arguments in notifications pagination.

This code in an anomaly in our components, and is causing issues with pagination links not having accurate destinations.

Props r-a-y. See #6205. (trunk)

#16 @johnjamesjacoby
5 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

Marking as resolved.

Thanks Ray!

Note: See TracTickets for help on using tickets.