Notification counter vs. pagination

[danbp]

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>

[danbp]

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.

[danbp]

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

[hnla]

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.

[hnla]

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.

Is this a live site have you got a link to it?

Pagination does appear to be broken, but broken for the 'number' links, the last of first '->' 'next' links do work.

[hnla]

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/&/

[danbp]

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;
}

[hnla]

@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 ;) :)

[danbp]

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( '&' . $r['page_arg'] . '=1', '', $this->pag_links );

But not the content issue.

[r-a-y]

Confirmed. Looking into it.

[r-a-y]

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.

[boonebgorges]

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.

[johnjamesjacoby]

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)

[johnjamesjacoby]

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)

[johnjamesjacoby]

Marking as resolved.

Thanks Ray!