fix: cleanup constants and refactor autoload handling

[justlevine]

What

This PR fixes the plugin's naive autoload detection which previously would:

1. throw a fatal error if dependencies were not installed (instead of the intended admin_notice)
2. show an admin_notice if the plugin was installed as a composer dependency itself (even though the plugin dependencies would get installed).

How

1. Autoload handling was moved to \WPGraphQL\ContentBlocks\Autoloader, where it checks (in order):
   a. if WPGRAPHQL_CONTENT_BLOCKS_AUTOLOAD wants us to skip autoloading
   b. if we've previously loaded the dependencies (via a static property)
   c. if the WPGraphQLContentBlocks class exists (that means it's being autoloaded already)
   d. and only then if there is a local vendor/autoload.php file.
2. The autoloader now runs in wp-graphql-content-blocks.php::wpgraphql_content_blocks_init(), where it is required_onceed instead of the (now autoloaded) WPGraphQLContentBlocks class.
3. To support this, the several constants that were defined in WPGraphQLContentBlocks have been moved to the pluggable wp-graphql-content-blocks.php:wpgraphql_content_blocks_constants(), (The versioning script was updated to accomodate the change)
4. Since the constants were already being merged to a single source, I took a moment to dedupe and deprecate the old ones:

• WPGRAPHQL_CONTENT_BLOCKS_FILE => WPGRAPHQL_CONTENT_BLOCKS_PLUGIN_FILE
• WPGRAPHQL_CONTENT_BLOCKS_PATH => WPGRAPHQL_CONTENT_BLOCKS_PLUGIN_PATH
• WPGRAPHQL_CONTENT_BLOCKS_MIN_PHP_VERSION => no replacement (this seems to be an artifact from wp-graphql core boilerplate).

To test

1. Create a composer-based WordPress install (e.g. bedrock)
2. Add the branch to the composer.json repositories:

"repositories": [
  {
    "type": "vcs",
    "url": "https://github.com/rtcamp/wp-graphql-content-blocks.git"
  },
],

3. Install the plugins as composer dependencies

  composer require wpackagist-plugin/wp-graphql wpengine/wp-graphql-content-blocks:dev-fix/constants-autoloading

4. Go to the Plugins Page, activate the plugin, see everything works with no missing deps admin notice.

Additional notes

@todo tags are used for version numbers and should be replaced once we know what the version will be.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 766737d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[jasonbahl]

@justlevine on quick scan I see the new AutoLoader.php but I don't see a change that invokes the class in in the main plugin?

[justlevine]

fml i didnt push everything 1 sec

@justlevine on quick scan I see the new AutoLoader.php but I don't see a change that invokes the class in in the main plugin?

[jasonbahl]

fml i didnt push everything 1 sec

Amazing that I caught you with a case of my famous "Moving too fasts". Usually it's me and not you that's suffering from this! 😆

[justlevine]

@jasonbahl force-pushed with all the files this time i promise 🤣

[jasonbahl]

while we're making changes to the versionPlugin.js. . .we might be able to satisfy the replacing of @since @todo references as well 🤔

[jasonbahl]

Not required to approve this PR, just a thought though. If we standardize on @since @todo or @since @next or something like that, then we could automate the update with the rest of the changesets version updates 🤔

[jasonbahl]

regular @todo like used in the _doing_it_wrong( '...', '@todo' ) functions might be a bit broad. . .although we could regex replace that like we do the WPGRAPHQL_CONTENT_BLOCKS_VERSION above? 🤔

[justlevine]

That's outta my wheelhouse, I had to triple check this "simple" change 🙃

[jasonbahl]

haha! all good. I can follow-up on that separately. . .would just need to make a standard of how we add the placeholders.

like is it always:

_doing_it_wrong( 'some string', '@todo'  );

and

/**
 * Some docblock
 * @since @todo
 */

etc?

[justlevine]

I mean that's how I do it, but really out of a general habit of checking all @todos before pushing a release.

To make it easier to regex regardless of if its _doing_it_wrong(), _deprecated_*(), @since or even a regular doc-block reference, maybe we intentionally want to use/reserve @next or @next-version? then we can just match the annotation instead of the wrapper

[jasonbahl]

ya, was thinking @next-version as well

[jasonbahl]

that way @todo can be left for other uses of @todo that IDEs already have tooling to pick up, etc 🤔

[justlevine]

So long as it doesnt make phpcs complain

[justlevine]

This was squashed in #279