brion(a)svn.wikimedia.org wrote:
> Revision: 37898
> Author: brion
> Date: 2008-07-21 22:37:33 +0000 (Mon, 21 Jul 2008)
>
> Log Message:
> -----------
> Revert r37872 for now -- "(bug 2971) Standardize format of links to hist/diff in Special:Contributions."
>
> This appears to have changed "(hist) (diff)" to "(diff; hist)". I'm a bit leery of callign that "standardization" as it changes it from looking like regular Recent Chagnes to looking like enhanced Recent Changes.
> Might be good to do a look around at other things, which use for example commas or pipes in parens as well, and figure out which is best to stick with.
>
Note that while Special:Contributions uses "(hist) (diff)", regular
Special:Recentchanges uses "(diff) (hist)". This is confusing and should
probably be changed.
Anyway, I think that all the pages - Special:Contributions, regular
Special:Recentchanges and enhanced Special:Recentchanges - should use the same
formatting.
Hello all,
Comments from a technical perspective would be appreciated at
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Proposal:_M…
I really don't know why the main page was put in the article namespace in
the first place - if a developer could at least drop by to clarify that it
would be appreciated. I don't know exactly where the developers stand on
this, but I would think that as developers you would be in a better position
to understand what the appropriate thing to do is.
--
Remember the dot
http://en.wikipedia.org/wiki/User:Remember_the_dot
On Mon, Jul 21, 2008 at 12:24 PM, <ialex(a)svn.wikimedia.org> wrote:
> Revision: 37884
> Author: ialex
> Date: 2008-07-21 16:24:39 +0000 (Mon, 21 Jul 2008)
>
> Log Message:
> -----------
> Use the internal diff engine if the diff excutable is not found
> ...
> + $diffs = new Diff( explode( "\n", $before ), explode( "\n", $after ) );
> + $format = new UnifiedDiffFormatter();
Maybe it would make sense to have diff engine do the fallback to the
diff utility, rather than the caller? It seems like
$wgExternalDiffEngine currently must be manually set to true to take
advantage of utilities like Unix diff. Unless there are problems with
the option, it seems like it would be sensible to use command-line
utilities automatically if available.
A few people have convinced me to start work on a side project (My main
project as always is ElectronicMe), an extension short discussion ended
up calling PatternFilters.
Currently we have a number of blacklist extensions -- SpamBlacklist,
SpamRegex, RegexBlock, UsernameBlacklist, TitleBlacklist, BadImagesList,
BlockTitles, etc... -- and there is very little consistency among them.
Some match plaintext and some match regexps. Some have a specialpage
interface and some use a article page.
The idea of PatternFilters is a single extension replacing all of these
with one extension founded around the singular principle all of these
extensions share, Filtering (blacklisting and whitelisting) some part of
user interaction using some sort of pattern.
However other than just combining a mess of extensions together I hope
to improve some other things. Primarily making the interface for
filtering things more intuitive. Firstly, using a special page rather
than a page on the wiki with cryptic syntax. And secondly, giving a
helpful interface on that special page which helps give an estimate on
what the filter will affect on the wiki. Just as an extra, it could
easily validate a regex on it's own before adding it to avoid issues
like with the other blacklists where a bad regex breaks the whole
filter. As well the extension would properly support global/local modes.
For example, if you were to go to [[Special:PatternFilters]], select
global, select blacklist, select regex, select 'block existing users',
'block user creation', and 'block title editing' with 'Restrict to
namespaces' on User and User_talk, and fill in the pattern 'Fo+Bar' then
hit the check button the page would help give an estimation on what the
filter would do by listing out existing usernames which match that
regex, and also existing pages which match it as well. Things like url
backlisting would work nicely to with the externalinks table.
For a little more ui simplicity I plan to support wildcards as well. The
text blacklist of course can't go hunting through the entire DB, so
rather than that it'll display a text field you can use to check and see
if a filter will catch something inside a block of text, probably even
highlight it. Also separate from url and title, comments could be
blacklisted as well.
Of course some checks are DB heavy, so there's a special right already
in so you can disable use of those simply by not giving out that right.
Currently I only have a small special page but the start of it can be
viewed at:
http://svn.nadir-point.com/viewvc/mediawiki-extensions/trunk/PatternFilters/
I've also created some dev wiki dedicated to the extension (Don't want
filtering experiments going awry on my demo wiki):
http://spam.dev.wiki-tools.com/http://zeta.spam.dev.wiki-tools.com/http://omega.spam.dev.wiki-tools.com/
The number of wiki is for a variance in testing. The root spam.dev wiki
is the one that is configured as the global db so I want to test out an
interface change when you are editing the global db directly as a global
db instead of pure local. zeta and omega are normal and so you can test
global and local blacklists, probably add a global blacklist, whitelist
on one wiki, and test something on both. Though I may tweak it and turn
one of those into a local only setup to test the interface for that.
Currently there isn't much at all to test or do, but once the
PatternFilter extension, well... filters ;) then I'll consider tweaking
my right configurations on the wikis to allow people to grant themselves
the check, heavy, immunity, global, and edit rights for the patterns.
--
~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--The ElectronicMe project (http://electronic-me.org)
--Games-G.P.S. (http://ggps.org)
-And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
--Animepedia (http://anime.wikia.com)
--Narutopedia (http://naruto.wikia.com)
On Thu, Jul 17, 2008 at 10:16 PM, <werdna(a)svn.wikimedia.org> wrote:
> Log Message:
> -----------
> Make some more methods public. Useful for external use as in AbuseFilter.
>
> Modified Paths:
> --------------
> trunk/extensions/AntiSpoof/AntiSpoof_body.php
Perhaps these should be moved to core, someplace like StringUtils.php?
---- brion(a)svn.wikimedia.org schrijft:
> Revision: 37775
> Author: brion
> Date: 2008-07-17 09:26:01 +0000 (Thu, 17 Jul 2008)
>
> Log Message:
> -----------
> Revert r37748 "(bug 14020) Added an API interface to Special:Unwatchedpages in the form of the apfilterwatched parameter to list=allpages. If $wgMiserMode is true or if the user doesn't have the 'unwatchedpages' right, apfilterwatched is ignored and a warning is output."
> This is broken -- watched page filter results in a huge wash of duplicate rows -- one for each watcher for each page.
Oops :D I don't have SVN access right now and won't have it until Monday, so I'd like to request that someone recommit this right. All you'd need to do is revert Brion's revert and add one line:
> --- trunk/phase3/includes/api/ApiQueryAllpages.php 2008-07-17 09:25:19 UTC (rev 37774)
> +++ trunk/phase3/includes/api/ApiQueryAllpages.php 2008-07-17 09:26:01 UTC (rev 37775)
> - // Only allow watched page filtering if the user has the 'unwatchedpages' permission
> - // $wgMiserMode disables this
> - global $wgUser, $wgMiserMode;
> - if ($wgUser->isAllowed('unwatchedpages') && !$wgMiserMode) {
> - if($params['filterwatched'] != 'all') {
Add $this->setOption('DISTINCT'); after this line.
Thanks in advance to whoever does this,
Roan Kattouw (Catrope)
demon(a)svn.wikimedia.org wrote:
> Log Message:
> -----------
> Add $wgDefaultDirectoryChmod, allows customizing the default chmod
> value. Set to 0777 by default to keep current behavior.
Handy... I think there's some other uses of mkdir() directly which
should presumably have this default setting applied to them as well...
I'm not super fond of the name though -- maybe $wgDirectoryMode ? :)
Anyway...
Compare also with the patch on this old bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=6295
and further notes on:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14593
We've got similar issues where we may need to be able to override the
default permission mode for thumbnail files, see:
https://bugzilla.wikimedia.org/show_bug.cgi?id=6654
Check also texvc, see if old issues there have changed:
https://bugzilla.wikimedia.org/show_bug.cgi?id=6248
-- brion