Page MenuHomePhabricator

blacklist may become too big
Closed, DeclinedPublic

Description

At meta (290KB) and at w:en (160KB) the sbl has got many many entries, so it gets hard for some users to edit those pages. Some javascripts seem to fail already on some user's machines.

One can think of many different work-arounds. One fast solution could be, to use transcluded pages, s.t.

example\.org
{{some transcluded page}}
example\.com

where "some transcluded page" consists of only
foo
bar

will be treated by the extension as
example\.org
foo
bar
example\.com

The advantages would be:

  • sbl gets arbitrarily smaller, so editing gets easier
  • rendered sbl looks still the same, because transclusion works anyway
  • admins may chose, whether they want to use that feature (i.e. downward compatibility!)
  • doesn't need much programming on sbl extension

Version: unspecified
Severity: major

Details

Reference
bz25524

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:19 PM
bzimport added a project: SpamBlacklist.
bzimport set Reference to bz25524.
bzimport added a subscriber: Unknown Object (MLST).

If we are going to use this at meta, then I believe this breaks downward compatibility. That's too bad, because I really like this solution.

How should this break downward compatibility? (Maybe my explaination was bad.)

[[mw:Extension:SpamBlacklist]] and the source code says that the URL for fetching the spam blacklist is:

http://meta.wikimedia.org/w/index.php?title=Spam_blacklist&action=raw&sb_ver=1

This is just the wiki source of the page and does not expand transclusions (see e.g. http://en.wikipedia.org/w/index.php?title=Main_Page&action=raw in your favorite text editor). The character { followed by } is likely to make older spam blacklists spew errors.

Perhaps we can have a syntax like:

#SB_INCLUDE<page>

where the # conveniently comments out the line for those who can't understand it.

Then again, maybe spewing errors to get people to upgrade might be a good idea.

Oh, I didn't know that other (non-wikimedia) wikis use our sbl. Afaics this would be the only compatibility problem.

We could use a combination of our proposals:

#{{some transcluded page}}

So the first line of that transcluded page is ignored and could be used for a comment instead, e.g.

----%<----
please insert a space before each line
foo
bar
---->%----

Would that fix the problem, you mentioned?

matthew.britton wrote:

Or you could start actually maintaining those blacklists, rather than merely adding a link every time it gets used for spam.

(In reply to comment #7)

Or you could start actually maintaining those blacklists, rather than merely
adding a link every time it gets used for spam.

The blacklists are maintained already. Maybe you want to discuss that in detail at the meta talk page.

This seems like a duplicate of bug 14322.

Aklapper changed the task status from Open to Stalled.Feb 6 2022, 5:43 PM
Aklapper subscribed.

Ten years later, is this still an issue or is this obsolete?

i'm not sure.
as we deleted a lot of superfluous entries in the last years, the sizes of the SBLs are now the same (meta: 290kB) or even smaller (w:en: 140kB) than 2010.
as computers got faster during that time, it might be a not-so-big issue right now. however, i don't know what the situation will look like in the next years.
at least i'd say that this issue is of low priority.

Aklapper changed the task status from Stalled to Open.Feb 6 2022, 10:50 PM
Aklapper lowered the priority of this task from Medium to Low.

https://meta.wikimedia.org/wiki/Spam_blacklist is about 300kB (assuming that's what the ticket is about). That's not a big size for web browser. If some users run into specific issues when editing those pages, please create specific bug reports so issues can be worked on and better solutions can be found, as it seems that the proposal in this ticket does not target root causes of any potential issues. thanks!