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. ? 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 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  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 . 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.


 * 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):


 * 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:


 * 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
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)