Itmw, I'm able to work around this by forcing SP to return an empty $items array for themes at https://github.com/cedaro/satispress/blob/v0.4.1/src/Repository/InstalledThemes.php#L53 commenting out foreach loop.

I was wondering if that would ever become an issue. I don't think there's a way to differentiate between those right now and it might be difficult since the slug is the only thing used throughout SatisPress to identify packages. Ideally they should be unique. I'm guessing this might be one reason WordPress Packagist uses the wpackagist-plugin and wpackagist-theme vendor names.

If you have control over the theme and plugin, I'd recommend giving them unique names.

Beyond that, it sounds like you might be encountering an error that we could potentially prevent? Did you add both packages to SatisPress? Or do you get the fatal if only one of them is added?

I did not enable any themes for Satispress at all, so it looks like just adding one of them (in this case, the plugin) is enough to confuse the system.

Order of operation might also matter. If themes are checked first, they will always win the array key race.

I wasn't totally clear what was going on here, but after getting a chance to dig in, I see which keys you were referring to. Those aren't really used anywhere, so prefixing (or removing them) should be fine.

It still wouldn't be possible to add two packages with the same name, but updating those keys will prevent that error.

It still wouldn't be possible to add two packages with the same name, but updating those keys will prevent that error.

Sounds good (enough) to me.

It still wouldn't be possible to add two packages with the same name, but updating those keys will prevent that error.

To try to get this working via dynamic vendor filtering, do you think

For example, doing a super simple monkey-patch like $vendor = apply_filters( 'satispress_vendor', 'satispress' ) . '-' . $package->get_type(); seems to work exactly as I'd want.

Yeah, that can be added as an arg to that filter.

I'd have to do some testing, but I don't think it'll totally do what you're wanting because the download route doesn't receive any information to disambiguate the request by package type. All it receives is the slug and version.

At the very least, I think the release URL would probably need to have a query parameter specifying the package type and the download route would need to use that to look up the package.

@bradyvercher

Thanks for pointers, I have compiled the above pull request. I have tested it on my local website with composer / direct download from dashboard, it seems to work fine for me.

Will appreciate if you can give it a try and provide feedback if any.

As its a critical and long standing issue for us, would love to wrap it ASAP.

Thanks