Rename $plugin to prevent variable name conflict

[kraftner]

At the place the plugin file is included there already is a variable $plugin containing the path to the plugin file which is overwritten with the Plugin object.

At first look this doesn't cause much issues, but e.g. a plugin expecting the return value of plugin_loaded to be a string would Fatal here.

[schlessera]

Agree this should be changed.

I'm not quite happy with the alternative you're proposing. We're not using camelCase here, and just appending "object" seems too random and technical...

Trying to come up with a better name right now. I'm sure I'll have something soon...

Any time soon now...

...just bear with me...

...hmm... 🤔

[schlessera]

Thinking about doing an IIFE for this, but not quite sure that is preferable...

https://twitter.com/schlessera/status/1139101197518983168

[robwoodgate]

Doesn't the factory allow you to avoid using the global all together?

/*------------------------------------------------------------------------------
 *-- 3. Instantiate and kick off our "composition root" (our "Plugin" class). --
 *----------------------------------------------------------------------------*/

/*
 * We register activation and deactivation hooks by using closures, as these
 * need static access to work correctly.
 */
\register_activation_hook( __FILE__, function() {
    ( BasicScaffoldPluginFactory::create() )->activate();
} );

\register_deactivation_hook( __FILE__, function() {
    ( BasicScaffoldPluginFactory::create() )->deactivate();
} );

/*
 * Finally, we run the plugin's register method to Hook the plugin into the
 * WordPress request lifecycle.
 */
( BasicScaffoldPluginFactory::create() )->register();