Extension talk:SearchLog

Is their a way to sort the searches simply by newest (top) to oldest (bottom) ? ... thanks. Iloveemeryville 15:11, 1 August 2009 (UTC)

---

I get the error:

Fatal error: Call to a member function getID() on a non-object in /home/[red]/includes/SkinTemplate.php on line 311

After installing and running the script on MW 1.7.1 at http://arborwiki.org/city/Special:SearchLog. Not sure if this is an extension bug, or something messed up on my end.

Unfortunately it seems that this extension has a bug which is preventing it from working on 1.7.x and earlier. I haven't been able to figure out a solution so far, I'll let you know if I figure it out. --Nad 11:48, 28 May 2007 (UTC)

Restricting access to the page

What code would be added to the extension file in order to restrict access to the Special:SearchLog page to bureaucrats only? --Porplemontage 02:02, 29 May 2007 (UTC)

I've added a global in the latest version $wgSearchLogGroup which can be set to a group to restrict access --Nad 05:42, 29 May 2007 (UTC)

I've set this global in my setup, but Special:SearchLog is still visible to everybody. It should be something like $wgSearchLogGroup = 'bureaucrat'; # restrict viewing to a particular group by setting this, yes? I can't see anything else that I might be doing incorrectly. --Emufarmers 12:25, 28 June 2007 (UTC)

The global should be set after the include line in yout localsettings, not changing the actual script, but it still should have worked... I'll look in to it. --Nad 20:46, 28 June 2007 (UTC)

The global is in the script itself by default, but setting it in LocalSettings.php after the include didn't help either. --Emufarmers 12:19, 29 June 2007 (UTC)

Have you been able to find where the problem is with access not being limited by group? I love the extension, but I really need the search data to be private! (And the readout is so nice that I'd rather not give it up.) Emufarmers 12:53, 2 July 2007 (UTC)

"bureaucrat" didn't work for me, only "sysop" worked, if sysop doesn't work for you either, let me know what version mediawiki version you're running so I can check it out in more detail? --Nad 00:25, 3 July 2007 (UTC)

I've tried setting it to "sysop" both in the extension file and in LocalSettings.php, and neither works. I'm on 1.10.0. If it only works for you when it's set as "sysop," then you might want to look at how other extensions handle group access control—every other extension I've used where there's a group access restriction has worked for any group, even a custom one (renameuser, CheckUser, et cetera). I'm no good with coding, though, so I probably can't help you further. I can give you a link to my site in private (if you enable wiki emailing here, or whatever) if you think it would help, though. Emufarmers 13:26, 4 July 2007 (UTC)

The problem is I don't really know what I can change to try and fix it, all my special page extensions just use a template which is all the normal special page code. I have some other special pages which don't show up at all in some wiki's but do in others and it seems to be independent of the mediawiki version! I'll look into it some more soon and see if I can figure it out. --Nad 21:02, 4 July 2007 (UTC)

Me again: Have you looked at what sort of authentication mechanism other extensions use? For instance, I'm looking at CheckUser, and it seems to have some auth-looking stuff that yours doesn't have, like this:

		if( !$wgUser->isAllowed( 'checkuser' ) ) {
			$wgOut->permissionRequired( 'checkuser' );
			return;
		}

I haven't been able to add that in and have it work, but I know little about coding, so I can only hope you'll be able to. --Emufarmers 14:39, 20 July 2007 (UTC)

I've tried playing with this code (with 'Sysop') and cannot get it to work. Any luck yet? Mguentz 15:34, 30 August 2007 (UTC)

Thalion 21:01, 26 October 2011 (UTC) The above code will work if you add $wgUser to the "global" line that is above it- otherwise it can't find that variable.

It works fine on my wiki's showing up in the sysop-only section of special-pages list, but one thing I noticed is that the group name is case-senstive and must be lower-case or it won't show up at all. --Nad 20:34, 30 August 2007 (UTC)

This is actually something that something that has occurred with a couple of extensions that I've installed. I've only only wanted to give them to sysop and higher, but I've never been able to figure it out/reverse engineer other code. I still actually don't understand what needs to be done. I'm running MW 1.11 but whatever has worked in the past, seems to be working in 1.11. As someone who's never made an extension, and doesn't know PHP, can you please offer some advice? Thanks.

- Marc 10/01/07 7:46PM EST.

I think $wgSearchLogGroup is not a group but the user right required to view the SearchLog page. See the constructor of SpecialPage Manual:Special pages#Constructor - Patrick 12:24, 4 April 2008 (UTC)

Thalion 21:01, 26 October 2011 (UTC) I made a number of tweaks to this extension that fix several problems here. The changes I made are:

// In SearchLog.php, right below the "require_once "$IP/includes/SpecialPage.php"; add these lines: so that SearchLog gets added to Special:SpecialPages,
// into the "logs" area.
$wgSpecialPages['SearchLog'] = 'Searchlog';
$wgSpecialPageGroups['SearchLog'] = 'changes'; 

// (As Marc pointed out above) the $wgSearchLogGroup variable above is not being used as a group, it is being used as a user right.
// So I just decided to use 'viewsearchlog' to be the user right involved everywhere.
// That means in the Constructor for classSpecialSearchLog in SearchLog.php I changed it to read like this:
function SpecialSearchLog() {
    SpecialPage::SpecialPage('SearchLog','viewsearchlog');
}

// And in function execute() : 
// Add "$wgUser" to the "global" line, and add the if below so you get the following for that line and the ones right below it:
                global $wgOut,$wgUser,$wgSearchLogFile,$wgSearchLogEntireLog,$wgSearchLogReportHeading,$wgSearchLogDateFormat,$wgRequest;
                $this->setHeaders();
                // Only people with 'viewsearchlog' right get to see this page
                if ( !$wgUser->isAllowed( 'viewsearchlog' ) ) {  
                        $wgOut->permissionRequired( 'viewsearchlog' );
                        return;
                } 

// And then, in LocalSettings.php, add this lines:
$wgGroupPermissions['sysop']['viewsearchlog'] = true;   // Let Administrators view the Special:SearchLog page

Sorting in Search Log

I see that in the "working example" there is possibility of sorting on keywords or usage count. In the extension I've downloaded, however, there is no sorting. It is a build-in feature of MW 1.10 (I'm using 1.8.3) or some other extension I'm not aware of? -- Khitrenovich 10:05, 15 July 2007 (UTC)

