Extension talk:LiquidThreads

Jump to: navigation, search

About this discussion

Archives 

Archive 1 Archive 2

See also Talk:LiquidThreads 3.0/Design, Talk:LiquidThreads 3.0.


By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
Glameglumps33 (talkcontribs)

So, I've been recovering an old wiki from a laptop that died, and had to upgrade it from 1.18.5 (I think) to 1.24.1 to get it to work on my newer version of XAMPP. I've actually managed to get everything working pretty well, except for LiquidThreads. I'm thinking it might be best just to uninstall it and use regular talk pages, but I'd like to recover the content of those talk pages.

Is that possible, perhaps by somehow viewing the data tables in phpMyAdmin?

I have not uninstalled LiquidThreads yet, but I am currently unable to open talk pages. Instead I get the following error:

Fatal error: Call to undefined method MediaWiki::getVal() in E:\XAMPP\htdocs\mywiki\extensions\LiquidThreads\classes\Dispatch.php on line 25
Ciencia Al Poder (talkcontribs)

You must upgrade Liquid Threads as well, downloading the 1.24 version.

Glameglumps33 (talkcontribs)

Yeah, you're right. I thought I had updated it when I was updating the rest of my extensions, but it looks like I somehow skipped that one. My bad :p

TDeeming (talkcontribs)

Were you successful?

  • I am transfering the contents to a new wiki. And getting a similar problem. I was using LiquidThreads before, but unfortunately the pages are no longer found... or empty. I am using the 1.24 version... and it seems that I can only manually copy and paste into a new thread... on the new wiki. Any ideas?
Reply to "How to Recover Content of Talk Pages?"

LQT nor formatting properly after changing web host

10
Lee Bunce (talkcontribs)

I've recently moved a mediawiki installation (mw: 1.23.3, lqt: 2.1 alpha) to a new web host and as a result liquid threads no longer formats properly. On the page responses to threads do not appear in ordered grey boxes but rather appear in plain list down the page without any formatting, as though no CSS is being picked up.

Any idea what the cause might be?

Ciencia Al Poder (talkcontribs)

Open the web developer tools of your browser (hit F12), switch to the console view, and reload the page where you have LQT.

Look on the console view if you see any JavaScript error or if some HTTP request receive HTTP 5XX/4XX responses.

Lee Bunce (talkcontribs)

Thanks, I don't get those errors. I get the following:

  • Error in parsing value for 'display'. Declaration dropped. load.php:1
  • Unknown property 'zoom'. Declaration dropped. load.php:1
  • Expected declaration but found '*'. Skipped to next declaration. load.php:1
  • Expected 'important' but found 'ie'. Expected ';' or '}' to terminate declaration but found 'ie'. Declaration dropped. load.php:1
  • Error in parsing value for 'background-image'. Declaration dropped. load.php:1
  • Unknown property 'user-select'. Declaration dropped. load.php:1
  • Unknown pseudo-class or pseudo-element '-ms-input-placeholder'. Ruleset ignored due to bad selector. load.php:1
  • Unknown pseudo-class or pseudo-element '-webkit-search-decoration'. Ruleset ignored due to bad selector. load.php:1

and:

  • "Use of "delayedBind" is deprecated. Use the jquery.throttle-debounce module instead" load.php:148
Ciencia Al Poder (talkcontribs)

Those are just CSS errors/warnings, but they're normal.

Did you found any 5XX/4XX HTTP errors?

Is your wiki public so you can post a link to it here?

Lee Bunce (talkcontribs)

No, only a few HTTP/1.1 304 Not Modified messages. The wiki is private sadly. The only thing that changed to stop it working is the web host, any ideas what the difference could be?

Ciencia Al Poder (talkcontribs)

No idea. The only thing I can suggest is to append ?debug=true to the URL (or &debug=true if the URL already contains a question mark), that way every JavaScript and CSS file will be downloaded separately and you could track if one of them of LQT doesn't load in your wiki, comparing to here. But apart from that, there's nothing more we can do...

Lee Bunce (talkcontribs)

Strangely when I append &debug=true the page loads correctly! Does that give you a clue?

There's a whole load of new errors in the console, but given that the page works I'm not sure if that'll help diagnose why the regular URL doesn't work?

Ciencia Al Poder (talkcontribs)

