Extension talk:LiquidThreads/Archive 1

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

Very old discussions: m:Enhancing talk pages

Those who do not understand Usenet are doomed ...

Initial comments

... to reinvent it, poorly." - Henry Spencer, some time before 1995. All web forums I've ever seen are examples. What does LiquidThreads do that an NNTP server with a group per article couldn't do? (Of course, there are problems, e.g. a .newsrc listing a million groups ...) - David Gerard 13:43, 20 Jan 2005 (UTC)

Have you looked at this? -> http://www.jibble.org/piespy/ The LiquidThreads concept reminded me of some of Jibbler's experiments. Quinobi 20:41, 8 Mar 2005 (UTC)

Sure, Usenet is one option. I agree with the spirit of your post which is not to invent yet another discussion system, and then spend the next decade rediscovering all the hard lessons everyone else learned about handling abuse, personalisation, account management, etc etc. I'm not sure Usenet is very appropriate however because it is designed for distributed discussions and WP is clearly in the centralised mode.203.114.139.185 06:52, 1 December 2007 (UTC)

When? Hi, I'm very interested in this since I'm hoping to start a wiki or two where forums (vs. current talk pages) would be a huge plus. If anyone has any more info on whether or when this might be incorporated into MW, drop me a line of you don't mind. Zach 16:58, 11 Apr 2005 (UTC)

It isn't in development or on the roadmap. R3m0t 14:34, May 19, 2005 (UTC)

There is a Wiki called fuwiki (short for "FUCKUP Wiki"), which is basically a wiki trying to work like a forum while still giving its users all the wiki options. You can find it here. If you want to see a running instance of this wiki, go here. --Elfboi 20:10, 7 November 2005 (UTC)

---

How are time stamps added to this page?

The MediaWiki software automagically timestamps your edit if you add five tildes (~~~~~). Four tildes adds your username and the timestamp if you're logged in or your IP address and the time if you'r not. Three tildes adds only your user name or IP address. This is all basic stuff. See Help for much more information about how this all works. Quinobi 17:19, 4 March 2006 (UTC)

Nomenclature

Why is it called Liquid Threads, anyways? DavidMcCabe 04:00, 3 May 2006 (UTC)

Ermm... you can move them between pages like liquid! 212.85.21.28 09:53, 5 May 2006 (UTC)

Problems

It think that it is a problem that one can move the channels around! This means that if I comment on one page, then someone can move the channel/comment to a page where it is out of context and make me look like a fool. --130.225.29.254 14:36, 25 May 2006 (UTC)

Only if no one looks in the edit history. If that's the case, anyone can do that now by cutting and pasting. —Simetrical (talk • contribs) 03:17, 1 June 2006 (UTC)

---

Hi there, I just installed LiquidThreads and right away I'm getting this error, I can't figure out why:

Fatal error: Call to undefined function wfarrayinsertafter() in /home1/public_html/wiki/extensions/LiquidThreads/classes/Hooks.php on line 425

Any ideas what I should do with this? I'm using MW 1.15.

Same problem with MediaWiki 1.15.1 here (using LiquidThreads revision 63022). The function wfArrayInsertAfter() seems to be a global MW function -- the extension works for me on MW 1.17alpha. For testing I've copied the function from 1.17a to 1.15.1 and got "Magic word 'useliquidthreads' not found" now.

I had the same problem. I fixed it by removing my "LiquidThreads" folder from the extension directory and did a re-checkout from svn using the /branches/REL1_15/extensions/LiquidThreads instead of the trunk version. Using MediaWiki 1.15.3 --Sxtynnmach1 15:29, 19 July 2010 (UTC)

Running 1.15.1 I followed this advice - removing the trunk version and checking out the branch rev. The branch version resolves the issue with Hooks.php, but now I get a MySQL error when I try to start a new thread -

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "Threads::newThread". MySQL returned error "1054: Unknown column 'thread_change_type' in 'field list' (localhost)". --Enterprise user 16:31, 28 July 2010 (UTC)

After I edited my signature, the post displayed the message: "Edited by 0 users. Last edit: 07:00, 22 August 2010". Very confusing. Kaldari 07:05, 22 August 2010 (UTC)

Conflict

