Wiki/MUX SQL function request

surreality

There is something I would really very much like to see happen, and I cannot code for beans. I know even less about SQL and the wiki-to-MUX or MUX-to-wiki integration.

It would, ideally, be one function. (It may need other functions it might be dependent upon; I do not know enough about MUX code to know if it will or will not.)

I do not think it would likely be an easy thing. I just know that for the kind of wiki-fu I screw around with, it would be amazingly useful.

What I'm picturing: name of the function could be anything that doesn't conflict with something else, I'm just going to call it 'wikiyank' here.

[wikiyank(namespace,pagename,template variable)] -- something roughly like that.

Namespace and pagename should be fairly self-explanatory; by template variable, I mean something like this:

{{Template
|variable01=something
|variable02=something else
|variable03=something else entirely
|variable04=and another thing
}}

so it'd look something like: [wikiyank(namespace,pagename,variable03)]
in the code, and that would spit out: something else entirely
as raw text.

(Some of the things I want to use this for could arguably just be a page of raw text brought over through existing methods. Others, no, as this would mean scads of specifically named pages consisting of something like the number 3 and nothing else. <eyetic> Not doing that.)

This may be even more complicated than it sounds because the delimiter you'd expect you'd want to look for -- the pipe symbol -- is used throughout a whole lot of other wiki code. If necessary, I may be able to work around that, but I can't guarantee it.

Also, super curious if anyone has managed to find a way of sending the output of +events or similar code from the MUX to the wiki -- or can think of a way the wiki could populate something along those lines to send to the MUX. I can set it up to force a raw text output for that, but I suspect it's not that simple.

I have no idea what I could potentially bribe anyone with to try to accomplish this, or what would need to be set up server side to allow for it. I just know that at this point, it would be incredibly useful, and have the potential to make my life about 10x easier. It would be sincerely appreciated.

(I make beaded jewelry -- yes, some of it can be worn easily by dudes and/or I can make pieces that are -- and dye yarn and wool roving, so if by some strange miracle there's someone into either of those things, has a significant other into those things in need of shiny stuff, or similar, I would happily send some of either or both as a thank you. You can probably guess how likely money is in this scenario because I make beaded jewelry and dye yarn for a living. These are... not exactly cash cows on the best day, unfortunately. )

skew

Short answer: It'd be a little tricky, or a lot sloppy, but is doable.

Long answer: The data is not stored "in" the template. The database is stored exactly as you see it when you edit your page. It's when you call that page that the wiki renders all of that information, and calls whatever templates are in use. This means there's no table that holds all the people using all the templates, all the data they've entered, etc.

How I'd do it is essentially specify the variable, then trim everything before the variable. Then look for the next pipe, and trim everything after it. I'd have to do a little more studying on SQLing to get that going, but it think the concept is sound.

As for +events, I could see a few ways of easily doing it. Output the data from the MU into an SQL table, then have MediaWiki query the table on demand. It looks like there's a few options ( https://www.mediawiki.org/wiki/Extension:SQL2Wiki ) but they are all flagged as dangerous, or a security risk, because you are meddling with the database. I'm not sure if it's possible to lock an extension down in a way that it only functions when an admin type is the one to first use it.

All in all, it looks possible. Personally, I wouldn't have time to think any harder about this for at least a week.

surreality

@skew The tricky bit is the pipes, definitely. There are workarounds for that wiki-side -- but mediawiki uses pipes everywhere. I have the pipe template ({{!}}) in place already in some of them, since mediawiki's own code loves to barf all over them entirely on its own.

It may be a case of 'only some pages can get yanked' -- and ensuring the things that people would want to yank from those pages doesn't have pipes present. Problem being, I'm not 100% sure when it parses the pipe template, so even if it's swapped in so there's no pipe in the raw text, it may be swapping the pipe in when it gets yanked. That's what I'm not sure about.

I am not a coder, so even the events suggestion is beyond my abilities. (I just wiki weird things into being, pretty much.) Poke me if you are willing to look at it later on, though -- and if you want yarn/jewelry bribes?

Roz

God I'd love this for PennMUSH

Bobotron

I would maybe dig into @Mercutio 's SceneSys which chucks stuff TO the wiki via SQL, might be something in there that's reverse-engineerable?

surreality

Magic has been made to happen on this front, but I'll let the magician announce themselves if they wish to do so.

So very, very much on this one.

Mercutio

SceneSys does not chuck into MediaWiki through SQL. It uses the Semantic Forms' ability to take POST requests and sends logs through that medium.

MediaWiki changes its SQL schema too often. So that was a far more viable method of doing it.

I do have some code laying around somewhere to pull pages from SQL. But it's not clean, nor can I recommend it.

You may want to look into just isolating this to Semantic Properties. That'd make your life a LOT easier.

surreality

@Mercutio We've got it running, actually -- though I would love to see the SceneSys code as well. We do have Semantic Forms installed.

Mercutio

Volund has an improved version of SceneSys. I've not done any new MUSH project coding in a while since my stint at trying to get the Entity Framework going. (Graph based SQL backing for MUSH storage. Hit a big roadblock.).

You can find his package around on... GitHub I think it is?

skew

@surreality When you gonna share?

surreality

@skew It's giving us some quirky timeouts, so once that's no longer an issue, I'll pass it over to ya.

Roz

Is this something that's only going to work on MUX?

somasatori

@Roz If I'm not mistaken, Rhost allows you to have SQL integration. I'm pretty sure PennMUSH does not; I'm not sure about MOO, or MUD codebases like Circle. I think Circle would be one of the few that would work with it, given how complex it is. You could probably get it to work with MOO, since you can customize the fuck out of that platform.

Edit to add: SQL injection is what causes wiki-to-MUX framework possible. Somehow @Chime got it to work and I stared at her with starry eyes.

Glitch

@Roz @somasatori It's totally doable in PennMUSH if you configured the game with mysql enabled.

somasatori

@Glitch Right on, I had no idea Penn had progressed to that point. Good to know if I ever get my grimdark Pugmire game up and running!

Thenomain

@somasatori said in Wiki/MUX SQL function request:

grimdark Pugmire

You made me a little sad thinking about this.

somasatori

@Thenomain said in Wiki/MUX SQL function request:

@somasatori said in Wiki/MUX SQL function request:

grimdark Pugmire

You made me a little sad thinking about this.

You could help me with this project Theno.

Thenomain

@somasatori said in Wiki/MUX SQL function request:

@Thenomain said in Wiki/MUX SQL function request:

@somasatori said in Wiki/MUX SQL function request:

grimdark Pugmire

You made me a little sad thinking about this.

You could help me with this project Theno.

Only if there are dog scientists that wear chocolate labcoats! (Pun not mine; thank or blame Hey Ash Whatcha Playin'.)

somasatori

There would also be dogs short enough that the wouldn't be able to peer above the knees.

Ha! Ha! Ha! Ha!

Mercutio

@somasatori

Only since December of 2002