Saw an article mentioned on Slashdot about Wordpress themes and plugins
being required to be disributed under the GPL because they are derivative of
Wordpress. Is this also true for Mediawiki extensions and skins? It seems
like the arguements for why Wordpress themes and plugins also apply to MW.
Article:
http://markjaquith.wordpress.com/2010/07/17/why-wordpress-themes-are-deriva…
Thanks for any insight
Andrew Fitzgerald
http://wiki.swiftlytilting.com
Greetings,
MediaWiki, in its grandmotherly kindness, automatically converts plain
text unmarked URLs like "http://google.com" into "<a
href="http://google.com" class="external free" title="http://google.com"
rel="nofollow">http://google.com</a> when rendering. Is there any
sensible way to disable this? I couldn't find a public configuration
option for this, although these are apparently a subtype of magic links(*)
and I'd be happy to disable magic links completely if need be. Commenting
out "$text = $this->doMagicLinks( $text );" or stabbing at the regexp in
said function in Parser.php works, but, eww.
(*) http://www.mediawiki.org/wiki/Markup_spec/BNF/Magic_links
Cheers,
-jani
(changing topic so that Gmail won't mix it up with the original
Foundation-l discussion for me . . .)
On Fri, Jul 23, 2010 at 6:51 PM, Platonides <Platonides(a)gmail.com> wrote:
> Even if you remove censoring ability from anonymous users, you still
> need to purge from squid cache all pages that include the images when
> category changes.
Only if the category changes in such a way that would affect whether
the image censored by default. I expect that on many wikis there will
be no censored categories at all by default, so on those wikis this
would be never. Images that are likely to ever be in categories
censored by default are very unlikely to be used on many pages, and
Squid cache is much cheaper to purge than parser cache, so I think
this would be acceptable from a performance standpoint. Or we could
just say that anonymous users might get censored-image lists that are
a few days outdated.
Realistically, I don't see very many wikis enabling this feature by
default. Wikis where the community doesn't want a particular type of
image will tend to not use that type of image at all, they won't want
to display it inline but blocked out with a message "Click here if you
want to see naked people!" I see this feature mostly being used by
individuals who object to the standards of a wiki they use.
> There are some large galleries.
> For instance contains 746 files each with 4-5 categories. That's nearly
> 3000 categories being retrieved.
You seem to have left our the link here. But this is an edge case,
and it's still not going to be particular slow -- the query to
retrieve the categories here should take only a few milliseconds.
Time and again, the 100 MB limit on file uploads is a problem,
in particular for multipage documents (scanned books) in PDF
or Djvu, and for video files in OGV.
What are the plans for increasing this limit? Would it be
possible to allow 500 MB or 1 GB for these file formats,
and maintain the lower limit for other formats?
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
Ahoy there,
My name is David Breneisen. I was referred here by James Alexander. I'm a
Comp. Sci. student at George Washington
University and have had an interest in open education web development for
the last few years. I thought that I might be able to offer technical
services for the Wikiversity development/maintenance while getting some
experience working on larger, "real," projects.
I also hope to see if it is possible to do a more formal summer internship
after this school year with Wikimedia, and thought it
would be nice to get used to the overall manner in which Wikimedia
design/development goes.
Regards,
David Breneisen
Ahoy there,
My name is David Breneisen. I was referred here by James Alexander. I'm a
Comp. Sci. student at George Washington
University and have had an interest in open education web development for
the last few years. I thought that I might be able to offer technical
services for the Wikiversity development/maintenance while getting some
experience working on larger, "real," projects.
I also hope to see if it is possible to do a more formal summer internship
after this school year with Wikimedia, and thought it
would be nice to get used to the overall manner in which Wikimedia
design/development goes.
Regards,
David Breneisen
Auto-deferral regexes for CodeReview were implemented in r63277 [1],
and I deployed this feature three weeks ago. It allows us to set an
array of regexes that will be matched against the path of each new
commit; if one of them matches, the commit is automatically marked as
'deferred' instead of 'new'.
There are a few limitations to this implementation that are important
to understand:
* it only matches paths, not commit summaries. This means
auto-deferring e.g. TranslateWiki exports is harder
* it only matches the root path of the commit, which is very often an
uninformative one like /trunk/phase3 , /trunk/extensions , /trunk or
even / . This means you can't e.g. auto-defer all commits touching a
certain file or path
Despite these limitations, this feature could be quite useful for
autodeferring at least some large parts of the repository we don't
care about review-wise. Any suggestions for paths to auto-defer?
Roan Kattouw (Catrope)
[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/63277
jidanni(a)jidanni.org wrote:
>
> The first words the user* sees on every page are "Take me back"....
I agree that link should be renamed with different text. I've already
seen two people confuse it with the back button's functionality,
thinking they needed to click it after logging in to get back to the
page they had to log in to create. For those users, who were never in
Monobook to begin with, they were taken "back" to somewhere they had
never been before, didn't know what to do when they got there, and
weren't very happy about either of those facts.
May I suggest, "Use legacy interface" or "Abandon new interface"?
It's broken again. Can someone fix the Extension Distributor. At least
the symptoms, if not the real problem. There are regular complaints
about it on our IRC channel.
> svn: Working copy '/mnt/upload6/private/ExtensionDistributor/mw-snapshot/trunk/extensions' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
Thanks.
--
Niklas Laxström
Hey,
I want to make several structural changes to the new installer, to make it
fit in a more general deployment model. This will involve moving code and
renaming things. Does anyone have objections to me doing this? (I don't want
to undermine work people are currently doing.)
Cheers
--
Jeroen De Dauw
* http://blog.bn2vs.com
* http://wiki.bn2vs.com
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69
66 65!
--