Plugin installs to subdirectory of itself

[tylerwiegand]

Hello again! Hopefully this is a quick and simple fix just like last time.

So there are two plugins so far that we have experience with this issue, although I only remember the name of one today.

When installing pixelyoursite-pro via composer and satispress, the directory structure installs like this:

Here's where it gets interesting: when I use a typical GUI zip extractor, the zip file extracts as you would expect -- without the weird MACOSX folder and without itself inside a subfolder. HOWEVER...when I use the "unzip" command line tool (UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send) it spits out the weird MACOSX and subfolder!

Then I tried to do the same thing with the vendor provided download, and found the same oddity with the extraction. I can guess that this is due to the plugin vendor zipping improperly somehow, or at least not like everyone else, but I wonder if there's anything that might be done to detect a plugin installing into a subfolder of itself (which obviously doesnt allow the plugin to function).

(PS: thanks for answering our last issue so quickly, satispress makes our flow for site creation soooo much faster and more maintainable!!)

[bradyvercher]

My guess is that the vendor creates the zip by right clicking the directory and compressing it on OSX. That would add the __MAXOSX directory -- which is hidden on OSX, but visible on other OS's -- and also nest the files in a subdirectory.

WordPress accounts for the files being nested like that in its installer, which is why uploading the zip file works, but Composer installs it in a subdirectory.

The options I see for working around this are:

1. The vendor(s) changes their process for creating the zip file so the files aren't nested in a subdirectory.
2. The Composer installer is updated to account for the nesting.
3. SatisPress inspects the zip file to determine if it needs to be reconfigured before archiving it.

I imagine WordPress is mostly accounting for the nested files as a user experience enhancement to prevent common issues, so ideally the vendors should change the way they're creating their packages.

[bradyvercher]

Hi @tylerwiegand, were you able to resolve this?

[tyrann0us]

Hi @bradyvercher,

[…] so ideally the vendors should change the way they're creating their packages.

Since our SatisPress instance has been running, we have been confronted with the issues of nested folders repeatedly. We had to manually fix and upload the zip file generated by SatisPress every time an affected package was updated. Since we use Private Packagist to mirror SatisPress, in addition we always had to empty the cache there (delete the package). Understandably, this is a very cumbersome and extremely error-prone process.

Now manually fixing a package escaped our attention again, so a plugin required for legal reasons ("Borlabs Cookie") was disabled on a production system of one of our clients. This is of course bad.

Many third party vendors do not have good release automation that would create an archive with GitHub Actions, for example. This seems to be in the nature of premium plugin vendors …

I understand that it is good to inform the vendor in any case and ask them to implement proper release automation or at least provide correct zip files, but this is not feasible with an increasing number of installed packages in SatisPress. And success is not guaranteed; if a vendor refuses to change his workflow, there's nothing you can do about it.

TL;DR it would be really great if you could reconsider identifying and fixing nested folders in SatisPress.

Thanks!