Show Custom Field data on All Pages table listing

That documentation may not be totally useless, it just needs to be adapted. All admin tables are based on the same WP_List_Table class, so even if the documentation is for, say, posts, such as Plugin API/Action Reference/manage posts custom column, the information can be extended to other table types.

The only real trick is determining the correct filter and action to hook. For pages, I’m guessing you use the ‘manage_page_posts_columns’ filter and ‘manage_page_posts_custom_column’ action, but I could be wrong.

The basic process is to use the filter to add your columns to the column name array. The action is then triggered when it is appropriate to output HTML for that column in each row of the table. Your callback is passed the column name and page ID, you can output what ever you want from where ever at this point.

@bcworkz

Your assumptions are correct: I am using manage_pages_custom_column docs, and the mananage_page_posts_custom_column action. I think I missed the filter manage_page_posts_columns.

I think may have been missing something in your explanation: that the filter actually adds a column name to the definition for the table, and that that column name becomes the trigger for my custom data to be written into the table. I was assuming the column had to be part of a preexisting SQL entity for it to become part of the table. I’ll have another look now with this in mind.

The column is completely arbitrary, it can be for anything. The content inserted in the column at each row can be anything within the scope of the action hook. It is logical the data be related to the other table content, but it is not required. The data is often from the database, but this is not a requirement.

I actually looked a little deeper into WP_List_Table last night for my own benefit during some free time. (Is that pathetic?) The filter for adding columns is very consistent amongst the various class extensions. The only variable is the screen id. The hooks to insert cell data are much more variable. They are usually actions, but are filters in some cases. The Posts table (used for Pages as well) actually has several possible actions, it appears you can use either ‘manage_pages_custom_column’ or ‘manage_page_posts_custom_column’ for Pages. The correct filter to add columns for the Pages table appears to be ‘manage_edit-page_columns'(note the one hyphen ‘-‘ ).

I’ve not actually tested any of my findings, but it comes from a fairly thorough study of the class definitions and screen IDs. Adding the column is pretty straight forward, but the action to output content takes some care. The action fires for every custom column added, so your action callback must not only get the ID for the current row’s entity, but must also check the column name to ensure the correct data is going into the correct column.

It takes some work to wrap one’s head around how list tables work, but once you get it, it can be a very powerful tool, especially when combined with AJAX to provide interactivity.

It just dawned on me where your assumption about the need for column data to be from SQL tables. This actually is a requirement for the column to be sortable, as the sorting is done by mySQL. As long as the column does not need to be sortable, it can contain any arbitrary data. If your data MUST be sortable, this is a crucial distinction.

Ah ha! ;-P
Thanks for taking the time. The quality of your feedback is most excellent. I do not require sortability for this case, so I was able to resolve it by creating an arbitrary column and feeding the data I needed visible when that column was hooked.
Thanks, bcworkz. Top notch.