mediawiki installer updates

3 posts / 0 new
Last post
#1 Sat, 08/09/2008 - 08:08
kato

mediawiki installer updates

Hi, I fixed the mediawiki installer to accept table prefixes, so that more than one mediawiki can share a single db. I posted the thread in the blue skies forum, and it hasn't received a reply.

Please let me know if you'd like to consider this addition, and if there's any way for me to help with testing and integration.

http://www.virtualmin.com/index.php?option=com_fireboard&Itemid=77&func=...

Sat, 08/09/2008 - 13:11
Joe
Joe's picture

We always welcome patches Jamie might end up rewriting to suit his fancy, but we're always looking to make things more resilient and capable, as long as it doesn't add complexity for the end user. Table prefixes is a bit more complexity, but I think a few others already have such an option. (It seems silly to quibble about one more option...but we already have so many options, that a lot of new users find Virtualmin at the root level absolutely terrifying. It's a little bit better on the virtual server owner level, but still, more options is generally a net loss on usability.)

Anyway, I've pointed Jamie at the blue skies thread, and he'll chime in.

In the future, don't hesitate to file "task" tickets for this kind of thing. Concrete, minor, changes don't need to be discussed too much. Toss them into the ring in the tracker, and we'll either add it or tell you why not. Blue skies is all about crazy dreams and stranger things. So, adding a new option (or even better, removing a confusing one) are things that get a ticket, and adding a whole new module or product line is a blue skies thing. To make that concrete: Supporting a completely different webserver is blue skies. Supporting a new Apache directive is for the ticket tracker. ;-)

--

Check out the forum guidelines!

Thu, 08/14/2008 - 08:11 (Reply to #2)
kato

Will do, thanks.

As for complexity, I can understand that. A great model for this is the layered approach, where all advanced options are hidden from the user initially, but available as time continues.

I understand that this is easier said than done, but I can throw in some ideas on how to accomplish it if you posit a problem. In this particular case, I'd go with hiding things like the database name and table prefix under an advanced section that collapsed by default.

This model is a great way for new users to drop in comfortably without getting scared away, and open up to new features as their model of the system develops.

Again, we're talking abstractly here. I don't disagree that the table prefix is a fairly minor option.

Topic locked