User talk:Jldupont/Archive

return to basepage: User_Talk:Jldupont

BizzWiki related

see Extension_talk:BizzWiki

Messed up extension

Ouch! I hope not. Can you clarify? - I'm not seeing the problem. Not in the browser (same Firefox) and not in the template code.

The changes I made only added choices to the list of types. They should not have affected layout unless I made a typo. I tried doing a diff to compare the current version with the version before my changes and I can't see the typo if there is one. If you can see anything I missed, help would be appreciated.

Some newer extensions (i.e. recently posted on MediaWiki.org) I stumbled upon appeared messed up; but now, I can't find which ones. Sorry.

I have looked at some of my extensions and they appear OK.

Sorry for the confusion. Jean-Lou Dupont 13:25, 7 September 2007 (UTC)

If you are referring to the <?php /* that seems to appear at the start of many of your extension pages, it may have another source. I noticed them in my browser before I changed the template. I don't believe that this version of MediaWiki has any extensions that support embedded PHP (check Special:Version to be sure) and the MediaWiki core markup certainly doesn't (it is a security risk for an open-to-the-public wiki like this one). Egfrank 07:29, 7 September 2007 (UTC)

No I am not referring to <?php /* appearing on my extension pages; I know where these come from: I do not like to maintain multiple pages with the same content. The extension pages I post on MediaWiki.org come straight out of my Google Code SVN file; those are executable PHP pages. So, when I copy an extension from my SVN to MediaWiki.org, I just cut&paste the actual executable PHP code. Of course I could remove the extra <?php /* but sometimes I forget. Sorry for that. Jean-Lou Dupont 13:25, 7 September 2007 (UTC)

Are you still having problems with the "way things look?

Whoops - no need to answer - just saw your note above. But thanks for the feedback anyway. Egfrank 13:30, 7 September 2007 (UTC)

Backup related extension

Do you mean an extension that assists in backups? In theory there is no reason why it couldn't exist - most professionally administered installations probably have a few mediawiki backup scripts lying around. I know we do. I did a quick search and found Extension:Backup & Restore (unstable) Your mediawiki maintenance directory also has a nifty little script dumpHTML.php Although I suspect you already know about both of these.

Did you have something specific in mind? Egfrank 20:07, 9 September 2007 (UTC)

Well, I am writing an extension that provides a 'backup' hook; this hook will be used by another extension of mine which provides a backup facility to Amazon S3.Jean-Lou Dupont 20:19, 9 September 2007 (UTC)

This sounds like the kind of thing that would normally be put on a special page. Perhaps you want to consider writing a subclass of special page and then add a custom hook that lets those who install your special page extension define custom backup procedures in addition to whatever ones you bundle with your extension. Egfrank 11:17, 10 September 2007 (UTC)

It's a bit more complicated than this; I have picked a bad name for the extension (i.e. 'backup') because it is more akin to a 'replication' function. There most probably will be a 'special page' for the 'restore' part but not for the 'backup' part. Anyhow, since I am working part on this, it will take some time before the complete solution is ready. Jean-Lou Dupont 15:55, 10 September 2007 (UTC)

(TODO) While we're on the topic of hooks

I've been doing some cleanup on Category:Hook extensions and Extension hook registry. I've noticed you've defined quite a number of custom hooks for your extensions. Perhaps you might want to add some documentation of each of those hooks to the Extension hook registry - it would help users make better use of your extensions. Egfrank 11:17, 10 September 2007 (UTC)

Of course. Jean-Lou Dupont 11:37, 10 September 2007 (UTC)

Unknown action handler

How does Extension:UnknownActionHandler relate to the MediaWiki hook of the same name: c.f. UnknownAction ? Egfrank 16:40, 10 September 2007 (UTC)

It allows setting an 'handler' for an 'unknown' action. The handler is PHP code stored in a database page. The code is enclosed in <php> tags. Jean-Lou Dupont 16:56, 10 September 2007 (UTC)

Thanks for the quick answer. Looking at your code, it appears that you are using the UnknownAction to create the association between the action and the php code. Is this what you mean? I've added a paragraph to Extension:UnknownActionHandler explaining that - the original description was a bit confusing and made it sound like you had defined your own custom hook in lieu of UnknownAction . Egfrank 17:03, 10 September 2007 (UTC)

Correct.

This extension is part of my '1st wave' of extensions I did. I wasn't as sophisticated nor tidy about documentation as now... not that I am that good either ;-) Jean-Lou Dupont 17:15, 10 September 2007 (UTC)

Parse markup

Hi. I'm trying to hack Semantic Forms to parse wiki markup on its forms and show it on its Special:EditData pages. Unfortunately, the developer doesn't seem too interested in implementing this so I was wondering if you would know how to do this. I'm hoping this will allow other extensions, like Simple Forms to work with Semantic Forms (instead of just showing up as unparsed wiki markup). Any help would be appreciated! Thanks. Eek 19:05, 17 September 2007 (UTC)

If its a case of parsing wikitext in $text (example), then just a parser call suffice. E.g.

 global $wgParser;
 // clone our global parser to get access to all defined parser functions & magic words
 $parser = clone $wgParser;
 $parsed_document = $parser->RecursiveTagParse( $text );

Or are you looking for something more complicated i.e. exactly how to retrofit the above code in the extensions you are referring to? Jean-Lou Dupont 19:52, 17 September 2007 (UTC)

Yea, more specific, since I'm not much of a coder and wouldn't know where to put this. :/ I'll mention it to the dev though. Thanks. Eek 06:35, 18 September 2007 (UTC)

OK, in SF_FormPrinter.inc I tried putting this (starting at line 450):

            if ($new_text) {
              if (is_numeric($field_name)) {
                // if the value is null, don't include it at all -
                // TODO: this isn't quite right
                if ($cur_value_in_template != '')
                  $template_text .= "|$cur_value_in_template";
              } else {
                // if the value is null, don't include it at all
                if ($cur_value_in_template != '')
		   //new - parse value for markup
		   global $wgParser;
		   $parser = clone $wgParser; // clone global parser to get access to all defined parser functions & magic words
		   $cur_value_in_template = $parser->RecursiveTagParse( $cur_value_in_template );
		   //end new
                   $template_text .= "\n|$field_name=$cur_value_in_template";
              }

but get this error:

Fatal error: Call to a member function getUseTeX() on a non-object in ../wiki/includes/Parser.php on line 550

Any ideas? Eek 08:05, 18 September 2007 (UTC)

Looks like the parser isn't initialized. You probably want to to something along the lines of:

 global $wgParser;
 $parser = clone $wgParser; // clone global parser to get access to all defined parser functions & magic words
 // find a meaningful $title object to stick below
 $po = $parser->parse( $text, $title, new ParserOptions );
 // to get the text 
 $texte = $po->getText();

Jean-Lou Dupont 18:01, 19 September 2007 (UTC)

OK, so what about the RecursiveTagParse function--is it no longer necessary? I'm not sure about the variables either...or even where to specifically place all this code anyway... Eek 10:53, 20 September 2007 (UTC)

Sorry about that. I have glanced over the code in question and I can't easily find head from tail i.e. this code looks difficult to maintain. I am disappointed to say that I will not be helping you on this one. Maybe next time. Jean-Lou Dupont 11:58, 20 September 2007 (UTC)

Extension Translation

Hi, I'm the man whose contact you last week, I just want to kow if you have an order of preference for the translation. If you have extension that need translation immediately or I can do it without order? And i would add that your extension are very very good. And when there is no i8n.php , I don't know what I have to translate^^. --Add 00:00, 6 January 2008 (UTC)

I have no preferences on this subject matter. As for the extensions that do not have an i18n file, point them out to me please. Jean-Lou Dupont 00:46, 6 January 2008 (UTC)

Extension:XML Class - broken link (CLOSED)

Hello. One of you're extensions named Extension:XML Class got a broken download link. Is this extension still supported? If I understand this extension correctly, it can serve XML data within a page to page requests? I'm experimenting with a web application and is interested in testing MediaWiki as a "database" for serving xml requests, since it's much easier to keep updating/adding this way. Trond.olsen

Hi - I have updated the download link. Please note that I do not support this extension anymore. Jean-Lou Dupont 11:45, 25 March 2008 (UTC)

Ty for the link. The MediaWiki API also seems to have similar support for XML. Although it requires double-parsing. Trond.olsen

Request for assistance in 'fixing' a conditional infobox (CLOSED)

Hello; I'm hoping to recruit your assistance in solving a problem that I've encountered on a recently-installed, (public) (to-be) project wiki.

I've installed a wiki for a friend, where infoboxes are critical to the purpose of the site. I have conditional infoboxes working just fine on my private wiki, so I did a fresh install of MediaWiki for my friend and then copied & pasted code from my wiki (including MediaWiki:Common.css and MediaWiki:Monobook.css). I figured that I could set up the 2nd wiki to be near identical to mine, for the most part, and then go from there.

However, on the second site, the infoboxes get heavily distorted. I narrowed it down to the conditional fields, because it accepts just fine an entry that includes the name of the starship class being focused upon (as shown here where only the standard field is used).

To me, this means it relates to some change I made to the server-bound files on the original wiki at some point, and were not yet made to the new install. Someone at mwusers.com thought I needed to define the class "infoboxrow", but since MediaWiki:Common.css and MediaWiki:Monobook.css are a direct copy from the original site, I don't think that is the problem (at least as far as those two files are concerned). I just don't have a clue as to what I'm leaving out of the newly installed wiki.

The original site is using MediaWiki: 1.11.0, while the new one is using 1.12.0rc1 (I don't want to update the original, if screwed up infoboxes might be the result).

Any assistance you could possibly provide would be appreciated. Thank you. --LeyteWolfer 21:11, 19 March 2008 (UTC)

Sorry but I do not know enough about the inner workings of the infobox template. Jean-Lou Dupont 11:40, 25 March 2008 (UTC)

A big thank you in advance (closed)

I have downloaded all of the files and I am testing out your awesome extension right now on mediawiki 1.7.

I don't think it will work the first try because of SecureHTML/SecureHTML in the required once section of localsettings.php, but I have been wrong a million times before.

If it works, then I will leave you alone. If it doesn't work, I will try to tweak it a little and then give up until I can pay $49 for siteground to have me upgrade to mediawiki 1.12. Either way I get out of your hair :)

Before I test this, I just wanted to say thank you for the awesome extension. I feel like the maid who is trying to tidy up a beautiful mansion that you built. A maid who occasionally breaks things as he/she cleans and gets scolded by the mansion owner/builder. THANKS AGAIN! Odessaukrain 18:02, 31 March 2008 (UTC)

First try: my page doesn't load.

I will change SecureHTML/SecureHTML to SecureHTML in localsettings.php Odessaukrain 18:05, 31 March 2008 (UTC)

Second try: my page doesn't load.

My web page no longer works. damn. I give up. Thanks for everything, see you after the upgrade!Odessaukrain 18:10, 31 March 2008 (UTC)

Dependent on your budget, you might want to consider switching hosting provider; I find it hard to imagine shelling out 49$ for upgrading 1 software package... Also, to be less reliant on a hosting provider with your domain, you might want to consider splitting domain hosting from web hosting. I use EasyDNS for my DNS needs and 1and1 for the hosting part; this way I can switch easily. Jean-Lou Dupont 18:17, 31 March 2008 (UTC)

IT FUCKING WORKS HA YES.

I realized that siteground was down too after I gave up and deleted all the files and changed my localsettings.php

So after realizing localsettings.php was down, I had redo everything again (creating folders etc--I need to find an online FTP which allows me to drag and drop folders).

This is the correct code:

require_once( "$IP/extensions/StubManager/StubManager.php" );

require_once( "$IP/extensions/SecureHTML/SecureHTML.php" );

I will update everything then say goodbye. Odessaukrain 18:34, 31 March 2008 (UTC)

Meta Tag Extension is not XHTML valid (closed)

The MetaTag Extension destroys the XHTML Validation of MediaWiki Pages. PLZ make the Tag XHTML Valid! 77.182.142.204 17:31, 10 April 2008 (UTC)

Please provide fix, either on this talk page or on my project site's issues [1]. Jean-Lou Dupont 17:33, 10 April 2008 (UTC)

Line 26

$parser->mOutput->addHeadItem("<link{$_rel}{$_type}{$_href} />\n");

Line 41

$parser->mOutput->addHeadItem("<meta{$http}{$cont}{$name} />\n");

--77.182.143.79 19:27, 16 April 2008 (UTC)

Fixed in SVN trunk, awaiting for a release. Thanks! Jean-Lou Dupont 03:44, 17 April 2008 (UTC)

HELP (CLOSED)

I'm trying to use your extensions to create/edit pages dynamically via php, but as soon as I include them in the local settings, the pages all just blow up with errors. Help please!

Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of call_user_func(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file in /home/content/d/e/m/demonscarnage/html/extensions/UnknownActionHandler.php on line 99 Retrieved from "http://www.mediawiki.org/wiki/Extension:UnknownActionHandler/Code"ViewsExtension Discussion Edit History Personal toolsLog in / create account Site Main page Browse categories Community portal Recent changes Download MediaWiki Extensions Support User help Technical manual FAQ Support desk Development Bug tracker Browse SVN Download from SVN Code docs Communication IRC (#mediawiki) Mailing lists Search Toolbox What links here Related changes Upload file Special pages Printable version Permanent link Warning: Cannot modify header information - headers already sent by (output started at /home/content/d/e/m/demonscarnage/html/extensions/RunPHP_class.php:280) in /home/content/d/e/m/demonscarnage/html/includes/WebResponse.php on line 10

Warning: Cannot modify header information - headers already sent by (output started at /home/content/d/e/m/demonscarnage/html/extensions/RunPHP_class.php:280) in /home/content/d/e/m/demonscarnage/html/includes/WebResponse.php on line 10

Warning: Cannot modify header information - headers already sent by (output started at /home/content/d/e/m/demonscarnage/html/extensions/RunPHP_class.php:280) in /home/content/d/e/m/demonscarnage/html/includes/WebResponse.php on line 10

Warning: Cannot modify header information - headers already sent by (output started at /home/content/d/e/m/demonscarnage/html/extensions/RunPHP_class.php:280) in /home/content/d/e/m/demonscarnage/html/includes/WebResponse.php on line 10

Warning: Cannot modify header information - headers already sent by (output started at /home/content/d/e/m/demonscarnage/html/extensions/RunPHP_class.php:280) in /home/content/d/e/m/demonscarnage/html/includes/WebResponse.php on line 10

Warning: Cannot modify header information - headers already sent by (output started at /home/content/d/e/m/demonscarnage/html/extensions/RunPHP_class.php:280) in /home/content/d/e/m/demonscarnage/html/includes/WebResponse.php on line 10

Warning: Cannot modify header information - headers already sent by (output started at /home/content/d/e/m/demonscarnage/html/extensions/RunPHP_class.php:280) in /home/content/d/e/m/demonscarnage/html/includes/WebResponse.php on line 10

Warning: Cannot modify header information - headers already sent by (output started at /home/content/d/e/m/demonscarnage/html/extensions/RunPHP_class.php:280) in /home/content/d/e/m/demonscarnage/html/includes/WebResponse.php on line 10

Extension:UnknownActionHandler requires Extension:Runphp page to work. Did you also install this? Note these extensions were part of my first wave of extensions for MediaWiki i.e. not very refined nor greatly documented. Jean-Lou Dupont 12:05, 13 May 2008 (UTC)

Thanks. I installed the class, but not the page ;) However, I think I will try the secure version first. What I am doing is making a flash portal, so I need to be able to have things update dynamically based on changes to the database. The ;php tags will be a real help, but the security will also be vital. Currently I have disabled editing of the main page, but not the discussion, to all users. I dont want people to be able to use the php tags there, will your secure version fix this? [2] if you are curious. Demons carnage 15:47, 13 May 2008 (UTC)

In a word, yes: please see documentation Extension:SecurePHP. Jean-Lou Dupont 15:49, 13 May 2008 (UTC)

THANK YOU!!! You will have saved me a ton of time trying to figure all of this out!!! I am a noob at wiki, but somewhat less so at php, and there are many things easier to do with it as well. Thankyou for doing this wonderful bit of code! Demons carnage 19:32, 13 May 2008 (UTC)

Extension:ConditionalShow not 'cache' friendly, what exactly does that mean?

When, on Extension:ConditionalShow, you say that "This extension is not 'cache' friendly," what exactly do you mean?

I mean that the intended behavior is not supported in all cases when parser caching functionality is configured. E.g. when parser caching is in effect, the conditional sections are not evaluated on a per-page basis. Consider using Extension:ParserPhase2 with Extension:ConditionalContent instead. Jean-Lou Dupont 19:38, 14 May 2008 (UTC)

So would it be shown when it is not supposed to be, be not shown when it is supposed to be, or both? Smaug 19:44, 14 May 2008 (UTC)

Both; consider user-related information available through parser-functions to be test-cases here. Jean-Lou Dupont 19:47, 14 May 2008 (UTC)

Thanks for clarifying. Smaug 20:15, 14 May 2008 (UTC)

Widgets (closed)

Hi, Jean-Lou,

I see that you released your SecureWidgets extension - it's great to see some competition in the field. Too bad you didn't have it developed when I needed the widgets ;)

You approach seems to be covering some things that are quite far on development time line for Widgets. Hope we'll be able to benefit from each other's work.

The only concern I have is that you're reusing widget code without giving credit to those who spent time creating it. Users who contributed the widgets (including myself) are not very happy with that. I hope you'll consider this a good practice to mention them.

In any case, I think it'll be beneficial if we'll figure out a way to combine our effort in creating widgets and maybe even developing the code - this will definitely benefit end users. --Sergey Chernyshev 15:49, 16 May 2008 (UTC)

Hi - I did inspire some of my widgets from your repository, that's all. Sorry for any harm done. I have added a note on the base-page of the extension attributing some credits to yourself. I hope you can forgive me. Jean-Lou Dupont 17:54, 16 May 2008 (UTC)

Jean-Lou, I wish you all the best in SecureWidgets development! Please don't forget that Open Source is not just about freely promoting yourself, but about contributing to community and giving credit to those who helped you. --Sergey Chernyshev 21:19, 20 May 2008 (UTC)

Well, it would be better if you credited the authors on the widget pages themselves. Yaron Koren 20:36, 16 May 2008 (UTC)

I am happy to oblige provided you tell me where, please. Could I also remind you guys that the embed code is readily available on the originating service web site e.g. Yahoo for Flickr etc. I hope we can conclude this matter swiftly. Jean-Lou Dupont 20:53, 16 May 2008 (UTC)

I'd say somewhere in the documentation part of each relevant widget (e.g. here). I created the YouTube and AddThis widgets, and I believe Sergey created all the rest on mediawikiwidgets.org. Obviously some of them weren't that hard to create, but the programming did take some work, in addition to writing the descriptions and such. Yaron Koren 21:07, 16 May 2008 (UTC)

Guys, I have added additional credits on the widget pages directly. If you are looking for these on my web-site, please bear in mind that the content of my site is mostly cached and refreshed every 2days. Thus, the updated pages should be visible then. I hope this conclude this aparte to your satisfaction. Jean-Lou Dupont 23:48, 20 May 2008 (UTC)

Cool, this is fine with me. Thanks. Yaron Koren 23:16, 22 May 2008 (UTC)

MediaWiki Question (CLOSED)

How I would be able to make it to where annon users can edit [[Project:Help Desk]] as well as talk pages, but nothing else. Thanks for your help.-71.221.196.127 01:08, 20 May 2008 (UTC)

Sorry I wasn't clear enough the last time around :- send me a private email on this subject. Jean-Lou Dupont 01:12, 20 May 2008 (UTC)

runphp tags: accessing $wgUser

Fatal error: Call to a member function getId() on a non-object in /home/content/d/e/m/demonscarnage/html/extensions/SecurePHP/SecurePHP.body.php(65) : eval()'d code on line 2

This is what I get when I try to use $wgUser->getId() within the runphp tags. Any suggestions as to how to get around it?

Did you insert global $wgUser; before this call? Jean-Lou Dupont 10:31, 20 May 2008 (UTC)

Thank you. I guess I didn't realize you needed to do that ;)