System view: Plugin link to plugins.getkirby.com

[distantnative]

If listed in plugins.getkirby.com, it could be nice to have the plugin link point there.

[afbora]

Technically, this is a very simple development, but the most challenging part of this development is the question of where to provide this link 🙂

Possible ideas:

• A new column: Contains the link text and link. It can provide a link for each plugin (View in plugins directory) or be blank.
• A new column: Plugins directory status. For each plugin, it will indicate whether it is exists in the plugins directory. If so, a link will be provided. For ex: Not exits string with cross icon in red color and Exists with check icon in green color.
• An additional link text in the Version dropdown: View in plugins directory
• A link can be provided by placing an icon in the Name cell at the far right.

What kind of UI do you think it should be?

[distantnative]

I don't think we should add another UI element. I think that'd be too much - then having two links to two different places. My idea was to use it instead of the current link that goes e.g. to GitHub.

But I am not fully sure whether we should do this. Or if the current links are the better option.

[afbora]

My idea was to use it instead of the current link that goes e.g. to GitHub.

It makes sense to use the link on the name. If it's listed in the directory, we can provide a directory link on plugin name, if not, provide a GitHub link.

[bastianallgeier]

I think it's a good idea to prioritize the plugin directory here. This also makes us more independent from Github in the long run.

[distantnative]

Do we have a good way to know in the backend what plugin is listed in the plugin directory? I was thinking maybe with he update status, but that can also be disabled via config option etc.

I guess what we could do is

• Add a route to the plugin directory that captures the plugin namespace and name
• Try to find the matching plugin in the directory, if successful redirect to that page
• If not, we also send $plugin->link() (what we currently use) as query parameter and the directory redirects to that instead

Plugin::link() could be rewritten as

public function link(): string|null
{
	$info   = $this->info();
	$link   = $info['homepage'] ?? null;
	$link ??= $info['support']['docs'] ?? null;
	$link ??= $info['support']['source'] ?? null;

	return 'https://plugins.getkirby.com/find/' . $this->name() . '?link=' . (V::url($link) ? $link : null);
}

(+ some url encoding I guess)

What do you think?
(pinging @lukasbestle too cause maybe there is also already a reliable way with UpdateStatus?)

[afbora]

Yes, I looked into this development today, but I got stuck on exactly the part you mentioned and couldn't move forward 🙂

I really liked your suggestion @distantnative I hadn't thought of that. I think it would be great if we always had control 👍

[lukasbestle]

As soon as the update status component has any other status besides the grey unknown question mark, a plugin profile exists. So we could hook into that.

Not at my desk to check the proper terms, but maybe it helps. Otherwise I can look into it tomorrow.

[distantnative]

But if one would disabled the update check, we would not know, right?

[lukasbestle]

No, but I don't think we need to support the links in this case.

If the update check is disabled, the only way would be those find links, but what would happen if we have neither a custom link nor a plugin profile? We would have to display an error message and that's worse than no link at all IMO.

[distantnative]

Fair.

As soon as the update status component has any other status besides the grey unknown question mark

Is that when $plugin->updateStatus() returns null?

[lukasbestle]

Is that when $plugin->updateStatus() returns null?

No, that's when the update check has been disabled for that plugin.

I'd go for:

$pluginProfileExists = $plugin->updateStatus()?->status() !== 'error';

We cannot differentiate between "actual error during fetching" and "no plugin profile exists", but those are essentially the same for this use case. If we couldn't successfully determine that a profile exists, it's IMO better to omit the link than display a potentially broken link.