![[Home]](http://meatballwiki.org/meatball.gif)
RecentChangesRecentChangesThis page uses AsynchronousAutorefresh; if you are experiencing problems, try unchecking "Use Javascript for client-side filtering" below.
Page generated December 2, 2020 6:59 am
I added a couple of .htaccess bans for ABTS-AP-dynamic-074.151.169.122.airtelbroadband.in. Hopefully it works. Unfortunately, I'm unable to help with the reverts while I'm at work and then out tonight.
I think the ban could be just a little bit more efficient :(
I ended up cheating and banning all edits from the .in top-level domain. Thanks everyone for reverting the material. I have been ridiculously busy lately and rarely near an Internet connection while I'm not at work.
Excuse me, I feel very stupid, but I've never been able to change the RecentChanges behaviour: how can I see older edits? Nothing happens if I change the "days to display" value, and if I uncheck "Use Javascript for client-side filtering" the page reloads unchanged with the checkbox checked.
Federico, I wouldn't feel stupid. The user interface is rather confusing to me as well as it was experimental--and proven!--but not refined. I'm open to doing a screen share with you to see what your experience is. Do you have Skype? I'm sunirshah on Skype. I'll warn you that I'm rarely online these days, so I'd prefer to book a time this Sunday from 4-6pm CEST.
Thank you for your generous offer. I've "resolved": on Ubuntu (9.10) it works with Epiphany or Chromium, so it's only a Firefox problem (nothing changes disabling extensions), where nothing happens if I click enter after changing the value of "days to display" (it works on Windows); maybe an explicit button would work. Anyway there's a simple workaround, so don't worry.
Federico, unfortunately, that means there is still a bug out there that is unresolved. If it affected you it probably affected others. It would be helpful to understand the underlying issue so I can make a fix.
I mass reverted all the airtelbroadband.in spam. My ban filter wasn't effective as it turns out.
I mass reverted all the host354388.mpdedicated.com spam. I am considering rebasing MeatballWiki on Bibdex so I can better manage the site. That requires a bit more discussion, naturally.
I mass reverted all the 180.92.186.135 and 180.92.186.154 spam.
I think I fixed the spam filter. It was overeager. It should be better now.
Thanks for fixing the spam filter.
Would rebasing it also result in fixing the links in the RSS feed? Right now they all point to the feed itself, not the pages, which makes the feed pretty useless... Since I mostly keep track of the wikis through the feeds, I simply stopped reading Meatball because of that. I know that everyone are busy, but maybe it's just a 5-minute fix?
I'll look into it.
Like Radomir, I'm just following the RSS feed, given the low level of activity recently.
Does ..."rebasing"... indicate any plans to re-vitalize Meatball?
Yes. Right now, I'm too busy to deal with it, especially since MeatballWiki's codebase lacks sanity or the tools to even tell what's going on here. However, unifying the two will make life easier.
Thanks for taking the time to reply, Sunir. -- Hans
Thanks for taking the time to reply, Sunir. - Hans
I've been upgrading Bibdex to better support public communities in prep for the move. It's slow going right now because I'm not as focused on it as I could be.
I've been upgrading Bibdex to better support public communities in prep for the move. It's slow going right now because I'm not as focused on it as I could be.
Thanks for fixing the spam filter.
Wow, somebody is spamming the wiki using my username! Please, review all changes made using my username very carefully!
Damn it, I can't even edit this talk page? "Invalid URL RecentChanges/action=edit&id=RecentChanges/Talk."
Alex, I've noticed the same thing on this and other pages. Some form actions incorrectly insert the current page's URI between the wiki CGI "http://meatballwiki.org/wiki/" and the query string for the form "action=edit&id=...".
UPDATE: You can work around this problem by editing the URL Meatball generates for page editing:
http://meatballwiki.org/wiki/RecentChanges/action=edit&id=RecentChanges/Talk ==> http://meatballwiki.org/wiki/action=edit&id=RecentChanges/Talk
100+ spam edits under SunirShah reverted...
I wrote a script to delete all the botnet spam last night. Thank you to MarkusLude, MarkDilley, and NathanielThurston for cleaning it all up.
We need a plan to get MeatballWiki off this codebase and onto something more robust (I vote the Bibdex codebase). It would certainly be a better use of our time than fighting spam and never moving this thing forward. Anyone interested in helping?
I will open source the Bibdex codebase finally as well.
Hi Sunir,
is the bibdex code also written in perl or in another language?
In which way do you consider the bibdex codebase more robust?
Were some of the anti spam measures disabled during last months or 1-2 years? The only I'm aware of is the open proxy thing.
I think we should track the addition of links more. It's quite uncommon to have the same link posted quite often to different pages or to add a lot of links to the same domains.
Recently as a short term measure I blocked access from some IP addresses or networks. With better anti spam measures we may remove them again.
The MeatballWiki code is unreadable by humans and out of control. The Bibdex code (RubyOnRails?) is unit tested and better decomposed; it's not perfect, but it's better. It doesn't support all the features of MeatballWiki; but it does support authentication. I've lost faith in allowing anonymous edits.
I have no idea what's going on for spam protection with MeatballWiki. The code is hard to reason about.