Disable autoloader when using class_exists()

[michael.heuberger]

A couple of files inside the /wp-includes/pomo directory use class_exists() the wrong way, for example in /wp-includes/pomo/entry.php :

if ( !class_exists( 'Translation_Entry') ):

It should be:

if ( !class_exists( 'Translation_Entry', false) ):

The second parameter 'false' disables autoloading. This is important because I'm integrating some WP functions into another existing website which already comes with an Autoloader for some classes = confusion.

This should be easy to fix. Thanks :)

[kurtpayne]

Can you add your own autoloader to the stack before you add WordPress to your existing codebase?

spl_autoload_register( function( $className ) {
  // If you're the last on the stack, the other autoloader should
  // take care of its own classes, but if it fails to find $className
  // you'll end up here, just don't throw an exception
} );

This might prevent the errors you're seeing.

You could also look at loading only the pieces of WordPress you need with SHORTINIT
​http://wordpress.org/support/topic/load-wp-core-in-another-framework-shortinit-wp_query?replies=3

[michael.heuberger]

Done, that works. But really, it's not cool and I'll remove that code once this bug has been fixed.

By the way, WordPress should come with an own bootstrapper to load only the pieces we need with SHORTINIT. Do not like the code there in that discussion forum. Shouldn't be like that.

[wonderboymusic]

We can probably do some of this

[wonderboymusic]

In 34348:

Pass false as the 2nd argument to class_exists() to disable autoloading and to not cause problems for those who define __autoload().

Fixes #20523.

[westonruter]

@wonderboymusic This change to wp_ajax_add_menu_item broke a plugin. We had defined an autoloader for our plugin namespace and then added a filter like:

add_filter( 'wp_edit_nav_menu_walker', function () {
    return __NAMESPACE__ . '\Walker_Nav_Menu_Custom_Fields';
} );

Since the class_exists() now prevents autoloading, it then caused the class to not get loaded and the add-menu-item Ajax call would fail returning with 0 due to:

if ( ! class_exists( $walker_class_name, false ) )
    wp_die( 0 );

Now, it's easy enough to change our plugin to explicitly require_once the class file in the filter:

add_filter( 'wp_edit_nav_menu_walker', function () {
    require_once( __DIR__ ' . '/class-walker-nav-menu-custom-fields.php' );
    return __NAMESPACE__ . '\Walker_Nav_Menu_Custom_Fields';
} );

But plugins that use autoloaders aren't going to expect to have to do this.

[nacin]

Are we concerned that this will break things, per @westonruter's comment?

I don't see how class_exists() is being used in the wrong way here.

[markjaquith]

I think we should only be doing this for hardcoded class checks. Not variable ones.

[markjaquith]

20523-revert.diff​ reverts the completely variable instances.

[markjaquith]

@nacin reviewed.

[markjaquith]

In 35749:

Do not pass FALSE as second parameter in variable class_exists() checks

Because these are generally plugin-provided, we want plugins to be
able to use autoloaders.

fixes #20523