As a workaround for you, you can set $wgResourceLoaderDebug to true, which sould do the same as appending debug=true to the URL

Lee Bunce (talkcontribs)

Great, I realsied it isn't actually working entirely correctly, for replies the 'History', 'edit' and 'Link to' etc links appear in a list rather than under the more option, but this is a workable solution for now. Thanks again.

Nemo bis (talkcontribs)

Well, this means it's a bug with ResourceLoader. Please report it.

Reply to "LQT nor formatting properly after changing web host"
Wmat (talkcontribs)

Seeing this alot with MW 1.23.5:

PHP Notice: Undefined index: thread in ../extensions/LiquidThreads/classes/ParserFunctions.php on line 68

Any ideas why?

Reply to "Undefined Index errors"

JavaScriptless LQT silently fails to create a new topic

1
Gryllida (talkcontribs)

JavaScriptless LQT returns no error after I try to start a new topic and click submit. No topic is created, either. The message I typed is lost.

Reply to "JavaScriptless LQT silently fails to create a new topic"

Is it possible to access the discussion contributions from the wiki after removal of LQT?

7
Kappa~mediawikiwiki (talkcontribs)

I am wondering whether it is possible to find the discussion page created with LQT in the wiki after LQT has been removed from LocalSettings.php. In the DB I still can find a page with the name "Talk:SamplePage/Contribution1" in namespace 90 in the "page" table. If I follow the keys from the "page" table to the "revision" table and then to the "text" table, I also find the text of the contribution. I did however not succeed in finding the contribution in the wiki after removing LQT. If LQT is included in the wiki, the "show permalink" option renders the following permalink for the contribution: "Theme:Talk:SamplePage/Contribution1". As long as LQT is included, this link actually leads to the contribution. As soon as LQT is removed, the link however leads to a non-existing page. Does anybody have an idea, how to solve this problem?

This post was posted by Kappa~mediawikiwiki, but signed as Kappa.

Ciencia Al Poder (talkcontribs)

It's "Theme:Talk:SamplePage/Contribution1" or "Thread:Talk:SamplePage/Contribution1"? It should probably be the second.

I guess the problem is the Thread: namespace that creates LQT, that is no longer present when not installed. You could try defining the Thread: namespace again in LocalSettings.php and you may be able to access messagess as individual pages, although I haven't tested it.

Kappa~mediawikiwiki (talkcontribs)

Great! Defining the namespace in LocalSettings.php works fine. Thank you very much for your quick and helpful answer. By the way: in the German version the namespace name is "Thema", but using "Thread" as namespace name in LocalSettings.php also works fine for other languages.

define("NS_THREAD",90);
define("NS_THREAD_TALK",91);
$wgExtraNamespaces[NS_THREAD] = "Thread";
$wgExtraNamespaces[NS_THREAD_TALK] = "Thread_Talk";

This post was posted by Kappa~mediawikiwiki, but signed as Kappa.

Nemo bis (talkcontribs)

Can you make screenshots?

Ciencia Al Poder (talkcontribs)

screenshots of what?

Nemo bis (talkcontribs)

Of how things look after removing LQT

Kappa~mediawikiwiki (talkcontribs)

I don' have a screenshot, but I can describe what happens: all contributions appear on pages of their own (pages and subpages, depending on the previous nesting). The look-and-feel of a thread on one page will be lost, but the texts of the individual contributions are saved.

This post was posted by Kappa~mediawikiwiki, but signed as Kappa.

Reply to "Is it possible to access the discussion contributions from the wiki after removal of LQT?"
Cavila (talkcontribs)

Apparently, saving the page after editing a particular section (through "edit section") leads to the loss of all other sections. Is there a way we can disable section editing for LQT?

Ciencia Al Poder (talkcontribs)

That's a bug. Alternatively, you can put __NOEDITSECTION__ on a message with sections

Cavila (talkcontribs)

Thanks, I know about the magic word. I was just wondering if there was a more general setting for the Thread: namespace. Maybe 'editsection' can be used as a user right in $wgNamespaceProtection.

Reply to "How to disable section editing"

force-refresh a discussion page?

10
Summary by Nemo bis
F.trott (talkcontribs)

Is there any way to force-refresh a discussion page? I am sick of getting a notification about a new comment, going to the talk page and not finding the discussion. Makes me forget about threads I should answer all the time.

