Well that, like many things about dumps, took longer than I would have
liked but the January enwikipedia run is finally complete. Unless
someone really really wants them (and then we might talk off list about
it) I am not going to provide a single file for download of the history
dumps; instead they are available in 15 pieces, both bzip2 and 7z
compressed.
The next run is under way; I expect it to take a while as well, as we
are still working bugs out of the system.
Please get your eyeballs on these, if you haven't picked them up
already, and let me know of any issues with the contents.
Thanks,
Ariel
Hello,
Urgent helpis needed!
We carry our genealogical wiki "GenWiki"
http://genwiki.genealogy.net
in version 1.14.1.
We planned to update soon to 1.17.1.
So we checked out to http://wiki-test.genealogy.nethttp://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_17/phase3
and after clearing all conflicts we updated database with
./maintenance/update.php
All seemed good because of no failures.
Calling our test-wiki you will find
Warning: mysql_real_escape_string() expects parameter 2 to be resource,
null given in /data/wiki/wiki-test/includes/db/DatabaseMysql.php on line 316
Warning: mysql_real_escape_string() expects parameter 2 to be resource,
null given in /data/wiki/wiki-test/includes/db/DatabaseMysql.php on line 316
Warning: mysql_query(): supplied argument is not a valid MySQL-Link
resource in /data/wiki/wiki-test/includes/db/DatabaseMysql.php on line 23
All of these code snippets are in "core code", not in our extensions!
Where/how to heal?
We thaught, that code should be running at least?
Switch back to 1.16.2?
Wait for release of 1.17.x?
--
I look forward to your answers...
Uwe (Baumbach)
U.Baumbach(a)web.de
I found that [[Special:ListFiles]] is enabled on Commons. Very nice,
especially the separation of author (though titled "User") and
description.
Too lazy to look it up - is this grabbed from the rendered HTML, or
stored in the database? If it's the latter, is there a special page to
list the files by author, instead of by uploader? Does it work for all
authors, or "only" Commons users?
Magnus
Secure basically fell over for awhile, generated nothing but proxy errors. I'm
not sure that's what really happened. It may have been a complete inability to
actually send or receive data, resulting in a timeout of some sort.
Take a look at the Ganglia graphs. Free memory gone. Big spike in processes.
Big drop in network activity!
http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/New_skin_layout
I have some plans for a new way of laying out skins in a new skin system.
The key changes being; The creation of new region block handling in the
system (default skins typically just including a standard body region
and messages region) to replace newtalk, sitenotice, the jsmessage div,
bodytext, catlinks, and dataAfterContent (used by flaggedrevs, smw, and
other extensions). And changes to what types of navigation we support
and how dominant the location of the toolbox is.
This new layout and system will likely be done using a planned xml/html
based template syntax.
http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Monobook_templatehttp://www.mediawiki.org/wiki/User:Dantman/Skinning_system#xml.2Fhtml_templ…
I've thought a lot about various template languages and template
language vs. no template and ended up with the result that a xml/html
based syntax is the best. The advantage it has over all other syntaxes
is context sensitivity. As a simple advantage the fact we can
differentiate between html context, attributes, and even css url
contexts makes skins much cleaner. There are also various other parts of
the syntax that cut down on excessive php blocks. Additionally the
backwards compatibility, intelligent lang support, and autodetection of
regions are not possible without the template syntax.
Additionally the template system being built is designed differently
than our QuickTemplate, it doesn't run keys of code which it does not
need. This in particular means that things like the addition of support
for alternative types of navigation can be added without the
inefficiently of parsing navigation messages for navigation pieces which
are not used, it also starts to cut out our limitation to pre-defined
skin pieces.
----
http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Skin_examination
I would also like to eventually eliminate our three skins using the
legacy system (Nostalgia, Standard/Classic, Cologne Blue). They don't
"properly" use our SkinTemplate system and require another 930+ lines of
code dedicated to their support, full of code duplication which
repeatedly gets in the way of new features because we insist that any
change we make to the ui should be backported to also work with legacy code.
The only arguments I've seen so far for their inclusion are:
- There are people from en.wp using these skins, they'll riot if we get
rid of any old skins
- The quickbar is meant to collapse and nostalgia has no sidebar, these
are good for users with small screens.
Simple still fulfills the requirement of a functional skin without
excess css and js and Simple is not using Legacy code so it's not part
of the list trying to be killed off.
On the first one I think we need some real stats from en.wp on what skin
preferences active users have.
On the second one, I've been thinking the best way to deal with users on
small screens would be to build an alternative 'thin' version of Vector
which is laid out somewhat like nostalgia with no sidebar and a top
navigation. The opposing issue of increasingly wide monitors with less
vertical space was brought up, so I also thought about making another
fat/wide version of vector that tries to skim the content area as close
as possible to the top of the screen.
----
If you're wondering what my ideal timeline was:
- Minor improvement of footericons and footerlinks (1.18, done).
- Improvements to SkinTemplate making it much easier to use (1.18, done)
- Moving the whole legacy skin system out of the normal tree and
dropping support for use of it outside MW (1.18, done).
- Initial introduction of the new template based skin system, not quite
making it the dominant system yet (ideally 1.18).
- Dropping all legacy skins from the system (1.19)
- Migration to the use of the new skin system throughout core and
depreciation of SkinTemplate (1.19)--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Hello,
The foundationsite says in the article peering that the foundation is
looking for free rack-space / routers.
What kind of facilities do they want? Is there a more detailed pages
with the wishes en needs for the foundation, or can that be geven here
on the list?
Best,
Huib
On 11-03-14 10:53 AM, Daniel Barrett wrote:
> What is the recommended way to get a parser tag like<foo> and another hook callback to communicate or have a shared state? Here's a simple use case:
>
> 1. Use a<foo> parser tag to generate some wikitext
> 2. Use the SkinAfterBottomScripts hook to inject that wikitext at the bottom of the page
>
> In this case, what's the best way for the callbacks for<foo> and SkinAfterBottomScripts to share information (in this case, the generated wikitext)? I can think of a few places that<foo> could put its generated wikitext for SkinAfterBottomScripts to access :
>
> Method 1: Put the two callbacks in the same class and create a static variable to hold the wikitext. I don't like this method because it feels like an ancient "shared memory" solution (with all the usual pitfalls& risks).
>
> Method 2: Create a custom property in the ParserOutput object ($parser->mOutput) and hang the generated wikitext there. This feels a little better, but unfortunately the parameter list for the SkinAfterBottomScripts hook doesn't include a Parser or ParserOutput object, so it can't access the data. (Theoretically one could use $wgParser, but when I tried this, something in between deleted my custom property.)
>
> This is just one example. The real question is: what's the best practice for sharing data/state between two callbacks in a MediaWiki extension?
>
> Thank you very much.
> DanB
Method 1 is doomed to fail in situations where we fetch from the parser
cache. Which is ideally most of the visitor page views.
You may be able to use a combination of the ParserCache and it's
setProperty, OutputPageParserOutput, and BeforePageDisplay. iirc I used
something like that in the Description2 extension.
SkinAfterBottomScripts looks annoying without an $out param though.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]