Im getting a conflict by using LiquidThreads & the extension SelectCategoryTagCloud. Everytime ajax loads the comment form. The category cloud is opening in a new tab (opera9.).

Question/suggestion

I'm not sure I understand this project fully, but would LiquidThreads make it possible for posts to be made to two different user talk pages at the same time? That is, someone posts on my "talk page", and I respond on his "talk page", but on both pages the full conversation is visible. A real weakness right now is the fractured discussions when two people discuss something via user talk pages. --Spangineer^[en] [es] (háblame) 15:24, 26 May 2006 (UTC)

Editable comments

The author of a comment can determine if other users may edit it.

I strongly disagree with this idea. SoftSecurity is one of the great strengths of wikis. Rarely does anyone edit anyone else's comment to vandalize or substantially modify it, and this is easily detected and quickly censured. Much more often, comments are edited to fix formatting (consider the newbies who try indenting their posts with spaces at the beginning of the line), subst templates that should be substed (such as boilerplate user talk messages), or to delete spam. Some also edit comments to remove personal attacks; this is controversial, but there's no consensus against it at least on the English Wikipedia, so prohibiting it by technical means is unreasonable.

So if this is going to be in the package, make it optional, perhaps per-usergroup. It shouldn't be imposed. —Simetrical (talk • contribs) 04:25, 1 June 2006 (UTC)

I agree. Ability to edit user comments is very important. In many ways, it makes every user a "moderator" (in the conventional forum sense) which is very much the wiki-way. — Ambush Commander^(Talk) 22:01, 17 June 2006 (UTC)

Possibly this could be a site-wide option (as to whether posters can chose whether others can edit their comments)? Wikimedia wikis wouldn't use it, but some other wiki installations might find it useful.

James F. (talk) 12:36, 18 June 2006 (UTC)

It should be possible for an admin to lock a thread which has been identified as "toxic" or somesuch, however, to prevent the continuance of a discussion which is liable to cause actual harm… —Phil | Talk 13:26, 19 June 2006 (UTC)

Well, admins don't have that ability right now... except maybe to RFC someone. Is that really necessary? — Ambush Commander^(Talk) 14:09, 19 June 2006 (UTC)

It is possible to protect a page, which in the case of a discussion page would have the effect of locking all discussions thereon. The point is that LiquidThreads allows a much finer granularity, so a particular discussion could be locked down leaving others to continue without interruption. This is not a revolutionary concept in bulletin-board systems which LiquidThreads is attempting to simulate. HTH HAND —Phil | Talk 08:20, 20 June 2006 (UTC)

Blah, blah. You're opposed to it on the basis of some ideological persuasion. A comment that someone makes has always been that person's comment. Nobody should have the power to modify it -- only if the speaker says they can. This is how a conversation is different from a collective work. -130.49.221.7 00:49, 20 January 2007 (UTC)

On the en.wikipedia at least, it's really important to be able to edit others' comments. That's how we handle requests to edit protected pages, replace templates when they're being deleted, fix erroneous category links, etc. It would be a maintenance nightmare if it took an admin just to replace templates, or had to run bots with admin rights to edit talk pages. 68.40.167.173 11:42, 27 May 2007 (UTC)

Link system

Cross posted from: [1]

Although subpages would be the preferred manner for a new special page, there might be some problems integrating it into a Talk page.

