[wp-hackers] Overriding Cor Functions (Was: IIS Problem)

[Ryan Boren]

On Sun, 2005-04-03 at 16:30 -0500, Robert Deaton wrote:
> How about splitting some of the bare necessities out of functions.php
> and into another file, so that we would have access to some of the
> functions that nobody should be changing anyways and that plugins
> would need (get_option, add_action, add_filter, etc.). This way, we
> don't lose some of the features that plugins can provide and still
> have the option to override most core functions. This could become a
> whole new major feature for whatever the next release is (dare I say
> 1.6, 1.7, or 1.8, who knows?). It could be called more of a "module"
> or "addon" instead of plugins, because it offers greater power over
> what happens everywhere.

get_alloptions() and some other functions call do_action() and
apply_filters().  If we call these before the plugins are loaded, no one
will be around to listen to those actions and filters.

We could have a set of preload-functions.php, but none of those
functions should invoke filters or actions.  Doing so would be useless.
Adding filters and actions would be okay.

Ryan

> On Apr 3, 2005 1:40 PM, Ryan Boren <ryan at boren.nu> wrote:
>         On Sun, 2005-04-03 at 03:32 -0500, Scott Reilly wrote:
>         > Since you mentioned it, WP doesn't currently support plugins
>         > overriding core functions even if those core functions are
>         wrapped in
>         > function_exists(), correct?  I know the intent is for
>         plugins to be
>         > able to do that, but how?  Plugins aren't sourced until
>         after all core
>         > files have been sourced, which is too late.  Or am I missing
>         > something?
>         
>         Here's an approach I've been mulling over.
>         
>         Add a preload_file action to be called from plugin
>         files.  This allows
>         plugin files to specify a file to be loaded before the core WP
>         includes.  In the plugin:
>         
>         function test_plugin_preload_file() {
>            preload_file(dirname(__FILE__). '/test_preload.php');
>         }
>         
>         add_action('preload_file', 'test_plugin_preload_file');
>         
>         preload_file() runs plugin_basename() on the supplied file and
>         adds it
>         to a 'preload' array in the options DB.
>         
>         In plugins.php, we call the preload_file action whenever a
>         plugin is
>         activated.  This is a bit tricky.  First we'll have to unset
>         all
>         existing preload actions and then include the just activated
>         plugin.
>         Then we call the preload_file action.  This is the only
>         situation where
>         the preload_file action is called.
>         
>         In wp-settings.php, we loop through the list of preloaded
>         files after
>         wp-db.php is included but before functions.php is
>         included.  Since
>         functions.php is not yet included, we have to be careful not
>         to call
>         get_option() to retrieve the preload array etc.  Only wpdb may
>         be used.
>         
>         Thoughts?
>         
>         Ryan
>         
>         _______________________________________________
>         wp-hackers mailing list
>         wp-hackers at lists.automattic.com
>         http://lists.automattic.com/mailman/listinfo/wp-hackers
> 
> 
> 
> -- 
> --Robert Deaton
> http://somethingunpredictable.com
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers