MediaWiki-l December 2015

mediawiki-l@lists.wikimedia.org

68 participants
65 discussions

[Cargo] Duplicate Cargo Rows
by Ed 14 Dec '15

14 Dec '15

Hi everyone, I'm getting duplicate rows in the cargo tables. The instances I have found have the same data with the exception of the _ID. It happens on main tables, tables created for fields with multiple values, and tables created for multiple instances of a template. This is creating cartesian products on calls to #cargo_query. I'm running MySQL with InnoDB tables and the version of cargo I have is 0.10 last updated on 11/22. If there is a way to turn on a trace for the SQL queries or add debug statements in the code I could provide a log. Thoughts? Thanks!!

2 6

Tabbed Panes extension
by Ed Swing 13 Dec '15

13 Dec '15

Is there a good way - or a recommended extension - for Tabbed Panes on a wiki page? I'm looking to have chunks of code in different languages on a page, but I only want one code language visible at a time. Many thanks

5 4

[Templates] Displaying a multi-instance template as a table
by Ed 12 Dec '15

12 Dec '15

Hi everyone, I would like to display a multi-instance template as a table so that the multiple columns are aligned. I'm using Semantic Forms and Cargo. I tried echoing the <tr><td>...</td></tr> from the multi instance template and the <table>...</table> from the main template, but the first <table> is somehow filtered out and doesn't output. <noinclude><pre> {{Main MultiParm= }} </pre></noinclude> <includeonly> ... <table> {{{MultiParm}}} </table> </includeonly> What is the proper way to do it? Thanks!

1 1

[SemanticForms] Form Rendering Order for Embedded Templates
by Ed 12 Dec '15

12 Dec '15

Hi everyone, I have a form that uses 3 templates A, B, and C. Template A is a wrapper that brings B (single instance) and C (multi instance) together. No matter what I do C(m) always show at the top and B at the bottom. Is there a way that I can have B at the top and C(m) at the bottom? BTW, the template presentation is fine and the template calls on the page are fine. The issue is with the input form. This is how the form is defined: <includeonly> {{{for template|A}}} {{{field|bbb|holds template}}} {{{field|ccc|holds template}}} {{{end template}}} {{{for template|B|embed in field=A[bbb]}}} {| class="formtable" ! B1: | {{{field|b1}}} |- ! B2: | {{{field|b2}}} |} {{{end template}}} {{{for template|C|multiple|embed in field=A[ccc]}}} {| class="formtable" |{{{field|c1}}} |{{{field|c2}}} |} {{{end template}}} </includeonly> This is how the input form is rendered: input fields for C[1] input fields for C[2] input fields for C[3] input fields for B This is how I would like it to be rendered: input fields for B input fields for C[1] input fields for C[2] input fields for C[3] Is that possible? Thanks! -Ed

2 2

Best practices for managing multiple large, busy wikis
by Justin Lloyd 11 Dec '15

11 Dec '15

Hi all, I'm not sure where the best place to post this request would be, so I figured I'd start here. If there is a better place, or someone I should contact directly, please let me know. So, I haven't found much in my research about best practices for running multiple large, busy wikis across multiple servers. As such, I am very interested in discussing architectural considerations at the various layers (e.g. web server, database, caching, operating system, hardware, deployment, config management) with someone with first-hand experience in running larger, busier wikis, especially Wikipedia itself. :) I originally posted a thread on this list back in mid-November titled "Troubleshooting stuck Apache requests". I did get some feedback from a few people, for which I am thankful, and fortunately the problem seems to have disappeared, at least for the moment, despite not having done anything. (It's possible our community members may have acted upon a couple of emails we'd sent them regarding certain kinds of pages and templates.) I followed up that list thread with a /r/mediawiki post <https://redd.it/3t2apu> discussing my hardware and software architecture in much more depth, but didn't receive a single reply. Thus, I'm really hoping to find people with the appropriate knowledge and experience who would be willing to have an in-depth conversation on these topics. I'd be happy to have such a discussion on this list, but if you prefer to email me directly for whatever reason, that would be great as well. Thanks! Justin

3 2

OutputPage.php won't render with Cometchat
by David Shaw 10 Dec '15

10 Dec '15