Besides hooking it in to MediaWiki (while Special Pages make passing everything after the slash easy, I'm not that sure about talk pages), there could be collisions if you need to keep the old talk pages hanging around.

However, making them subpages does have a significant aesthetic appeal. I would imagine it would look like this:

[[Talk:Article/Channel/Thread#Post_id]]

I would strongly advocate meaningful titles as opposed to numeric IDs. MediaWiki follows a strong convention of using unique meaningful ids for the interface while keeping a non-meaningful integer id inside. Also, I don't think paginating the discussion would be beneficial (it would definitely make linking to posts easier). — Ambush Commander^(Talk) 22:00, 17 June 2006 (UTC)

Great idea - offer to contribute

Message board functionality on Wikipedia would save an immense amount of work and encourage greater participation. Some of the most serious issues that I've enumerated with wiki-based discussion include:

• Manual archiving, and difficulty in searching after manual archiving
• Edit conflicts
• The need for new users or one-time users to understand section and signature syntax, and that new sections go at the bottom.
• The problems associated with manual formatting, such as missing indents and the confusion resulting from the convention of "resetting" nesting back to the left side (who is the next reply replying to?)

With real message boards, a multitude of frustrations will evaporate, and this proposal seems to get more or less everything right. I'm a PHP coder with Mediawiki experience and I'd be happy to help in any way I can with this project, and point other interested people to it as well. Deco 21:04, 28 June 2006 (UTC)

Reply notification

I'm a non-intensive wikipedian; that is, I go around making general improvements to deficiencies I happen across in my browsings (as random as it gets sometimes). Rarely, I'll post something on a talk page. When I do, I'd like the wiki software to tell me (like that big brown box that says when somebody posts on *my* talk page) when somebody replies to my post.

All things considered, I think this whole project is marvelous, and the constant progress and improvements being made speak loudest for the potential herein. Excellent work, everyone (except the trolls)! w:User:Xaxafrad (why doesn't my account copy to other wikimedia projects? or at least the parent ones) 68.6.27.235 23:49, 13 July 2006 (UTC)

Channels vs Threads

Hey lookit me! I have a meta account now (read the above anonymous comment). If my ideas are bad, can you not ignore them, but instead tell me why they're bad?

Should I edit the (project?) page directly, or appeal for changes here?

Anyway, channels vs threads...why are they different things? I've tried understanding these from a conceptual point of view and one or the other seems redundant. Maybe I need an example of a channel containing several different threads. Why not simply have threads with comments? I've tried studying the mock-up picture and it seems overly complex. Remember w:K.I.S.S.? Don't diverge too far from the original, just put some make up on it. Start by codifying the ID numbers for individual comments, that should be the foundation. On top of that, you can design a plethora of presentation paradigms (sorry for the alliteration, it just kinda came out). Maybe they could be made customizable like the skins in our monobooks? If each comment is like an article's subpage, then couldn't some tricked out esoteric template process each comment, read subject lines and summaries from the header, and display the content when somebody clicks on the titles?

You guys have been at this for months, and have probably already come up with and rejected these ideas for various excellent reasons, but maybe not. Xaxafrad 05:18, 29 July 2006 (UTC)

Synchronised threads on usertalk pages

This page was recently mentioned to me by w:User:Piotrus. I think it's a brilliant idea, and I really look forward to it. Just one question, though: it doesn't seem to support another useful tool: synchronised threads. Synchronised threads are subpages where a conversation occurs that are transcluded to the userpages of the users involved. They help make talkpages more readable by keeping the entire conversation in a single location. Ingoolemo ^talk 22:22, 13 August 2006 (UTC)

Why not xanological structures?

If we have wiki and discussions, why not take it all the way and implement (or adapt) token_word or http://www.abora.org , as first articulated by w:en:Project_Xanadu. This would be better than a discussion forum, because (among other things) it would keep each comment connected to all the comments about it or parts of it. It will also automatically track all changes to documents. It is a more general and useful framework than wiki or discussion forums. All it requires is that the comments and links between them be stored separately, and that links be able to reference arbitrary parts of text, indexed (for example) by the number of characters from the start of the document. -130.49.221.7 04:23, 20 January 2007 (UTC)

LiquidThreads to complement Talk pages, not to substitute them

I think LiquidThreads may be even more interesting as a complement for talk pages instead of as a substitute.

Talk pages often contain some content about an article that remains valuable for editors but has no place in the article itself. This can, for example, be sources, evaluating comments about source, sources that have become invalid or unavailable or agreements about style and content of the article.

Talk pages also contain some amount of small talk or noise, which may also sometimes arrive at valuable conclusions. A sensible application of LiquidThreads could be to keep debates in LiquidThreads but to retain the Talk page as a place for summaries of debates or other content with permanent value for editors. --Fasten 11:38, 25 February 2007 (UTC)

While I think LTs are a wonderful idea, and I've been hating Mediawiki's idea of discussions for some time, I do agree that having both is a big plus. There are some things that despite my aversion to them I have to admit comment pages ARE good at.

One thought that occurs to me is instead of mucking around in the Talk: namespace, maybe a Thread: or Forum: namespace would be more appropriate. So that you would have Thread:Article/Channel/Thread/message_id (or whatever you come up with to identify each message uniquely). This would also be helpful in upgrades so you would not clobber existing sub-talk-pages where they already exist. The downside of course is figuring out how to integrate the namespaces into existing Wiki namespaces, since right now they use the even/odd namespace IDs... personally I think that was a bad idea, and that talk namespaces should have been a sub-namespace of some sort, but that's an entirely different ball of wax. --24.23.186.34 01:26, 2 April 2007 (UTC)

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.

The separate namespace idea is a good one; I, too, don't like the idea of having LiquidThreads replace the existing Talk pages. The new namespaces are also good ideas, and making things like Forum:, User forum:, Template forum:, etc. would be a good idea. It would probably require re-numbering the existing namespaces, and it would confound the existing even/odd model, but it should be pretty easy with an update script.

Perhaps that issue could be partially resolved by simply adding namespaces at a different point in the number line. Maybe numbers from 0-199 could be reserved, instead of 0-99 as it currently is in MW 1.10.0, and the numbers beginning at 100 could be used for the new NS's. 100 could be Forum:, 102 could be User forum:, 104 could be Project forum:, etc. That could be a solution. Not sure what to do with the odd numbers 101, 103, 105... Perhaps another new MediaWiki feature will be developed to use those. The only problem is, it makes adding new namespaces more complicated, since this scheme only works with numbers less than 10; this means it wouldn't even work with the current revision of MediaWiki, which has namespaces -2 through 15 defined as of SVN r22580 of Defines.php.

Barring that unlikely scheme, it seems that MediaWiki would be rewritten to use four namespace numbers per namespace: NS, NS_TALK, NS_FORUM, and an unused NS_BLANK for another, future feature. But I'm just rambling ;) — Tuvok[^Talk/_Contribs] 09:03, 28 June 2007 (UTC)

I'd just use discussion/talk for LiquidThreads, replacing the previous talk pages and add a new page draft/concept that allows to post conclusions and decisions from the discussions. --Fasten 16:23, 26 July 2007 (UTC)

The way I imagined this, each comment would accept the full Mediawiki syntax, for including examples and so on, and there would be a communal area at the top of the thread that all can edit, like a "Sticky" post that anyone can edit. Omegatron 01:32, 6 June 2008 (UTC)

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

Private userpage threads

Having run various electronic forums for years and years (like since 300 baud was neat), one thing I can tell you is that correcting someone's mistakes in public sometimes is not a good idea. You can, no matter how gently, take a contributing member and turn them away, or worse, turn them into some sort of monster. People just don't take it well.

That being the case, it may be nice for at least admins at various levels to be able to start private threads on the user's page where he and the user can discuss problems behind closed doors. Should not be all that hard to implement. Maybe have a special 'private' channel on the userpages, and only the user and the person who started the thread can read it. --24.23.186.34 01:50, 2 April 2007 (UTC)

The times they are a-changing. By that I mean, people WILL get used to it. By simply removing privacy, people will unavoidably CHANGE. __meco 06:32, 5 June 2007 (UTC)

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.

We have run talk pages on which people can edit each others mistakes in public for years, and it's worked just fine. :) Omegatron 01:47, 6 June 2008 (UTC)

Status

What is the status of this? Summer of code 2006 is not really currently happening as the article suggests, not? ;-) --Axel Kittenberger 09:23, 20 July 2007 (UTC)

Public beta since a few days. The test wiki is at wikixp.org. --Tgr 20:30, 14 September 2007 (UTC)

Fairly stable right now, could probably be used in a production environment. Some enhancements would be nice though (might work on developing some). MinuteElectron 11:31, 12 August 2008 (UTC)

Access to undeclared static property: SpecialPage::$mStripSubpages

PHP Fatal error: Access to undeclared static property: SpecialPage::$mStripSubpages in /home2/web/mj41/docroot-test/w/extensions/LiquidThreads/LqtPages.php on line 912. See my Special:Version LiquidThreads is r26766. -- mj41

try this: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/SpecialPage.php?revision=26820&view=markup

Cannot replicate in current version. MinuteElectron 11:29, 12 August 2008 (UTC)

Main project

Any chance of Liquid Threads coming to the main project, that is to Wikipedia? To make you see what frustrating Wikipedia situation I'm coming from, I've been re-directed to this place from this threadw:en:Wikipedia:Village_pump_(proposals)#Talkpages_structured_like_forums. --Tlatosmd (talk) 21:45, 26 November 2007 (UTC)

Very unlikely, especially until it becomes more maintained and widespread. MinuteElectron 11:30, 12 August 2008 (UTC)

Does not work on 1.11

I tried to test it with a clean 1.11 install, but absolutely nothing happened. Special:Version shows a bunch of functions named lqtSomething, there is a thread namespace, but both that and the talkspaces behave like any other namespace. Did I miss some sort of configuration setting? Or does it need a newer/special version? (I didn't find the liquidthreads branch in SVN, so I supposed it has been merged.) --Tgr 11:37, 1 December 2007 (UTC)

--I second this, I did a clean install on 1.11 and nothing happened. Phillip

--Same frustrating experience for me as well. Steve

--The same case. kati

--- Works for Wikieducator.org with MediaWiki 1.12alpha (r31084). See: [2] ~ Phillip

-- Any solutions on the not working in 1.11? I Experience the same problem. Maybe something with DB prefix? Did some fiddling with that. Parser function hooks and hooks do show up in Special:version. Would like to get this working ... -- Jac

It could well be that this extension hasn't been developed with old versions in mind, you may be able to use a branched version of the extension - but all current development in trunk will always be targetted at the development copy of MediaWiki. MinuteElectron 11:28, 12 August 2008 (UTC)

translation

In the last days I started to complete the german Translation for LQT-Extension. But many things are still hardcoded. I hope it will not be much work to complete outsourcing the Messages, because I would like to complete the translation and I could use it in my german Wiki. Please make it fast. -- 134.147.154.66 11:59, 2 April 2008 (UTC)

Appears to be fully translated now. MinuteElectron 11:27, 12 August 2008 (UTC)

how to access old talk pages

... that is after installing lqt?

I don't want to lose their content and would like manually transferring all that out of the talk pages before activating lqt. Thanks. Evgeny. 128.200.203.33 20:42, 7 July 2008 (UTC)

They should appear at the very top of the new LQT talk pages, above any LQT discussion. MinuteElectron 11:22, 12 August 2008 (UTC)

On my wiki the header is not displayed! Another question, does the protection of a talk page only effect the header or also the ability of creating new threads? --DaSch 10:57, 18 August 2008 (UTC)

This problem with the heading not appearing - which I just encountered - seems to be fixed in r43682. --Jlerner 19:24, 18 November 2008 (UTC)

I recently installed the latest on 1.13.1 and was very excited to use it until I found that it indeed seems to be "hiding" my prior talk pages as DaSch seems to be experiencing. Any reasons why this would be the case, or how to correct it? --Gmoyle 20:35, 26 September 2008 (UTC)

Forum frontend

It would be great to have a forum front end - some special page where all threads/messages could be found. Elaboration of "New messages" special page seems like a logical path.

In the current state messages are scattered throughout talk pages - this encourages less participation then it could.

Evgeny.

no development?

will there be any furhter development? Or will anybody create a fork or something to develop this very nice extension. There are some bugs to fix and many features to add. Please go on with developing. --DaSch 18:18, 8 July 2008 (UTC)

I'm interested also, need it for this site. Would you be willing to write some code too? -Evgeny.

I have fixed a few bugs and plan on making additional improvements to this extension. Please open bugs and feature requests in the LiquidThreads component of MediaWiki extensions on Bugzilla. MinuteElectron 14:08, 24 August 2008 (UTC)

Moved to a new server

I was notified that my wiki was being moved to a new server and this happened over the weekend. Due to it being organized across several different IT departments, something went weird with my Liquid Threads.. there are still a list of threads under the Thread NS but none of them are accessable. When i try to recreate the threads i get duplicates in the thread NS which makes it really cluttered. Does anyone know how i can get the no longer accessible threads out of the NS? I think it has something to do with a discrepency between the SQL tables added by LQT and the actual contruct of the wiki itself but i'm not at all sure where to begin.

Kay

Migrating talk pages after install?

I would be good if the 'old' talk pages turned up as a single thread in the archive of the new LQT page. Would this be a simple or a complex SQL query? --Dmb 08:49, 1 August 2008 (UTC) --Dmb 10:10, 1 August 2008 (UTC)

This would be quite difficult given the diversity of talk pages, and sometimes there are already headers so it is not as simple as copying the data. MinuteElectron 11:32, 12 August 2008 (UTC)

Details...

• What namespaces does this extension create?
• What configuration variables does this extension provide?
• Does the 'you got mail' feature still work? (And why not?).

--Dmb 10:10, 1 August 2008 (UTC)

• • "Thread" and "Summary".
  • "$egLqtNamespaceNumbers".
  • Yes.

MinuteElectron 11:20, 12 August 2008 (UTC)

User Controle

Is it posible to disable peoples ability to edit other peoples discution contributions?

--gtron 11:40, 8 August 2008 (UTC)

Yes. MinuteElectron 11:16, 12 August 2008 (UTC) - I don't remember writing this. MinuteElectron 14:07, 24 August 2008 (UTC)

How? --DaSch 14:43, 12 August 2008 (UTC)

Future of this extension?

Hi - I'm in the process of setting-up a MediaWiki wiki and this extension seems to provide a significant improvement over the standard talk pages. However, I'm concerned about what would happen if development on this extension stopped one day, and the extension then became incompatible with future versions of MW. If I had to uninstall the extension, what would happen to the discussions up to that point? - 89.241.239.81 07:35, 16 August 2008 (UTC)

They would disappear. MinuteElectron 14:06, 24 August 2008 (UTC)

Translate

Namespaces are not translated: "Thread", "Thread talk", "Summary", "Summary_talk". How may I translate them? (in Lqt.alias.php?) Thank you for help.

I have the same problem. Please help!

Warning concerning call_time by reference (modify line in php.ini, if possible)

Using WAMP/XP on localhost, I get this warning (but the page dysplay under), that force me to modify my php.ini after installing the LQT extension (11/9/2008): Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of [runtime function name](). 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 D:\www\mw12\extensions\LiquidThreads\LqtBaseView.php on line 229

I get a similar warning with Mediawiki 1.15.1 and the corresponding LQT version under MAMP:

propellermac:testwiki achimbode$ php maintenance/sql.php extensions/LiquidThreads/lqt.sql

Deprecated: Assigning the return value of new by reference is deprecated in /Applications/MAMP/htdocs/testwiki/extensions/nusoap/nusoap.php on line 6496
Warning: Parameter 1 to Language::getMagic() expected to be a reference, value given in /Applications/MAMP/htdocs/testwiki/includes/StubObject.php on line 58
Warning: Parameter 2 to wfAddMagicWordForUser() expected to be a reference, value given in /Applications/MAMP/htdocs/testwiki/includes/Hooks.php on line 117
Detected bug in an extension! Hook wfAddMagicWordForUser failed to return a value; should return true to continue hook processing or false to abort.
Backtrace:
#0 /Applications/MAMP/htdocs/testwiki/languages/Language.php(1761): wfRunHooks('LanguageGetMagi...', Array)
#1 /Applications/MAMP/htdocs/testwiki/includes/MagicWord.php(244): Language->getMagic(Object(MagicWord))
#2 /Applications/MAMP/htdocs/testwiki/includes/MagicWord.php(197): MagicWord->load('lst')
#3 /Applications/MAMP/htdocs/testwiki/includes/parser/Parser.php(4034): MagicWord::get('lst')
#4 /Applications/MAMP/htdocs/testwiki/extensions/LabeledSectionTransclusion/lst.php(50): Parser->setFunctionHook('lst', Array, 2)
#5 [internal function]: LabeledSectionTransclusion::setup()
#6 /Applications/MAMP/htdocs/testwiki/includes/Setup.php(310): call_user_func(Array)
#7 /Applications/MAMP/htdocs/testwiki/maintenance/commandLine.inc(256): require_once('/Applications/M...')
#8 /Applications/MAMP/htdocs/testwiki/maintenance/sql.php(10): require_once('/Applications/M...')
#9 {main}

Is this the same problem? Any hints how to fix this? --Achimbode 16:51, 21 October 2009 (UTC)