[dokuwiki] Re: [GSOC] Rewrite Plugin Management

  • From: José Carlos Campos <zecapistolas@xxxxxxxxxxxxxx>
  • To: dokuwiki@xxxxxxxxxxxxx
  • Date: Sun, 27 Mar 2011 23:37:37 +0100


On Fri, Mar 25, 2011 at 6:55 PM, Håkan Sandell <sandell.hakan@xxxxxxxxx> wrote:
> The red padlock is a very strong UI symbol, I don't it should be used
> with mixed meanings.
> We have a similar problem with the config manager imho.

Yes, I agree with that, red padlock is a very strong UI symbol.

On Sun, Mar 27, 2011 at 10:35 PM, Michael Hamann
<michael@xxxxxxxxxxxxxxxx> wrote:
> Hi,
> Yes, exactly. But it's not requirement, just an idea. The problem is
> imho that there are so many plugins that you don't know where to start
> and the first plugin you'll find might not be the best one. So imho it
> would be nice to show (new) users some selected plugins. But there is
> also another problem, the plugins need to be select, I don't know if the
> plugins and templates team has made any progress on the selection.
> You can read more about this on
> http://www.freelists.org/post/dokuwiki/Idea-about-managing-Plugins-on-dokuwikiorg,8
> and
> http://www.freelists.org/post/dokuwiki-teams/plugin-template-Suggestion
> - perhaps integrating these "solutions" into the plugin manager might be
> a nice idea, too. Or supporting plugin bundles in general.

New users can start explore plugins with Tags. I think that 'Searching
for Tags' is a quick way to begin to see new plugins, because the name
of many plugins is self descriptive.
But, I will read that two topics, thanks for that.

> Okay, that sounds good. Wordpress has also the concept to try enabling
> the plugin temporarily and if the request (in an iframe afaik) doesn't
> succeed the plugin won't be enabled. I don't like iframes but perhaps we
> could do something similar by making plugin enabling a two-step process:
> a) enable plugin temporarily by ignoring the disable-setting/file
> b) display a page or a redirect where the plugin is then finally enabled
> And if enabling the plugin fails the user can simply go back and
> everything will still work.
> Or we could simply execute an Ajax request in the background and check
> if it works, or perhaps implement both methods and decide based upon the
> availability of JavaScript in the browser.

Yes, we can "enable plugin temporarily by ignoring the
disable-setting/file and if the plugin fails the user can simply go
back and everything will still work", I like this solution.

> Yes, probably such a list of trusted people isn't that good/working. I'm
> not sure if the vote feature will really work because I can't imagine
> the figures won't be that different from the current popularity data
> except that developers with a lot of plugins will get more votes.  Votes
> can also be abused easily if you don't protect it properly.
> The problem is that signing the plugin might be difficult unless we
> provide a simple step for doing it and it won't work at all with the
> automatically created archives of GitHub that are currently used for a
> lot of plugins.
> I'm also not sure the most popular plugins are the best ones. If you
> look at the code in the Wordpress Plugin repository e.g. plugins like
> All In One SEO Pack that are really popular had or still have security
> issues (have a look at
> http://www.wptavern.com/forum/plugins-hacks/1492-all-one-search-engine-optimization-pack-must-suspended.html)
> and it is even blocked by some webhosters afaik because it badly impacts
> the performance by modifying the HTML output of the template using
> string manipulation, and the coding style was also not that good, at
> least some time ago. So imho popularity is no sign for good plugins that
> should be installed by everybody.

Yes, I agree when you said "Votes can also be abused easily if you
don't protect it properly." but how can we trust on plugin from
someone?! Vote, Popularity, Sign Plugins?!
Last semester I had 'Computer Systems Security' and I think the only
way we can trust a developer if he sign the plugin. If not, we'll
never know if the plugin is from that developer. And if something goes
wrong if that plugin, we can ask for responsibilities because we know
that plugin is from a particular developer.
This is a critical point, I think we (developers for DokuWiki) need to
think a lot on this.


New version of mockups: http://goo.gl/DQtGb
- More options to install plugins/templates (Searching, by URL like
now, upload a file);
- More warnings on information about a plugin;
- More information on template info;
- General: more detail about all mockups.

DokuWiki mailing list - more info at

Other related posts: