Envato Fatal Error

[timnolte]

Our SatisPress instance has started having a fatal error due to the Envato integration.

Fatal error: Uncaught TypeError: Return value of SatisPress\Integration\EnvatoMarket::filter_package_download_url() must be of the type string, bool returned in public/wp-content/plugins/satispress/src/Integration/EnvatoMarket.php:59
Stack trace:
#0 public/wp/wp-includes/class-wp-hook.php(309): SatisPress\Integration\EnvatoMarket->filter_package_download_url(false)
#1 public/wp/wp-includes/plugin.php(191): WP_Hook->apply_filters('https://satispr...', Array)
#2 public/wp-content/plugins/satispress/src/Archiver.php(196): apply_filters('satispress_pack...', 'https://satispr...', Object(SatisPress\Release))
#3 public/wp-content/plugins/satispress/src/ReleaseManag in public/wp-content/plugins/satispress/src/Integration/EnvatoMarket.php on line 59

WordPress: 6.0.1
PHP: 7.4
SatisPress Plugin: 1.0.4
Envato Market Plugin: 2.0.7

[timnolte]

Some more details is that I see now that one of the plugins that was supposed to be updated from Envato must have tried to download a bunch of times and kept failing. When I logged into Envato/CodeCanyon the download page says that there were attempts to download the plugin 20 times just today and hit the maximum download limit. It seems like there are major problems with how Envato downloads are happening.

The plugin that seems to be causing this is: https://codecanyon.net/item/media-folders-manager-for-wordpress/21715379

I removed the single item token setup for that 1 plugin and now the site is not throwing that error anymore on the plugins page and when using the WP-CLI for plugin activities.

Now, this could also be due to our setup. We have a setup where WordPress Core/SatisPress/other functional plugins are installed and managed via Composer. However, all of the other plugins are managed the normal through the Dashboard. However, our setup requires that files(like manually installed plugins) are installed in a shared files space that lives beyond site deployments when there are Composer updates. This means that every plugin that we are serving via SatisPress, and having auto-updated are symbolic linked directories and can't be deleted. In general, this has worked fine as the SatisPress packages have been captured but the running plugin on the SatisPress site doesn't get updated and requires a manual install/update.

[bradyvercher]

SatisPress hooks into the WordPress update process, so it doesn't trigger any events of its own. My guess is the fatal error prevents the core transient from being saved, which causes the update process to run more often than it should.

I don't have time to look into this for a little bit, but this line probably needs to account for the download() method returning a boolean. That should prevent the fatal error and the excessive download attempts. If you can test and submit a PR, I'll review it and get that merged for you.

You'll probably need to debug why Envato isn't allowing that particular plugin to be downloaded, though.

[timnolte]

@bradyvercher so today I went to go check the downloads and after downloading the plugin found that there was a bogus __MACOSX folder in the zip archive. I'm pretty sure this is breaking the update/download process. I've seen this happen for other premium plugins when apparently their deployment process is just zipping up some code on their local computer. 😱

I can take a look at the line you mentioned probably get a PR opened for that. The zip file with bad folder in it I'm not sure the best course of action for that. I've notified the plugin author that they need to fix their packaging. Thanks!

[bradyvercher]

I believe this should be good to go after #182.