I have Extension:MathJax installed & it tests out to be working
following the instructions in mediawiki. I still have 1 issue though;
Example; If I load up Template:Quantum mechanics which includes the
following :
> {{Sidebar with collapsible lists
> |name = Quantum mechanics
> |bodystyle = width:18.5em;
> |title = [[Quantum mechanics]]
> |image = <hr/><div style="padding:0.35em 0 0.3em;"><math>\Delta x\, \Delta p \ge \frac{\hbar}{2}</math></div>
> |caption = <div style="padding-bottom:0.5em;">[[Uncertainty principle]]</div><hr/>
I get the proper output in the navbox. When that template is transcluded
onto another page I get this error in the navbox:
> Failed to parse (Cannot write to or create math temp directory):
> \Delta x\, \Delta p \ge \frac{\hbar}{2}
>
I notice that the output from the math is supposed to be an image, but
it seems to me that it is 'transcluded' as something else; The page
source output for the navbox is below.
> <table class="vertical-Navbox
> nowraplinks" cellspacing="5"
> style="float: right; clear: right;
> color: black; background: #f9f9f9;
> border: 1px solid #aaa; width:
> 22em; margin: 0 0 1.0em 1.0em;
> padding: 0.2em; border-spacing:
> 0.4em 0; text-align: center;
> line-height: 1.4em; font-size: 88%;
> width:18.5em;" cellpadding="0"><tr>
>
>
> <th class="" style="padding: 0.2em
> 0.4em 0.2em; font-size: 145%;
> line-height: 1.2em; font-weight:
> bold;"><strong
> class="selflink">Quantum
> mechanics</strong></th>
>
>
> </tr><tr>
>
>
> <td class="" style="padding: 0.2em
> 0 0.4em;"><hr /><div
> style="padding:0.35em 0
> 0.3em;"><strong
> class='error'>Failed to parse
> (Cannot write to or create math
> temp directory): \Delta x\, \Delta
> p \ge \frac{\hbar}{2}</strong>
>
>
> </div><div style="padding-top:
> 0.2em; line-height: 1.2em;"><div
> style="padding-bottom:0.5em;"><a
> href="/pw/index.php?title=Uncertainty_principle&action=edit&redlink=1" class="new" title="Uncertainty principle (page does not exist)">Uncertainty principle</a></div><hr /></div></td>
>
>
>
Any suggestions to fix this are appreciated.
Thanks!
frosty
Le 18 févr. 2012 à 23:41, Nicolas Brouard a écrit:
> Le 16 févr. 2012 à 22:26, Platonides a écrit :
>
>> On 16/02/12 09:51, Nicolas Brouard INED wrote:
>>> Thanks to Platonides for his comment and also to Olivier (the author of the Realnames extension) who told me to forward the following patch to wikitech-l (which I just subscribed to) for advices, comments and critics.
>>>
>>> I was just wondering if this small patch in User.php (function idFromName) was enough in most cases:
(...)
>> This is only patching User::idFromName(), which won't be enough.
>
> Sorry, could you detail why it won't be enough!
>
>> You could well be storing the email instead of the username in the page
>> history.
>
> I was probably not clear enough: I don't want the email in the page history. Also the Realnames extension (quoted above) is trying to do what you seem suggesting but it is a complex extension which did not work on 1.18 for example.
>
> The proposed patch is also a solution which manages the transition for Wikipedians. Having an authentication with e-mail only is brutal and won't be understood. I like the possibility of having both option with a priority to username for performance also.
>
> But allowing new authors from Arabic or Asian (or Russian or ...) countries (with non Roman characters) to sign new articles in their own language with their own standard, not transliterated, signature will be appreciated if they also have an easy way to authenticate on an English keyboard (pad, smartphone etc.).
I didn't express it right.
If you do $user = User::newFromName("email(a)address.com"), that gets
cached, and if youlater use that object for eg. storing the username in
the history, boom, $uset->getName() will say it's called email(a)address.com
That's probably not happening, but you would need to check all paths in
core and the extensions...
>> As I said, you should fix it in SpecialUserlogin.php.
>
> What should I fix? Is there something wrong in the proposed patch?
The patch should go against SpecialUserlogin.php, authenticateUserData() function.
>>> Then, just try to enter your e-mail on a standard wiki in place of your username and you will be authenticated to the first ID (and user_name) having your e-mail.
>>>
>>> The importance of e-mails as a simple way to authenticate on modern sites can't be ignored.
>>
>> It can also expose the fact that someone is registered there with that
>> email address.
>
> I don't understand what you mean and if someone has already entered an email for a username what is the problem?
>
>> In the patch provided, it would also happily show under some
>> circunstances the username associated to an email (not a problem for the
>> internal wiki of a company, where everybody know each other's mail, an
>> issue for public wikis out there).
>
> That is the reason why I was asking this mailing list. But, as I said in a previous and detailed answer to Bergi,
> the patch is very short (a single "if") and thus consequences are not
tremendous.
Go to Special:Contributions and enter the email of an existing user.
I think it may show the user contributions.
> We made some tests on various wikis, and we haven't found yet any circumstance where the username associated to an email is displayed:
> - it can't happen when the authentication works;
> - the only situation that I have found is when you are asking for a new password: then the username associated with the email entered (in place of the username) is displayed in the received email, but it is not a security issue because you are the only person to read your email.
Le 16 févr. 2012 à 22:26, Platonides a écrit :
> On 16/02/12 09:51, Nicolas Brouard INED wrote:
>> Thanks to Platonides for his comment and also to Olivier (the author of the Realnames extension) who told me to forward the following patch to wikitech-l (which I just subscribed to) for advices, comments and critics.
>>
>> I was just wondering if this small patch in User.php (function idFromName) was enough in most cases:
>>
>> $dbr = wfGetDB( DB_SLAVE );
>> $s = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_name' => $nt->getText() ), __METHOD__ );
>>
>> if ( $s === false ) {
>> //Start Patch $result = null;
>> $stwo = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_email' => $nt->getText() ), __METHOD__ );
>> if ( $stwo === false ) {
>> $result = null;
>> }else {
>> $result = $stwo->user_id;
>> }
>> //End patch
>> } else {
>> $result = $s->user_id;
>> }
>
> This is only patching User::idFromName(), which won't be enough.
Sorry, could you detail why it won't be enough!
> You could well be storing the email instead of the username in the page
> history.
I was probably not clear enough: I don't want the email in the page history. Also the Realnames extension (quoted above) is trying to do what you seem suggesting but it is a complex extension which did not work on 1.18 for example.
The proposed patch is also a solution which manages the transition for Wikipedians. Having an authentication with e-mail only is brutal and won't be understood. I like the possibility of having both option with a priority to username for performance also.
But allowing new authors from Arabic or Asian (or Russian or ...) countries (with non Roman characters) to sign new articles in their own language with their own standard, not transliterated, signature will be appreciated if they also have an easy way to authenticate on an English keyboard (pad, smartphone etc.).
> As I said, you should fix it in SpecialUserlogin.php.
What should I fix? Is there something wrong in the proposed patch?
>
>> Then, just try to enter your e-mail on a standard wiki in place of your username and you will be authenticated to the first ID (and user_name) having your e-mail.
>>
>> The importance of e-mails as a simple way to authenticate on modern sites can't be ignored.
>
> It can also expose the fact that someone is registered there with that
> email address.
I don't understand what you mean and if someone has already entered an email for a username what is the problem?
> In the patch provided, it would also happily show under some
> circunstances the username associated to an email (not a problem for the
> internal wiki of a company, where everybody know each other's mail, an
> issue for public wikis out there).
That is the reason why I was asking this mailing list. But, as I said in a previous and detailed answer to Bergi, the patch is very short (a single "if") and thus consequences are not tremendous.
We made some tests on various wikis, and we haven't found yet any circumstance where the username associated to an email is displayed:
- it can't happen when the authentication works;
- the only situation that I have found is when you are asking for a new password: then the username associated with the email entered (in place of the username) is displayed in the received email, but it is not a security issue because you are the only person to read your email.
>
>> If you want to enter your standard username for authentication you can do it too.
>>
>> But if your username is not a Roman but an Arabic, Thai, Japanese etc. username or even a French username with accents and if you decided to have authorship recognized in your own language and not only in a English transliterated way, you can also do it with as standard mediawiki installation. But if you are working with somebody who has an English keyboard only, the copy-paste of your Unicode username may be tedious and you would prefer to enter your e-mail address.
>>
>> The modified Login form could be:
>>
>> Username (or e-mail address): |___________________|
>> Password: |___________________|
>
> Changing the text displayed there is trivial (edit MediaWiki:yourname).
It seems that MediaWiki:Yourname is deprecated. The "(or e-mail address)" sentence must be translated too in all languages (more than 15 for Demopaedia). But I think that it is no a problem neither for us nor for Wikipedia.
Thanks for your comments,
-Nicolas
Hi;
I need a method or workaround to allow users to put contents with
wikitext tables inside template parameters.
The users use Open/Libre-Office MediaWiki export to generate the
wikitext and it is preferable that they do not have to add any extra
wikitext or codes.
This is my testing page:
http://www.eoi.es/wiki/index.php/Usuario:Dvdgmz/pruebas
If I write this the template (well the table) crashes:
{{Test|Contenido=
{| class="wikitable"
| bla
| bla bla
|-
| hola
|hola hola
|}
}}
Using Pipe Escape don't crashes but I don't want to ask users to write
it:
{{Test|Contenido=
{{#!:
{| class="wikitable"
| bla
| bla bla
|-
| hola
|hola hola
|}
}}
}}
I tried to put the Pipe Escape tags inside the template but seems to be
ignored.
David.
Hi,
We are managing Demopaedia.org, a site which aims to give access to old and recent versions of the Multilingual Demographic Dictionary (United Nations since 1958).
About 15 languages are already available in the first (en-i.demopaedia.org/wiki/10) or second edition (en-ii.demopaedia.org/wiki/10).
A secondary aim is to open an encyclopedia (en.demopaedia.org) on the Scientific Study of Population, based on the corpus of terms already validated by the dictionary.
Based on mediawiki (1.16 moving to 1.18), the site is a corporate site. People allowed to edit need to sign under their professional real name. Currently their login name (user_name) is their real name (not a pseudo), sometimes transliterated without accent and in roman characters (but not always, see Михаил Денисенко on http://ru-ii.demopaedia.org/w/index.php?title=90&action=history). Their e-mail address is also mandatory.
I would like to change their login process by entering their e-mail address as a login and having their real name in the history as well as for authorship. The simplest way could be that the user_name, user_real_name and user_email fields are kept intact, but the login process is authenticated by the e-mail address, keeping the same password that they have entered. Thus people could have a unalterable user_name (given by me), a user_real_name which could have accents or whatever and an e-mail address that they could change.
And here is my question, how can I do this and do I need any of the extensions like Realnames, PageHistoryRealnames, ShowRealUsernames etc.
I spent some time googling but didn't find an easy solution.
Many thanks for any hint.
Nicolas
Nicolas Brouard INED
brouard(a)ined.fr
If you develop MediaWiki core, or work on extensions that the Wikimedia
Foundation deploys, you should prepare for your development workflow to
switch on the weekend of March 3rd. Instead of Subversion and the Code
Review tool at mediawiki.org, we will be using Git and Gerrit.
Summary:
https://blog.wikimedia.org/2012/02/15/wikimedia-engineering-moving-from-sub…
Affected projects:
https://www.mediawiki.org/wiki/Git/Conversion#Affected_development_projects
If you work on an extension that the Wikimedia Foundation does not use,
or on a non-MediaWiki project hosted at svn.wikimedia.org, you have more
time to decide. Talk it over with your community and decide whether you
would like to move to Git immediately, move to Git sometime over the
next several months, or move to another hosting provider sometime before
mid-2013. We would like to gradually migrate all projects currently on
Wikimedia's Subversion repository so that we can make all of
svn.wikimedia.org read-only by the middle of 2013, and thus only have to
support one source control infrastructure.
New workflow instructions, open issues, docs, etc.:
https://www.mediawiki.org/wiki/Git
Thank you. (Please feel free to forward this to affected communities.)
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Hi, I tried to use the parser word PAGESIZE that hive the size in Kb of
any page.
Writing
{{PAGESIZE:MyPageName}}
But if I want to use it inside a Template writing
{{PAGESIZE:{{PAGENAME}}}}
it give 0 always as a result.
Is this a bug or issue?
Otherwise, ¿there are other ways to obtain quantitative information
about a page? Would be great obtaining the 'number of characters' or the
'number of words'.
I saw that the search results show the number of words in a page. Is
there a way to obtain it from the pages itself?
Hello all,
We are using MediaWiki to house an internal knowledge base, when an
application/customer is retired from our system we move all the data we
have accumulated from one Namespace to another that is not searched be
default. The issue arises when a application is only partially retired and
the Category (read [[Category:Blah Blah IIS]]) contains both retired and
none retired pages, is it possible to prevent the "retired" namespace from
showing up in this Category? We are using templates for the automagic
filling out of some information and one of them being the
application/customer name so simply removing the Category string is not a
option :(
I am open for ideas and thanks in advance for your time.
Hi,
I have installed Collection extension on my media wiki portal. I get
below error message while I export a book in PDF or want to convert article in PDF.
Can somebody maybe help me with this error?
Erreur du serveur de rendu
Une erreur est survenue sur le serveur de rendu : RuntimeError:
RuntimeError: command failed with returncode 256: ['mw-zip', '-o',
u'/home/pp/cache/c7/c72f9e935581ba89/collection.zip', '-m',
u'/home/pp/cache/c7/c72f9e935581ba89/metabook.json', '--status',
u'qserve://localhost:14311/c72f9e935581ba89:makezip', '--config',
u'http://www.teluq.experience-ipm.ca/ted6210/mediawiki118',
'--template-blacklist', u'MediaWiki:PDF Template Blacklist',
'--template-exclusion-category', u"Exclure lors de l'impression",
'--print-template-prefix', u'Imprimer', '--print-template-pattern',
u'$1/Imprimer', '--username', u'expipm', '--password', '{OMITTED}']
Last Output: 2012-01-15T12:46:53 mwlib.options.warn >> Both
--print-template-pattern and --print-template-prefix (deprecated)
specified. Using --print-template-pattern only. 1% creating nuwiki in
u'/home/pp/cache/c7/c72f9e935581ba89/tmp6usb_Z/nuwiki' Traceback (most recent call last): File
"/home/pp/local/lib/python2.7/site-packages/gevent/greenlet.py", line
402, in run result = self._run(*self.args, **self.kwargs) File
"/home/pp/local/lib/python2.7/site-packages/mwlib/apps/make_nuwiki.py",
line 118, in run api = self.get_api() File
"/home/pp/local/lib/python2.7/site-packages/mwlib/apps/make_nuwiki.py",
line 28, in get_api api.login(self.username, self.password, self.domain) File
"/home/pp/local/lib/python2.7/site-packages/mwlib/net/sapi.py", line
187, in login return self.login(username, password, domain=domain,
lgtoken=res["login"]["token"]) File
"/home/pp/local/lib/python2.7/site-packages/mwlib/net/sapi.py", line
191, in login raise RuntimeError("login failed: %r" % res) RuntimeError: login failed: {u'login': {u'result': u'NotExists'}} <Greenlet at 0x1b48550: <bound method start_fetcher.run of
<mwlib.apps.make_nuwiki.start_fetcher object at 0x1b9ba10>>> failed with RuntimeError removing tmpdir u'/home/pp/cache/c7/c72f9e935581ba89/tmp6usb_Z' memory used: res=16.5 virt=128.6 1% error Traceback (most recent call last): File "/home/pp/local/bin/mw-zip", line 9, in <module> load_entry_point('mwlib==0.13.0', 'console_scripts', 'mw-zip')() File
"/home/pp/local/lib/python2.7/site-packages/mwlib/apps/buildzip.py",
line 151, in main make_zip(output, options, env.metabook, podclient=podclient,
status=status) File
"/home/pp/local/lib/python2.7/site-packages/mwlib/apps/buildzip.py",
line 50, in make_zip make_nuwiki(fsdir, metabook=metabook, options=options,
podclient=podclient, status=status) File
"/home/pp/local/lib/python2.7/site-packages/mwlib/apps/make_nuwiki.py",
line 193, in make_nuwiki pool.join(raise_error=True) File "/home/pp/local/lib/python2.7/site-packages/gevent/pool.py",
line 105, in join raise greenlet.exception RuntimeError: login failed: {u'login': {u'result': u'NotExists'}} in function system, file ./bin/nslave.py, line 63 in function
qaddw, file /home/pp/local/lib/python2.7/site-packages/qs/slave.py, line 66
From: Steve Stevenson <fatmarauder(a)gmail.com>
To: mediawiki-l-request(a)lists.wikimedia.org
Cc:
Date: Mon, 13 Feb 2012 10:51:27 -0500
Subject: Newbee question
After all the installation minefields in apache2 and mysql
installation have been traversed, I cannot get mysql and mediawiki to
connect. It's on localhost, the database is wickedproblems, the prefix
is mct, the user is root, and password is what it is. I can get into
my sql just fine, but the configuration script says it can't find
anything. It's gotta be simple. help?
--
D. E. (Steve) Stevenson, Associate Professor