Failing to rename temporary folders

[lmartins]

Im using https://github.com/lmartins/webipack-posts-widget/raw/master/webipack-posts-widget.zip as the source parameter for one plugin I need. The plugin is downloaded and I get the message everything is ok. However when I go to the plugins page I get the notice the plugin was disabled for missing files.
Looking at the plugins folder, I see that the installed plugin folder has the name webipack-posts-widget.tmp. Im guessing something is failing and the .tpmnever gets removed from that folder name.

Anything I can do about it?

[GaryJones]

Anything in a debug log about this? Can you share what permissions and ownership the relevant folders have got?

[jrfnl]

@lmartins I've looked into this and there are basically two things going on here:

1. The zip you are referring to is not packaged according to the WP requirements for plugins. The zip contains the plugin files in the root, while they should be in a subdirectory called webipack-posts-widget. In other words, this zip file would never work for installing a plugin to WP, not via TGMPA, not via manual upload in the plugin install screen. Sorry, you're doing it wrong.
2. If you'd use the GitHub packaged zips - either master: https://github.com/lmartins/webipack-posts-widget/archive/master.zip or release based: https://github.com/lmartins/webipack-posts-widget/archive/v1.1.zip, you'd end up with an installed plugin, but with the plugin directory having a non-standard name webipack-posts-widget-master, cq webipack-posts-widget-1.1 which would cause TGMPA not to recognize it as installed.

Well, that last bit is something I could fix, so once PR #327 has been merged, that bit is sorted. All you need to do then, is make sure you actually point TGMPA to a usable download.

[GaryJones]

re 1. - if the files are not in a subdirectory, could we not attempt to move them into one? I can imagine there's plenty of repos that don't use a subdirectory, and other plugins like GitHub Updater probably prefer them without.

[lmartins]

Sorry for the lack of reply, i've noticed this on my personal blog and im quite overwhelmed with work at the moment. I'll give it another go this weekend.

[jrfnl]

@GaryJones I'd advocate against that as WP itself can't deal with that either in the plugin uploader. I believe we should stay in line with the WP guideline of having multi-file plugins for the zipfile in a subdirectory named after the plugin slug.
We can compensate for the name of the subdirectory (i.e. the way GitHub packages the plugins by default with suffix '-master'), but compensating for unknown directory structures seems like we'd be getting ourself into a wasp-nest.

Ref: https://wordpress.org/plugins/about/faq/#subdirectory

[Edit] It's not like the GitHub repo has to change, having the files in the GitHub repo root is fine. It was the .zip @lmartins manually created and has available in his repo that was wrong. The zips GitHub creates will generally be fine (as they will create a subdirectory for the branch) and those are the ones GitHub Updater looks to as well.
Let's revisit once it's in the wild and we get wider user-community feedback.

[GaryJones]

It was the .zip @lmartins manually created and has available in his repo that was wrong.

Ah - that's where my confusion lies.

[jrfnl]

Indeed ;-) I tested things locally with Martin's repo - originally with his zip to figure out the problem and then with the GitHub created zips for the fix (and those now work).