ofpiyush / dokuwiki-extension-manager

Hi there 👋

dokuwiki-extension-manager's Issues

Quicksearch

This is a followup to #21 and related to #13

The quicksearch does not differentiate between the tabs I'm on. I would not expect template results when I'm on the plugin tab. I'd also remove the template: prefix from the result and use some icon to show the type instead.

However. I'm still not convinced the quicksearch is useful at all and would simply remove it.

weird behaviour for safefnrecode plugin

Add something to make clear if more than a download is needed

Some plugins need more than just a download and have external dependencies or even need core changes. There should be a flag (also in the pluginrepo plugin) which helps informing people about that. And then that should be displayed in some way.

code cleanup

There are a lot of things my IDE is giving warnings about (eg. appending to not initialized variables and missing phpdoc comments). The classes also use PHP4 style.

I'm willing to send a cleanup PR, but since this will break mergability with my other PRs I'll wait til they are merged.

remove the info popup

This popup is not really useful.

It should be removed, instead the triangle should simply open and close the the info area below via JavaScript (just as it does by reload now).

layout broken in first usage..

I install the zip from the master, and unzip and copied it to lib/plugins. (No idea whether it's relevant: the extension manager had first no write access to lib/plugins and lib/template).

When i look on the tabs of this plugin i see many elements, but bad ordered and layouted. Seems missing some layout styles maybe/partly.

(i got message that lib/plugin and lib/template weren't writable, i fixed it.
When using next the refresh button on third tab, the layout was fixed.

I try to reproduced it by removing directory and installing again, but i don't know were downloaded data was stored, so maybe i need to remove it somewhere first.

Maybe this was a non-issue because of the wrong set writing permissions.

new_ui branch design issues

The new_ui branch needs a major design overhaul. As requested here's just a first start on what's wrong with the current design.

Id extensionplugin__searchtext conflict

This id is used for the li of the searchtext plugin and the search input.

Not sure about the search boxes

I don't think the search boxes in the Plugins and Template tabs are a good idea. At least not how they work currently.

Since the tabs are related to installed extensions, I would assume the search is as well. Eg. that is a filter, not a search.

I'd say remove the boxes for now. Later add a real filter with a bit of JavaScript.

Remove separate rtl.css

Tabs border on top of tools menu

The tabs ul has position relative and is thus displayed on top of the tools:

Delete files on update/re-install ?

At the moment no files are deleted from the extension before doing update OR re-install. Is this a desired behavior?

At least on update we want to keep the manager.dat file. Please comment

Default base directory ?

In case a downloaded (repo url) have missing PLUGIN.info.txt which base directory should we use?

a) Same as old plugin manager - top folder in zip/tar

b) Rename folder using dokuwiki pagename (aka repokey), we "know" which plugin we are downloading

c) ?

Reason I ask is because in case a) plugin:code3 will be ok but plugin:bbs will fail b) vice versa
In error handling we can't solve both without analyzing the actual code. In both cases the user risks
installing same files twice in different directories, breaking their installation.

I think I personally would chose a)

do not link default icons

Icons currently link to themselves which is completely useless. I see that it might be good for screenshots. But not for the default icons.

Maybe we should link to the plugin's website always?

JavaScript error - Undefined variable: plugin_manager (master)

Plugin branch: master
DokuWiki version: 2012-01-25 "Angua"

Affects: every page
Browsers used: IE9, Opera 11.64
Steps to reproduce: Enable display of JavaScript errors in the browser.

Accessing each page generaters JavaScript error:
Undefined variable: plugin_manager, Line: 1

Use some lightbox for screenshots

Clicking on any screenshot leads the user outside of the wiki. Using lightbox doesn't just make it more usable, it will also make sure to stay on the page. If that doesn't have a high priority, we should at least make the screenshots open in a new window/tab.

Action buttons need icons and/or colours

The action buttons need a bit to make it easier to distinguish them from each other. This is my first try (well, my second, actually):

What I don't like about it and still plan to change:

• The icons need to be lighter (some middle-dark grey).
• It would be great if the "enable" button would be a switched on lightbulb (but such an icon is not in the iconset I got the other from). So, it should be transparent in the middle with some beams around it. See also #38.
• I don't like the "delete" icon. Maybe a simple minus (to go with the plus for "download") would do the job. (But, again, such an icon was not part of the set, but should be easy to make.)

Mockup and implement new UI

Accessing getInfo on disabled plugins?

The extension manager displays more information than the previous plugin manager without the user need to press "info". Should it be ok to access getInfo() even on disabled plugins? I think it would be unwise.

Should we even use getInfo when user press info? The old plugin manager did this.

expanding details doesn't jump to target

When JavaScript is disabled, the opening the details of a plugin reloads the page, but does not jump to the according target. That's because the URL ends with &info=navi&#extensionplugin__navi. Removing the & before the # fixes it.

Add cache

Dokuwiki repo doesn't respond (timeout). This occurs when updating repo automatically. Probably a cache in repo plugin will fix this.

refresh button placement

The refresh button, falls out of the box. I guess it would be best to add it inside the error message.

Image paths broken with clean URLs

The plugin/template (default) image uses a relative path (lib/plugins/...) which doesn't work when clean URLs are used (e.g. doku.php/start leads to doku.php/lib/plugins/extension/...).

