Extension talk:TransformChanges

From mediawiki.org
Latest comment: 10 years ago by Jobst.prinzhorn in topic Doesn't work MW 1.20.2

CSS styles[edit]

Where should the CSS styles be added? --87.176.120.190 21:21, 24 April 2008 (UTC)Reply

Usually MediaWiki:Common.css - see Manual:Interface/Stylesheets. -- FND 07:05, 25 April 2008 (UTC)Reply

Doesn't work[edit]

I have MediaWiki 1.9.3 and this does't work at all--not even the CSS classes are showing up on the page. The extension shows up on Special:Version so I know it's installed correctly. -Eep² 22:37, 23 July 2007 (UTC)Reply

The row CSS styles don't work either. I tried overriding the ones on Organic Design but it had no effect, and analyzing the CSS revealed the table has an ID of "TABLE_2"... -Eep² 22:57, 23 July 2007 (UTC)Reply
OK, this extension won't work if "enhanced recent changes" is enabled in Special:Preferences. —Eep² 14:13, 2 September 2007 (UTC)Reply
Great extension, and it works perfectly after setup, EXCEPT from one major detail. The extension seem to be ignored or at least not parsed, if the user have chosen a language different from the default language of the wiki. Having a wiki family setup, the extension is installed on all of them, but as soon as a user have chosen a language different from the default wiki language, the extension simply does not work. If the user switch the language back to that of the wiki default language, the extension is loaded normally. The Wiki family is setup using 1.15.1. I have tried several things and everything seem to work perfectly aside from the language being setup in the preferences different from the default wiki language. Only one problem, but a major one. If this could be fixed, the extension would definitely go back in my setup. Unfortunately I had to remove it this time, as it only works for some users. Thanks. Peter Lee 11:49, 21 December 2009 (UTC)Reply

empty recentchanges[edit]

After installing the SemanticMediaWiki extension, this extension appears to be suppressing the content of Special:Recentchanges as long as the viewer is logged in. Any ideas why or how to fix this? --Alxndr 02:35, 11 August 2007 (UTC)Reply

I don't know what might be wrong there, I'm using SMW with this extension on a number of wiki's of various versions with no trouble. Can you give me an URL to the site with the problem or is it intranet? --Nad 05:06, 11 August 2007 (UTC)Reply
It's Oberwiki, but I currently have it disabled so everyone can see RC when logged in. Do you use Jabber or AIM? If we can coordinate a time I can flick switches on the server and show you what I was talking about. --Alxndr 17:46, 11 August 2007 (UTC)Reply
Silly me. My logged-in preferences show the last 500 edits, which maxed out pcre.callback_limit, which made one of the preg_replace_callback()s return NULL, so it wasn't happening when I was logged out. Nothing to do with SemanticMediaWiki. --Alxndr 23:12, 23 August 2007 (UTC)Reply
Thanks for the info, I'll see if I can think of a simple way to stop it relying on that pcre.callback_limit, maybe by breaking the content up with a split first or something. --Nad 05:10, 24 August 2007 (UTC)Reply


I wanted to use your extension (brilliant job, btw), but I had the same problem as Alxndr did about the preg_replace_callback() limits on my web hosting, so I modified the source considering your idea of splitting the content first.
Here's my edits :
- First I split the recent changes content using the delimitation of days ;
- Then for each day, if there is more than a number of edits for this day ($nbedits, set to 50, seems to work in any case, might be possible to go to 150 or more?), I split the content into parts containing $nbedits edits max (this is done by counting the numbers of </li> tags in the content, each one representing a change).
- Finally, each part of the content is being processed with preg_replace_callback().
My code might not be very optimized, but It seems to work like a charm now (even for 500+ changes). You can see it working here : [1] (french).
Here's the source code : TransformChanges.php.
My edits are based on the last version to date (1.0.7). Please feel free to check my code and report any bugs or possible improvements ! --Fish1203 23:04, 6 February 2008 (UTC)Reply
Thanks a lot for that :-) it seems to work fine, so I've updated the main code with your changes to version 1.0.8. --Nad 07:47, 7 February 2008 (UTC)Reply
This version is great. Fast and stable. One little problem is new. User, how is not allowed to read this page (not logged in and $wgGroupPermissions['*']['read']= false;) got this error
Invalid special page name ""

--Ozz 20:13, 16 February 2008 (UTC)Reply

Praise & Suggestion[edit]

Brilliant job - thanks for this!!

Small suggestion: There should be a warning that the user option Enhanced recent changes must not be used.

-- FND 21:29, 7 September 2007 (UTC)Reply

