I found a similar solution now, without using the internal function.

function renderer($input) { global $wgTitle,$wgParser,$wgUser; $output = $wgParser->parse($cal->getCurrentMonthView(), $wgTitle, ParserOptions::newFromUser($wgUser)); return $o->getText(); }

but I still think there should be a way for extensions to use the parser without hacks like this.

christof

On Fri, 21 Jan 2005, Muzaffer Ozakca wrote:

The solution below was offered by a hacker on this list a couple months ago.

function renderer( $input ) { global $wgParser;

...

 // pass $input to wiki parser
    $output = $wgParser->internalParse($input, true);

...

    return $output;

}

I'm aware that it works for images. It probably works for other kinds of links, too. This might fail to work for some other things, though.

Using this occasion, I'd like to thank to the person who came up with this solution in the first place, Jean-Christian Imbeault. Saved me a lot of effort.

...

From: mediawiki-l-bounces@Wikimedia.org [mailto:mediawiki-l- bounces@Wikimedia.org] On Behalf Of Christof Damian Sent: Friday, January 21, 2005 10:41 AM To: MediaWiki announcements and site admin list Subject: [Mediawiki-l] extensions and wiki markup

Hello, I wrote a tiny calendar extension for mediawiki to use it on my techno wiki website. It works allright, but I would like to improve it.

I used the example from http://meta.wikimedia.org/wiki/Write_your_own_MediaWiki_extension , which states "This function can then return a HTML string that gets inserted into the output in place of the tags and text. Note that the return string should be HTML, not wiki markup."

Is there any to implement extensions which can use wiki markup? Currently I have to implement Links with class Title and Article, basically reimplementing the [[link]] syntax and that doesn't even work nice with all skins.

I also might want to use templates and images in the calendar output.

Or is there an easy way to parse a string and get an html in return.

Christof

---

MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

I will soon need to create thousands of pages with a standard bit of text on each. Is there any reason that I can't just use php and add records to the "cur" table, putting values in the "cur_title" and "cur_text" fields? Do I need to set values in any of the other fields of the "cur" table, or any other tables?

(The text is just a set of extension tags, with the Page Name inside. Additional text can be added later by users using normal wiki methods.)

James

I got brave and tried a test, using phpMyAdmin to manaully insert a row. I don't see any obvious problems yet. I put my user id in but see that it doesn't lookup my name, and have to enter that manually as well. The "cur_random" I'm guessing is for the "present random article" logic, and an ordinary random number generator value could be placed in there. I presume the "cur_isnew" flag is primarily for "present new pages" logic, but I may not want to flood that page anyway. Most of the other fields have default values that seem to be fine.

At 06:54 PM 2/6/05, you wrote:

On Sun, 06 Feb 2005 03:59:32 -0600, =James Birkholz= j.birchwood@verizon.net wrote:

...

I will soon need to create thousands of pages with a standard bit of text on each. Is there any reason that I can't just use php and add records to the "cur" table, putting values in the "cur_title" and "cur_text" fields? Do I need to set values in any of the other fields of the "cur" table, or any other tables?

Well, I'm no expert on the database structure, but I'd imagine you'll have to put *something* valid (in the sense of vaguely similar to what MediaWiki would have put there) in *every* field of the cur table, else MediaWiki'll get mighty confused when it tries to do something like display the page history . Importantly, get cur_namespace right - don't be fooled into thinking there are articles called things like "User:Foo", when they're actually called "Foo" with cur_namespace=2 (you may know this already, but I think it's a reasonably common "gotcha", so worth pointing out). Also, I'd create a "fake" user to assign the edits to, and call it "Content seeding script" or something appropriate to show up in the page histories.

As for other tables, there are various scripts in the 'maintenance' directory for rebuilding various things, such as recentchanges, the links table, etc. It might be worth running at least some of those to make things consistent after your mass changes.

-- Rowan Collins BSc [IMSoP] _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

James Birkholz admin, Posen-L mailing list and website http://www.Posen-L.com

Hoping that I won't soon be slapping my head and screaming "doh!", how does one do that?

At 09:24 AM 2/6/05, Dori wrote:

If you're writing an extension, why bother with passing the name of the page that way instead of getting it directly?

-- [[en:User:Dori]] _______________________________________________

I've never used classes yet, is there something else I need to do to use this? Do I need to create an instance or declare a global?

At 10:20 AM 2/6/05, Dori wrote:

On Sun, 06 Feb 2005 10:29:03 -0600, =James Birkholz= j.birchwood@verizon.net wrote:

...

Hoping that I won't soon be slapping my head and screaming "doh!", how does one do that?

I haven't looked at the code in a long time, but something like $this->mTitle->getText();

--

Jan Steinman wrote:

Unfortunately, passwords are a problem. It appears to be some hash on the user name, since I tried copying and pasting the password data from one user to another, but the user for which I pasted it cannot log in with that password!

The hashes are salted to make it harder to bulk brute-force users' passwords if the hashes are leaked.

(You can turn off the salting to use a system where password hashes can be copied from user to user, but this is a) less secure and b) will invalidate all existing passwords, requiring them all to be reset. See settings in DefaultSettings.php)

Before I go crawling through the code, does anyone have any hints or alternatives by which I can bulk-enter password data for users to use?

The hashing algo is MD5(CONCAT(user_id,'-',MD5(password))).

Will the 'user_newpassword' field behave better for this sort of thing?

AFAIK it's hashed the same was as the main password.

-- brion vibber (brion @ pobox.com)

On 1/21/05 9:38 PM, Brion Vibber wrote:

Thanks for the response.

Scot Hacker wrote:

...

I recently had to turn PHP safe_mode=on for a shared server, and now a user running MediaWiki is having trouble since his scripts can't write to /tmp.

Try 1.4beta5; the default skin no longer uses the PHPTal template library and does not require storing a compiled template script file.

That's the version we're using. Using the monobook skin. I didn't realize that skins contained behavior/program logic - that's kind of surprising. The guy is pretty attached to this skin. No other workarounds? Would be nice to just have a $Tmp= option in the config.

If you still have problems, it would help to know exactly which files it's trying to work with in /tmp.

Hrm. What's the best way to find that out? (/tmp has tons of stuff from other apps intermingled).

Thanks, Scot

On 1/22/05 12:02 AM, Brion Vibber wrote:

The version of MonoBook in 1.4 doesn't use any temporary files, so there would be nothing to configure.

Make sure that you have completely replaced all script files; sometimes people end up with a strange mixture, or put in a new set of files but have their configuration load up the old version of code from another directory instead.

Looks like that was it. I just did a fresh install, keeping the old LocalSettings file, chowned his stuff back to his name, and all is working. Thanks for the tip!

Scot