Explicitly globalize $DISQUSVERSION variable

[dlh01]

Description

Explicitly assigns DISQUSVERSION to $GLOBALS rather than relying on the plugin file being loaded in global scope.

Motivation and Context

By default, WordPress core loads active plugins in global scope. However, at our agency, we typically load plugins in code, which allows for more consistency across environments and less risk of accidental deactivation by users. See our plugin loader library and also the recommendation from WordPress VIP for sites on their platform.

In these scenarios, plugins are typically not loaded within global scope, and so variables defined in the plugin entry file are not automatically globalized.

Although workarounds exist to globalize variables manually after including the plugin entry file, the Disqus plugin poses a challenge because it relies on the DISQUSVERSION variable, as a global, later in the same entry file, here:

disqus-wordpress-plugin/disqus/disqus.php

Lines 62 to 78 in 9c20fe3

	/**
	* Begins execution of the plugin.
	*
	* Since everything within the plugin is registered via hooks,
	* then kicking off the plugin from this point in the file does
	* not affect the page life cycle.
	*
	* @since 3.0
	*/
	function run_disqus() {
	global $DISQUSVERSION;
	$plugin = new Disqus( $DISQUSVERSION );
	$plugin->run();
	}
	run_disqus();

When the plugin is loaded in code, that variable does not exist yet as a global when run_disqus() runs.

The fix proposed here is to just assign DISQUSVERSION directly to $GLOBALS, rather than the current approach of assuming that the plugin is being loaded in such a way that the variable will end up in $GLOBALS. This change should ensure the variable is available to run_disqus() even when the Disqus plugin is loaded in code.

How Has This Been Tested?

Use the Plugin Loader library to attempt to load the Disqus plugin:

new \Alley\WP\WP_Plugin_Loader( [ 'disqus-comment-system/disqus.php' ] );

Observe that the Disqus settings page fails to load because the version number is missing from the enqueued JavaScript.

Apply the change, and observe that the version number is present again.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• All new and existing tests passed.

[tail]

Thanks for pointing out this issue. Could we change it to use just a constant with define() instead?

[dlh01]

Sure, for our purposes, I think a constant would work too.