Hi all,
Tomorrow we will be issuing a security release to all supported
branches of MediaWiki.
The new releases will be:
1.25.3
1.24.4
1.23.11
Fixes will be available in these respective release branches, the
unreleased 1.26.x branch, and master. Tarballs will be available
for the above mentioned point releases as well.
This security release will encompass core only, no bundled extensions
are affected.
-Chad
Hi,
Sorry if this message does show up in the original thread (I subscribed
to this ml after the original message was posted)
It's always extremely complex to debug relevancy problems and it depends
on many factors.
It looks like the word "share" is quite common in your corpus so it is
possible that your problem is due to the "all" field.
The all field is a performance hack that allows cirrus to query a single
field (see https://phabricator.wikimedia.org/T107666) but it has some
drawbacks with common words.
Could you try to add &cirrusUseAllFields=no to the search results URL
and see if it affects the ranking?
The URL should be :
https://mediawiki/w/index.php?title=Special%3ASearch&profile=default&search…
Note that if you use the all field :
$wgCirrusSearchAllFields = array( 'build' => true, 'use' => true );
and if you change weights in wgCirrusSearchWeights you'll have to
re-index your data.
Another test you could try is to disable rescore, rescore is a feature
that will reorder the top-N results (8192 by default). You can limit the
rescore impact by adding the following URL parameters
&cirrusFunctionWindow=1&cirrusPhraseWindow=1 .
If nothing helps could you share the result of
-
https://mediawiki/w/index.php?title=Special%3ASearch&profile=default&search…
and
-
https://mediawiki/w/index.php?title=Special%3ASearch&profile=default&search…
Thanks,
David
> From: *Daniel Barrett* <danb(a)cimpress.com <mailto:danb@cimpress.com>>
> Date: Mon, Oct 12, 2015 at 9:57 AM
> Subject: [MediaWiki-l] Help debugging CirrusSearch problems?
> To: MediaWiki announcements and site admin list
> <mediawiki-l(a)lists.wikimedia.org <mailto:mediawiki-l@lists.wikimedia.org>>
>
>
> We installed CirrusSearch recently to replace Lucene, and the results
> it returns from wiki searches seem wildly irrelevant at times.
>
> For example, our wiki (200,000+ titles) has a number of pages that
> include the word "share" in the title. But when I search for "share"
> using CirrusSearch, none of these pages come up in the top 100 hits.
> The first one is hit #120. The #1 hit has "share" only in the names of
> two categories.
>
> As a pathological example, I created a wiki page named "Share share
> share share share" and filled it with the word "share" over and over.
> When I search the wiki for "share", my page appears as hit number
> 750! (If I search for "share share", my page comes up first.)
>
> We're using the default CirrusSearch.php configuration except for the
> following overrides in LocalSettings.php:
>
> $wgCirrusSearchWeights = array(
> 'title' => 20, // default 20
> 'redirect' => 15, // default 15
> 'category' => 8, // default 8
> 'heading' => 4, // default 5
> 'opening_text' => 3, // default 3
> 'text' => 1, // default 1
> 'auxiliary_text' => 0.5, // default 0.5
> 'file_text' => 0.5, // default 0.5
> );
>
> // Prevent some custom namespaces from showing in search results
> $wgCirrusSearchNamespaceWeights = array(
> NS_VP_1 => 0,
> NS_VP_2 => 0,
> NS_VP_3 => 0,
> );
>
> $wgCirrusSearchDefaultNamespaceWeight = 0.5;
> $wgCirrusSearchPowerSpecialRandom = false;
>
> Any advice on how to debug these weird search results?
> Thank you very much,
> DanB
>
>
> _______________________________________________
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
Hi,
I've got a few MediaWiki installations on a my FreeBSD 10.1 / Apache
2.4.16 / PHP 5.6.14 server. The home pages of these sites are OK, but
when you click the "Log In" link, the style sheet fails to load, and
in the web server error log I see:
AH00052: child pid 32320 exit signal Segmentation fault (11)
The login page is still functional, but when I log in and go to edit a
Wiki page, I get the same segmentation fault while loading the style
sheet.
I found this page:
https://www.mediawiki.org/wiki/Manual:Errors_and_symptoms
which mentions a problem with pcre.backtrack_limit, but my
installation has that set to 1000000 so I'm guessing that's not the
case (and it seems weird that such a setting could cause a segfault
anyhow).
Is this a known issue? Is there an easy fix? Would it be helpful to
provide xhprof output? (I didn't want to go through the hassle of
setting that up until I was sure this wasn't a known issue.)
Thanks for any help you can give!
--
Tim Gustafson
Technical Lead, Baskin School of Engineering
tjg(a)ucsc.edu
831-459-5354
Baskin Engineering, Room 313A
We installed CirrusSearch recently to replace Lucene, and the results it returns from wiki searches seem wildly irrelevant at times.
For example, our wiki (200,000+ titles) has a number of pages that include the word "share" in the title. But when I search for "share" using CirrusSearch, none of these pages come up in the top 100 hits. The first one is hit #120. The #1 hit has "share" only in the names of two categories.
As a pathological example, I created a wiki page named "Share share share share share" and filled it with the word "share" over and over. When I search the wiki for "share", my page appears as hit number 750! (If I search for "share share", my page comes up first.)
We're using the default CirrusSearch.php configuration except for the following overrides in LocalSettings.php:
$wgCirrusSearchWeights = array(
'title' => 20, // default 20
'redirect' => 15, // default 15
'category' => 8, // default 8
'heading' => 4, // default 5
'opening_text' => 3, // default 3
'text' => 1, // default 1
'auxiliary_text' => 0.5, // default 0.5
'file_text' => 0.5, // default 0.5
);
// Prevent some custom namespaces from showing in search results
$wgCirrusSearchNamespaceWeights = array(
NS_VP_1 => 0,
NS_VP_2 => 0,
NS_VP_3 => 0,
);
$wgCirrusSearchDefaultNamespaceWeight = 0.5;
$wgCirrusSearchPowerSpecialRandom = false;
Any advice on how to debug these weird search results?
Thank you very much,
DanB
I'm having issues with saving Common.js, when I select save I get
This webpage is not available
ERR_CONNECTION_RESET
When Modifying the Common.css file I don't have any issues at all.
Has anyone seen this issue?
Thanks!
Phil
On Oct 11, 2015 2:46 PM, "Ilya Korniyko" <intracer(a)gmail.com> wrote:
>
> Is there a repository of tools, research projects etc related to wikimedia
> projects?
> I think it's a good idea to have one.
> I even dream about https://www.mediawiki.org/wiki/Community_Tech_team
> taking lead and responsibility for maintaining it.
>
> However I'm going to start working on it in background. Is there a specific
> existing page or portal that I can improve, or where should be better to
> create it, if it does not exist?
>
> Regards,
> Ilya Korniiko / [[User:Ilya]]
There's the research hub on meta at
https://meta.wikimedia.org/wiki/Research:Index
For tools, explore https://www.wikidata.org/wiki/Q6584911 the "Tools"
page at various wikis collecting a profusion of links.
I particularly like Atlasowa's collection of notes about a specific
subset at https://de.wikipedia.org/wiki/Benutzer:Atlasowa/edit_history_visualization
and the deluge of awesome at http://seealso.org/
plus the hay's directory that Magnus and Purodha linked.
And possibly more, depending on what specifically you're thinking of.
hello. i am making tatar script converter. i have made tests now and
it has become easier to work. i am saying about test in
\mediawiki\tests\phpunit\languages\classes\ . i am working in windows.
i open command line window in \mediawiki\tests\phpunit\ , and type
"chcp 65001" and "C:\xampp\php\php-cgi.exe phpunit.php languages", and
test runs, but there are some disadvantages:
1) i count till 40 before test completes and my test is only a little
dot among nearly 1000 dots here.
2) and some letters are not shown (only squares, ie they have not
fonts in lucida console font).
i would like if somebody writes a script to run my test from browser
window. i think i can make such test.php, but i cannot reuse the
already made class for tatar language, can only copy tests between the
class and my script manually.
3) and also i will need to make diff as it works in the test.
i think i can do that after some time of learning of the test scripts,
but maybe somebody can make that easily.
( https://phabricator.wikimedia.org/T114878 )
Wow. I've been running Mediawiki for a couple of years and just never looked at that. Probably is the problem. I looked for instructions on use but there's not much. Any suggestions on how to find info on how to use that page. Since I've never used it, there may be other things that will work better.Thanks John
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message --------
From: billinghurst <billinghurstwiki(a)gmail.com>
Date: 10/05/2015 4:32 PM (GMT-06:00)
To: MediaWiki announcements and site admin list <mediawiki-l(a)lists.wikimedia.org>
Subject: Re: [MediaWiki-l] Problem with syntax
Have you checked it via [[Special:ExpandTemplates]]?
For whatever reason, FULLPAGENAME is not evaluating.
On Tue, 6 Oct 2015 02:38 John Foster <jfoster81747(a)gmail.com> wrote:
> I,m seeing an error, at least it seems to be one when my Mediawiki site is
> performing this action
>
> {{/box-header|Categories|{{FULLPAGENAME}}/Categories|Purge=<i></i>}}
>
> it is calling for an actual Template:/Categories
> rather than what I suppose to be the actual call of
> Categories:WhateverTheNameIs/Categories
>
> I'm not even sure if my question is valid. I'm going by the fact that
> Wikipedia has this same syntax in a few places and it calls up something
> other than a non-existant template.
>
> ANY help is appreciated
> Thanks!
> John
> _______________________________________________
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l