dokuwiki / dokuwiki-plugin-pluginrepo Goto Github PK

see http://bugs.dokuwiki.org/index.php?do=details&task_id=2475

Currently "downloadurl" only support external URLs, but could it be possible to also support files uploaded on DokuWiki media manager ?

With the {{}} syntax:
https://www.dokuwiki.org/syntax#images_and_other_files

Eg: {{myfile.zip}} would be rewritten as: http://mywiki/lib/exe/fetch.php?media=myfile.zip

What is purpose of this syntax for real application?

Always combining templates and plugins makes the MySQL queries a way more complicated.

When you put a link on a description (either plain or using DokuWiki syntax), the link show up but is not clickable.

PHP message: PHP Fatal error: Call to a member function diff() on boolean in /var/www/wiki/htdocs/lib/plugins/pluginrepo/syntax/entry.php on line 114

introduces in: 05c95cb

As mentioned in dokuwiki/dokuwiki#1209 an effect of this is:

The page is empty and no pagetools are displayed at:
https://www.dokuwiki.org/plugin:keywords

I think it would be helpful if the plugin search page offers the option to list newly created resp. added plugins. That means a list of (more or less) all plugins, sorted by plugin's creation date, recently created at the top.

As sources for the creation date I see two possibilities:

1. The very first entry in "Old Revisions".
2. A stored creation date in the plugin's data record. When a new plugin page is created, this date is automatically stored. At the moment this data field does not yet exist, so it would have to be set up. (Plugins that do not already have this data field need not necessarily appear in the list.)

Motivation: I would like to have the option to check for new plugins every few weeks or months. I assume this is a feature that would be useful for many DokuWiki users. Especially for those who offer regular support in the forum. And also for many who maintain and extend their wikis in the long run.

I don't see any other practicable way to keep up to date on the new plugins offered. At least not with a reasonable effort or applicable by everyone.

I see the special advantage of my idea in the fact that no further maintenance is necessary, since the necessary data is already available anyway. Any possibility to better deal with the tons of plugins, which does not require any further maintenance, I find welcome.

(Of course with the templates this would be helpful also.)

Moved from https://www.dokuwiki.org/plugin:repository

"Random Template" on [[extensions]] page can show very old templates with no compatibility info. Maybe the plugin should be changed to show only those with recent compatibility info? --- [[user>sancaya|Constant Illumination]] //2015-04-06 16:43//

I have removed the whole widget as it not worth having if half of the templates it's displaying are unusable. --- [[user>ach|Anika Henke]] //2015-04-12 10:42//

Currently types are handled here:

https://github.com/splitbrain/dokuwiki-plugin-pluginrepo/blob/master/helper.php#L14

It would be good to be able to add more types (dynamically) in DokuWiki settings.

If I understand the current logic, it's handled with power of two right ? So types can be added ?

The old API endpoint repository.php is currently broken:

[Thu May 15 09:45:07 2014] [warn] [client 91.64.57.205] mod_fcgid: stderr: PHP Warning:  require_once(/var/www/wiki/htdocs/lib/plugins/pluginrepo/../../../lib/plugins/pluginrepo/helper.php): failed to open stream: No such file or directory in /var/www/wiki/htdocs/lib/plugins/pluginrepo/repository.php on line 13
[Thu May 15 09:45:07 2014] [warn] [client 91.64.57.205] mod_fcgid: stderr: PHP Stack trace:
[Thu May 15 09:45:07 2014] [warn] [client 91.64.57.205] mod_fcgid: stderr: PHP   1. {main}() /var/www/wiki/htdocs/lib/plugins/pluginrepo/repository.php:0
[Thu May 15 09:45:07 2014] [warn] [client 91.64.57.205] mod_fcgid: stderr: PHP Fatal error:  require_once(): Failed opening required '/var/www/wiki/htdocs/lib/plugins/pluginrepo/../../../lib/plugins/pluginrepo/helper.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/wiki/htdocs/lib/plugins/pluginrepo/repository.php on line 13
[Thu May 15 09:45:07 2014] [warn] [client 91.64.57.205] mod_fcgid: stderr: PHP Stack trace:
[Thu May 15 09:45:07 2014] [warn] [client 91.64.57.205] mod_fcgid: stderr: PHP   1. {main}() /var/www/wiki/htdocs/lib/plugins/pluginrepo/repository.php:0

It is still used by the translation interface.

When you do a search for a plugin where the author set no types, the plugin will not be in the results.

It's the same for both plugins & templates

Copied from dokuwiki/dokuwiki#2407 (created by @lpaulsen93):

