Add support for referencing plugins and themes with slug from WordPress.org

[kopepasah]

What problem does this address?

Currently, as far as I could tell, @wordpress/env does not allow referencing plugins and themes from the wp.org repository. While developers can referencing the zips, it is a bit cumbersome to add and update these (in an automated way), when we want the latest available plugin from wp.org.

What is your proposed solution?

Add ability for plugins|themes config array to reference plugins and and themes from the wp.org repository.

[kopepasah]

Side note, if the team can agree that this is acceptable, I am willing to build this feature.

[t-hamano]

I think the following configuration will refer to the latest plugins, is this a solution?

{
    "plugins": [
        "https://downloads.wordpress.org/plugin/{plugin-slug}.zip"
    ]
}

[kopepasah]

Yes, I believe so. However, I would argue that

"plugins": [ "{plugin-slug-1}", "{plugin-slug-2}", "{plugin-slug-3}" ]

is more succinct than

"plugins": [
    "https://downloads.wordpress.org/plugin/{plugin-slug-1}.zip",
    "https://downloads.wordpress.org/plugin/{plugin-slug-2}.zip",
    "https://downloads.wordpress.org/plugin/{plugin-slug-3}.zip",
]

In addition, if we wanted alternate versions we could reference versions.

"plugins": [ "{plugin-slug-1}#0.1.0", "{plugin-slug-2}#1.4.2", "{plugin-slug-3}#n.n.n" ]

---

In reality, it is trivial to create a program to handle this automation, but I am generally curious why the team would be opposed to referencing wp.org repository with a shorthand syntax.

[t-hamano]

At least I'm not negative about your suggestion. However, I'm concerned about the conflict with the case that sometimes relative paths can be specified in plugins to refer to local directories.

cc @gziolo @ryanwelcher

[ryanwelcher]

Thanks for taking the time to open the issue and start the conversation!

I think being verbose is more beneficial in this case.

The solution @t-hamano presented of linking to the primary .zip is a good solution here and addresses the issue of being able to load a plugin from the org repo ( I realize I am being a bit pedantic here ).

While I like the idea of not needed to type the full URL for each item and given that they are always the same, it does seem ripe for abstraction, I share the same concern about conflicts or confusion around what is being loaded from where.

For example, at a quick glance, it could be mistaken that all of these plugins are loading locally:

"plugins": [ "plugin-slug-one", "./plugin-slug-2", "/plugin-slug-3" ]

This feature is to load a .zip file, and not necessarily one hosted at https://downloads.wordpress.org/. There is a very real use-case of wanting to use a .zip that is hosted elsewhere. I realize that the implementation can check the value and either prepend the URL or just use the one provided but, respectfully, it feels like a needless complication - especially given the solution to the issue ( automated updating of plugins from .org ) can be done using the example above.

Happy to discuss further - perhaps there are use-cases I'm not aware of? - and it's definitely not solely my decision to make but that's my two cents 😄

[kopepasah]

While I do agree this this does have some potential to cause confusion, I would note that confusion could be resolved with a bit of documentation.

For example, we are able to reference Git repos from GitHub using simple <owner>/<repo>[#<ref>] notation, but that does not work the same for GitLab (or BitBucket), which would actually be similar (if not the same) notation. At some point a decision was made to allow GitHub, with documentation, but not other Git hosting platforms.

Now, I know I am actually digging a bigger hole, as we CANNOT support every possible way to access an external package using simple notation, but it does seem a bit odd that we cannot access plugins and themes from the official wordpress.org repository with a simple notation (just like with GitHub).

Lastly, as the same with documentation, prefixing the referenced name with wp.org (no protocol) could be a potential solution to alleviate confusion (e.g. wp.org/plugin-name or wp.org/theme-name).

Other than (minor) potential confusion, are there any other reasons not to implement this feature?

[noahtallen]

I think a good prefix is a great solution. wp.org seems fair to me as well.

[dd32]

I think a good prefix is a great solution. wp.org seems fair to me as well.

I'm hesitant to suggest that, as it would be introducing yet-another URI-like field that isn't actually a resolvable URI. It's short, which is "good" but it's not exactly explicit, and furthers the confusing format. It's a shame that this field supports such varied formats, as it's not clear at all what refers to what, as noted above. It's already a bit 'weird' in that folder/plugin-name could refer to a GitHub repo, but equally it could refer to a local folder.

I'd suggest being explicit, and instead just listing the URI, https://wordpress.org/plugins/example-plugin/, or there's this format which is used internally for some IDs: w.org/plugins/example-plugin OR just leaning into the existing weirdness and doing Local folder > LooksLikeGitHub && GitHub resolves > LooksLikeWordPress.orgSlug && WordPress.org resolves

Just accepting plugins: [ "plugin-slug" ] seems safe to me, it's highly unlikely that a folder would clash with it, but yet adds flexibility, in that you can add a local copy of the plugin into that folder and it "just works".

[kopepasah]

Just accepting plugins: [ "plugin-slug" ] seems safe to me, it's highly unlikely that a folder would clash with it, but yet adds flexibility, in that you can add a local copy of the plugin into that folder and it "just works".

@dd32 I really like your suggestion here, as it implements the least amount of complexity for a developer, while still enabling installing plugins from the WordPress.org repository. 👏🏻

[noahtallen]

Yeah, the GitHub situation is unfortunate. At least it now supports SSH-style git sources from any provider -- so we could theoretically deprecate the WordPress/gutenberg style for GitHub sources in favor of directly using ssh:git@github.com:WordPress/gutenberg.git. It still seems useful to have shortcuts for potentially common use cases, though.

I like the idea of listing the URI directly too, but it doesn't seem much better ergonomically than specifying the entire .zip download URL. 🤔

Local sources are supposed to start with some kind of path prefix like /, ~, or ., and I don't think it will ever transform a plain source like 'gutenberg' into a local path based on the logic here: https://github.com/WordPress/gutenberg/blob/d0220ea3a8de6f215f82cb2305b6d7ebb12cbe1d/packages/env/lib/config/parse-config.js#L92-L94

(After testing, it actually throws an error if you pass something like this-is-a-slug, because it doesn't have any source type to parse it into :P)

So mapping plain slugs to wp.org sources is definitely viable. But it does have the downside of not being explicit, which is a benefit of the prefix. We could also update the source installer to just pass "unknown" source types directly to wp plugin install, which seems like fair default behavior -- so a source of "gutenberg" ultimately turns into wp plugin install gutenberg