From: Sy Ali sy1234@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!
:::: At the root of our problem is America's addiction to cheap energy. It would be a sad commentary if our leaders found it easier to send Americans to fight in the desert than to impose gasoline and other energy taxes. -- James Gustave Speth, 1990 :::: Jan Steinman http://www.Bytesimths.com/Van
On 12/27/05, Jan Steinman Jan@bytesmiths.com wrote:
From: Sy Ali sy1234@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. =)
Undelete the pages; yes, undelete. Then nip into the page table and find out the page id...delete that page's row from the page table. Hop over to the revisions table and delete all rows where rev_page is the same as that page id. That's a permanent deletion; the page never existed.
For the small touches, check that corresponding revisions are wiped from the recent changes table, too.
Rob Church
On 29/12/05, Sy Ali sy1234@gmail.com wrote:
On 12/27/05, Jan Steinman Jan@bytesmiths.com wrote:
From: Sy Ali sy1234@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. =) _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
On 12/29/05, Rob Church robchur@gmail.com wrote:
Undelete the pages; yes, undelete. Then nip into the page table and find out the page id...delete that page's row from the page table. Hop over to the revisions table and delete all rows where rev_page is the same as that page id. That's a permanent deletion; the page never existed.
For the small touches, check that corresponding revisions are wiped from the recent changes table, too.
Is there wiki-side documentation on spelunking around the database like this? I don't know where to begin looking. (the mediawiki hacking topics?)
This looks like it's only good for totally nuking a complete page, can it be varied to delete the history of a particular page and leave the the present revision intact? I understand that it might not work that way now (with revisions being tracked, and not complete page copies).
This stuff wouldn't work for bulk stuff as-is, but if it's simple enough I could pull off some Ruby scripting it if there were some nice mysql tools for Ruby (I'm not sure). That, and I know some people I can pay to do it and test it if need be. =)
Do you want complete removal of the old revisions, or do you just want to hide them from the history?
If the latter...
1. Delete the page 2. Go to the undelete page (Special:Undelete/Pagename) 3. Scroll down and check the topmost box 4. Click Restore
This restores the latest revision from the deletion archives, but will keep the old revisions hidden from non-sysops.
Rob Church
On 30/12/05, Sy Ali sy1234@gmail.com wrote:
On 12/29/05, Rob Church robchur@gmail.com wrote:
Undelete the pages; yes, undelete. Then nip into the page table and find out the page id...delete that page's row from the page table. Hop over to the revisions table and delete all rows where rev_page is the same as that page id. That's a permanent deletion; the page never existed.
For the small touches, check that corresponding revisions are wiped from the recent changes table, too.
Is there wiki-side documentation on spelunking around the database like this? I don't know where to begin looking. (the mediawiki hacking topics?)
This looks like it's only good for totally nuking a complete page, can it be varied to delete the history of a particular page and leave the the present revision intact? I understand that it might not work that way now (with revisions being tracked, and not complete page copies).
This stuff wouldn't work for bulk stuff as-is, but if it's simple enough I could pull off some Ruby scripting it if there were some nice mysql tools for Ruby (I'm not sure). That, and I know some people I can pay to do it and test it if need be. =) _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Thanks for the info. Perhaps users that cannot delete pages should see a "grayed out" delete tab? Silly me, I had this problem because I never bothereed to log in as an admin so I never saw the delete tabs.
mediawiki-l@lists.wikimedia.org