User talk:HappyDog

From TestWiki
Jump to: navigation, search

appreciation in the MediaWiki community[edit]

I am writing to express support for your work on WikiDB and also to say that it is disappointing that the importance of this type of effort does not seem to have been appreciated in the MediaWiki community.

I was wondering whether your work might not have a greater chance of support and indeed inclusion into MediaWiki if it wasn't (at least initially) more focused on a specific and perhaps more urgent problem, which I'll illustrate using the example of artists and their works.

To be quite concrete, here's the problem description.

The "infobox" for artists should provide detailed information based on a template and data in a table. For simplicity, I'll assume that it's just one row in a single table.

The "infobox" for a work of art should similarly be based on a template and data which (for simplicity again) I'll assume comes from two tables - one for artists, and the other for works of art. The data about artists that appears in the works infobox would presumably be a small subset of the available data, e.g. just the artist's name, birth and death dates.

The basic requirement then is to have a way to construct a pretty infobox based on one or two rows of data. The trickiness is how to specify an artist (assuming that combinations such as name, birth and death names will not suffice).

In other contexts, one could (perhaps) use the ULAN system for artists, but that is unsatisfactory if there is even a single artist for whom a ULAN number has not (yet?) been assigned.

A hash of the basic data would be OK if that data was invariant, which is not likely. An accession number is error-prone and raises portability difficulties, but so far as I can tell would probably be the best general approach. Anyway, let's suppose an accession number is used.

For this to work, I believe that a "data-driven data entry form" for creating a record will be needed. Let me explain why.

We can use the template mechanism for defining new tables, but there has to be a way to perform the usual database operations. This effectively requires a form whose content is determined by the table definition.

For example, let's suppose Template:Define Artist defines the fields of the Artist table in some declarative manner. Then Special:Table page would allow all the CRUD operations:

This scheme I believe resolves all the significant issues except one:

  • What happens to existing records if the "Define Artist" template is changed?

Simplicity, I believe, would argue for adopting a rule to the effect that a table-defining template cannot be changed if there is any data that would be invalidated. This would, for example, allow more fields to be added, or the name of a field to be changed if there were no records with a value for that field.


Peter Koppstein (

The Consumerium development project[edit]

Hello there HappyDog. I've been the lead developer/researcher/designer/strategist for The Consumerium development project That wiki is now closed for editing (the wiki got badly spammed-out/vandalised making contributing almost impossible. Also internal incoherence reached a level due to many changes in the design paradigm that effectively obstructed making sense. But the work continues now in (Which is an attempt at an "implementation"-phase).

I invite you most warmly to register there so we could discuss how WikiDB could potentially be a solution to some serious problems regarding redundancy and needlessly high level of manual editing. I also sent you some emails but have received no reply. Otoh it might be better to discuss WikiDB and it's future development lines and application to making Consumeria a reality here, in this wiki, might be a better idea as it might attract more interested individuals to this development wiki if there were active discussions/planning going on around here.

The mission statement of Consumeria is simply to "enhance consumer informedness" and I really hope it is a cause that more people would find worth pursuing. Anyways, WikiDB extension seems very well thought out and promising. Best wishes --Juxo 18:43, 3 October 2007 (BST)


Simply amazing! Keep up the good work. I do dabble in PHP and SQL, so if I can be of any help, i'll try to help out where I can. I'm not an expert programmer, but if I can help. I would love to. I'll check my user page here occasionally if you need some help. Tazzy 01:14, 19 January 2008 (GMT)

Thanks Tazzy! There is some active development going on at the moment which will open the door for some cool new features soon... Keep checking back for more info! --HappyDog 01:09, 29 January 2008 (GMT)

Questions concerning transclusion/inclusion within a namespace[edit]

Hi there! First I want to thank you for the wonderful NonincludableNamespaces-Extension. I was wondering if you have any ideas how to allow include actions within a namespace, but disallow them inbetween namespaces. Is there something like an inclusion-from / inclusion-to concept?

Thanks. As far as I know there is no way of doing that, but there are hundreds of extensions out there, so you may be able to find something. The NonincludableNamespaces extension is purely to provide this now-standard MW functionality to earlier versions of the software, so it is not something that I would consider adding extra this feature to. --HappyDog 14:24, 10 March 2008 (GMT)
Thank you for the response. So... good reason for me to understand the nuts and bolts of the mediawiki code. Wish you a nice weekend. Thank you for the response. -- 16:25, 30 March 2008 (BST)

I love you HappyDog[edit]

I love you HappyDog, what a great Extension?? Hope to see a new verison soon. Jimmy

Thanks!! :-) --HappyDog 10:51, 21 July 2008 (BST)