If the table of contents is folded, then the "Compatible with DokuWiki" box is partly hidden and the assigned value for a specific DokuWiki release (e.g. "Yes") cannot be seen. See this screenshot:

Tested with Firefox.

It would be cool for user to be able to rate plugin. It could be done either by modification of pluginrepo or installing rater plugin

Lightbox support is not working with latest gallery dokuwiki plugin

@selfthinker said the version of gallery is 2009-10-07 on dokuwiki.org

One simple fix is to change the class from "media" to "lightbox"

As reported here http://irc.dokuwiki.org/index.php?d=2012-02-02#msg374076

the 'Tagged with' url misses the page-segment of the url in the datablock at the pluginpages

The "yyyy-mm-dd+" syntax used in the "compatible" field doesn't seem to be working anymore. See e.g. https://www.dokuwiki.org/plugin:sync. That also means that those plugins will only show at the very bottom of the plugin list under "Compatible with older DokuWiki versions" although many of them will be compatible with the latest version.

I personally never liked that syntax, but as long as we support it, this should be fixed. Or we should stop supporting it.

plugins are stored as ':captha'
while templates are correctly stored as 'template:dokucms'

Hi,
i added a simple plugin called passwordgrey:
https://www.dokuwiki.org/plugin:passwordgrey
No matter what I do, it won't show in the plugin repository:
https://www.dokuwiki.org/plugin:passwordgrey

Any ideas?
Kind regards,
Michael

Templates cannot use e.g. similar: dokuwiki to refer to another template, they need to use namespaces e.g. similar: template:dokuwiki.

The script needs to be rewritten for jQuery

Currently plugins name displayed are matching the pagename:
https://www.dokuwiki.org/plugins

It sometimes result in:
"Cacherevisionseraser plugin" which is not easily readable for humans.

https://github.com/splitbrain/dokuwiki-plugin-pluginrepo/blob/master/syntax/table.php#L357

It would be better to use "name" instead of "plugin"

The HtmlMetaTags Plugin was initially wrongly created in the "plugins" namespace and not the "plugin" namespace. Although it was deleted from there, it still appears in various places, e.g. the main plugin list on /plugins and on other plugin pages from the same author, e.g. https://www.dokuwiki.org/plugin:simplemysqlclient

The data should obviously be deleted as soon as the page gets deleted.

I restored an old version of the page and then deleted it again to see if that fixes it (the bug might have been fixed since then). But that didn't help.

Drupal has defined some imho really nice categories for describing the maintenance and development status of the project. I think it makes sense adding them to the plugin repository either as special tags that get some icon and tooltip explaining their meaning or as separate fields.

Some tags have only !obsolete tags remaining, probably the tag counts does not exclude these yet.

https://www.dokuwiki.org/plugins?plugintag=%21maybe.broken#extension__table

Queries on the database show removed plugin entry blocks, which are not removed correctly from the database.

e.g. https://www.dokuwiki.org/teams:plugins_gardening#extensions_with_no_type_defined

When a plugin marks another plugin as similar, the other plugin page would show it as similar as well without the need to add it to the page. But that functionality seems to be broken.

E.g. plugin:wrap has "pagebreak" as one of the similar plugins, but plugin:pagebreak doesn't have "wrap" listed.

On the other hand the Wrap plugin lists several similar plugins which it doesn't list in its markup, so it generally still seems to work.

We currently display all plugins in the table, when no filter was set. This results in a huge table and lots of data to transfer and process. And this problem is getting worse every day.

I think we should display a limited choice of plugins by default. I think the best choice here would be the most recently updated ones. Maybe with a way to switch to the most popular ones instead.

And most important: adding pagination would be a good idea. Only showing maybe 25 results per page or so.

Here are some crude mockups on how that might look like.

The current API already support returning XML data.
It would be great to make an RSS Feed for updated plugins based on the lastupdate field.

Eg. the probably tag:

https://github.com/splitbrain/dokuwiki-plugin-pluginrepo/blob/master/syntax/entry.php#L219
https://github.com/splitbrain/dokuwiki-plugin-pluginrepo/blob/master/style.css#L143

If it's in English "probably" is used, but in other language this doesn't work

Issue #27 depends on this

