On 12/27/05, Jan Steinman <Jan(a)bytesmiths.com> wrote:
From: Sy Ali
<sy1234(a)gmail.com>
... apparently going into the database
would indeed be required to purge history.. but such things are not
for me...
I think anyone who is going to administer a MediaWiki site would
benefit from learning something about MySQL.
If you're someone who does a lot of web stuff, that learning would
not be limited to one application, either, as the PHP/MySQL combo is
used on hundreds of free web applications.
There are also numerous GUI tools for administering a MySQL database,
that span the range from free to thousands of dollars. My favorite
(although it lacks a thing or two that cause me to run off to some
other tool now and then) is phpMyAdmin, which is free.
As when learning anything, work on a backup. Record the manual steps
you take to accomplish your goal. Then try to do them in a script.
Then instead of ranting, submit your work for the benefit of all, and
become a famous contributor, rather than an infamous ranter!
You might want to involve me in a reply to me.. I might have skipped
over this post.
Firstly, there are big fat disclaimers with making manual changes to
the mediawiki database. That alone says NO to fiddling around.
That's a real showstopper to most people and especially myself.
Then I could go on about how mysql isn't a real database and not a
real skill I want to pick up anyways. I'd rather not even work with
phpmyadmin or any other tool.. especially for functionality which
ought to exist in the host software. I could also go on about how php
is a letdown and not something I want to get involved with (too much
exposure to php5).
Having made those vague suggestions, I'd rather just say that I intend
to stay a regular everyday user, which means ranting when I feel that
developers leave gaping omissions in philosophy and functionality.
MediaWiki is built for the Wikipedia.. something which wasn't and
still isn't stressed enough. This means that its needs and focuses
aren't real-world. Which sucks and I'm unfortunately stuck with it.
Even if I were to get into it myself, which would invariably involve
hiring a team to do it for me, tinkering with a project's database
from the outside not only requires backups, it's not something which
can be done lightly on a live installation of thousands of documents.
It's not a matter of backing it up before trying it out, it would then
require a massive backup history. Tinkering with one thing leads to
fun issues way down the road.. and having had data magically poof away
from flakey database issues (thanks mysql!) there's no way I'd want
random hacking in my database.
So the only real solution to any of this is supporting a close fork of
mediawiki with a team that has very in-depth knowledge of that
project. The fork would then support the real-world functionality
that I keep ranting about.
This fork reaching stability would let me use the functionality I
need. Randomly hacking around without proper knowledge isn't a good
idea when a good decade of writing is on the line.
Or I could do some scripting, back my database up, unleash the script
to remove history older than a certain date, and then manually go
through a few thousand documents to see if there was any damage. I've
done that before, it sucks. I'd rather look for supported
functionality for stuff like that this time around.
The only real inbetween is to read the "it works for me" experiences
of others when they are poking around their database the manual way.
I'm not going to blaze any trails anymore..
For example.. I have an "it works for me" on removing the row for a
particular user login. Developers here gave a "the sky will fall!"
response to someone else's question about it.. so I'm still a bit
inbetween (that was probably mw 1.3 though).
In conclusion.. I don't like learning new tricks. =)