Dokuwiki: Fix/Update/Delete extension pages

Created on 3 May 2018 · 28Comments · Source: splitbrain/dokuwiki

We have quite a few plugins and templates that have no or broken downloads or are documented on pages in the wrong namespace.

These extension pages should be checked manually to see if there are any alternative downloads (eg. mentioned as a comment or its a bundled plugin). If no sensible download can be found, I vote for deleting the extension page completely.

Please refer to the Plugin Repository Manual to learn how the extension markup works.

All extensions that have recently shown problems are listed at https://www.dokuwiki.org/teams:extensioncleanup

DokuWiki.org easy needDocUpdate good first issue

Source

splitbrain

All 28 comments

I checked plugin/styling as it is bundled with DokuWiki :grin:

Edit: same for plugin/config.

lpaulsen93 on 3 May 2018

@leeyc0: on the plugin page niconico is marked as deprecated/discontinued. Would it be fine for you to remove the plugin page at dokuwiki.org?

lpaulsen93 on 3 May 2018

See https://www.dokuwiki.org/teams:extensioncleanup for this list in wiki format.
Also I have added automatically links to list above, but please take care whether the url points to the logic page.

Klap-in on 3 May 2018

What do we do with plugins that simply do not have a download repository? E.g. the tab plugin is very small and simple and has the complete source code on the plugin page. Should we contact the maintainers and try to ask them to create one (preferably on github)?

lpaulsen93 on 3 May 2018

I vote against deleting the extension page completely. If someone installed an extension which is now outdated, they should be able to learn what happened to it and be able to find potential alternatives.
Just removing the syntax with the dashes should be enough. For example,

---- plugin ----
description: This is the description of the plugin.
author     : John Smith
lastupdate : 2008-04-25
[...]
----

could be taken out of the repo by simplifying it like this:

* description: This is the description of the plugin.
* author     : John Smith
* lastupdate : 2008-04-25
[...]

selfthinker on 4 May 2018

👍1

@LarsGit223 go ahead to remove niconico plugin on plugin page

leeyc0 on 4 May 2018

I vote for deletion of plugin pages which are deprecated and unmaintained for a long time (only if they do not even have a proper repo. somewhere). Especially if the plugin page also points to an actual plugin as a replacement.

IMHO the age of DokuWiki is a problem in this case. I guess there are quite a few unmaintained plugins and pages and these don't make browsing on dokuwiki.org nicer. It's not so good if a new user searches for a plugin for functionality x and then has to click himself through a number of unmaintained probably incompatible plugins.

lpaulsen93 on 4 May 2018

I agree with Lars. Pages that still have a repository somewhere or where the code is available on the page itself should be kept. But pages where no sensible download is available and that obviously have been abandoned for years should be removed.

splitbrain on 4 May 2018

Fixed download-link of wikicalendar plugin

micgro42 on 4 May 2018

I guess there are quite a few unmaintained plugins and pages and these don't make browsing on dokuwiki.org nicer. It's not so good if a new user searches for a plugin for functionality x and then has to click himself through a number of unmaintained probably incompatible plugins.

When you delete the ---- plugin ---- bits, the plugin won't be findable anymore via the plugin page or the extension manager. The only way people could find it is via Google or DokuWiki's own search.
I guess it would be good to know how people generally discover plugins.

selfthinker on 5 May 2018

👍1

Some extension pages are clear meaningless and could be removed, but there is a serieus group of pages that is semi-useful. For example to provide people that still have the extension installed with information, or to show history of the old plugins etc.

My feeling is that removing the entry blocks is just a trick to hide them from extension list at template/plugins pages and from the extension manager. For these extensions some layout and behaviour changes could be useful.

At the dokuwiki.org/plugins dokuwiki.org/template pages the list is already filtered with following criteria:

extensions with tag !obsolete are hidden
extensions with any security issue are hidden
extensions without download url are hidden (only the bundled plugins could have no download url)

My proposal:

hide in the extension manager:
- extensions with the !obsolete tag
- extensions without download url (with exception for bundled plugins) (these are not installable via extension manager)

And to change the layout of the entry blocks at the plugins and template page if
- the extension is !obsolete,
- or had no download url,
- or has een security issue.
  
  (proposed layout change: lightgrey text, and adding explanation that it is not shown in extension manager due to !obsolete tag or the missing downloadurl )

Klap-in on 6 May 2018

To be honest, I would prefer to simply delete obsolete pages. The amount of people for whom these pages would theoretically be useful is getting smaller everyday (and is very small already). OTOH those pages are still found in searches via Google and DokuWiki but provide absolutely no value to users who not already have them installed. Instead they project an image of DokuWiki having a bunch of broken extensions. I would prefer to focus on our working ecosystem and not keeping the cruft with us.

splitbrain on 6 May 2018

I agree to Andi. Maybe if we see candidates for removal let's have a vote for it. Also let's ask the author what he/she thinks. If like for plugin niconico the author agrees to remove it, then IMHO we should do it.

