• Resolved Russell Cardwell

    (@russell-cardwell)


    Fatal error: Class ‘WP_Image_Editor_GD’ not found in /###########/wp-content/plugins/ewww-image-optimizer/classes/class-ewwwio-gd-editor.php on line 286

    This occurs when WPSSO plugin is active.

    Appears to be some kind of conflict.

    The page I need help with: [log in to see the link]

Viewing 10 replies - 1 through 10 (of 10 total)
  • JS Morisset

    (@jsmoriss)

    FYI – Here is the relevant code from WPSSO which is triggering the bug:

    
    $editors = array( 'WP_Image_Editor_Imagick', 'WP_Image_Editor_GD' );
    
    $implementations = apply_filters( 'wp_image_editors', $editors );
    

    js.

    Plugin Author nosilver4u

    (@nosilver4u)

    This appears to be fixed by the WP SSO devs already, make sure you’re running the latest versions of both plugins.

    JS Morisset

    (@jsmoriss)

    WPSSO cannot fix a bug in EWWW. ??

    The problem is that EWWW fails to make sure WP_Image_Editor_GD is available before extending the class. This can be done several ways – the easiest of which might be to include a ‘require_once’ for the WP class files in class-ewwwio-gd-editor.php.

    To avoid triggering this bug in EWWW, the WPSSO code has included the WP class files before using the ‘wp_image_editors’, but this does NOT fix the EWWW bug. ??

    js.

    Plugin Author nosilver4u

    (@nosilver4u)

    Right, I get that, but with the fix in WPSSO, the “bug” in EWWW IO should not be triggered by WPSSO anymore, as far as I can tell. Am I missing something there?

    There will be a preventative check in the next release of EWWW IO, just to clarify.

    JS Morisset

    (@jsmoriss)

    I’m not sure why you quoted “bug” – shouldn’t EWWW check for the existence of a class before extending it? If you don’t, then you risk a PHP fatal error, as shown in this instance.

    The current version of WPSSO avoids triggering this bug in EWWW by pre-loading the WP library files that EWWW needs.

    js.

    Plugin Author nosilver4u

    (@nosilver4u)

    Mostly because I wasn’t sure if that was really “normal” usage, to run the wp_image_editors filter prior to the loading of the editors. But also because the code in EWWW IO is only following the example of some core devs who wrote the WP_Image_Editor classes way back in version 3.5. For example, see the Gmagick extension.

    Anyway, having looked at it further, I believe I understand why you’re doing it, but it still seems a bit awkward to me, but that’s just my opinion, take it for what it’s worth ??
    Regardless, I have no qualms in making sure EWWW IO is safe from such conflicts in the future, whether one would call it “normal” or not. Also, I greatly appreciate the speed at which you resolved the conflict. Not many devs are that responsive to conflicts.

    JS Morisset

    (@jsmoriss)

    WPSSO needs to know which image libraries WordPress is using, so it can make sure those PHP extension modules exist. You may be surprised to know, but some sites do not have ImageMagick *or* GD installed. That’s a problem when WordPress must provide an image of a specific size (and not the full size image).

    So, a full example from WPSSO looks like this (edited for brevity):

    
    $editors = array( 'WP_Image_Editor_Imagick', 'WP_Image_Editor_GD' );
    
    $implementations = apply_filters( 'wp_image_editors', $editors );
    
    $extensions = array(
    	'curl' => array(
    		'label' => 'Client URL Library (cURL)',
    		'url' => 'https://secure.php.net/manual/en/book.curl.php',
    	),
    	'gd' => array(
    		'label' => 'Image Processing (GD)',
    		'url' => 'https://secure.php.net/manual/en/book.image.php',
    	),
    	'imagick' => array(
    		'label' => 'Image Processing (ImageMagick)',
    		'url' => 'https://secure.php.net/manual/en/book.imagick.php',
    	),
    	'json' => array(
    		'label' => 'JavaScript Object Notation (JSON)',
    		'url' => 'https://secure.php.net/manual/en/book.json.php',
    	),
    	'mbstring' => array(
    		'label' => 'Multibyte String',
    		'url' => 'https://secure.php.net/manual/en/book.mbstring.php',
    	),
    	'simplexml' => array(
    		'label' => 'SimpleXML',
    		'url' => 'https://secure.php.net/manual/en/book.simplexml.php',
    	),
    );
    
    /**
     * Only check for PHP image extensions that WordPress is actually using. :)
     */
    foreach ( $editors as $class_name ) {
    	if ( ! in_array( $class_name, $implementations ) ) {
    		switch ( $class_name ) {
    			case 'WP_Image_Editor_Imagick':
    				unset ( $extensions['imagick'] );
    				break;
    			case 'WP_Image_Editor_GD':
    				unset ( $extensions['gd'] );
    				break;
    		}
    	}
    }
    
    foreach ( $extensions as $php_ext => $php_info ) {
    	if ( ! extension_loaded( $php_ext ) ) {
    		/**
    		 * Show an error message for the missing extension module.
    		 */
    	}
    }
    

    js.

    JS Morisset

    (@jsmoriss)

    BTW, don’t forget that unlike most actions, all filters can be run from anywhere at any time. ??

    js.

    JS Morisset

    (@jsmoriss)

    And on a related note, here’s an easy way to tell WordPress not to use ImageMagick (even when available), or prefer GD over ImageMagick. ??

    https://surniaulula.com/2018/03/10/choosing-your-wordpress-php-image-extension/

    js.

    Thread Starter Russell Cardwell

    (@russell-cardwell)

    You guys are both spectacular in resolving this issue overnight. ????

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Fatal error: Class ‘WP_Image_Editor_GD’ not found’ is closed to new replies.