Any idea why this code causes the page to render blank? In MW/includes/OutputPage.php, starting at line 3305 we find: <<<<< public function getHeadLinksArray() { global $wgVersion; $tags = array(); $config = $this->getConfig(); $canonicalUrl = $this->mCanonicalUrl; <<<<< After "$canonicalUrl = $this->mCanonicalUrl;" I inserted these lines per instruction: <<<<< $tags[‘cometchat-footer-code-link’] = Html::element( ‘link’, array( ‘rel’ => ‘stylesheet’, ‘type’ => ‘text/css’, ‘charset’ => ‘utf-8’, ‘href’ => ‘/cometchat/cometchatcss.php’, ) ); $tags[‘cometchat-footer-code-script’] = Html::element( ‘script’, array( ‘type’ => ‘text/javascript’, ‘charset’ => ‘utf-8’, ‘src’ => ‘/cometchat/cometchatjs.php’, ) ); <<<<< And the page won't render. There is an associated call in the Vector template but that is displaying ok. It only blows up when I change OutputPage. The folks at Cometchat say it's an issue with caching. Thank you, David

2 1

All unit tests broken in Ubuntu 15.04
by Daniel Barrett 09 Dec '15

09 Dec '15

MediaWiki unit tests are broken in Ubuntu 15.04. Has anybody else encountered and worked around this problem? $ php phpunit.php PHP Fatal error: Class 'SebastianBergmann\Version' not found in /usr/share/php/PHPUnit/Runner/Version.php on line 74 PHP Stack trace: PHP 1. {main}() /home/wiki/wiki/wiki/tests/phpunit/phpunit.php:0 PHP 2. PHPUnit_Runner_Version::id() /home/wiki/wiki/wiki/tests/phpunit/phpunit.php:108 $ phpunit --version PHPUnit 4.2.6 by Sebastian Bergmann. This is with Mediawiki 1.26.0. Some web searches led me to these tickets from 2014 which are marked as Fixed, but I don't see an explicit workaround in them: https://phabricator.wikimedia.org/T66597 https://phabricator.wikimedia.org/T60881 Thanks for any advice, DanB

1 1

issue with main_page
by Agnese Camellini 09 Dec '15

09 Dec '15

Hello, i'm a newbie to mediawiki development and i'm starting from scratch. I've installed mediawiki in my server (apache 2.4) in the local machine and everything was working fine.. Well then i've messed a little bit up with my virtualhost and documentroot, and i moved the documentroot to my home directory to be able to use eclipse for development BUT then, when i tried to run the mediawiki index page again i got a 404 error: 127.0.0.1 - - [05/Dec/2015:06:16:23 +0100] "GET /project/Wiki/index.php/Main_Page HTTP/1.1" 404 244 "-" "Mozilla/5.0 (X11; Fedora; Linux i686; rv:38.0) Gecko/20100101 Firefox/38.0" The error doesn't explain much at all but from what i've done before i suspect i should get the problem. I've read all the configuration file used in the wiki but i don't understand why this is happening in practice and how to solve it. Can anyone help me out? Thanks in advance. Agnese

2 1

Re: [MediaWiki-l] What PHP version do you use?
by Mickey Feldman 08 Dec '15

08 Dec '15

I'm not sure that what you describe is what I've experienced. We were (are still) running MW 1.21.1 with PHP 5.3.29. Our host upgraded to PHP 5.5 as default, and will soon discontinue support for PHP5.3. MW 1.21 was advertised as "requires PHP5.3 or higher". I took that to mean PHP5.5 would not cause any problems. As soon as the switchover happened, we had a screen full of error messages rather than wiki pages. I set the .htaccess to use PHP 5.3, and we now have a functioning wiki again. However, I have no idea how long it will be before our host dumps PHP 5.3 entirely, so we now have an upgrade forced on us, like it or not. This would not be a such a bad thing if the upgrade process were a little less fraught with uncertainty and room for errors, but it can sometimes be a bit nerve wracking. I see that you mention LTS, and that 1.21 apparently slipped between the LTS versions. Too bad for us. My recollection is that we upgraded from 1.19 to 1.21 for the same reason - PHP updated and the version we had no longer worked. And it looks like we are (somewhat counter-intuitively) better off upgrading not to the current 1.26, but to 1.23, which is an LTS version. > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Dec 2015 17:27:14 -0700 > From: Bryan Davis <bd808(a)wikimedia.org> > To: MediaWiki announcements and site admin list > <mediawiki-l(a)lists.wikimedia.org> > Subject: Re: [MediaWiki-l] MediaWiki-l Digest, Vol 147, Issue 9 > Message-ID: > <CAGrKmBLWn7t0jwrRhudkdTZQpXZjFo7MquMm1zbEQBhbQAOmSw(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Mon, Dec 7, 2015 at 3:39 PM, Mickey Feldman <mfeldman(a)vigil.com> wrote: >> One more vote for this. >> >> Upgrades have generally caused us much pain with little or no obvious >> benefit. In our particular case, Mediawiki works well enough as is. Until >> our host decides to update PHP forcing us to upgrade Mediawiki, and >> discovering that it no longer works. >> >> While there may be things we might like improved, we can't afford to >> dedicate a full time Wikimedia guru to becoming expert in the hidden corners >> of the code and keeping up with every change that might have some unexpected >> side effect. >> >> I realize that some of the changes are security fixes, and a Good Thing, but >> I suspect these are in the minority. Our wiki is not public, so we could >> probably get away with being a bit more lax about that, but when Mediawiki >> is suddenly no longer compatible with php version-whatever, we have no >> choice but to upgrade. > > I've seen a couple of comments similar to this one that seem to have > the causal chain reversed so I thought I would try to clarify. > > If and when MediaWiki updates its minimum required PHP version nothing > will change for existing MediaWiki deployments. The change will only > effect new MediaWiki releases. If you are happily running MediaWiki > 1.23 or similar on your wiki nothing at all will change. > > If and when your hosting provider updates their installed PHP version > nothing will change for existing MediaWiki deployments. PHP generally > goes out if its way to maintain backwards compatibility with running > software designed for older versions of the PHP runtime. In the few > cases that there are backwards compatibility breaking changes it is > very likely that MediaWiki has already been patched to deal with them > unless you are running a version of MediaWiki that predates the > initial release of the new PHP version your provider has upgraded to. > In that case if you are running a supported LTS version of MediaWiki > you should only need to upgrade to the latest point version. If you > are running something older than a supported LTS release, yes you may > have to upgrade. > > Bryan > -- ------------------------- M. Feldman Vigil Health Solutions, Inc. 2102 - 4464 Markham Street Victoria, BC Canada V8Z 7X8 Tel: 250-383-6900

2 1

Re: [MediaWiki-l] What PHP version do you use?
by Ray Paseur 08 Dec '15

08 Dec '15

Greetings, colleagues. I took the PHP survey, so that part is done, but I'd like to weigh in on some of the comments I've seen in this thread. I have read all of your comments, and I agree with everything written here. First and foremost, thanks to all who support the software and the community. This mailing list gives me a welcome word every day. I believe that using the latest software is almost always a good idea. We are going to upgrade eventually - why deny ourselves the benefits of the latest software by putting off the upgrades? The only argument in favor of delay would be a breaking change, and this is something that the authors of the software must publicize. Second, I'm very empathetic to anyone who experiences troubles installing products or doing upgrades. In the PHP world, we have worked hard to make the major systems (WordPress, Joomla, Drupal, Laravel, etc.,) easy to install and upgrade, and to clearly identify breaking changes from one version to the next. It's almost axiomatic that breaking changes may not occur from one release to the next. The PHP-FIG (Framework Interoperability Group) has been instrumental in guiding our thinking on this point. PHP version 5, since PHP 5.3 has been pretty stable. I have not experienced a breaking change at all, up through PHP 5.6+. I have experienced deprecation warnings (mostly related to the antiquated MySQL extension) but these warnings can be suppressed, allowing time for developers to change to a supported database extension. This model of "deprecation before abandonment" has proved very useful for those of us who want to be up-to-date, and has given ample notice to those of us who want to remain on old software. PHP version 7 (there is no version 6) introduces breaking changes with the removal of previously deprecated features. But it's also much faster and has better language support for some modern design and coding techniques. That said, it seems logical to me that future releases of MW should "just work" with PHP 7. There may be a good bit of work between "should" and "just works" but this seems like an enticing objective. Some MW Extensions use PHP code that is PHP release-dependent. Finding and catching these instances before installing a breaking change is not easy. For example, consider a PHP 5.3 platform that needs the EmbedVideo extension. There is a gotcha - EmbedVideo uses a PHP array notation that is not supported in PHP 5.3. This is something that Composer is supposed to help us with. Throughout the PHP community, the universal advice is "If you're not using Composer yet, start using Composer!" Though I resisted that advice for a couple of years, I've found Composer to be one of those things like Git version control. It can save you much more than it costs you. So I would encourage anyone reading this thread to consider Composer and embrace it if possible. Perhaps greater publicity about Composer should issue forth from the Foundation? Perhaps there should be a community-standards requirement to use Composer to publish new or updated versions of MS Extensions? And on a slight tangent, but related... A native and naked installation of MediaWiki should not be an inviting hacker target. We should be able to download and install the software without having to think too much. Then we should be able to extend update rights to our community according to our community's needs. "Built by devs for devs" is so 2005. Less configuration and more convention is a better paradigm for our future. Again, thanks to all. I hope to see you in San Francisco, Ray Paseur Armedia, LLC

7 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l December 2015