WP 4.3 changes in WP_List_Table

[imath]

In ​WP32644, WordPress is introducing the get_default_primary_column_name() function into the WP_List_Table class and this new method seems to be required to avoid a notice error. We are concerned for the activity & groups administration screens.

This might evolve during WP 4.3 cycle, just putting this as a reminder.

[imath]

Just tested parts where we are using WP_List_Tables and found 2 little things we should also fix :

• Add a 'wp-list-table' class to the table tag in the display() methods of our classes (activity and groups) This makes sure WordPress css is applied to the button.toggle-row element of the primary column.
• Fix a notice error in the Manage signups WP_List_Tables extensions

6465.02.patch is 6465.patch + the above 2 points.

[johnjamesjacoby]

See also ​[WP33016] where the toggle that was introduced results in a rogue button in our rows

[johnjamesjacoby]

In 10005:

Admin: Add new wp-list-table class to Activity & Groups list tables.

The commit ensures BuddyPress's list-table implementation integrates nicely wih WordPress's default administration styling. It also addresses a WordPress 4.3 compatibilty issue introduced in ​[WP33016] that left the new .toggle-row button visible on our rows.

See #6465. For 2.4 (trunk)

[johnjamesjacoby]

In 10006:

Admin: Add new wp-list-table class to Activity & Groups list tables.

The commit ensures BuddyPress's list-table implementation integrates nicely wih WordPress's default administration styling. It also addresses a WordPress 4.3 compatibilty issue introduced in ​[WP33016] that left the new .toggle-row button visible on our rows.

See #6465. For 2.3.3 (2.3 branch)

[johnjamesjacoby]

In 10007:

Admin: Add primary columns to our list table implementations.

The commit ensures BuddyPress's list-tables have "primary" columns, to play nicely with new WordPress 4.3.0 requirement introduced in ​[WP32722]. BuddyPress manually sets $_column_headers for horse reasons.

See #6465. For 2.3.3 (2.3 branch)

[johnjamesjacoby]

In 10008:

Admin: Add primary columns to our list table implementations.

The commit ensures BuddyPress's list-tables have "primary" columns, to play nicely with new WordPress 4.3.0 requirement introduced in ​[WP32722]. BuddyPress manually sets $_column_headers for horse reasons.

Fixes #6465. Props imath. For 2.4.0 (trunk)

[imath]

For the signups WP_List_Table in multisite configs, the regular user row actions are output under the signup ones.

This appeared since the introduction of the WP_MS_Users_List_Table->handle_row_actions() function see 6465.row_actions.patch

[johnjamesjacoby]

Replying to imath:

For the signups WP_List_Table in multisite configs, the regular user row actions are output under the signup ones.

This appeared since the introduction of the WP_MS_Users_List_Table->handle_row_actions() function see 6465.row_actions.patch

Confirmed. And the patch fixes it, though I think we should return an empty string instead of having an empty method.

The empty method does more-simply satisfy the class/subclass override scenario (by assuming null results) but does not explicitly tell the system to ditch whatever assumptions were made previously (like WP_MS_Users_List_Table::handle_row_actions() does as an example.)

I'll commit to 2.3 branch and trunk so we can release an update when WP4.3.0 ships.

[johnjamesjacoby]

In 10026:

Sign-ups: Introduce BP_Members_List_Table::handle_row_actions() for WordPress 4.3.0 compliance.

This changeset ensures that sign-up list-table row-actions do not collide with row-actions from other classes in the stack.

Props imath. Fixes #6465. (trunk)

[johnjamesjacoby]

In 10027:

Sign-ups: Introduce BP_Members_List_Table::handle_row_actions() for WordPress 4.3.0 compliance.

This changeset ensures that sign-up list-table row-actions do not collide with row-actions from other classes in the stack.

Props imath. Fixes #6465. For 2.3.3 (2.3 branch)

[johnjamesjacoby]

In the above commit messages, I incorrectly identified BP_Members_MS_List_Table as BP_Members_List_Table.

[johnjamesjacoby]

Worth noting that this problem does not manifest itself when:

• WordPress is in Multi-side mode
• BuddyPress is activated only on the single site (not network activated)

In this funny scenario, the "Manage Signups" menu is added to the wp-admin/network/ dashboard but is probably using the incorrect class. This likely needs it's own ticket, related to this one.

[johnjamesjacoby]