Only exception should be plugins which show a significant usage. But if that happens that also could mean that there are some old installations out there which might have issues because of unmaintained deprecated software (performance, stability, security issues...).

IMHO really old plugins can be a problem. There is some time when you need to get rid of old things.

Also, if e.g. users only don't update DokuWiki and plugins because some old plugin doesn't work with a newer version than that is a chance for plugin developers to notice it and probably work on it. Otherwise such "landmines" will lie out there forever.

lpaulsen93 on 6 May 2018

I vote on deleting, and if possible putting a time criteria on it somehow.
It would put a lot of more value on the plugins and templates that are really and regularly used imho.

T100D on 6 May 2018

I wouldn't mind deleting so much if only there was a way to keep at least one old revision. But they are currently deleted after 14 days on dokuwiki.org. :-/

selfthinker on 6 May 2018

What is 14 days?
Revisions of older removed pages can still be brought back, did that several times these days.

Or is 14 days just the length of the global changelog? That is easy to expand, it isn't?

Klap-in on 6 May 2018

I've updated geophp

mprins on 7 May 2018

As @Klap-in mentioned, we do not delete old revisions at DokuWiki and I would keep it that way for the plugin pages we remove.

So I think consensus in this thread is to delete obsolete pages.

splitbrain on 7 May 2018

Oh, sorry, I remember we changed that a couple of years ago when I complained about the same thing. We used to delete them but I just double checked and found we don't anymore, and then I remembered: It was changed because we lost some valuable content of standard documentation pages back then because some troll deleted them and when we wanted to resurrect them, they were already completely gone.
Okay, deleting is not as bad then. :+1:

selfthinker on 7 May 2018

Okay, here just my two cents:
Why not split them? Moving plugins older then 3 or 4 years to an archive? When searching plugins I personally don't search for older plugins. Mostly based on popularity or date.

MvErven on 15 May 2018

👍1

There are quite a lot plugin pages which have no repository but the source code on the plugin page as a listing. Should we maybe define an explicit tag like norepo or sourceonpage? This would enable automatic checks to not throw a false positive for this pages.

lpaulsen93 on 22 May 2018

Is my impression right that these plugins, which have code on their wiki page, are mainly old plugins?
At times these plugins were created, online repositories like github were not common. So not used.

I think for plugin authors moving to online repositories add a lot of benefits in ways of sharing updates and tracking issues. (of course also a certain burden if you have to learn it from scratch, but learning it will help people also a lot in other code contributions, so I think it is worth.. Further platforms like github are good documented, so a doable hurdle IMHO...)

If plugins don't offer a download url, it is cumbersome for wiki admins to add such plugins to their wiki, because these are less/not visible or not useful via Extension Manager and online listing, further they need a lot additional manual steps to install. Therefore I expect these plugins are today unpopular.

My proposal is: hide plugins without download url completely from Extension Manager and online listing. Add an automatic notice at the plugin page to explain this (to educate (new) authors to make improvements...).

At the moment I'm preparing a pull request for completely hiding extensions marked with !obsolete tag. With explanation notice as well. (I will share pointer if it is there). If appreciated, I can combine it with this proposal.

Klap-in on 23 May 2018

Is my impression right that these plugins, which have code on their wiki page, are mainly old plugins?
At times these plugins were created, online repositories like github were not common. So not used.

Yes, I think so.

I think for plugin authors moving to online repositories add a lot of benefits in ways of sharing updates and tracking issues. (of course also a certain burden if you have to learn it from scratch, but learning it will help people also a lot in other code contributions, so I think it is worth.. Further platforms like github are good documented, so a doable hurdle IMHO...)

Well I fear that there is not much interest of the authors to invest the required time in such old plugins. That plugins often haven't been touched for 10 years or more. I will try to get in contact with the authors for this plugins too, but often there is a invalid mail or simply no reaction.

lpaulsen93 on 23 May 2018

Popularity score for plugins without download url can be found here: https://www.dokuwiki.org/teams:plugins_gardening#plugins_missing_download_button

Klap-in on 23 May 2018

👍1

To what does the number under Popularity relate to? Isn't it a percentage usually?

lpaulsen93 on 23 May 2018

The Popularity score is a counter based at the times the plugin availability was submitted via the popularity plugin.
See for the numbers the last column of: https://www.dokuwiki.org/plugins?pluginsort=^c#extension__table
(the numbers are calculated by cron.php of the pluginrepo. It counts the number of submissions in 2 years)

Klap-in on 23 May 2018

See https://github.com/splitbrain/dokuwiki-plugin-pluginrepo/pull/119 for implementation of mentioned ideas. Idea is to make consequences more clear to extension authors and wiki users.

Klap-in on 23 May 2018

A little update:
I have adopted the webcomics plugin, see https://www.dokuwiki.org/plugin:webcomics.

I suggest to eventually remove some deprecated and/or similar plugin pages like: