The change is made
You can download it from here for now https://github.com/TukuToi/cc-plugin-checker
Click the green “Code” button, then “Download ZIP”, then unzip it, then rename the folder to cc-plugin-checker and install on the test site.
2 Likes
Great. Will do.
Fantastic! Thanks @anon66243189 
Works with both CC and WC activated. The only little thing I can find is the “No WC Tag” should be in the pale grey, but the ones with the tags should be solid black.
Now it’s a proper plugin!
I’ll look into that!
It still needs work
I don’t like how it echoes styles and generally how the html is generated, but that is rather a “cosmetic” thing, not really bound to functionality, so for usage it is fine.
Yes, do whatever you like. I found a similar sort of plugin on the WP repo and just modified it to suit. But even I could tell it was really badly written.
Are you happy to take this on and add it into the CP directory? It would need the Update Manager file added to it. I can sort it out if you prefer, but I’m not really in the business of looking after plugins. If we can get it up I will write a tutorial on the CC website about how to use it to check before migrating.
This is great! Many thanks. Nice to have something that was a vague idea a few days ago move along so fast.
2 Likes
About updater… I don’t really do that update manager thingy, I don’t like the idea.
Mainly because I don’t want to admin yet another website/server (I admin more than 20 of those, so each and every add-on server or site is a pain that I want to avoid, specially if it could affect other sites) and security concerns.
I also had (still have) my own updater system but I don’t ship it anymore in plugins/themes because of the security issue it implies.
Let’s assume my VPS on which I would have said repo gets hacked, and “evil” realises what it is used for, they just need to upload a poisoned file and increase version, the thing is then potentially on all sites using the plugin or theme. Which might be none, or hundreds, thousands (in my dreams)
I don’t like this idea, at all. This is why WP has WP Repo (for wp plugins) and we should have our own centrally managed server/update mech which gets monitored etc, or directly pulls from git.
Usually I just push to WP, but the problem with this plugin is that I can hardly mask it as a WP Plugin like I do with my other ones… so pushing it to WP repo will be tricky or impossible 
Also, I am not sure about this, aren’t the CP “research” plugins supposed to be somewhat “core” plugins?
I am happy to add it to my instance of the directory once we are happy with it, however… since you authored it I think the honours should be yours?
We anyway need to pep up our directory to also allow for “contributors” to show up there, not everything is a one-person-show
I will fiddle a bit more with the code later next week, maybe until then we have a taker who is willing to provide a update mech too.
No, the research area is just a general playground.
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.
You don’t have to rename it.
16 posts were split to a new topic: Security concerns on using Update Manager without a dedicated site
@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 
Thanks! I’ll test it out.
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.
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. 
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…
2 Likes
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.
1 Like
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.
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…)
1 Like
I gave the answer pretty early on.
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…
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>';
}
1 Like
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.
3 Likes