[wp-trac] [WordPress Trac] #36339: Possible issue with export_wp() and undefined custom post types (was: Possible issue with wp_export() and undefined custom post types)

[WordPress Trac]

#36339: Possible issue with export_wp() and undefined custom post types
--------------------------+------------------------------
 Reporter:  theMikeD      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Export        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Description changed by DrewAPicture:

Old description:

> While writing the improved docblock for wp_export, I noticed something
> that may be an issue if an invalid custom post type is supplied. Here is
> the code:
>
> {{{#!php
> <?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 occured 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.
> 1. 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?

New description:

 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
 <?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.
 1. 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?

--

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36339#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform