A few days ago in #mediawiki ^demon made a comment about php 5.4 having a
built-in webserver.
After a little bit of looking at that we found that when MediaWiki was
combined with a standalone copy of 5.4 and the webserver and sqlite
support built-in it was possible to startup a quick and easy development
instance of MediaWiki with nothing but the MW code and an isolated copy of
php. (ie: no real extra dependencies besides what you'd expect on a
unix-like OS setup to be able to compile something)
I threw together some bash scripts that will download the latest php 5.4,
configure and install it into maintenance/dev/php/, install an sqlite
based install of MediaWiki, and startup php's built in development
webserver on localhost.
Anyone have a problem with these bash scripts being committed to
/trunk/phase3/maintenance/dev/ for anyone checking out MW to use?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On September 22nd I started an initiative to document what extension
authors should be doing when trying to support newer (and older!)
versions of mediawiki. This culminated in
[1] http://www.mediawiki.org/wiki/Manual:Extension_support
Now that we have a new version coming out (1.18.0beta1, I would like
to call core dev attention to two articles that need updating:
[2] http://www.mediawiki.org/wiki/Manual:Extension_support/1.18/ExtUpgrading
Is for extensions authors who have extensions in 1.17 and want to
update them for 1.18. Please feel free to add anything you know of.
While code samples for best-practices are encouraged, linking to
manual pages where new documentation resides is the preferred method
when possible.
[3] http://www.mediawiki.org/wiki/Manual:Extension_support/1.17/ExtDowngrading
Is for extension authors who are coding against 1.18, and want to
support the large number of 1.17 already deployed who will take awhile
to upgrade. A strong emphasis here would be on branching code that
allows people to use the new "preferred" method while still retaining
support for older methods (through the use of method_exists and the
like). Code samples are more frequent here, but again please link to
actual documentation for individual objects, methods, etc.
One advantage of having itemized lists like this is that extension
authors don't have to dig through all the changelogs (which often just
have a short summary and links to bug reports), and changes are more
clearly communicated to the community of developers. People who have
requirements for supporting older wikis also have clear instructions
on how to best go about it, and our "upgrade" instructions of the
future quickly become our "downgrade" instructions of the past.
Hopefully in the long run this will help communication between these two bodies.
Thanks,
Olivier Finlay Beaton
Alexander Gesinn (planetenxin) now has extensions access. "I'd like to
commit a new and lightweight extension (UserAgent) that adds
some magic words to retrieve User Agent ID and User Agent Version from
HTTP_USER_AGENT. Further plans to maintain existing extensions."
Welcome!
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Hi all!
After building texvc and setting $wgUseTex = true in my LocalSettings.php I
am running into a warning message:
Warning: wfMkdirParents: failed to mkdir "/path_to_mw/images/tmp" mode 511
in /path_to_mw/includes/GlobalFunctions.php on line 2324
This warning also occurs after manually mkdir "tmp" in "images" -- there's
also no change with both directories set to 777.
What am I doing wrong? Any hint is greatly appreciated.
Thanks a bunch -- Duy
Hello,
Last I heard, many Wikimedia and other MediaWiki installations relied
on HTML Tidy to some degree to cope with bad markup, like templates may
generate. There is also some interest in using "HTML5" features in
MediaWiki wikis, but combining the two is difficult as Tidy will choke
on elements it does not know (since it does not know how to parse them)
and configuring them with the new-*-tags options is troublesome.
I made http://lists.w3.org/Archives/Public/www-archive/2011Nov/0006.html
some patches to address that problem (and only that problem really, Tidy
is not going to be a proper "HTML5" parser that parses documents exactly
as a browser would) so that Tidy keeps working with old markup as usual,
but doesn't choke on new elements, doesn't complain about new attributes
and doesn't "break" conforming documents. Where new markup is malformed,
Tidy is unlikely to repair it as sensibly as it does for old markup, and
it may in fact make them even more malformed or otherwise break them. I
do not care about that at this point, and there is nobody else contribu-
ting code to the project of late.
I am interested in polishing my patch and including this in the official
repository, but I need people I can blame instead of myself when it does
not work right, err, I mean, testers. I haven't heard from anyone with a
MediaWiki background that they actually had some problem with Tidy plus
"HTML5", but if that is just because deployment is slow, this is likely
the best place to look for takers.
Discussion is taking place on tidy-develop(a)lists.sourceforge.net but you
can also use the bug tracker on sourceforge or mail me directly, ideally
sending a copy to www-archive(a)w3.org so there is a publically archived
copy I can refer others to if they would like to help out. Feedback on
other things than the patch or "HTML5" support in general is welcome too
of course.
regards,
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
"Search is central to the Wikipedia experience – both as a way of
reaching the website as well as discovering content on Wikipedia."
http://blog.wikimedia.org/2011/10/26/search-and-wikipedia/
Alas, Search is not central for these lists,
$ GET http://lists.wikimedia.org/robots.txt
# robots.txt for lists.wikimedia.org
#
# Disabled crawling for several lists 2005-11-26 to
# discourage people from complaining about items they
# post on public mailing lists being the first Google
# search result about them.
#
# Disabled for all lists 2006-11-03, now that an internal
# search has been set up using htdig.
#
# Note that list archives remain public.
#
User-agent: *
Disallow: /pipermail/
Can they at least take that line about hitdg out.