Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugin / Theme installation needs a way to define the path to install into. #1802

Closed
dd32 opened this issue Sep 25, 2024 · 2 comments
Closed
Assignees

Comments

@dd32
Copy link
Member

dd32 commented Sep 25, 2024

Currently installAsset guesses the path to install an asset into based on two things:

  1. The ZIP name (ie. folder-name.zip => plugins/folder-name)
  2. The Directory contained within the ZIP (ie. zip contains a folder called my-plugin at the root level => plugins/my-plugin)

This is not ideal in some scenario's, especially as some software and plugins expect the plugin to be installed into a very specific path.

For example, Plugin Check expects that the folder that the plugin is installed in is the ultimate slug on WordPress.org. This is usually incorrect, but is sometimes correct.

This becomes a problem when we're loading user-supplied ZIPs into playground, as we can't force the ultimate install path, and it may end up being something like 2024_09_25-uploaded-my-plugin or My-Plugin-For-Review rather than the expected hello-world-example.

Ideally, InstallAssetOptions would expose a slug/installFolder optional property that can be set via InstallPluginOptions, which forces installAsset.assetFolderName rather than the heuristic guess that's presently in place.

An example step after this would be, to install the hello-dolly plugin into a arbitrary hello-world-example path:

{
      "step": "installPlugin",
      "pluginZipFile": {
        "resource": "wordpress.org/plugins",
        "slug": "hello-dolly"
      },
      "options": {
        "activate": true,
        "installFolder": "hello-world-example"
      }
    }

Another option would be that it's a property of the FileReference, but that might overload the FileReference structure to be too asset-central.

{
      "step": "installPlugin",
      "pluginZipFile": {
        "resource": "url",
        "url": "https://example.zip",
        "installSlug": "hello-world-example",
      }
    }
@dd32
Copy link
Member Author

dd32 commented Sep 25, 2024

Note: This can be worked around with a step after the installPlugin step that involves renaming the folder, although that's not ideal longer term, and would also require then re-implementing any activation logic. It's harder when there's multiple plugins installed as well, as we're not able to know for sure which folder it was installed into at the blueprint stage.

bazza pushed a commit to WordPress/wordpress.org that referenced this issue Sep 25, 2024
…gainst an uploaded ZIP file, attempt to force the plugin to be installed into the expected folder path.

This resolves issues of plugin check suggesting that the textdomain should be `2024_09_25-uploaded-file-SLUG` rather than `SLUG`.

This is intended on being temporary until the upstream issue is resolved.

See #7405.
See WordPress/wordpress-playground#1802.


git-svn-id: https://meta.svn.wordpress.org/sites/trunk@14078 74240141-8908-4e6f-9713-ba540dce6ec7
@bgrgicak bgrgicak moved this from Inbox to In progress in Playground Board Oct 8, 2024
adamziel pushed a commit that referenced this issue Oct 9, 2024
This allows for installing a user-generated ZIP file into a specific
theme/plugin path.

See #1802 

## Implementation details

`InstallAssetOptions` has a new param, `targetSlug` (to match it's
existing `targetPath`) which if set the ultimate install path is
`targetPath/targetSlug`. If the param is not set, it defaults to
guessing from the ZIP filename and ZIP contents as current.

`InstallPluginOptions` and `InstallThemeOptions` both gain the same
parameter, and pass it through if set.

`InstallThemeOptions` was previously not actually in use, this fixes
that, bringing it inline with `InstallPluginOptions`.

Tests are a bit of a weird mess, as the testing structure doesn't
cleanup between iteration runs, and the helper methods are different
between each section. `zipFiles` helper from the plugin tests should
probably be a common helper instead.

The tests should show the current "issue" with 6b3b5a5 failing, and the
latest changeset resolving that error.

## Testing Instructions (or ideally a Blueprint)

```
{
  "landingPage": "/wp-admin/admin.php?page=example",
  "steps": [
    {
      "step": "login",
      "username": "admin",
      "password": "password"
    },
    {
      "step": "installPlugin",
      "pluginZipFile": {
        "resource": "wordpress.org/plugins",
        "slug": "hello-dolly"
      },
      "options": {
        "targetSlug": "hello-example-plugin"
      }
    },
    {
      "step": "writeFile",
      "path": "/wordpress/wp-content/mu-plugins/example.php",
      "data": "<?php add_action('admin_menu', function(){ add_menu_page('Example','Example',0,'example',function(){ echo '<pre>'; print_r( glob( WP_PLUGIN_DIR . '/*' ) ); echo '</pre>'; }); } );"
    }
  ]
}
```

This should display a admin page with the following output:
```
Array
(
    [0] => /wordpress/wp-content/plugins/hello-example-plugin
    [1] => /wordpress/wp-content/plugins/hello.php
    [2] => /wordpress/wp-content/plugins/index.php
)
```
@adamziel
Copy link
Collaborator

adamziel commented Oct 9, 2024

Done in #1803

@adamziel adamziel closed this as completed Oct 9, 2024
@github-project-automation github-project-automation bot moved this from In progress to Done in Playground Board Oct 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

2 participants