Difference between revisions of "Extension talk:ImageHistoryClear"
(New section: Call to a member function getNamespace() on a non-object) |
(→Call to a member function getNamespace() on a non-object: where's the error?) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 136: | Line 136: | ||
You shouldn't try and call a method on a variable that isn't an object, and the [http://nz.php.net/manual/en/function.is-object.php is_object] function determines whether or not a variable is an object. --[[User:Nad|nad]] 12:17, 13 November 2008 (NZDT) | You shouldn't try and call a method on a variable that isn't an object, and the [http://nz.php.net/manual/en/function.is-object.php is_object] function determines whether or not a variable is an object. --[[User:Nad|nad]] 12:17, 13 November 2008 (NZDT) | ||
+ | :Just got this from Rob via Nick, you'll appreciate [http://giveupandusetables.com/ this app] ;-) --[[User:Nad|nad]] 12:20, 13 November 2008 (NZDT) | ||
+ | ::The extension works fine locally as it is, though I have included the is-object condition. On this wiki, the parser complains about the same object reference even when the whole of the function content is commented out - most odd.--[[User:Jack|Jack]] 20:04, 13 November 2008 (NZDT) | ||
+ | :::What's "this wiki"? you said it works locally, and you don't have access to change the running extension on this server, so where is this error being raised? I uncommented it from your local settings and don't get any error on flashkiwi... --[[User:Nad|nad]] 08:24, 14 November 2008 (NZDT) |
Latest revision as of 19:24, 13 November 2008
Parser errors:
Notice: Undefined index: title in C:\www\wiki4\extensions\ImageHistoryClear\ImageHistoryClear.php on line 24
Notice: Undefined property: StubObject::$mBodytext in C:\www\wiki4\extensions\ImageHistoryClear\ImageHistoryClear.php on line 56
--Jack 17:33, 24 October 2008 (NZDT)
- The first error is due to the index "title" not existing in the array which since you're now using strict raises a warning, you'll need to encase the entire thing into a condition based on whether the title index exists (you can use isset() or in_array() ) and after that whether a title object could be made. Strict enforces safe coding practice which can be a bit tedious and verbose, but it solid and predictable.
- The second error is that you've tried to access $wgOut before it's properly initialised - you should be accessing it from the callback function registered with the OutputPageBeforeHTML hook.
- --nad 18:22, 24 October 2008 (NZDT)
You should really be executing the condition in the extension setup function or the class constructor not in the global scope (also the global keyword is redundant since you're already in global scope there). Also there doesn't appear to be any such function as egImageHistoryClear which you've assigned to the hook. --nad 19:50, 24 October 2008 (NZDT)
Parser output for print_r: StubObject Object ( [mGlobal] => wgOut [mClass] => OutputPage [mParams] => Array ( ) )
So the fact that nothing is happening at all indicates that something is wrong with this in addition to any deficiencies it may have in gathering the runtime state :(
--Jack 17:33, 28 October 2008 (NZDT)
- Still many things wrong, I've fixed it up and commented it. --nad 18:42, 28 October 2008 (NZDT)
OK well my next problem is (and I've been banging away at this for a while) is that I have a &$out parameter which appear to be an object but I need to access mBodyText and $out does not seem to have that property, I'm having no luck printing it anyway ... --Jack 09:49, 29 October 2008 (NZDT)
- If you're not able to print the content of the object then obviously you won't be able to access any properties from it, so you need to sort out why you're not getting any output first - i.e. establish whether the function is even getting executed. --nad 11:30, 29 October 2008 (NZDT)
Yep its executing inside the callback, print_r($out) results in the following, which looks like an object to me...
- I deleted the content cos you pasted it in in an unusable way, you should view source and copy it from there and then paste it in here wrapped in a pre tag. Anyway I saw that there was the bodytext property so there seems to be no problem. --nad 13:05, 29 October 2008 (NZDT)
Sorry about the pre. Anyway, I would therefore expect that I would get some bodytext (but instead I get no output) with
print_r($out->mBodytext);
If I substitute
print_r(gettype($out->mBodytext));
it prints string, which is correct.
--Jack 13:20, 29 October 2008 (NZDT)
strlen returns 0, so there is a bodytext property, it just doesn't contain anything
--Jack 13:48, 29 October 2008 (NZDT)
- what kind of page are you on when it has nothing in it? --nad 14:06, 29 October 2008 (NZDT)
- or more to the point, what does it have in it on an image page? --nad 14:07, 29 October 2008 (NZDT)
- Well there are no conditions on the code yet so Main_Page is the page, and when I print_r($text) it comes up with the correct wikitext of it perfectly --Jack 15:08, 29 October 2008 (NZDT)
- But you haven't answered the question - what does $out->mBodytext give you on an image page? --nad 15:57, 29 October 2008 (NZDT)
- Well there are no conditions on the code yet so Main_Page is the page, and when I print_r($text) it comes up with the correct wikitext of it perfectly --Jack 15:08, 29 October 2008 (NZDT)
- or more to the point, what does it have in it on an image page? --nad 14:07, 29 October 2008 (NZDT)
ah, i get textbox plus the image and a caption:
<ul id="filetoc"> <li><a href="#file">Image</a></li> <li><a href="#filehistory">File history</a></li> <li><a href="#filelinks">Links</a></li> </ul> <div class="fullImageLink" id="file"> <a href="/wiki4/images/d/de/Boat.jpg"> <img alt="Image:Boat.jpg" src="/wiki4/images/d/de/Boat.jpg" width="318" height="480" border="0" /> </a> <br /><br /> <a href="/wiki4/images/d/de/Boat.jpg">Boat.jpg</a> </div>
Jack 16:12, 29 October 2008 (NZDT)
- So - does that contain the output that you need to manipulate? --nad 16:16, 29 October 2008 (NZDT)
Well no, what I'm seeing is some of the code. It is missing its title, and all of the history and links code that I actually want to omit. Ironically, it means that the contents of mBodytext will actually do the job I want without having to use a regex to nix all the detail underneath it.
I am concerned about what happened to all the other text that appears on the rendered page, it must be some other property than mBodytext.
I have found this in ImagePage.php though, it looks related:
/** * Handler for action=render * Include body text only; none of the image extras */ function render() { global $wgOut; $wgOut->setArticleBodyOnly( true ); parent::view(); }
Jack 16:28, 29 October 2008 (NZDT)
- Thats a different thing, action=render is used by AJAX etc to request that the page have no skin whatsoever - for example, see this page with action=render. --nad 16:51, 29 October 2008 (NZDT)
- Looks like you're right, looks like that hook only allows manipulation of the parsed text - there's another later hook though which is for skin hacks and should have everything in it called BeforePageDisplay --nad 17:00, 29 October 2008 (NZDT)
Yes indeed I just already checked out the BeforePageDisplay hook and it included the stuff I want to omit so I'll have a little think about this now ...
Jack 17:07, 29 October 2008 (NZDT)
Obviously something wrong with the regular expression, the action is not performed and the error message is
Warning: preg_replace() [function.preg-replace]: Unknown modifier '.' in C:\www\wiki4\extensions\ImageHistoryClear\ImageHistoryClear.php on line 30
Jack 17:44, 29 October 2008 (NZDT)
- You have a missing starting delimiter, and you shouldn't have delimiters on the replacement paramater --nad 18:35, 29 October 2008 (NZDT)
- Also you haven't assigned the result of the replacement to anything so even when the regex works, nothing will happen --nad 18:37, 29 October 2008 (NZDT)
Result of this (incredibly simple) regex is mickey_mousemickey_mouse
function efImageHistoryClear (&$out) { $jktext = $out->mBodytext; $out->mBodytext = preg_replace ('%.*%s','mickey_mouse',$jktext); return true; }
I see nothing in this code causing it to be displayed twice, it may have something to do with the hook I suppose
--Jack 20:34, 29 October 2008 (NZDT)
- perhaps you should add a counter to see if the hook is being called twice? --nad 21:32, 29 October 2008 (NZDT)
- I did the regex myself and got the same result - it seems to be also matching the start of line (a zero length chr) or something, so change it to %^.*%s so that its only everything following the start of line that matches. But this problem wouldn't affect your proper regex that you want to perform on the image pages. --nad 21:51, 29 October 2008 (NZDT)
- Ta - Adding the hat resulted in a correct return, I'll work on the regex now --Jack 21:58, 29 October 2008 (NZDT)
- I did the regex myself and got the same result - it seems to be also matching the start of line (a zero length chr) or something, so change it to %^.*%s so that its only everything following the start of line that matches. But this problem wouldn't affect your proper regex that you want to perform on the image pages. --nad 21:51, 29 October 2008 (NZDT)
I can't see any special characters in here that need to be escaped:
$out->mBodytext = preg_replace ('%<h2 id="filehistory">.*<div class="printfooter">%s','<div class="printfooter">',$out->mBodytext);
--Jack 22:44, 29 October 2008 (NZDT)
- Have a closer look at the content of $out->mBodytext and you'll see why your match is failing --nad 23:46, 29 October 2008 (NZDT)
- Why not just replace %<h2 id="filehistory".+$%s with empty instead of isolating many different things? --nad 09:03, 30 October 2008 (NZDT)
- True, changed. The condition works so the extension is finished :) --Jack 09:19, 30 October 2008 (NZDT)
- Hey not so fast - it's far from perfect yet - you shouldn't use a hard-coded namespace 6, you should use the constant NS_IMAGE, you shouldn't use the request super-global, and you still have two regexps instead of one. --nad 11:09, 30 October 2008 (NZDT)
- Looks all good, you're done! :-) --nad 08:44, 31 October 2008 (NZDT)
- Hey not so fast - it's far from perfect yet - you shouldn't use a hard-coded namespace 6, you should use the constant NS_IMAGE, you shouldn't use the request super-global, and you still have two regexps instead of one. --nad 11:09, 30 October 2008 (NZDT)
- True, changed. The condition works so the extension is finished :) --Jack 09:19, 30 October 2008 (NZDT)
- Why not just replace %<h2 id="filehistory".+$%s with empty instead of isolating many different things? --nad 09:03, 30 October 2008 (NZDT)
flashkiwi is not loading with ImageHistory Clear included.
Parse error: syntax error, unexpected '<' in /var/www/extensions/ImageHistoryClear/ImageHistoryClear.php on line 46
Of course, there is no line 46, code is 45 lines long. Any ideas? --Jack 16:31, 1 November 2008 (NZDT)
- Oops, my bad I pasted the skin script into the image history clear! correct one in there now, but its not doing the replacement in the image pages, maybe because you're on a 1.10.0 which may have slightly different output. --nad 16:41, 1 November 2008 (NZDT)
Call to a member function getNamespace() on a non-object
You shouldn't try and call a method on a variable that isn't an object, and the is_object function determines whether or not a variable is an object. --nad 12:17, 13 November 2008 (NZDT)
- Just got this from Rob via Nick, you'll appreciate this app ;-) --nad 12:20, 13 November 2008 (NZDT)
- The extension works fine locally as it is, though I have included the is-object condition. On this wiki, the parser complains about the same object reference even when the whole of the function content is commented out - most odd.--Jack 20:04, 13 November 2008 (NZDT)
- What's "this wiki"? you said it works locally, and you don't have access to change the running extension on this server, so where is this error being raised? I uncommented it from your local settings and don't get any error on flashkiwi... --nad 08:24, 14 November 2008 (NZDT)
- The extension works fine locally as it is, though I have included the is-object condition. On this wiki, the parser complains about the same object reference even when the whole of the function content is commented out - most odd.--Jack 20:04, 13 November 2008 (NZDT)