WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 21 months ago

#18817 closed enhancement (wontfix)

WP_List_Table nonce output moved to its own method

Reported by: bigdawggi Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.2.1
Component: Plugins Keywords: has-patch
Focuses: Cc:

Description

A quick little patch to move the nonce field generation and output to its own field. I ran across a need for this when implementing the class on a postmeta box on the post edit screen. Both the post edit form and the WP_List_Table class were outputting a nonce field using the name "_wpnonce". Upon submission this was prohibiting the post from saving.

I had to override the entire display_tablenav method whereas if the output of the nonce was its own method, I could override it there and change the name of the field it was outputting.

Attachments (1)

wp-list-table-nonce.diff (878 bytes) - added by bigdawggi 6 years ago.
Patch to move the output of the nonce field for the WP_List_Class table to its own method

Download all attachments as: .zip

Change History (6)

@bigdawggi
6 years ago

Patch to move the output of the nonce field for the WP_List_Class table to its own method

#1 @devinreams
6 years ago

  • Cc devin@… added

#2 @bigdawggi
5 years ago

I don't see any issue with this ticket, can this make it into 3.4?

#3 @bigdawggi
4 years ago

This still seems like it needs addressed. I checked and the implementation in the original patch should still work.

#4 @nacin
3 years ago

  • Component changed from General to Plugins

#5 @DrewAPicture
21 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I can see the merit in your request, as I've run into a very similar problem recently and, like you, ended up completely overriding the display_tablenav() method.

In the case of the list table class, it's built in such a way that it's inherently meant to be overridden and with that structure comes a certain predictability. I think the best move is to leave it as-is. As you said, even if we were to relocate the generated nonce to a new method, you'd still have to override the new one. The problem would become more localized, yes, but mostly just relocated.

Note: See TracTickets for help on using tickets.