Git-updater: Release Asset not getting installed from Github releases?

[emeraldjava]

Hi,
I have my wordpress plugin hosted on gitub.

* GitHub Plugin URI: https://github.com/emeraldjava/bhaa_wordpress_plugin

I use composer within my plugin, so i've setup a github actions flow which runs composer and then creates a tag specific zip which create a github release.

From the documentation on this plugin, I have the Release Asset flag set to true.

In my releases area

https://github.com/emeraldjava/bhaa_wordpress_plugin/releases/tag/v2019.12.07

in have a zipped plugin which matches the repo-tag.zip format. When i attempt to pull my release plugin code to a clean wordpress instance, it seems that standard code zip file is being installed, and the zip archive with the vendors/autoload.php is not getting selected.

I assume i some mis-configuration but am unsure how or where to proceed with this. Any help would be appreciated.

[emeraldjava]

https://github.com/emeraldjava/bhaa_wordpress_plugin/releases/tag/v2019.12.07

[emeraldjava]

The v2019.12.07 release has three artifacts

The default source zip is

https://github.com/emeraldjava/bhaa_wordpress_plugin/archive/v2019.12.07.zip

My pre-built plugin with composer dependencies is

https://github.com/emeraldjava/bhaa_wordpress_plugin/releases/download/v2019.12.07/bhaa_wordpress_plugin-v2019.12.07.zip

Is there some trick to get github-updater to generate the second URL when installing?

[afragen]

It is best to use semantic versioning. I would remove the v from the version number. Not sure if that's an issue but possible.

[afragen]

In testing, it does seem to be getting the correct release asset. Though the update process doesn't seem to like the downloaded source name. You might try changing the repo name to use - not _, though I'm not certain that's the issue. This part of the update process is all WP Core code.

[emeraldjava]

Thanks for that suggestion. I've removed the underscores from the plugin name and dropped the 'v' from the tag/release label.

https://github.com/emeraldjava/bhaa-wordpress-plugin/releases/tag/2019.12.08

but i'm afraid the issue remains. I need to see what the GitHub_API.php class is really doing. Thanks again.

[afragen]

When I stepped through the code with your plugin there was an error in WP core about the first parameter of the copy() not being a directory. It got to copy after rename failed.

I’ll have to look closer.

[afragen]

The issue is that the PHP rename() function doesn't seem to like the file paths that are sent to it from $wp_filesystem->move(). I have no idea why.

Here is the error on my local installation.

Exception has occurred.
Warning: rename(/Users/afragen/Local_Beta_Sites/lightning/app/public/wp-content/upgrade/bhaa-wordpress-plugin-2019.12.08-4BoFpV/,/Users/afragen/Local_Beta_Sites/lightning/app/public/wp-content/upgrade/bhaa-wordpress-plugin-2019.12.08-4BoFpV/bhaa-wordpress-plugin): Invalid argument

The arguments are valid. ¯\_(ツ)_/¯

[emeraldjava]

I'm looking at the exception message above and am wondering where this character string is coming from

-4BoFpV

Could it be i've some character encoding issue in the plugin name?

[afragen]

That’s what core does when in downloads a zip then it copies that to a folder without the hash that corresponds to the plugin slug.

This is normal and expected behavior.

[emeraldjava]

Am i correct to say that the class controlling this flow is Fragen\GitHub_Updater\Base.php and the function is

function upgrader_source_selection() { ..... $new_source = $this->fix_misnamed_directory( $new_source, $remote_source, $upgrader_object, $slug ); $new_source = $this->fix_release_asset_directory( $new_source, $remote_source, $upgrader_object, $slug ); // this is the call to core wordpress which try and rename() or else a copy(). $wp_filesystem->move( $source, $new_source ); return trailingslashit( $new_source ); }
I'd plan to add extra logging to a local instance to see what's happening to the github release artifact zip.

[afragen]

That is the slug renaming code. It occurs at the end of the update cycle. But be aware that the error seems to be coming from the $wp_filesystem->move() which is all core code.

The downloading of the asset for installation is elsewhere, but this too is WP Core code. I simply hook into the code at various points to fix/change some things.

[afragen]

More error information. The error inside of WP Core is from a @rename( $source, $destination)

I have no explanation but I was able to create a fallback if rename() fails.

@emeraldjava please confirm that this works on your end.

[afragen]

https://github.com/afragen/github-updater/commit/d8083336237214e047b93b0cb40ca6bb8791a855 should be more versatile and replace use of $wp_filesystem->move()

[ploplu]

Hi, as you were replacing the $wp_filesystem->move() by your own function a new problem appeared. For those who are using FS_METHOD with "direct", it is working like a charm. But for all the others (FS_METHOD=ftpext,...) the function is running endles until the server dies because you are copying as long as there are files left. My debug.log grows every time over 1GB ;)

[afragen]

@ploplu could you create a new issue please? This one is several months old and resolved. Feel free to reference it.