Ciencia Al Poder (talkcontribs)

New comments appear in Special:NewMessages as well, no need to go to your talk page.

F.trott (talkcontribs)

Well, maybe I should get sent a link to my Special:NewMessages then.

Nemo bis (talkcontribs)

Sent where? It's in your personal tools.

F.trott (talkcontribs)

Sent to me by email instead of the link to the discussion page where the new comment is not showing up.

Nemo bis (talkcontribs)

That's bugzilla:34247. LQT is unmaintained, remember.

F.trott (talkcontribs)

Ah, thanks! Did not find that bug.

Do you know the general plans for LT? Is it even worth looking into bugfixing?

Nemo bis (talkcontribs)

There are no plans for LQT. It will surely not used on any Wikimedia wiki and I can't recommend any faint-hearted sysadmin to use it on their wiki.

However, if you care about any of the wikis using it, submitting patches is very welcome. Krenair and translatewiki.net staff usually review rather quickly.

Woozle (talkcontribs)

"It will surely not used on any Wikimedia wiki..." -- umm, that's what is being used to conduct this discussion... (That it's not being officially maintained is still true, however.)

Nemo bis (talkcontribs)

Sorry, I meant that it won't be installed on any new Wikimedia wiki.

Reply to "force-refresh a discussion page?"
Skunark (talkcontribs)

There seems to be some artifacts with removing the LQT extension and lingering "what links here" links to old LQT threads. Is there a way to fully remove LQT? I can provide a link to the issue if needed, but thanks in advance if not.

Nemo bis (talkcontribs)

AFAIK there is no exit strategy for LQT. LQT are forever.

Ciencia Al Poder (talkcontribs)

It should be possible to remove all threads with nukeNS.php

Reply to "How to fully uninstall LQT?"
VolkoV (talkcontribs)

I stuck in this complex code trying to develop a special page allowing for an General Threads Overview. It is actually like any talk page but without the restriction on the article allowing to view the most recent discussions on all pages of a smaller wiki.

Has anyone done something like this before?

Cavila (talkcontribs)

Yes, that would be useful.

Perhaps you can also use the Semantic MediaWiki extension, make sure that the namespace "Thread" allows for semantic properties, and produce a table of single threads sorted by modification date. But I haven't tested this.

VolkoV (talkcontribs)

At least I found an SQL-Statement that can do that:

SELECT *
FROM prefix_thread
WHERE (thread_parent IS NULL OR thread_ancestor=thread_id) AND (thread_type<>2)
ORDER BY thread_modified DESC
VolkoV (talkcontribs)

I have written an extension with a special page showing all threads without a summary - therefore a summary can be used to close a thread. As soon as I have cleaned up the coding I will post it here.

Reply to "General Threads Overview"
Cavila (talkcontribs)

Yesterday I pulled the latest version from Git, which solved one issue but introduced another. This time Special:NewMessages has become unavailable, leading to an "Internal error":

[4208aaa9] /wiki/Special:NewMessages Exception from line 376 of .../includes/SpecialPage.php: Call to undefined method SpecialNewMessages::getPageTitle

Backtrace:

#0 .../extensions/LiquidThreads/pages/SpecialNewMessages.php(23): SpecialPage->__call(string, array)
#1 .../extensions/LiquidThreads/pages/SpecialNewMessages.php(23): SpecialNewMessages->getPageTitle()
#2 .../includes/SpecialPage.php(631): SpecialNewMessages->execute(NULL)
#3 .../includes/SpecialPageFactory.php(488): SpecialPage->run(NULL)
#4 .../includes/Wiki.php(298): SpecialPageFactory::executePath(Title, RequestContext)
#5 .../includes/Wiki.php(602): MediaWiki->performRequest()
#6 .../includes/Wiki.php(467): MediaWiki->main()
#7 .../index.php(49): MediaWiki->run()
#8 {main}

Any ideas?

Cavila (talkcontribs)

It's a change in the code relating to MW 1.23 that brought about the error:

https://git.wikimedia.org/commitdiff/mediawiki%2Fextensions%2FLiquidThreads/3680e12bd1cd5372c6a57abbc2b03800bfc1bee4

Restoring getPageTitle to getTitle (deprecated in MW 1.23 but still used in MW 1.22) solved things.

Reply to "Internal error for Special:NewMessages"