[Resolved] Custom filter in WordPress dashboard is only half working

[Author]

Posts

[Jackie]

Hi there,

This question may be beyond what Toolset Support can provide, but perhaps the wizards are feeling generous today.

The goal: on the "All items" list of a custom post type in the WordPress dashboard, add an additional pull-down menu by which to filter the list of posts. For example, I'm building a course catalog for the Continuing Education department at a college of art and design. New catalogs launch every season. I'd like to filter the list of all courses by season so I can focus on just spring and ignore summer. Does that make sense?

Here's the code I came up with (based on reading https://wordpress.stackexchange.com/questions/45436/add-filter-menu-to-admin-list-of-posts-of-custom-type-to-filter-posts-by-custo):

// add the select menu to choose the catalog season
function pce_restrict_filter_admin_posts ( ) {
$type = 'section' ;

if ( isset ( $_GET['post_type'] ) ) {
$type = $_GET['post_type'] ;
}

if ( 'section' == $type ){
$catalogs = get_posts ( array ('numberposts'=> -1, 'post_type' => 'catalog' ) ) ;
$values = array ( ) ;
foreach ( $catalogs as $catalog ) {
$values[$catalog->post_title] = $catalog->ID ;
}

?>
<select name="catalog">
<option value="">All catalogs</option>
<?php
$current_value = isset ( $_GET['catalog'] ) ? $_GET['catalog'] : '' ;
foreach ( $values as $label => $value ) {
printf
(
'<option value="%1$s"%2$s>%3$s</option>',
$value,
$value == $current_value ? ' selected="selected"' : '',
$label
);
}
?>
</select>
<?php
}
}
add_action ( 'restrict_manage_posts', 'pce_restrict_filter_admin_posts' ) ;

// modify wp_query before it's executed
function pce_filter_posts ( $query ){
global $pagenow;

$type = 'section';

if ( isset ( $_GET['post_type'] ) ) {
$type = $_GET['post_type'];
}
if ( 'section' == $type && is_admin ( ) && $pagenow == 'edit.php' && isset ( $_GET['catalog'] ) && $_GET['catalog'] != '' && $query->is_main_query ( ) ) {
$section_ids = toolset_get_related_posts ( $_GET['catalog'], 'catalog-to-section-relationship', array ( 'query_by_role' => 'parent', 'limit' => 999, 'return' => 'post_id', 'role_to_return' => 'child' ) ) ;

$query->query_vars['post__in'] = $section_ids ;
unset ( $query->query_vars['name'] ) ;

}
}
add_filter ( 'parse_query', 'pce_filter_posts' ) ;

The above code actually works. Here's my issue: after I press the "Filter" button, the listing of posts on the screen that loads next no longer displays the filter menu. It disappears. Please see the attached animated GIF. Do you know why the menu is disappearing?

Saul

[Christian Cox]

Not sure offhand, this is custom code that's not supported here in the forums. My suggestion is to add some debug log statements to your code so you can follow the code execution by tailing the error log. If any errors are thrown, you'll see them appear in the error log. If no errors are thrown, you'll still be able to verify the code is being executed. For example:

function pce_restrict_filter_admin_posts ( ) {
$type = 'section' ;

if ( isset ( $_GET['post_type'] ) ) {
error_log( 'isset post_type');
$type = $_GET['post_type'] ;
error_log('type: ' . $type);
}

if ( 'section' == $type ){
error_log('section == type');
$catalogs = get_posts ( array ('numberposts'=> -1, 'post_type' => 'catalog' ) ) ;
error_log(print_r($catalogs, true));
// and so on

To turn on error logging, go in your wp-config.php file and look for

define('WP_DEBUG', false);

Change it to:

define('WP_DEBUG', true);

Then add these lines, just before it says 'stop editing here':

ini_set('log_errors',TRUE);
ini_set('error_reporting', E_ALL);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');

Now when the page loads, it will create an error_log.txt file in your site's root directory. You can tail it or keep it open in a browser and refresh it frequently. By following the log statements, you can see how the code is being executed.

[Jackie]

Christian,

Thanks for the suggestions. I made the changes that you recommended, but no errors are being logged when the code executes. At this point I have to think that there's a logic error somewhere. I'll keep trying to figure it out.

Perhaps this ticket could be marked as closed but not resolved?

Saul

[Christian Cox]

Thanks for the suggestions. I made the changes that you recommended, but no errors are being logged when the code executes.
Right, I didn't expect errors, necessarily. I meant that you should log something important at each step in the code to determine which lines of code are actually being executed, and why.

Perhaps this ticket could be marked as closed but not resolved?
If we mark it closed, it cannot be reopened. I'll mark it resolved and if you'd like to continue discussion you may reopen the ticket later.