I've modified it to disable the enhanced changes automatically --Nad 21:47, 7 September 2007 (UTC)Reply
Wow, that was quick, and even better than what I'd asked for - thank you very much! -- FND 21:52, 7 September 2007 (UTC)Reply

TransformHistory[edit]

Can this work for histories too? That's a more commonly referenced/visited page than recent changes and a watch list... Also, a sortable table would be nice... -Eep² 22:41, 23 July 2007 (UTC)Reply

See Lists -> tables for more suggestions. -Eep² 03:36, 24 July 2007 (UTC)Reply

It'd be great if this extension would improve the History page's layout as well. -- 20:23, 8 September 2007 (UTC)

Eventually I want to get it to work on history and watchlist, but haven't had time. --Nad 22:33, 8 September 2007 (UTC)Reply

MW 1.13.0[edit]

It's not working on MW 1.13.0. Recent changes looks the same with and without TransformChanges installed. Ruiz 03:37, 20 August 2008 (UTC)Reply

See bug 16634 (closed there), it has to do with the SpecialPage hooks you're using. ^demon 21:12, 13 December 2008 (UTC)Reply
Perform this replacement in extension file:
$wgHooks['SpecialPageExecuteAfterPage'][] = 'wfTransformChanges'; // before
$wgHooks['BeforePageDisplay'][] = 'wfTransformChanges'; // after
I've also found display problem when user's (from recent changes) talk page is not created. --Aik099 10:52, 14 December 2008 (UTC)Reply

MW 1.14.0[edit]

Doesn't work with MW 1.14.0 in my wiki; There's an "Error: match failed!" 90.136.204.168 14:40, 22 February 2009 (UTC)Reply

MW 1.15.1 and TransformChanges 1.1.6[edit]

On our wiki (MW 1.15.1), the Recent Changes are empty - with and without the changes in the Mediawiki:Common.css page. I tried the Hook Replacement (see above), but no result. Does the code require changes in order to work with this MW version? -- 8:30, 2 September 2009 (UTC)

Highlight own changes[edit]

Thanks for this extension.

I altered it for my wiki, so that changes done by the logged-in user are highlighted differently.
To do this, add a line tr.mw-line-own to your css (just like "odd" and "even") with the style you want it to have.

Then go to the wfTransformChangesLI function. Add $wgUser to the globals and delete $row .= "<tr class=\"mw-line-$wgTransformChangesRow\">";

After that, insert:

 $searchname="/".$wgUser->getName()."/";
 if (preg_match($searchname, $user)) $wgTransformChangesRow = 'own';
 $row .= "<tr class=\"mw-line-$wgTransformChangesRow\">";

just above

 if ( $allowed ) foreach ( $cols as $col ) {
    $val = isset($$col) ? $$col : '';
    $row .= "<td class=\"$col\">$val</td>";
 } 

Sidcom 09:01, 25 August 2010 (UTC)Reply

WARNING: This will not work if a username is part of another. e.g. the logged-in user is named "Steve", then changes by "Steven" and "theSteve" might also be highlighted. This might be easy to fix by adding the right delimiters, but so far I could only test this on a live wiki, so I didn't want to play around. Sidcom 16:33, 25 August 2010 (UTC)Reply

MW 1.18.1[edit]

The version 2.0.4 (from svn.organicdesign.co.nz) seems not to work with MW 1.18.1. Is there an update? Best, --ThT (talk) 18:16, 5 March 2012 (UTC)Reply

Not working 1.19.3[edit]

Can't get it to work on MW 1.19.2. No error message, its just that the Recent changes page doesn't change at all. Too bad, looks like it would be a good extension. --Craig131 (talk) 02:50, 14 September 2012 (UTC)Reply

It's working in 1.19.3
Though the left navigation bars (toolbox, search and so on) moved down :-(
What php version are you using ? Perhaps the same problem as the user in next thread, my php is 5.2.x --Erkan Yilmaz (talk) 10:47, 9 January 2013 (UTC)Reply

Worked in MW 1.15, but not working in MW 1.19.2[edit]

Perhaps it's a MW problem, perhaps it is due to our new PHP version (5.4)... I played around with the code a little, but now I give up - it's nice to have, but not mission critical :-( from IP 193.26.252.225, 10 October 2012

See above thread, works for me in 1.19.3. Perhaps it's really the newer PHP ? --Erkan Yilmaz (talk) 10:49, 9 January 2013 (UTC)Reply

Doesn't work MW 1.20.2[edit]

I get:
Error: match failed!
after including the code from http://svn.organicdesign.co.nz/ in Rev 689.

Product Version
MediaWiki 1.20.2
PHP 5.3.3-7+squeeze15 (apache2handler)
MySQL 5.1.66-0+squeeze1

--Jobst (talk) 16:40, 22 May 2013 (UTC)Reply