There are some good Javascript sortable table components, we've been using the one in this example, but will soon be changing to JavascriptToolbox because it also allows filtering like a spreadsheet. --Nad 06:37, 16 July 2007 (UTC)

I'm trying to install one you are currently using, but it does not work for some reason. Hope I'll manage to do it later... Thank you for the links, anyway! Khitrenovich 14:16, 25 July 2007 (UTC)

You can use Extension:Javascript to load the script, or set $allowUserJS and put it in MediaWiki:Common.js --Nad 21:48, 25 July 2007 (UTC)

Nice extension, thanks! Storing JS files in filesystem looks much more convenient way for me. I have some notes, however: [1] The extension (incorrectly) assumes that the Wiki directory is located under document root. I'm not good enough in PHP programming to fix this in generic way... [2] The list of JS files in extension description breaks nesting alignment in older Wiki versions (ex. 1.8.3), since Version page is not table-based there. Khitrenovich 08:48, 26 July 2007 (UTC)

Found a problem with sortable tables. It may be good idea to mention that the table must have "id" attribute... :) Khitrenovich 08:55, 26 July 2007 (UTC)

Sortable search results

Is there an extension that sorts the search results by namespace, date, user, etc? -Eep² 04:15, 29 July 2007 (UTC)

Notice Error

I got this error for every single line in the table, any Idea how to fix this ? --Bricel 20:22, 20 November 2007 (UTC)

Undefined index: workspace in /home/vhost1/www.optitex.com/vroot/html/Help/en/extensions/SearchLog/SearchLog.php on line 87

Sorry about the delay I missed this post, should be fixed now. --Nad 21:39, 8 December 2007 (UTC)

No months in Linux

A strange problem. i checked this extension on Winodws machine with MW 1.11. All is fine. Then i deployed it on my actual wiki on linux. It's working fine except that select option doesn't show any months. There's only one value "Entire Log". the log has data for OCt,Nov and Dec, which is correctly shown in Windows. But in Linux, that's not coming. new words are added to the log, but no month-wise splitting. plz help Was the log file new, or was it copied over from a development server where several months of search logs had already been collated? --Zven 00:24, 9 February 2008 (UTC)

