Self-contain wp-includes/load.php, wp-includes/plugin.php

[scottconnerly]

I'm trying to write a high-performance plugin.

I still want the whole of WP to be used by the admins, and the main part of WP to still be used by most user workflows, but I want certain end users to instead be using an alternate controller, instead of /index.php, when they're doing certain things.

This new controller I'll write will use a couple of the core files, but skips most for the goal of increased performance. The proposed core files to re-use are:

• wp-includes/version.php
• wp-includes/load.php
• wp-includes/plugin.php
• wp-includes/wp-db.php
• wp-includes/class-wp-error.php

However, wp-includes/functions.php is a can of worms, that if I included, would require me to include many other files, and it spiders out from there.

What would be better is if the following functions that wp-includes/load.php and wp-includes/plugin.php require be moved into those files from the functions file. Specifically:

• wp_die()
• validate_file()
• stripslashes_deep()
• add_magic_quotes()
• _doing_it_wrong()
• trailingslashit()

If they aren't, I'll have to copy-paste them into my custom controller, maintaining separate versions of them (less than optimal).

Of course, this process still requires me to write my own simpler versions of many more complex functions:

• wp_cache_init()
• wp_cache_close()
• wp_get_active_network_plugins()
• is_blog_installed()
• get_option()
• update_option()

but that's completely acceptable.

Moving those first 6 functions from the functions file to the load and plugin files would not negatively affect core, but would positively affect plugin authors' abilities to write high-performance plugins.

[scottconnerly]

trailingslashit() is actually in formatting, not functions.
If trailingslashit() is moved, it makes sense to move untrailingslashit() as well.

Also, I'd like to strike the wp_cache_*() functions from my latter list. Looks like /wp-includes/cache.php is unavoidable to include. Not that it matters for this ticket, they were just there to round out the discussion. I may later log some other ticket to address those 4 remaining functions in a different manner.

[scottconnerly]

I suppose another way to phrase this request is to make SHORTINIT viable again.

[nacin]

One problem with doing this is then we commit to always maintaining this in the future. Our bootstrapping is a bit too fragile (and SHORTINIT was never designed for non-internal use) to take on this additional burden. The moment we patch this, we take on the responsibility of keeping this working for the long term.

Sorry you never got a reply on this ticket. I'm going to presume you found another way to do this in the meantime. I'd love to improve on what is currently the fragility of loading WP in pieces but that will take years of small improvements.