[wp-trac] [WordPress Trac] #22538: 'wp_image_editor_class' vs. 'wp_image_editors'

[WordPress Trac]

#22538: 'wp_image_editor_class' vs. 'wp_image_editors'
-------------------------+--------------------
 Reporter:  scribu       |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  3.5
Component:  Media        |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+--------------------

Comment (by nacin):

 I'd really like to see what we can do to model this after WP_Http as much
 as possible, as it has served us well, and it is good to have consistency.

 Check it out:
 {{{
         public static function test( $args = array() ) {
                 if ( ! function_exists( 'curl_init' ) || !
 function_exists( 'curl_exec' ) )
                         return false;

                 $is_ssl = isset( $args['ssl'] ) && $args['ssl'];

                 if ( $is_ssl ) {
                         $curl_version = curl_version();
                         if ( ! (CURL_VERSION_SSL &
 $curl_version['features']) ) // Does this cURL version support SSL
 requests?
                                 return false;
                 }

                 return apply_filters( 'use_curl_transport', true, $args );
         }
 }}}

 Note how SSL is tested, based on $args. This would be equivalent to
 checking mime types in test(). In our case, the filter outside test() does
 make more sense.

 I actually like our existing filters. I would not tweak much, given the
 chance. But:

  * image_editors should be a simple array of available editors. $args
 should not be desired here, as it allows us to be able to always figure
 out all registered editors, regardless of conditionals. Better for
 forwards compatibility.

  * We should probably have a variable filter on the result of test(),
 which *should* receive $args. Think about the use case of *removing* a
 single editor from the rotation based on a certain situation. You don't
 want to force a particular one, you just want to remove it. Also great for
 unit testing.

  * A image_editor_class filter probably makes more sense as the return
 value of _wp_image_editor_choose(), not in wp_get_image_editor(), so
 supports() uses that information to know whether an editor is available.
 Alternatively, there should be a filter on supports().

  * image_editor_class should be on the class name — I don't really see the
 reason for it to be on the object. If anything, we should fire an *action*
 with the instantiated object to allow triggers to happen then.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22538#comment:26>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software