Gentlemen, my mom, age 50 (hexadecimal) years old, thinks wikis ought to
have "send this article to a friend" buttons like normal websites do.
Indeed, the flagship Wikipedia site lacks such basic equipment last time
I would have told her "just send them the URL yourself, for that
personal touch", but since she's 120 (octal) years old, maybe it's time
to take a tip from our elders and add such a feature, without me needing
to do as much as even check to see if an extension already can do it.
If not a complete "Share (on FarceBook, etc.)", "Suggest" button, then
at least a simple "mail to a friend".
>>>>> "M" == Annette "Mom" Jacobson writes:
M> Excellent title. Thanks for fixing the typos, etc. I was thinking --
M> is it possible to put an ikon in this articles page for a "send to a
M> friend" possibility? Most article blogs have one, and I always use
M> them to help get articles I like around. The send 'aps' on the
M> article's page are so simple to access and use. What do you think?
M> ----- Original Message -----
M> From: <jidanni(a)jidanni.org>
M> To: Mom
>> OK, made
In a message dated 4/28/2011 10:34:40 PM Pacific Daylight Time,
> Interesting how Facebook has lots of things that connect to Wikipedia,
> but Wikipedia doesn't have the reverse... but then Wikipedia is supposed
> to be neutral. Anyway, at least a 'share this page via email' button on
> Wikipedia might be warranted.
Similar to how we have the "find a book" thingie setup so when you click on
an ISBN you get a page of choices, we could have a thingie where you click
on it and get a page of social network choices. That would still let us be
neutral. I don't necessarily like the sidebar for the Wikipedia site, as I
can see it growing out of control.
Our wiki has a template that displays a mini-periodical table. Each table
entry is represented by a small box, which is a link to the corresponding
When we upgraded to 1.16.2, this template stopped working. I have traced
the problem to some html added as link text. Specifically, an element (in
this case Hydrogen) is represented by:
[[Hydrogen |<div style="filter:alpha(opacity=99);
border-bottom:1px solid #fff;
border-left:1px solid #fff;
border-top:1px solid #fff;
border-right:1px solid #fff; background-color:#333">
When I inspect the output html at the browser, the output div is:
<div style="/* insecure input */" ...
When I remove "filter:alpha(opacity=99);" from the link text, things work
fine (at least on FF and Safari). Investigating, it seems the
"filter:alpha(opacity=99);" attribute is an IE specific opacity setting.
I am attempting to fix this problem, but I don't know where the "/*
insecure input */" value is generated. Is it in the parser? Is by the
browser? Somewhere else? Is there some global I can set to eliminate this
behavior? Is the value "filter:alpha(opacity=99);" obsolete,
necessitating it to be changed to something else?
-- Dan Nessett
Is there a way to dump the articles of a wiki to individual files
named by their title? Like if you had something called /wiki/Hello
World it would be, among the other articles, dumped as
'hello_world.xml'. You can do this on websites like wikidot which
send you a zip file containing each article as a single text file.
Inside of Article.php, there is a query that joins the user table
to the revisions table in the function getContributors. The
important bits are:
$fields = array(
'rev_user_text AS user_name',
'MAX(rev_timestamp) AS timestamp',
'GROUP BY' => array( 'rev_user', 'rev_user_text' ),
$res = $dbr->select( $tables, $fields, $conds, __METHOD__, $options, $jconds );
return new UserArrayFromResult( $res );
This breaks for those databases that don't allow for a
non-deterministic GROUP BY (yes, sometimes you can
technically get away with leaving fields out of the GROUP BY,
but this is not one of those cases :). One solution that
has been raised to this general problem is to have MW
recognize 'group by' queries and add fields as needed to the
GROUP BY by parsing the SELECT list. Obviously this is
a non-starter in this case, as we are doing a user.* in the
SELECT clause. Which makes me wonder if we really need that
here in the first place. We definitely don't need all those fields
to display user contributions, but what's the minimum needed
to satisfy UserArrayFromResult? This tracks back to loadFromRow
in User.php. No doubt it is convenient having a complete user
object ready to use anywhere, but do we really want to encourage
pulling back user.* everywhere or is another approach better?
So I'm looking for comments on the best solution here, both
in the specific and general case. As I see it, the options are:
1) Manually add in all the columns from the user table to the
GROUP BY. Painful, and subject to immediate breakage when a
column is added or removed from the user table.
2) Teach MediaWiki how to parse queries and expand the user.*
into a list of columns to feed to the GROUP BY. Actually not
as hard as it sounds, but not very elegant at all.
3) Rewrite the SELECT above to only pull the columns we need
for that section of code. In this case, probably user_id,
user_name, user_real_name, and user_email? This would mean
that the user object returned would have unset fields for
things like $this->mToken. The best short-term solution, but
breaks the underlying promise that a user object is a complete
and populated user object.
4) Something else. Return a new object that's a subset of the
User table? Perhaps with the fields that are commonly used
for displays of other users, but without the you-as-the-user
specific fields such as the password, last touched, etc.?
Seems silly to be slinging around all those attributes when
we don't need to be.
Greg Sabino Mullane greg(a)turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201104271012
this might look weird, however I thought I just ask: (maybe it's not the
right place to ask)
Since April 2008 the Volunteer Climbing Team of Greenpeace Germany runs a
Mediawiki for skillsharing and training purposes, at
Obviously the wiki is closed - and it doesn't run on official Greenpeace
servers, but on my own - since I started the wiki 3 years ago.
Until now it has proven very valuable and we use a lot, for all sorts of
stuff - currently we try to "internationalize" it, like having multilanguage
support - and I try hard to fix the extension "ConfirmAccount" ....
Well, I run and administer it, even though I'm not an expert, I just learned
in the process. Now it just gets too much, so I wonder if there is anyone
around here, who is willing to help us a little? Preferably on a voluntary
basis - sorry, we don't have a lot of budget to spend on this.
I guess for an expert or a more experienced person this would be a lot
easier and faster, than for me - and I wouldn't risk loosing the entire wiki
Prefered would be someone from Germany, Hamburg or Berlin, so we could set
up a meeting ...
Looking forward to your replies ...
if you have any advice for us, or if you want to direct our question
somewhere else, we're very grateful for any help
P.S. this is my list-email-address, you also reply to
Greenpeace Germany, Volunteers & Action Departement
Florian Asis Schulz
Extension:MultiUpload allows multiple file uploads but each file has to be
selected individually. Is there a way to select and upload a list of files,
using the normal OS selection mechanism (shift-click on a range of files,
Matthew Betts PhD, Russell Group
CellNetworks, BioQuant, University of Heidelberg
Im Neuenheimer Feld 267, 69120 Heidelberg, Germany
phone:+49 6221 54 513 61