How can we improve KANBOARD Plugins information?

Of course, this is a personal perspective, nothing more.

BTW, I had absolutely no problem when starting with KB. So what?

1 Like
1 Like

Why not?

1 Like

Progress so far…

  • filter search works, copied from kanboard website… its not great but it works - yet to be styled
  • this is the only information which i could pull from kanboard… surprisingly, there is no plugin-installed-related information in the database.
  • I want to sort it alphabetically by plugin name but im heavily struggling with that because of the code ‘foreach’ loop

STILL NOT READY FOR RELEASE…

2 Likes

You can sort it by php built-in function:
https://www.php.net/manual/en/function.array-multisort.php

1 Like

Just an additional thought:

For me, an important plugin property would be, whether the plugin modifies the database scheme. Even if I know that this won’t be cleaned up on uninstallation. Unfortunately, there are no resources for that, it always has to be done manually. This property (has Schema directory) would be helpful for users that try or test plugins frequently.

Recent example: The plugin SubtaskDescription adds a new column to the subtask table. After uninstalling the plugin, that addition remains forever, even if no longer useful.

Keep it clean and proper!™

2 Likes

I understand and agree with you on that…

for the schema issue, could we not adjust/adapt what @creecros did for getting the latest versio of KB…

if (strpos(APP_VERSION, 'master') !== false && file_exists('ChangeLog')) { $accurate_version = trim(file_get_contents('ChangeLog', false, null, 8, 6), ' '); }

i mean could the above not be changed to check for a schema folder?

1 Like

Yeah, for installed plugins that should be possible. But real coolness comes up, when you know that from all plugins, in advance, before installing them.

2 Likes

if a schema folder exists in a plugin, its there to modify you database. would be an easy thing to check for, if you are trying to write code to detect that.

also, makes me wonder though, does it have to be there forever…never really thought about that. What would it take to undo.

thought experiment:

  1. what DB is being used
  2. find coinciding Schema
  3. read schema
$pdo->exec("ALTER TABLE `subtasks` ADD COLUMN `due_description` TEXT NOT NULL DEFAULT ''");
  1. uninstall plugin
  2. execute countermeasure:
$pdo->exec("ALTER TABLE `subtasks` DROP COLUMN `due_description`");
  1. win
2 Likes

Not to forget dropping the appropriate record in table “plugin_schema_versions”.

2 Likes

I tried this but it didn’t work:

                <?php
                $pluginName = $this->text->e($plugin->getPluginName())
                ?>
            <?php if (SchemaHandler::hasSchema($pluginName)): ?>
            This plugin makes database changes
            <?php endif ?>

What exactly didn’t work?

it doesnt load the page

Quick & dirty: I think you need the full qualified name.

<?php $schema = Kanboard\Core\Plugin\SchemaHandler::hasSchema($plugin->getPluginName()); ?>
<?= $schema ? " YES" : " NO" ?>

1 Like

nice but this still doesnt work on 1.2.20

I’m on the current version, and I don’t have any 1.2.20 running. Sorry.

1 Like

stop testing on old stuff :slight_smile:

2 Likes

getPluginName() will work on installed plugins, but it will not work on info from the Directory.

ya thats a bust, there wouldn’t be any way to determine the schema at all, if it is not already installed…

if the info is not here:

we can’t conjure it. Well…maybe we could, if we check the github page…hmmm

Yes, I know that. I think scanning the entire directory would be too expensive for practical use.

Ya, we’d have to do more than just scan the directory, we’d have to scan each github repo associated with each plugin within the directory.