How can we improve KANBOARD Plugins information?

121

can somebody help me with this please?

<?php if (isset($plugin['has_schema']) && $plugin['has_schema']): ?>
    <?php if ($plugin['has_schema'] == true): ?>
        show if true
    <?php elseif ($plugin['has_schema'] == false): ?>
        show if false
    <?php endif ?>
<?php else: ?>
    not specified
<?php endif ?>

I need to target the ‘true’ ‘false’ answers so I can switch the icons/tooltips but I cant get it to work… only the first php if works

1 Like
122

Split the outer compare.

<?php if (isset($plugin['has_schema']): ?>
  <?php if ($plugin['has_schema']): ?>
    <!-- schema is true -->
  <?php else: ?>
    <!-- schema is false -->
  <?php endif ?>
<?php else: ?>
    <!-- not specified, assume false? -->
<?php endif ?>

Maybe it’s a matter of coding-style or -taste, but I really dislike boolean compares. If you know (and trust) that something is a boolean, you can write

if ($plugin['has_schema'])

for checking if true, or

if (!$plugin['has_schema'])

for checking if false.

If you are unsure of the type, you can check this with

if ($plugin['has_schema'] === true)

The === operator checks both, the datatype and the value. This example will throw an error if

$plugin['has_schema']

e.g. is a number.

2 Likes
123

excellent, tested and works fine… will apply to the rest

thanks for explaining it the way you did.

1 Like
124

Now, that you have almost released, should I open issues?

1 Like
125

You can open issues any time… But I haven’t released it yet. I’m working on the directory page which will take a couple more days

1 Like
126

Your README link is the best guess, works only for plugins hosted at GitHub. You must adjust this.

2 Likes
127

I’m not sure I understand? I haven’t gone through every plugin in the directory yet but I’m presuming all plugins will be on github

If the json is a custom url then it will specify

1 Like
128

I don’t understand.

Maybe you’ll end up in another property.

Here are some samples:

https://github.com/aljawaid/PluginManager/blob/master/README.md
https://gitea.com/Griefed/ServerPackCreator/src/branch/main/README.md
https://gitlab.com/accumulatenetwork/accwatch-client/-/blob/main/README.md

I recommend removing this README link for now.

1 Like
129

I’m away from the pc. When I get back to the code I will have a look at it again. Or if you are referring to anything specific I have done overnight, just comment on the code or create an issue. I think you are referring to the directory readme icon but I can’t remember if I pushed that yet

1 Like
130

Cu, enjoy your Sunday!

2 Likes
131

Oh did you mean issue #10?

1 Like
132

Yes, I saw that later, after I detected the issue.

2 Likes
133

its only github and (2) gitlab links in the plugins.json… i will do if statements

1 Like
134

Sorry, but this is not a solution, IMHO.

These URLs can vary, you cannot know in advance how.

Here you have an example self-hosted GitLab server. Do really want to exclude them?

https://framagit.org/framasoft/framaspace/home/-/blob/master/README.md

We have the freedom to host our git repos wherever we want. There must be another, real solution for this.

1 Like
135

I agree but what I mean is out of a total of 107 plugins in the directory, only 2 were non-github…

1 Like
136

Then I’m out, as I’m mainly working on Gitea. :expressionless:
But I’s OK, the README link has for me only minor importance.

1 Like
137

I can add gitea and gitlab let me work on it tonight and see what i come up with

1 Like
138

After a little longer thinking, here is my idea.
The problem strikes only for installed plugins, that are not (yet) registered at the Kanboard directory. Once registered, the PM can take the README-URL from the file plugins.json, same as for other has_xxx properties.

Of course, we could add another function for this to file Plugin.php:

public function getPluginReadMe()
{
return 'https://wherever/it/is';
}

Unfortunately, this would require changes to the Loader code. This won’t be accepted, I assume. So forget it.

But if we put a new file Plugin.json in each repo, with the same content that will be copy/pasted for the registration later, let’s name it a draft, we’d have all the info at hand. If the file is missing/forgotten etc., the PM will not show a README link. Having such a local Plugin.json file is absolutely voluntary.

Example Plugin.json:

{
  "KanboardPermalink": {
    "title": "KanboardPermalink",
    "version": "1.0.0",
    "author": "Theobald Software GmbH, aljawaid",
    "license": "MIT",
    "description": "Adds a convenient link to copy the task url to the clipboard",
    "homepage": "https://github.com/theobald-software/KanboardPermalink",
    "readme": "https://github.com/theobald-software/KanboardPermalink/blob/master/README.md",
    "download": "https://github.com/theobald-software/KanboardPermalink/releases/download/v1.0/KanboardPermalink-1.0.zip",
    "remote_install": true,
    "compatible_version": ">=1.2.20",
    "has_schema": false,
    "has_overrides": false,
    "has_hooks": true,
    "last_updated": "2022-11-09"
  }
}

Unfortunately, there is some data duplication for registered plugins here. But for unregistered but installed plugins, the PM all information you need.

I would immediately agree to publish such a file whenever I’d write a plugin. It’s similar to package.json for npm projects.

1 Like
139

yes but looking at the last updated dates being done so far, not many developers are keeping their plugins active so cant expect anything from them

1 Like
140

done… hope it works on your side…

1 Like