Make WordPress Core

Opened 8 years ago

Last modified 8 years ago

#39795 new enhancement

WordPress objects are only accessible via global variables

Reported by: jdmweb's profile jdmweb Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.8
Component: General Keywords:
Focuses: Cc:

Description

Hello.

Here's the context:
I'm trying to write some high quality plugins that go through some code analysis tools before any new release is made available to the public. That means that the code that is being analysed is on a repository of its own.

When running the plugin code through such tools (sensio labs insights for example), some errors are marked as major issues: "Global variable or function should never be used" and that is related to the access of some WordPress objects like $blog_id, $wpdb and $wp_filesystem to name a few.

Upon investigation I found out that for $blog_id, there was an alternative, which is to use the get_current_blog_id() function. That is great, because it respects the WordPress way of working on the WordPress side, and in my plugin, I can now use a function instead of a global variable.

Could we make some equivalent functions for the other global WordPress objects? Like get_wp_db(), get_wp_filesystem() for example?

Thanking you.

Regards.

Change History (3)

#1 @SergeyBiryukov
8 years ago

  • Focuses administration template removed

Hi @jdmweb, welcome to WordPress Trac!

For $wpdb, this was previously suggested in #31556, which was closed as wontfix. Feel free to add a comment there.

#2 follow-up: @swissspidy
8 years ago

Even if we'd add get_wpdb() or get_wp_filesystem(), those functions would still use global variables.

IMHO a solution like in #37699 should be preferred.

See also #38073 and #36934 that try to improve the global variable situation.

#3 in reply to: ↑ 2 @jdmweb
8 years ago

Replying to swissspidy:

Even if we'd add get_wpdb() or get_wp_filesystem(), those functions would still use global variables.

You're absolutely right, but I'd say that's not what makes them interesting, but rather the fact that they could serve as point of exchange between the core and plugins, allowing plugins to get rid of global uses if they want. And furthermore, centralizing access to WordPress main objects behind a commun function could also be an opportunity to change the code that is executed behind this function without having to rewrite any plugin code in the future.

Let's say for now you keep the code you'd write in a plugin:
In WordPress core:

function get_wpdb(){
    global $wpdb;
    return $wpdb;
}

And in your plugin:
$wpdb = get_wpdb();

Then in the future, you decide to change this to use dependency injection or any other way discussed in the very interesting tickets you mentioned, (even though I must admit that after 456 comments it gets a bit difficult to keep an idea of where we're at), you'd implement this behind the get_wpdb() function .

What do you think of this first baby step?

I also was thinking that sometimes, in case of $wpdb for example, the code is rather simple to get access to the object. But some other times, for $wp_filesystem for example, you can't just use the global variable, you also have to check if the object exists, if the class is loaded, if not load the class, which can result in about 10 lines of codes here and there. And as it's something I don't like todo, I abstract the code in functions already.

Note: See TracTickets for help on using tickets.