tl;dr
discussion start "How/whether MediaWiki could use ZendOptimizuerPlus"
Since a short time
* ZendOptimizerPlus (Opcode cache; source [4])
is under PHP license and planned to be integrated in PHP 5.5.
The former restrictions of this program (closed-source etc.) appear to
be gone,
so I'd like to open discussions how MediaWIki could be adapted to make
use of it.
Because APC does not work with PHP 5.4, (or APC is beta for PHP 5.4),
I wanted to make use of the new ZendOptimizer with PHP 5.4 ...
* but MediaWiki apparently does not work with that. ( CACHE_ACCEL )
*Who knows more ?*
and could help to get the Zend cache working and APC replaced ?
Or is this not possible, because Zend is only for opcode caching ??
MediaWiki pages [1,2] should be /*revisited *//*and updated*/ according
to current knowledge and version /*by cache experts*/
Tom
[1] https://www.mediawiki.org/wiki/Manual:Cache
[2]
https://meta.wikimedia.org/wiki/PHP_caching_and_optimization#PHPA_or_Zend_O…
[3] https://wiki.php.net/rfc/optimizerplus
[4] https://github.com/zend-dev/ZendOptimizerPlus
[3}] says: "This RFC proposes integrating the Zend Optimizer+ component
into the Open Source PHP distribution. Optimizer+ is the fastest opcode
cache available for PHP, and presently supports PHP 5.2 through 5.5,
with public builds available for PHP 5.2 through 5.4. It was originally
developed in 1998 and was the first opcode cache available for PHP.
Presently, Optimizer+ is a closed-source, yet free-for-use component. As
a part of implementing this RFC - Zend will make the source code of
Optimizer+ available under the PHP License, so that it can become an
integrated part of PHP with no strings attached. Once that happens,
community contribution would be welcome exactly like it is with any
other PHP component, and the component will be governed by the exact
same processes (RFC et. al) that are employed by the PHP community."
Hello!
This is your weekly preview of higher-risk or general "you should be
aware of" items for the slew of deployments coming in the near term.
== During the week of March 25th ==
* Wikidata Phase 2 is going to test2 on Monday
** Then on Wednesday, if all goes well, it is going to about 10% of
projects' page views, these wikis:
*** it, he, hu, ru, tr, uk, uz, hr, bs, sr, sh
* AFTv5 is taking a longer window than normal on Tuesday (9am - 1pm
Pacific)
* Lightning Deploys on M/T/W/Th at 4pm! :)
Full schedule:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_March_25th
Best,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Tim rolled back wmf12 after a nasty bug last night:
https://bugzilla.wikimedia.org/show_bug.cgi?id=46397
Our fix we deployed to test2 didn't fix it:
https://gerrit.wikimedia.org/r/#/c/55086/
We're still diagnosing/etc.
So, we're staying on wmf11 for now (except on test2, which is running
the broken fix in wmf12).
Please ping me or Robla with any questions.
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hey All
I have someone helping me add translation done by Translators Without
Borders of key medical articles. An issue that slows the work is that
many languages require CAPTCHA to save the edits. Is their anyway
around this (ie to get an account confirmed in all languages)?
Project is here
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Medicine/Translation_tas…
--
James Heilman
MD, CCFP-EM, Wikipedian
The Wikipedia Open Textbook of Medicine
www.opentextbookofmedicine.com
Hi,
Just a quick reminder that we'll be holding IRC office hours in about
50 minutes. If you have questions about how to use Lua, or issues
you'd like help with, join us in #wikimedia-office on Freenode.
More information about how to connect to IRC is available at
https://meta.wikimedia.org/wiki/IRC_office_hours
On Wed, Mar 13, 2013 at 7:38 PM, Guillaume Paumier
<gpaumier(a)wikimedia.org> wrote:
> Greetings,
>
> As you might have seen on the Wikimedia tech blog (article included below)
> or the tech ambassadors list, a new functionality called "Lua" is being
> enabled on all Wikimedia sites today. Lua is a scripting language that
> enables Wikimedia editors to write faster and more powerful MediaWiki
> templates.
>
> If you have questions about how to convert existing templates to Lua (or how
> to create new ones), we'll be holding two support sessions on IRC next week:
> one on Wednesday (for Oceania, Asia & America) and one on Friday (for
> Europe, Africa & America); see m:IRC office hours for details. If you can't
> make it, you can also get help at mw:Talk:Lua scripting.
>
> If you'd like to learn about this kind of events earlier in advance,
> consider becoming a Tech ambassador by subscribing to the mailing list.
>
>
>
> =================================
>
> New Lua templates bring faster, more flexible pages to your wiki
>
> Posted by Sumana Harihareswara on March 11th, 2013
>
> Starting Wednesday, March 13th, you’ll be able to make wiki pages even more
> useful, no matter what language you speak: we’re adding Lua as a templating
> language. This will make it easier for you to create and change infoboxes,
> tables, and other useful MediaWiki templates. We’ve already started to
> deploy Scribunto (the MediaWiki extension that enables this); it’s on
> several of the sites, including English Wikipedia, right now.
>
> You’ll find this useful for performing more complex tasks for which
> templates are too complex or slow — common examples include numeric
> computations, string manipulation and parsing, and decision trees. Even if
> you don’t write templates, you’ll enjoy seeing pages load faster and with
> more interesting ways to present information.
>
> Background
>
> MediaWiki developers introduced templates and parser functions years ago to
> allow end-users of MediaWiki to replicate content easily and build tools
> using basic logic. Along the way, we found that we were turning wikitext
> into a limited programming language. Complex templates have caused
> performance issues and bottlenecks, and it’s difficult for users to write
> and understand templates. Therefore, the Lua scripting project aims to make
> it possible for MediaWiki end-users to use a proper scripting language that
> will be more powerful and efficient than ad-hoc, parser functions-based
> logic. The example of Lua’s use in World of Warcraft is promising; even
> novices with no programming experience have been able to make large changes
> to their graphical experiences by quickly learning some Lua.
>
> Lua on your wiki
>
> As of March 13th, you’ll be able to use Lua on your home wiki (if it’s not
> already enabled). Lua code can be embedded into wiki templates by employing
> the {{#invoke:}} parser function provided by the Scribunto MediaWiki
> extension. The Lua source code is stored in pages called modules (e.g.,
> Module:Bananas). These individual modules are then invoked on template
> pages. The example: Template:Lua hello world uses the code
> {{#invoke:Bananas|hello}} to print the text “Hello, world!”. So, if you
> start seeing edits in the Module namespace, that’s what’s going on.
>
> Getting started
>
> Check out the basic “hello, world!” instructions, then look at Brad Jorsch’s
> short presentation for a basic example of how to convert a wikitext template
> into a Lua module. After that, try Tim Starling’s tutorial.
>
> To help you preview and test a converted template, try
> Special:TemplateSandbox on your wiki. With it, you can preview a page using
> sandboxed versions of templates and modules, allowing for easy testing
> before you make the sandbox code live.
>
> Where to start? If you use pywikipedia, try parsercountfunction.py by
> Bináris, which helps you find wikitext templates that currently parse slowly
> and thus would be worth converting to Lua. Try fulfilling open requests for
> conversion on English Wikipedia, possibly using Anomie’s Greasemonkey script
> to help you see the performance gains. On English Wikipedia, some of the
> templates have already been converted — feel free to reuse them on your
> wiki.
>
> The Lua hub on mediawiki.org has more information; please add to it. And
> enjoy your faster, more flexible templates!
>
> Sumana Harihareswara, Engineering Community Manager
>
> =================================
>
>
> --
> Guillaume Paumier
> Technical Communications Manager — Wikimedia Foundation
> https://donate.wikimedia.org
--
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation
https://donate.wikimedia.org
I suggest renaming of pages
1. "Cross-site scripting" => "Cross-site scripting (XSS, XSSI)"
https://www.mediawiki.org/wiki/Cross-site_scripting
2. "Cross-site request forgery" => "Cross-site request forgery (CSRF)"
https://www.mediawiki.org/wiki/Cross-site_request_forgery
Before doing that I want to be sure that you accept it. To you support
my initiative.
Another page, part of the MW Security Guide, has already (only) XSS in
its name
DOM-based_XSS
https://www.mediawiki.org/wiki/DOM-based_XSS
See https://www.mediawiki.org/wiki/MSG .
Rationale:
The change would have the advantages, that the section and pages in the
MediaWiki Security Guide (MSG) have the same, more detailed page title.
And that the commonly used abbrevations are then forming part of this title.
I am asking, because these pages are so important and I don't want to be
rude simply changing it.
Can you confirm you allow me that change?
T.
Right now a lot of our links to generated documentation on php classes are
manually copied.
One of the reasons for this seems to be how badly Doxygen handles the
anchors to sections on individual methods.
Instead of simply using the method name it generates a md5 hash of a
signature that is impossible to know simply with a class and method name.
Meaning we can't simply have a template to link to documentation.
However Doxygen exports a tagfile that includes a list of classes, their
methods, and the anchors used for their links.
This is currently at: (*warning* large file)
https://doc.wikimedia.org/mediawiki-core/master/php/html/tagfile.xml
What does everyone think of making it so that when Jenkins generates this
documentation. It processes the tagfile, splits it up and converts it into
multiple lua tables, then uses the API to update a Module: page on
mediawiki.org.
This way templates can have some Lua code that uses that data to create
links with something like:
local classes = mw.loadData( 'DoxygenTags mediawiki-core class' )
...
function p.methodLink(className, methodName)
local class = classes[className]
...
local method = members.function[methodName]
...
return "https://doc.wikimedia.org/mediawiki-core/master/php/html/" +
method.anchorfile + "#" + method.anchor
end
...
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
I've noticed that sometimes Jenkins +1s changes and other times it +2s them
(for Verified, that is). Is there any specific pattern to this? It's not a
problem or anything; I'm just curious. I feel like it was explained back
when the system was changed to +1 and +2 but I forget and can't seem to
find anything in the archives.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo(a)gmail.com
Hi,
This is a friendly reminder to everyone about the preferred way to
link to bugs in your commit messages. When you include them as
part of the footer, they are indexed and are thus searchable. For
example:
"""
Fixing some weird bug
More explanation
Blah blah blah.
Bug: 1234
Change-Id: Ia90.....
"""
So when you do this, you're able to search for "bug:1234" via Gerrit.
By doing this, you're also removing it from the first line (which was
our old habit, mostly from SVN days), providing you more space to
be descriptive in that first line.
-Chad