This likely needs it's own ticket, related to this one.

Confirmed. This seems more like a bug/quirk in the bp_is_multiblog_mode() implementation. The above mentioned activation configuration causes bp_get_admin_url() and bp_core_do_network_admin() to return results that don't really apply to this setup.

[mercime]

WP 4.3 trunk, BP 2.4 trunk, single site

Toggles for Activities are missing and layout broken in mobile view per attached screenshot. (groups are fine)

[DJPaul]

@mercime I just tested this on the BP 2.3 branch and WP trunk, and I see the arrows in the place where you've indicated. Don't know what fixed it.

[mercime]

@djpaul ​https://core.trac.wordpress.org/ticket/33313 fixed the arrows :)

There's still some style issues though, alternate color overlapping to the next TD. Attached is a screenshot as seen in Chrome.

[DJPaul]

I can't figure out how to fix that styling. Help, please.

[r-a-y]

I think this could be a WP CSS bug.

Changing display:block to display:table-cell works for the following declaration in /wp-admin/css/list-tables.css:

@media screen and (max-width: 782px) {
   .wp-list-table tr:not(.inline-edit-row):not(.no-items) td:not(.check-column) { display: table-cell; }
}

[DJPaul]

I couldn't figure out what we were adding to the table that was causing it to break with WP's CSS. Were you able to narrow it down to anything specific?

[r-a-y]

Just looked into this.

It has to do with the div.row-actions block. In Activity admin, the 'div.row-actions block is in the second <td>, while on other admin pages, the div.row-actions block is in the first <td>.

That is the gist of the problem.

My CSS patch should fix this for the Activity admin area, but because our div.row-actions block is not in the first <td>, when you click on the arrow to expand the activity, the expanded content doesn't look like other WP admin pages and looks slightly off.

[mercime]

@r-a-y Exactly! We also need to remove duplicate <button> in markup. Attached screenshots

[mercime]

+1 for r-a-y's CSS solution and removing extra buttons :)

[r-a-y]

mercime - Is the duplicate button markup a result of using WP 4.3.0?

I'm not sure if it is. Regardless, duplicate-button-markup.patch should fix this. Had to override the WP_List_Table::row_actions() method to remove the hardcoded <button> markup.

[mercime]

@r-a-y Just checked old test install using WP 4.2+ and BP 2.3.1 and there are no button markups within TD's there.

[r-a-y]

Yeah, you're right, mercime!

Looks like WP decided to add an extra <button> in WP_List_Table::row_actions() for v4.3.

duplicate-button-markup.patch above should fix the problem.

[DJPaul]

6465.duplicate-button-markup.patch​ doesn't fix the problem on trunk (on the Activity wp-admin list table). Also, the copy/paste from WP has a handful of coding standards issues.

[r-a-y]

6465.duplicate-button-markup.patch​ doesn't fix the problem on trunk (on the Activity wp-admin list table).

Works for me on the Activity admin page. You should only see one <button> in the table row. Specifically, in the td.column-author column.

Are you talking about BP trunk or WP trunk? I'm testing on WP 4.3.0 and BP trunk.

Can someone else verify?

---

If you're talking about comment:19, you'll also need to ​apply this patch.

[DJPaul]

WP trunk (the one where they changed the version to 4.4-alpha or something). BP trunk.

I am only applying 6465.duplicate-button-markup.patch​ which I can confirm removes the duplicate button element. However, that doesn't fix the problem, which is the overlapping backgrounds as shown in Mercime's screenshot here ​https://buddypress.trac.wordpress.org/ticket/6465#comment:19

What am I doing wrong?

[r-a-y]

See the latter part of my comment:32:

If you're talking about comment:19, you'll also need to ​apply this patch.

Let me know if this works for you.

[DJPaul]

I don't understand why if both these patches are needed, why they are split, but thanks.

[djpaul]

In 10065:

Activity, Groups: fix styling compatibility problems introduced by WordPress 4.3.

Fixes #6465 (trunk). Props r-a-y, mercime.

[djpaul]

In 10066:

Activity, Groups: fix styling compatibility problems introduced by WordPress 4.3.

Fixes #6465 (2.3 branch). Props r-a-y, mercime.

[r-a-y]

I don't understand why if both these patches are needed, why they are split, but thanks.

Sorry about that! The issues were reported separately, so I isolated each issue into its own patch.