Ya, that was my idea. Actually it was more of a $wgUseExtensionManager
cause the only global variable I remember in the manual which used
disable in the name, was a depreciated variable. The actual though of,
do I want to use this in the first place, can also be added as a check
box in the config/index.php script.
The reason I thought of the use of things like the .ext/.enabled as the
determining factors in if the extension manager was so that old
extensions which don't use the system can still be used in the old way.
And we don't need to tell anyone to mess with what they already have.
Also, another fact of the idea is that using the .ext folder idea even
though some people may restrict the ability to write to the extensions
folder. The scripts can still read those folders even when we say they
can't write. And in the case of things where we want to write the
.ext/.enabled file with the content "enabled" but it's restricted so
that we can't write we can display a set of instructions telling the
administrator how to do it. Such as:
Please save the following content to the
/extensions/*extensionid*/.ext/.enabled/ file:
enabled
Actually, if I weren't already working on a number of other things.
Including my Database Dependency configuration script (Allows for the
controlling and creation of new wiki using only the database; Only a
baseline of configuration is done in LocalSettings.php and settings/
folder files; The actual base information is grabbed from the shared
database).
On a side note, I've had a few improvements for the shared database
stuff for some time. I commonly run a simple shared interwiki table
hack, and even a shared ipblocks table hack possibly. But really, all
I'd do is add an array of tables you could use a shared one instead of
the local one. If no one was opposed to it, the setup is something that
would probably fit right into the MediaWiki base code.
Now that I think of it, I could probably fix it so that the shared
database will work with table prefixes.
~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and
Wiki-Tools.com
Gary Kirk wrote:
Someone earlier mentioned introducing
$wgDisableExtensionManager for
people who want or need to disable it.
On 09/06/07, Michael B Allen <mba2000(a)ioplex.com> wrote:
On Sat, 9 Jun 2007 10:11:31 -0700
Jan Steinman <Jan(a)Bytesmiths.com> wrote:
From:
Dantman <dan_the_man(a)telus.net>
Adding and removing things from LocalSettings.php might be
troublesome.
How about a single line in LocalSettings.php that includes a
"don't
touch me" file that is maintained only via the ExtensionManager?
Part of the manual installation would be to include this one line, as
well as remove any existing extension inclusions.
I haven't read this whole thread so pardon if I'm restating
something
that's been discussed already but being someone who has extensions for
several LAMP apps that allow you to administer extensions, there's one
fundamental problem that always get's in the way:
To be able to upload a package file, the web server needs write access
to the extensions directory. This is fatally flawed because anyone who
can run a web script can now overwrite your auth plugin with their own
hacked version of it.
So whatever you do, just make sure you can always do it the old-fashioned
way - putting the file to the extensions dir and adding two lines to
LocalSettings.php.
Mike
--
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/mediawiki-l