Possible issue with export_wp() and undefined custom post types

[theMikeD]

While writing the improved docblock for export_wp(), I noticed something that may be an issue if an invalid custom post type is supplied. Here is the code:

<?php
        if ( 'all' != $args['content'] && post_type_exists( $args['content'] ) ) {
                $ptype = get_post_type_object( $args['content'] );
                if ( ! $ptype->can_export )
                        $args['content'] = 'post';

                $where = $wpdb->prepare( "{$wpdb->posts}.post_type = %s", $args['content'] );
        } else {
                $post_types = get_post_types( array( 'can_export' => true ) );
                $esses = array_fill( 0, count($post_types), '%s' );
                $where = $wpdb->prepare( "{$wpdb->posts}.post_type IN (" . implode( ',', $esses ) . ')', $post_types );
        }

The two things that occurred me are

1. If a valid custom post type is supplied but its can_export property is false, posts will be used instead. This is unexpected behaviour. I think it should stop and not export anything.
2. if an invalid custom post type is supplied, every post type that has can_export set to true is used. This is also unexpected behaviour. I think it should stop and not export anything.

Am I reading this wrong? Is there a reason why it works this way?

[theMikeD]

Improved docblock is here FTR #36338

[screamingdev]

It might be solved as described below.
Maybe a core committer can review the described way, so that I don't do all the work for nothing ;)

I'll write a UnitTest next week covering these scenarios:

• If a valid post type is supplied but its can_export property is false, no entry of this post type should be exported.
• If an invalid post type is supplied then an error message should occur instead of doing the regular export with all allowed post types.

After that a mock of the error message is needed here to show what the error message will look like.
Later on I try solving this ticket.

[earnjam]

I agree. We should be throwing errors from export_wp() instead of exporting unexpected data, even if that odd behavior is properly documented now.

The current export UI in the admin doesn't show any post types which don't have can_export set to true. This would only be a possible issue for other external direct calls to export_wp(), so there wouldn't be any design work involved here.