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!!
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
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!
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
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
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
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/T66597https://phabricator.wikimedia.org/T60881
Thanks for any advice,
DanB
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
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
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