Skip to:
Content

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#6465 closed defect (bug) (fixed)

WP 4.3 changes in WP_List_Table

Reported by: imath Owned by: johnjamesjacoby
Milestone: 2.3.3 Priority: normal
Severity: blocker Version:
Component: Administration Keywords: has-patch early
Cc:

Description

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.

Attachments (10)

6465.patch (1.5 KB) - added by imath 3 years ago.
6465.02.patch (3.6 KB) - added by imath 3 years ago.
Screen Shot 2015-07-10 at 4.32.44 PM.png (28.9 KB) - added by johnjamesjacoby 3 years ago.
See also [WP33016] where the toggle that was introduced results in a rogue button in our rows
6465.row_actions.patch (835 bytes) - added by imath 2 years ago.
admin-activity-mobile.png (31.9 KB) - added by mercime 2 years ago.
admin-activity-mobile-ii.png (40.1 KB) - added by mercime 2 years ago.
6465.activity-admin.patch (457 bytes) - added by r-a-y 2 years ago.
bp-activity.png (95.6 KB) - added by mercime 2 years ago.
bp-groups.png (33.3 KB) - added by mercime 2 years ago.
6465.duplicate-button-markup.patch (2.3 KB) - added by r-a-y 2 years ago.

Download all attachments as: .zip

Change History (48)

@imath
3 years ago

#1 @DJPaul
3 years ago

  • Keywords early added
  • Milestone changed from Under Consideration to 2.4

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


3 years ago

#3 @imath
3 years ago

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.

@imath
3 years ago

@johnjamesjacoby
3 years ago

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

#4 @johnjamesjacoby
3 years ago

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)

#5 @johnjamesjacoby
3 years ago

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)

#6 @johnjamesjacoby
3 years ago

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)

#7 @johnjamesjacoby
3 years ago

  • Owner set to johnjamesjacoby
  • Resolution set to fixed
  • Status changed from new to closed

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)

#8 follow-up: @imath
2 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

#9 in reply to: ↑ 8 @johnjamesjacoby
2 years ago

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.

#10 @johnjamesjacoby
2 years ago

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

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)

#11 @johnjamesjacoby
2 years ago

  • Milestone changed from 2.4 to 2.3.3

#12 @johnjamesjacoby
2 years ago

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)

#13 @johnjamesjacoby
2 years ago

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

#14 @johnjamesjacoby
2 years ago

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.

#15 @johnjamesjacoby
2 years ago

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.

#16 @mercime
2 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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)

Last edited 2 years ago by mercime (previous) (diff)

This ticket was mentioned in Slack in #buddypress by djpaul. View the logs.


2 years ago

#18 @DJPaul
2 years ago

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

@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.

#19 @mercime
2 years ago

@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.

#20 @DJPaul
2 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

This ticket was mentioned in Slack in #buddypress by djpaul. View the logs.


2 years ago

#22 @DJPaul
2 years ago

  • Severity changed from normal to blocker

#23 @r-a-y
2 years ago

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

#24 @DJPaul
2 years ago

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?

#25 @r-a-y
2 years ago

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.

#26 @mercime
2 years ago

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

@mercime
2 years ago

@mercime
2 years ago

#27 @mercime
2 years ago

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

#28 @r-a-y
2 years ago

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.

If the duplicate markup happened before WP 4.3.0, we should apply the duplicate markup patch in v2.4.0 since it isn't a regression.

Last edited 2 years ago by r-a-y (previous) (diff)

#29 @mercime
2 years ago

@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.

#30 @r-a-y
2 years ago

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.

#31 @DJPaul
2 years ago

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.

#32 @r-a-y
2 years ago

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.

Last edited 2 years ago by r-a-y (previous) (diff)

#33 @DJPaul
2 years ago

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?

#34 @r-a-y
2 years ago

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.

#35 @DJPaul
2 years ago

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

#36 @djpaul
2 years ago

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

In 10065:

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

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

#37 @djpaul
2 years ago

In 10066:

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

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

#38 @r-a-y
2 years ago

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.

Note: See TracTickets for help on using tickets.