HappyDog, What Do You Think Of...[edit]

HappyDog, first off for taking an interest in this effort. It is hugely important to me that someone has finally decided to work on this.

My question pertains to the possibility of how I might use this on my Wiki.

Our site specializes on rare NASCAR racing results. We would very much like to mimic the style used by a major series reference sheet without compromising the flexibility and editabilty of our tables. Ex. 2002 Aaron's 312 Race. If you clicked on that race you would view race results (simple, right?). However, when you click on a driver's name (say winner Jason Keller), you would get a very detailed (and obviously very finely tuned query code) individual database. Obviously, typing in data for every driver manually is a pain.

Do you think your extension could encompass that idea. I know I would have to do some work to get the query as effective as that, but it'll be worth it. If you think it'll work, I'll gladly get the extension installed and give you feedback. -DaNASCAT (on Wikia)

I think it should do what you want, at least in theory. The query syntax is a bit basic at the moment, but what you want should be possible - if not, then that's something that needs fixing! I suggest installing the latest version and trying it out - please let me know how you get on! --HappyDog 14:04, 9 September 2008 (BST)

PersonalisedHomepage extension compatibility with Mediawiki 1.18[edit]

Do you have any plans to update your PersonalisedHomepage extension for Mediawiki 1.18? Currently it fails with this error displayed in the browser:

Fatal error: Call to a member function addMessages() on a non-object in C:\Inetpub\wwwroot\mediawiki-test\extensions\PersonalisedHomepage\PersonalisedHomepage.php on line 45

Sure enough the $wgMessageCache object that's referenced on line 45 is removed in MW 1.18. AndyL 17:05, 21 February 2012 (UTC)

Update... I've had a play with it myself and I think I've got it working. However I'm unfamiliar with both PHP and the Mediawiki API so I'd appreciate some feedback on whether what I've done here is sensible!

First change was to comment out line 45:

// $wgMessageCache->addMessages($pPERSHOM_Messages);

$wgMessageCache can be replaced with MessageCache::singleton(), but the addMessages method has been removed from the MessageCache class as well. Since $pPERSHOM_Messages doesn't actually contain any messages anyway, can we get away with just removing this call?

Second change is to line 55 - MediaWiki::getVal("action") seems to have been replaced by MediaWiki::getAction(), so this becomes:

if ($mediaWiki->getAction() == "view") {

AndyL 18:00, 21 February 2012 (UTC)

Hi AndyL - Thanks for your suggestions! I hadn't tested in 1.18, so didn't know it had been broken. I've incorporated your changes into the extension, and put the latest code live on the extension's description page. Note that instead of using $mediawiki->getAction(), I used $wgRequest->getVar(), as this works on 1.18 as well as continuing to work on older versions (I currently support as far back as 1.6!). The messages code could simply be removed - you're right, it was totally unused! Thank you so much for your input. --HappyDog 22:49, 22 February 2012 (UTC)

common library catalog for minority languages[edit]

Dear friend; I used to contribute at LibraryThing: profile/gangleri. The events at R'lyeh where origininaly linked to zemdlekh-זעמדלעך which means grains of sand in Yiddish.
I would be happy to get your extension running as a common database for minority language libraries from all over the world using some sort of w:MARC standards. Please see allso Adding BVB = Bibliotheksverbund Bayern = OPAC of Bavarian Libraries as book source.
I try to be on irc #kavehoyz on a regular basis using the nickname gangleri_back . Best regards Gangleri 12:24, 19 January 2014 (UTC)

Question about WikiDB criteria[edit]

First off, thank you so much I have used WikiDB in a number of mediawiki installations I have done. It is an incredible extension! Very good for technical documentation.

My question relates to conditions with the repeat tag. Is there a string contains or a wildcard I can use with the criteria? Eg

<repeat table="Servers" criteria="os=Win*">

This would get all windows servers.


Hi there - thanks for your kind words. The feature you're after is not currently implemented in WikiDB, but it is a good idea and I will see if I can add it soon. --HappyDog (talk) 22:03, 12 September 2017 (BST)