https://bugzilla.wikimedia.org/show_bug.cgi?id=32819
--- Comment #16 from Peter Bena <[email protected]> --- (In reply to comment #3) > Thought I'd look over this extension and give some thoughts: > > > Line 28 of InteractiveBlockedMessage.php: > $wgAutoloadClasses['InteractiveBlockMessage'] = > "$dir/InteractiveBlockMessage.php"; > > I'm not sure what that's about (It won't hurt anything, but there is no such > class, so it probably shouldn't be there) > if it's not there, be bold and fix it. I am sure it was there in past. > *LanguageGetMagic hook usage - That's probably ok, but if you use a > .magic.i18n.php file, the magic word name can be translated at translatewiki > (I > think anyways) > translating magic words? Nooooo please :) keep it compatible cross-language (magic words are already translated in Microsoft Excel and it's pain in the arse) > *MagicWord id being all capitalized - Doesn't really matter, but the magic > word > id (not the actual magic word, just its internal id) are all lowercase for > all > the magic words in core > > *$user->isBlocked() call - should perhaps pass a true to explicitly ask the > result to come from slave (doesn't really matter though, since slave is > default, but good to be explicit) > so fix it. > *Doesn't work on anon user pages (not sure if intentional or not. if it's > wanted, all that needs to be done is pass false as second argument to > user::newFromName) if it did work for anons, there might be security > implications in revealing auto-blocks (As mentioned on the en wp page, > although > given the number of autoblocks in place at one time, it'd be difficult to > glean > much from this, but still not a good thing) > well, the original purpose was to make block messages on anon pages less confusing. But given the incredible amount of bureaucracy on english wikipedia, who knows if it's even possible since the question "am I even allowed to edit wikipedia" is TOP SECRET now. > *If the user causes their own user page to be rendered, the magic word will > report true if the user is blocked via auto-blocks, proxy auto-blocker, or > DNSBL block (although I don't think the last two are used by wikimedia). This > is inconsistent (Compared to other people rendering the page), and probably a > bad thing (Although not horrible). Perhaps better to use Block::newFromTarget > directly, in which case it would only look at explicit blocks (and could also > be used on anon user pages without leaking auto-blocks). > > *We should perhaps add a hook to SpecialUnblock::processUnblock so that this > extension could explicitly purge user pages on an explicit unblock. > let's fix it > -- > Cheers > > ------- > btw, does this extension still need review by the senior dev cabal? (I know > there is a mailing list thread about that) if so, it should have the keyword > "need-review" and be blocking bug 31235. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