in helper/repository.php in getPlugins() only powers of 2 are supported.
But mySQL does a bitwise comparison (https://dev.mysql.com/doc/refman/5.7/en/bit-functions.html) so asking 5 would work fine:

AND (A.type & :plugin_type)

if plugin is A.type=5, it matches in current query at following requests plugin_type: 1,4,5, others return 0.

todo: improve filtering.

current approach:

public $types = array(
        1   => 'Syntax',
        2   => 'Admin',
        4   => 'Action',
        8   => 'Render',
        16  => 'Helper',
        32  => 'Template',
        64  => 'Remote',
        128 => 'Auth'
    );
            if(!$this->types[$type]) {
                $type = 255;
            }

Are there opinions about adding a field mentioned 'updatemessage' which plugin authors can use to share an note regarding the offered update? Now the 'securitywarning' is sometimes used for this purpose.

Idea is to show it as 'Update message: ....... '. In same yellow layout at the other messages.
This needs change of the Extension Manager as well.

In the plugin and template entries a 's' is added to :plugin and :template in the tagurls.
This is ok for :plugins, but :templates don't exist, it should be :template.

See:
https://github.com/splitbrain/dokuwiki-plugin-pluginrepo/blob/master/syntax/entry.php#L289

Random example template page: https://www.dokuwiki.org/template:dokuwiki

Should we put a switch to hide the popularity column on the table component ?

https://www.dokuwiki.org/plugin:repository:manual#pluginrepo_table_component

The screenshot it too width, so it moves below the buttons. Changing the margin-left helps.

@media screen
.dokuwiki div.pluginrepo_entry div.mainInfo a.screenshot {
    display: block;
    margin-left: 1.5em;  /* lower this */
}

I can image that always showing bundled plugins, causes too much buzz in the overview.
But with the current settings they are never shown.

Search for 'bundled' tag:
https://www.dokuwiki.org/plugins?plugintag=%21bundled#extension__table

Search for Remote type, acl plugin could appear.
(probably it is in the counter of 5 above the list, but it is not displayed (4 plugins are shown))
https://www.dokuwiki.org/plugins?plugintype=64#extension__table

https://www.dokuwiki.org/plugin:repository:manual#api

From the documentation, "plugins" filter should return data based on an array of plugin name but it's not working:

http://www.dokuwiki.org/lib/plugins/pluginrepo/repository.php?plugins=barcode

https://github.com/splitbrain/dokuwiki-plugin-pluginrepo/blob/master/helper.php#L117

In the master branch, we have performance problems related to the calculation of popularity data. I just pushed a change in the stable branch that introduces a cron script that updates popularity data once and saves it directly to the plugins table. This should make all popularity related selects much simpler (and faster). All that's left to do is to rewrite those queries.

@HakanS I'd be grateful if you could have a look at this.

It seems that the maximum value for template popularity isn't calculated correctly. The top used template still has no full bar:

The popularity data on plugins and templates seems to be wrong or mostly missing. The quite popular wrap plugin for example has '0' installations, the most popular plugin has just '11' and most others have 0 as well. The templates don't show any data at all (but those were already missing in the previous version.)

Type should be 'plugin' or 'template'.
Probably these wrong types originate from namespace of repository entries that are stored at wrong location.

See also:
dokuwiki/dokuwiki-extensionmirror@12aba0c

Maybe idea to disable or give warning for repository entries outside the 'plugin' and 'template' namespace. Such that wiki editors can fix them self already.

There's a field 'depends:' to add dependencies to dataentry.

But it's not straight forward to get the plugins that were required somewhere. Can an automatic listing be added to the plugin(/template)entry?

It seems that conflicting plugins aren't shown currently. @selfthinker can you squeeze this into the design somehow?

As reported here [http://bugs.dokuwiki.org/index.php?do=details&task_id=2443], the ru:templates page is blank.

The same thing happens on my local installation for the normal templates or plugins page. Unfortunately my apache error log only lists PHP notices before it actually completely restarts! (Parent: child process exited with status 3221225725 -- Restarting.) There is nothing in my MySQL error log (not sure if the SQLite errors should be listed there as well?).

The layout for plugin pages is broken on the new template and needs adjustment

There is no field to tell that a plugin is not compatible with a release, the currents data is "Yes" or "Unknow". I would suggest adding a notcompatible field to allow plugin authors to mark them not compatible.

I just deleted a plugin and it still shows in the sameauthor box, see http://www.dokuwiki.org/plugin:issuetracker

Everything is fine after a ?purge=true, though.

Reported at https://bugs.dokuwiki.org/index.php?do=details&task_id=2289

Beside the tagcloud on https://www.dokuwiki.org/plugins are filteroptions for plugin types.

The last added plugintype is added yet, that's: Remote

(no idea whether such plugins exist already..)

e.g. in pluginrepo/repository.php, pluginrepo/syntax/table.php

• use Input class to retrieve only desired entries instead of passed whole array to inner functions
• maybe filter more throughtly the provided values
• so far seen sanitation of used entries of the array is fine in inner functions

The popularity bar currently has only the title/tooltip of '1', while it should have '1/11' to indicate the overall number of available data sets.