Appropriate slug rename on update

[afragen]

Fixes a hard forced rename of a FAIR integrated package to the slug-didhash. This can be problematic for previously installed and running packages that suddenly are updating via FAIR and now have their install slugs changed and are automatically deactivated.

Fixes #341

[github-actions]

🧪 Test this PR on Playground

[costdev]

Installing Git Updater by searching Add Plugins for "Git Updater" didn't rename the directory properly.

It ended up: afragen-git-updater-cd3e9e9/git-updater.php
On 1.1.0, the directory is correctly renamed: git-updater-f27e06/git-updater.php

Searching by DID appears to work fine though.

[afragen]

Something more to test, thanks.

[afragen]

Something more to test, thanks.

[afragen]

Installing Git Updater by searching Add Plugins for "Git Updater" didn't rename the directory properly.

It ended up: afragen-git-updater-cd3e9e9/git-updater.php On 1.1.0, the directory is correctly renamed: git-updater-f27e06/git-updater.php

This worked fine for me.

[costdev]

This worked fine for me.

Try it on the Playground link

[afragen]

Sorry, but since I can't trace code in Playground, I have zero idea of what's happening and perhaps it's simply related to Playground.

[afragen]

I see the issue. There is no DID associated with the Install button to later parse.

[afragen]

Maybe AC can add the Plugin ID header to $upgrader->new_plugin_data and we could use that?

[costdev]

I see the issue. There is no DID associated with the Install button to later parse.

Yeah, noticing that myself too. That's not caused by this PR though. We're detecting and adding a DID to the release package cache whenever it's already installed on the site or when the user searches by the DID, but not if it appears in search results when they just search for a term.

I'll get a PR up for this separate issue ASAP.

For now, I'm going to try to work out why I was getting a different directory name outcome between this PR and 1.1.0. I'll either rule out this PR as the cause, or flag what's going on if in certain circumstances it causes a regression.

[afragen]

It's because there's nothing from the DID cache and that's the standard zip from GitHub that we must rename.

Since it's an install and not an update. We don't have the usual data.

If the Plugin ID and Theme ID headers are passed in $upgrader->new_plugin_data we can get the DID and fix it.

[afragen]

To test you will need to have false returned from the DID cache.

[costdev]

Though new_plugin_data and new_theme_data aren't always set, depending on filesystem setups.

We just need to add any FAIR packages that appear in the search results to the release package cache, as we already do for direct DID searches and for updates. The DID is available in the search result data.

[afragen]

Related fairpm/aspirecloud#18

[costdev]

I've done some more testing since the recent updates and all paths I can think of seem to be working as intended now.