Problem with UTF-8

The search log incorrectly displays UTF-8 characters (as black diamonds with question sign inside)
And the second thing: the empty log file must be created manually during installation (may be this is my server configuration problem, but it did not work until I created it).

The UTF-8 rendering should be resolved in version 1.0.7. The issue is that a search can involve unicode UTF-8 characters which automatically get converted to their character within the browser. Escaping these characters with the check box option display raw unicode creates a table where the actual underlying UTF-8 code may have been entered in the search. There is another situation where a person could copy a rendered character in a search box, in this case the rendered character is what is searched on, not the UTF-8 code e.g. Searching on '�' by putting the � character on the copy clipboard then you should not be translating to the searches underlying UTF-8 character set because '�' is what the search actually was.

Yes the log file needs to be created and given correct permissions for the extension to start logging searches to file --Zven 01:01, 9 February 2008 (UTC)

Still not working: I enter russian text in Search field and press "Go". After that I see new line of black diamonds in SearchLog. PS. Black diamonds I see in FireFox, in IE I see empty squares :-)

Hmm, sounds loke the character set is not supported --Zven 18:03, 12 February 2008 (UTC)

By the way, http://www.organicdesign.co.nz/Special:SearchLog does not work: I see empty page --Konstbel 15:42, 12 February 2008 (UTC)

Sorry, I think the Specialpage on OD might be configured for Sysops only. --Zven 18:03, 12 February 2008 (UTC)

Special:SearchLog

The column Search phrase shows a string combination which seems to be the result of: $type,$phrase (with a comma in-between). Thus the resulting internal link for the search phrase spam using the article button is

[[go,spam]]

I wonder, if this was intended. The reason might be, that the user names in our wiki contain a comma. Could this be fixed? I'd also suggest two separate columns for $type and $phrase, which is useful in a sortable table. --ThT 16:40, 30 April 2008 (UTC)

SOLVED: æ,ø å is incompatible

The extension searchlog is not compatible with the norwegian symbols æ,ø,å. If a search is made on a word containing one of the caracters, it corrupts the log and it shows up empty on the special page. If I manually change the caracters in the log on the server, the log reappears OK. Is there a quick fix for this?

Solution

Change line 90 in SearcLog.php

- $i = strtolower(trim($phrase));
+ $i = mb_strtolower(trim($phrase),"UTF-8");

Does not work for me. Error.

Fatal error: Call to undefined function mb_strtolower() in C:\Inetpub\wwwroot\mediawiki\extensions\SearchLog\SearchLog.php on line 90

Mitjad 14:01, 27 March 2009 (UTC)

Install php-mbstring (the mbstring library for php)

Cloud

Is there an easy way to generate a cloud to add to the MainPage? --62.128.18.198 09:08, 1 October 2008 (UTC)

Error

After a day or so of searching, my search log has wiped itself and I get a 500 error when I try to get to the SearchLog page. New searches aren't being added to the log either anymore. I'm using MW 1.13. How can I fix this? --Resplendent 16:40, 18 October 2008 (UTC)

Special:SearchLog not generated

When the logfile in our wiki reached the size of approx. 198 kByte, Special:SearchLog was not generated anymore (blank page instead). The Webadministrator found the following error message in a logfile of the webserver:

PHP Fatal error: Allowed memory size of 20971520 bytes exhausted (tried to allocate 416700 bytes) in [...]/wiki/includes/Parser.php on line 4233

We followed the instructions according to Fatal error: Allowed memory size of nnnnnnn bytes exhausted (tried to allocate nnnnnnnn bytes), raised

ini_set in LocalSettings.php

from 20M to 64M and Special:SearchLog is o.k. Can anyone explain the correlation between these figures?

• filesize < 200kByte
• tried to allocate 416700 bytes
• Allowed memory size of 20971520 bytes
• Special:SearchLog: ca. 225 kByte

I assume that the parsing from text to XHTML may cause some growth, but these dimensions seem to be extraordinary. Thanks in advance, --ThT 16:50, 8 January 2009 (UTC)