detail info broken sometimes

Sometimes the alignment of detail info is messed up:

Seems to be a CSS problem because the HTML looks good:

(Newest Chrome)

management buttons

About these buttons:

They need some spacing, but more importantly. I think they are not really useful. Nobody will usually delete on enable/disable a whole bunch of plugins. Maybe two or three at maximum. One would be fine with doing them one by one then.

I think we should drop the checkboxes and these buttons completely. Instead we add one single button: "Disable all Plugins". That's the one button you would use when debugging a problem. You disable all plugins, then reenable them one by one.

Add "enable" on template tab

Currently its done by the config manager.
To change this I will need some more time so keeping this outside of the GSoC term.

Merge core changes (new plugin enable/disable)

The extension manager is dependent on changes in both pluginutils and plugincontroller.

function plugin_getcascade()
function get_plugin_components()

They must be merged before publishing the extension plugin

enabled/disabled icons confusing

I didn't understand what the icons on the screenshots mean until I looked at the source code and discovered they mean 'enabled' and 'disabled'. The struck through red circle means to me "you cannot do anything with this" and I assumed it meant that it is incompatible with my current DokuWiki version. Not sure how to better convey that meaning, though. What about good ole greying out?

Many screenshots produce 404

I get 23 missing images on the template tab, although most of them exist.

E.g. the one for beaufort points to https://www.dokuwiki.org/_media/http://www.roelofpieter.nl/beaufort.png although it should be https://www.dokuwiki.org/lib/exe/fetch.php?hash=28a2c4&media=http%3A%2F%2Fwww.roelofpieter.nl%2Fbeaufort.png

Part of intro text redundant

The intro text currently reads:

Use this page to enable, disable and update your installed plugins and templates. You can also search and install additional extensions made public by the DokuWiki community at www.dokuwiki.org.

The second part is redundant and also not true. You cannot search and install any more extensions on dokuwiki.org, unless they are at the wrong place (not using the pluginrepo and/or not in the correct namespace) or if they have security issues. Pointing to www.dokuwiki.org also seems irrelevant because that doesn't help finding any other extensions. If there is a page I have missed, it should rather point there.

I suggest to just remove the second sentence.

missing download button

Some (all?) templates have no download button, even though a download is set at dokuwiki.org.

Popularity bar needs explanation

If you don't know what it is, there is no way of knowing what the popularity bar is. Even its title only says "16" or "213". The minimum is that its title explains what it is, e.g. "Popularity: 16/2532" or even "0.2% of all wikis have this plugin installed".

Search auto completion

Autocompletion for for plugin/template names and tags might be a nice additions and should be relatively easy to add with JQuery UI

Pull Screenshots via fetch.php

Screenshots should be pulled via fetch.php instead of using them directly to utilize caching (probably using the cache=recache option).

Popularity info overlaps with authors

When there are many author names the popularity info overlaps with the author names (example: discussion plugin):

better version alignment

A linebreak before the displayed version would help with the layout for plugins with download and those without.

Wrong base causing trouble

In my list of templates there is one entry which seems to include references to 3 templates at once. What's even weirder is that all of those templates have an entry of their own. Not sure what's going on!?

broken getInfo in one plugin might break extension manager

To make the manager more robust, the call to getInfo should be protected by exists() as it's called for every plugin

$pm_plugins_list_lib::possible_errors not used

The above class has an array or error messages(?) but they aren't used currently. The code starts with a if(false && ...) clause.

What exactly were they meant to be used for? Can this be removed?

Resize screenshots

Some screenshots are still very big. They should be resized. (Also as discussed on #37.)

Quicksearch misplaced

It seems the quick search popup shows up in the wrong location. However I'm not sure we really need the quick search anyway. I'd say no and would vote for simply removing it all together.

Remove hardcoded versions and dead code

Line 78 of the helper.php contains a hardcoded list of DokuWiki version names. This is not maintainable. I'm not sure what it is used for, but if we really need it, we should pull that info from the API.

search tab issues

Download of templates

Right now it's allowed to "download as disabled" but this button isn't shown

weird borders

Normal plugins:

Protected Plugins:

mark new_ui branch as default branch

This can be done in the github admin of this repository. This way people will checkout the correct code automatically.

code design

I'm not too fond of how an instance of the admin or action plugin is passed to the various manager classes which then work on some member variables of this passed instance.

It makes it very hard to follow the code flow. IMHO the main plugin classes should never be passed around and modified. Instead they should simply use the manager classes to create the wanted output (or get certain return values).

add link to source repo

The details should contain a link to the source repo of the plugin (if available) as this is the most important tool to check the source code before installing. However it seems the info is not in the API right now.

do not show all extensions

We should not show all extensions on the search&install plugin. This is is a performance hog. Instead display the 10 most recently updated ones or something similar.

Remove autofocus from search field

The autofocus is a bad usability and accessibility practice when whatever is autofocussed is not where the vast majority of users would want to focus. It makes e.g. the Google homepage more usable, but here it is out of place.

As soon as I see a list of plugins, I'd like to scroll down, which I can't because I first need to get out of that search field. On the search tab it might be better suited, but even there I'm not sure it's really a good idea.