Monorepo / subdirectory for plugin?

[braco]

I can't seem to get monorepo/subdirectory style updates setup.

File layout is as such:

github.com/user/monorepo:
   plugin-name/...
   other-thing/...

The goal would be to treat the subdirectory of github.com/user/monorepo/plugin-name as if it were the plugin, ignoring the other folders.

This seems to break whatever regex you're using,

$myUpdateChecker = Puc_v4_Factory::buildUpdateChecker(
	'https://github.com/user/monorepo/plugin-name',
	__FILE__,
	'plugin-name'
);

and will throw a Uncaught Error: Call to undefined method Puc_v4p5_Plugin_UpdateChecker::setAuthentication()

This, just for the record, which I gather is all kinds of wrong since second option should be the plugin __FILE__ path, like /var/www/html/wp-content/plugins/plugin-name/plugin.php:

$myUpdateChecker = Puc_v4_Factory::buildUpdateChecker(
	'https://github.com/user/monorepo',
	'plugin-name/plugin.php',

produces this: Fatal error: Uncaught RuntimeException: The update checker cannot determine if "plugin-name/plugin.php" is a plugin or a theme. This is a bug. Please contact the PUC developer

Am I not understanding something or is this just a missing feature right now?

One issue is that you'd probably have to download the entire monorepo and copy out the one folder since Github doesn't support downloading a zip of one folder.

[YahnisElsts]

This is just a missing feature. This update checker was designed with the assumption that each repository contains only one plugin or theme. There is currently no support for updating multiple plugins from the same repository, and I don't think you would be able to make it work without a bunch of custom code.

[braco]

Thanks for the reply. What else would it need beside the repo regex and smarter zip extraction?

[YahnisElsts]

Here's what comes to mind:

• Disable GitHub releases and tags.
• Additional logic to retrieve readme.txt, changelog and the main plugin file contents from a subdirectory instead of the repository root.
• When generating the "last updated" field, somehow find the latest commit that affected a subdirectory instead of just looking at the last commit in a branch/tag or the release timestamp.

The ZIP extraction bit would be a bit more complicated than you may think. Normally, the update checker doesn't handle update download and extraction - WordPress core does that. The update checker just give WP the download URL and then renames the update directory to match the installed plugin. I think it would be possible to use the same hook(s) for moving/deleting directories, but this would take more research.

[melcarthus]

Is there a way without zip extraction to make plugin-checker checkout on a branch subdirectory and pull that instead?

[YahnisElsts]

So not just a branch, but a subdirectory that's inside a branch? I don't think that's possible in the current implementation. As I mentioned above, the update checker doesn't actually perform update installation - it hands off that task to WordPress core. And, as far as I know, WordPress only supports installing updates from ZIP files.

[melcarthus]

I understand. If I instead zipped all the files, and have a zipped theme inside my branch would that work?

[YahnisElsts]

That could work, but it would require additional setup to make the update checker use those ZIPs. A couple of possibilities come to mind:

• Add those ZIP files as release assets. You would then need to manually construct the GitHubApi instance (see the readme) and call $api->enableReleaseAssets($fileRegex) to tell it to use those assets. The $fileRegex is an optional regular expression that the update checker will use to pick a specific asset when there are multiple files.
• Instead of relying on the GitHub API, create a JSON file with update metadata and set the download URL to a direct link to one of the ZIP files. This takes more manual work, but it provides a lot of control over how and when updates are detected, and you can point the update checker at any valid ZIP file.