I also have the same problem, but still havent been able to correct it --Cad 18:17, 9 May 2009 (UTC)

Searches for Categories mess up search log display (and a possible fix)

If you search for a category page in the search field like "Category:somePage" the search logs contain an empty line for each category you searched for and the search log page is displayed like it belongs to every of these categories!

Line

 $table .= "<tr><td>[[$k]]</td><td>$v</td></tr>\n";

could be changed to

 $table .= "<tr><td>[[:$k]]</td><td>$v</td></tr>\n";

to prevent this problem!

Searches containing HTML tags mess up SearchLog display (and possible security flaw)

If a users enters HTML tags like <div> into the search, the display of the SearchLog page is messed up until this search is removed manually from search log. HTML oder Wiki code should never be written to the log. This may even be used for exploits?

Updated SQL and getting error

I went from 5.2 to 5.3 and now I have this error occurring:

Deprecated: Function ereg_replace() is deprecated in SearchLog.php on line 12

Warning: Cannot modify header information - headers already sent by (output started at SearchLog.php:12) in WebResponse.php on line 16

Warning: Cannot modify header information - headers already sent by (output started at SearchLog.php:12) in WebResponse.php on line 16

Any idea how to fix this? TeraS 03:31, 11 January 2011 (UTC)

Replace line 12 with this:

$wgSearchLogFile = "$wgSearchLogPath/logs/".preg_replace('/^www./','',$_SERVER['SERVER_NAME']);

—Emufarmers^(T|C) 07:10, 11 January 2011 (UTC)

Thank you! This does fix that line apparently, but you then get this error:

Deprecated: Function ereg() is deprecated in SearchLog.php on line 49

if (ereg('^([0-9]{4})([0-9]{2})[0-9]{2},',fread($fh,16),$match)) list(,$y1,$m1) = $match;

Deprecated: Function ereg() is deprecated in SearchLog.php on line 55

if (ereg('^([0-9]{4})([0-9]{2})[0-9]{2},',$end,$match)) list(,$y2,$m2) = $match;

Can I assume that you change ereg() to preg_replace ? TeraS 04:56, 13 January 2011 (UTC)

preg_match, I think. You also need to add a delimiter. Try:

Line 49:

if (preg_match('/^([0-9]{4})([0-9]{2})[0-9]{2},/',fread($fh,16),$match)) list(,$y1,$m1) = $match;

Line 55:

if (preg_match('/^([0-9]{4})([0-9]{2})[0-9]{2},/',$end,$match)) list(,$y2,$m2) = $match;

—Emufarmers^(T|C) 05:31, 13 January 2011 (UTC)

Thank you, this appears to work correctly!TeraS 23:36, 22 January 2011 (UTC)

Unexpected behaviour when search suggestions are enabled (MW 1.13+)

Hi there, I installed the SearchLog extension on my wiki (MW 1.15.2) and I quickly figured out that not only "requested" searches (ie. by clicking on a button in the search box or pressing the "Enter" key) are logged but also requests generated by the "auto search suggestions" option from Mediawiki.

That is, if someone is for instance typing "led zeppelin" in the search box, then the extension will log all steps each time mediawiki proposes auto suggestions, e.g. :

• l
• le
• led
• led zep
• led zeppel
• led zeppelin

This behaviour occurs when the variable $wgEnableMWSuggest is set to 'true' in LocalSettings.php. I think it is undesired logs so I modified the extension so that it won't log those searches (corresponding to a search type = 'other' for this extension).

In function wfSetupSearchLog() from SearchLog.php I just added the if ($type != 'other') condition (see below):

# If a search has been posted, log the info
if (isset($_REQUEST['search'])) {
    $search = $_REQUEST['search'];
    if (isset($_REQUEST['fulltext'])) $type = 'fulltext';
    elseif (isset($_REQUEST['go'])) $type = 'go';
    else $type = 'other';
    
    if ($type != 'other') { // <-- MODIFICATION HERE
        # Append the data to the file
        if (empty($search)) $search = $_REQUEST[$type];
        if ($fh = fopen($wgSearchLogFile,'a')) {
            $text = date('Ymd,H:i:s,').$wgUser->getName().",$type,$search";
            fwrite($fh,"$text\n");
            fclose($fh);
        }
    } // <-- MODIFICATION HERE
}

