Dev needed for simple (?) CC plugin idea

[ozfiddler]

@anon66243189

I am not sure about this, aren’t the CP “research” plugins supposed to be somewhat “core” plugins?

No, the research area is just a general playground.

@anon66243189

since you authored it I think the honours should be yours?

OK. I have used the Updater previously so can get that going. If you will get it into a state where it is OK to go public I will take it from there.

[joyously]

@anon66243189

then rename the folder to cc-plugin-checker

You don’t have to rename it.

[anon66243189]

@ozfiddler the plugin now makes sure that only non-existing version checks are greyed out and also can be disabled, activated, and deactivated without issues (I hope)

For a first, this should be good to go. Since the changes need to be merged by a CP owner, you’ll have to test with the branch I shared earlier.

On a sidenote, I dont understand why we’d push this to the CP “research”. All it does is making development more hard, there is no advantage in providing a repo since Git is free for all, and everyone can fork from everywhere… the only it does, is putting work on the owners of the CP repo, since only those can now push these changes, you can’t control your own plugin anymore, in other words. Not sure that is the best approach. Suggestion: you can fork back the plugin from my repo, to take back control, and get the changes, without waiting for the PR to be committed.

Especially if the plugin isn’t going to be part of CP I do really not see the advantage of this “common” research repo. Well, other than adding more work to the Owners of that repo, and perhaps adding a few more eyes to the commits… I might miss something

[ozfiddler]

Thanks! I’ll test it out.

@anon66243189

On a sidenote, I dont understand why we’d push this to the CP “research”.

The CP research area is usually a place for half-baked ideas to be stored, waiting for someone to come along and show some interest. I think of it as more of a black hole for prototypes.

The fact is, you came along immediately and jumped onto this and had it finished in record time. So yes, in this case it could have stayed with me, and I’ll see about setting it up back up in my GitHub account.

And I’ll add it into the CP directory.

[ozfiddler]

@anon66243189

non-existing version checks are greyed out and also can be disabled, activated, and deactivated without issues

Yes, perfect! Thanks for your efforts. Activates, deactivates and deletes correctly. Looks good. I think I will just add a line at the top to say that WC tags will only show up when WC or CC is activated. I will now include the Update Manager file and test that out.

Cheers.

[anon66243189]

@ozfiddler

I think I will just add a line at the top to say that WC tags will only show up when WC or CC is activated.

That’s a good idea, however note the plugin can’t even be activated if neither is active (better: if WC or CC are not active, the plugin cannot be activated)

However, still good idea adding that notice, since you can easily deactivate WC or CC after activating the checker plugin, without issues…

[james]

@ozfiddler

WC tags will only show up when WC or CC is activated

Why is this?

Woo/CC must be registering something with WP/CP internals to tell it to look for those plugin info fields.

An alternative that doesn’t require Woo/CC to be active would be if this checker plugin detects whether WP/CP is aware of those plugin info fields already, and if not, goes ahead and registers them as valid info fields.

I am not familiar with the mechanism that is used to make WP/CP pick up on these plugin info fields - and I’m a bit surprised that it seems to work that way - but this seems like it should be possible.

[ozfiddler]

@james

Why is this?

I have no idea! It surprised me. It’s not really a big deal because I can’t see a case where you would have neither installed. It’s just a reminder to activate one or the other.

[anon66243189]

It is the default behaviour of get_plugin_data() | Function | WordPress Developer Resources

While it reads the first 8 KB of said file, it also hardcodes the headers to a default set of args.

I did not dig into how WC registered the additional header info, but I do not believe it is worth investigating registering it in the Checker plugin because de facto, that plugin is explicitly for WC (and maybe CC)
Without that plugin installed, the Checker process is redundant. Why would you want to know what your plugin require from WC or CC if it is not installed and active?

The only reason I could think of is that for debugging purposes you deactivate the WC/CC
So a solution here could be to instead of checking for active plugin we could check for installed plugins.

This is possible with

$path = WP_PLUGIN_DIR . '/plugin-folder/plugin-file.php';

$installed = file_exists( $path );

It can be amended around line 77 of the activator file, see it in PR 09-11-2021 by smileBeda · Pull Request #1 · ClassicPress-research/cc-plugin-checker · GitHub

However then the checker won’t work as the header infos are not registered… If someone knows how those get registered we can of course add them.
I believe it is extra_{$context}_headers filter extra_{$context}_headers | Hook | WordPress Developer Resources, but would need to experiment with it to be sure.
This filter could be added in the main class of the plugin and then a callback in an admin facing class (which is not included in the plugin, as I decided to put all things in one class in this case, usually I separate things into admin/public/includes, but I didn’t do that with this one…)

[joyously]

@anon66243189

If someone knows how those get registered we can of course add them.

I gave the answer pretty early on.

@joyously

Did you use get_file_data()?

[anon66243189]

As far I see that function does not get anything that is not registered first as extra header

And that’s done with the filter

In any case the plugin doesn’t use get_file_data so it’d need to be changed (and as far I see the thing we’d need to do is filter the header data to add the specific wc header)

I didn’t try, it’s just reading the code that I see that, so I could be wrong…

[ozfiddler]

@ozfiddler

@joyously

Did you use get_file_data()?

Yes. That and get_plugins().

I was wrong! I didn’t use get_file_data() at all. I used get_plugin_data(). So @joyously is spot on. I just tested in my prototype and if you use get_file_data() it returns values whether WC/CC is enabled or not.

			$plugin=get_plugins();
				foreach($plugin as $key => $plug) {
					$PluginName = $plug['Name'];
					$PluginSlug = $plug['TextDomain'];
					$PluginPath = WP_PLUGIN_DIR . '/' . $key;

					$plugin_data = get_file_data( $PluginPath, array(
						'Version' => 'Version',
						'WC requires at least' => 'WC requires at least',
						'WC tested up to' => 'WC tested up to',
					) );

					$PluginCurrentVersion = $plugin_data['Version'];

					$RequiresAtLeast = $plugin_data['WC requires at least'];
					if ($RequiresAtLeast === '') {
						$RequiresAtLeast = '<span>No WC tag</span>';
					}

					$TestedUpTo = $plugin_data['WC tested up to'];
					if ($TestedUpTo === '') {
						$TestedUpTo = '<span>No WC tag</span>';
					}

[ozfiddler]

I have now changed the plugin to use get_file_data(). Works well. I have removed the WC/CC check you added @anon66243189.

I’ll get a new version out.