Extension talk:SearchLog

From MediaWiki.org

Jump to: navigation, search

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)

Contents

[edit] 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)
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 [1] - Patrick 12:24, 4 April 2008 (UTC)

[edit] 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)

[edit] Sortable search results

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


[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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?

[edit] Solution

Change line 90 in SearcLog.php

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

[edit] 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)

[edit] 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)

Retrieved from "http://www.mediawiki.org/wiki/Extension_talk:SearchLog"
Personal tools