...if anyone feels the same about these search suggestions logs :o)

I didn't see any bad side effect with this modification, but please share any feedback on this! Thanks.

I also noticed that the months in the time period dropdown-list sometimes appear in English and sometimes in French (although my wiki is in English, but was in French a long time ago)... Couldn't figure out why yet though. :/

--Fish1203 23:22, 24 February 2011 (UTC)

Sorry to resurrect an old thread... I tried this modification and found that searches entered from the search field at the top of the wiki page are not being captured. Only searches from the actual Special:Search page are logged. Fish, not sure if you're still using this extension, but if you are, can you confirm you are seeing the same behavior? I'm on MW 1.16.5.

--Jlemley (talk) 22:02, 21 February 2013 (UTC)

Turns out this is a problem with Internet Explorer (surprise!). It does not pass the "button" parameter when you press enter - only when you click the physical button. I did an ugly hack workaround by adding another hidden parameter into my skin's php called "box", then added that parameter to the if statement in SearchLog.

--Jlemley (talk) 16:13, 25 February 2013 (UTC)

Excluding searches that lead to a page

Hello, I am wondering if it is possible to exclude on this list, searches that lead to a page. If we could only include searches that don't have a page associated with them, it could be used to know what to make redirects for. Is this possible? 24.41.47.147 16:52, 29 March 2011 (UTC)

Not working after PHP/Wiki upgrade

After Upgrade from PHP 5.3.2 to PHP 5.3.6 and Mediawiki from 1.15.1 to 1.17.0 I get a 500 server-error by calling SearchLog. I fixed the deprecated calls, but I also get this PHP Fatal error:

Call to undefined function wfElement() in [..]\extensions\SearchLog\SearchLog.php on line 69

Also the name of Search-Log at the Special-Pages Overview have now some special chars inside: &lt,searchlog&gt, (replace comma with semicolon)

Any Idea?

--85.178.187.247 17:41, 8 July 2011 (UTC)

Having this problem also --207.239.97.10 14:47, 24 August 2011 (UTC)

Fix is to use xml:: in place of wf on all mentions in SearchLog.php -- KevinDankoWebDesign.com

Changing wf doesnt work for me :/ 66.231.53.81 01:18, 29 September 2011 (UTC)

There are only three wf you need to change, lines 69, 71 and 73. Just copy and paste the original code again, change that and you should be ok, works on 1.17

Not working after MW upgrade to 1.18.1

After upgrading from 1.10.1. to 1.18.1 the wiki looks fine, but SearchLog does not work.

• MediaWiki 1.18.1
• PHP 5.2.14 (apache2handler)
• MySQL 5.0.26

The changes suggested in Restricting access to the page (regarding Local Settings.php) and Not working after PHP/Wiki upgrade (xml:: in place of wf in 3 lines) are included. Any piece of advice is welcome. --ThT (talk) 09:09, 5 March 2012 (UTC)

Modifying i18n

I found I was able to get this extension working in 1.18 along the lines suggested in Manual:Special_pages#The_Messages.2FInternationalization_File

I commented out $wgMessageCache->addMessages(array('searchlog' => 'Search Log'));

and added:

$dir = dirname(__FILE__) . '/';
$wgExtensionMessagesFiles['SearchLog'] = $dir . 'SearchLog.i18n.php';

then created an i18n file as suggested.

I also had to implement the xml:: fix

--Jacknz (talk) 23:14, 5 April 2012 (UTC)

I replaced $wgMessageCache in SearchLog.php and created the following internationalization file SearchLog.i18n.php, but it still doesn't work:

<?php
/**
 * Internationalisation for Search Log
 * http://www.mediawiki.org/wiki/Manual:Special_pages#The_Messages.2FInternationalization_File
 * http://www.mediawiki.org/wiki/Extension_talk:SearchLog#Modifying_i18n
 *
 * @file
 * @ingroup Extensions
 */
$messages = array();
 
/** English
 * @author <your username>
 */
$messages['en'] = array(
        'searchlog' => 'Search Log', // Ignore
        'searchlog-desc' => "The extension logs all searches and creates a Special Page",
);
 
/** Message documentation
 * @author <your username>
 */
$messages['qqq'] = array(
        'myextension-desc' => "{{desc}}",
);

--ThT (talk) 17:38, 13 April 2012 (UTC)

I think you forget the closing php tag. Maybe you also have to change the qqq section and add a description. This one worked for me (German Language):

<?php
/**
 * Internationalisation file for SearchLog Extension
 *
 * @file
 * @ingroup Extensions
 */
$messages = array();
 
/** English
 * @author 
 */
$messages['en'] = array(
        'searchlog' => 'SearchLog', // Ignore
        'searchlog-desc' => "Display Searches of the wiki",
);
 
/** Message documentation
 * @author 
 */
$messages['qqq'] = array(
	'searchlog-desc' => 'Do not translate',
);

/** German (Deutsch)
 * @author 
 */
$messages['de'] = array(
	'searchlog-desc' => 'Zeigt alle Suchanfragen des Wiki',
);
?>

--92.231.188.199 20:20, 8 May 2012 (UTC)

Thanks, I tried that and used exactly your SearchLog.i18n.php, but it still doesn't work. --ThT (talk) 13:51, 23 January 2014 (UTC)

1.19.1 error

I added the following code to local settings and placed the files according to the instructions and the extension doesn't load. I am wondering if the code below is formatted correctly for the local settings. When I omit the code below the includes method the extension still doesn't load.

include("$IP/extensions/SearchLog/SearchLog.php");

$wgSearchLogPath = $IP/extensions/SearchLog/logs  ;

$wgSearchLogFile = $wgSearchLogPath/search.log ;

$wgSearchLogDateFormat = %b %Y ;

$wgSearchLogGroup = empty;

When I do it like this it doesn't work either:

$wgSearchLogPath = "$IP/extensions/SearchLog/logs"  ;

$wgSearchLogFile = "$IP/extensions/SearchLog/logs/search.log" ;

$wgSearchLogDateFormat = %b %Y ;

$wgSearchLogGroup = empty;

1.19.1 fix

I got it to work in 1.19.1 by doing the following:

• I changed $wgSearchLogFile to "$wgSearchLogPath/logs/search.log";
• The xml:: fix -- I changed wfElement to xml::Element on lines 69 and 71, Change wfCheckLabel to xml::CheckLabel on line 73
• I commented out line 137 -- $wgMessageCache->addMessages(array('searchlog' => 'Search Log'));
• I don't know if it's my server settings or what, but I had to set search.log to at least 757 in order to get it to write to it. I'm on a private server though, so I could set it to 777 and it wouldn't matter.

The only problem (and maybe this is how it's supposed to work, or maybe that's what line 137 was for I don't know) is that no matter what someone types in the box, whether they hit a button to search or not, it shows up in the log. Even if they just take too long to finish a word. Like if they're going to do a search for "dogs" and they type "do" and then pause, then finish out "dogs" and then delete it and type "cats" and hit enter there's an entry for "do" and "dogs" once and "cats" shows 2 entries, one where they typed it and one where they hit Search.

I fixed this by changing line 87 from

if (preg_match('/^([0-9]{4})([0-9]{2})([0-9]{2}),(.+?),(.+?),(.+?),(.+)$/',fgets($fh),$match)) {

to

if (preg_match('/^([0-9]{4})([0-9]{2})([0-9]{2}),(.+?),(.+?),(fulltext|go),(.+)$/',fgets($fh),$match)) {

Fatal error: Call to a member function addMessages() on a non-object

I've upgraded from 1.16 to 1.21 and I get the error: Fatal error: Call to a member function addMessages() on a non-object in xxx.com/extensions/SearchLog/SearchLog.php on line 136 Any idea how to remove this error? --Tech (talk) 18:15, 25 August 2013 (UTC)

Strict Standards: Declaration of SpecialSearchLog::execute() should be compatible with that of SpecialPage::execute()

I've upgraded my site from 1.16 to 1.21 and I have the error: Strict Standards: Declaration of SpecialSearchLog::execute() should be compatible with that of SpecialPage::execute() in xxx.com/extensions/SearchLog/SearchLog.php on line 29 Any idea how to debug this? --Tech (talk) 18:17, 25 August 2013 (UTC)