Jump to content
MediaWiki

Extension talk:LiquidThreads/2014

Add topic
From mediawiki.org
This page used the LiquidThreads extension to give structured discussions. It has since been converted to wikitext, so the content and history here are only an approximation of what was actually displayed at the time these comments were made.

Internal error for Special:NewMessages

[edit ]
Latest comment: 11 years ago 2 comments1 person in discussion

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 (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 12:02, 13 February 2014 (UTC) Reply

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. Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 12:13, 13 February 2014 (UTC) Reply

General Threads Overview

[edit ]
Latest comment: 11 years ago 7 comments2 people in discussion

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? VolkoV (talk) 06:49, 2 March 2014 (UTC) Reply

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. Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 07:36, 2 March 2014 (UTC) Reply
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 (talk) 06:11, 3 March 2014 (UTC) Reply
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. VolkoV (talk) 12:57, 11 March 2014 (UTC) Reply
Here we go, it is still quick and dirty:
https://github.com/GeneralVolkoV/LiquidThreadsOverview VolkoV (talk) 14:04, 11 March 2014 (UTC) Reply
Good work! Having just tested this I can confirm that it works. Obviously it would be great if the devs could adopt this. Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 1.8.0.5, SF 2.5.4) 07:21, 12 March 2014 (UTC) Reply
And here is a the extension's page VolkoV (talk) 18:24, 12 March 2014 (UTC) Reply

How to fully uninstall LQT?

[edit ]
Latest comment: 11 years ago 3 comments3 people in discussion

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. Skunark (talk) 05:23, 4 March 2014 (UTC) Reply

AFAIK there is no exit strategy for LQT. LQT are forever. Nemo 20:21, 6 March 2014 (UTC) Reply
It should be possible to remove all threads with nukeNS.php Ciencia Al Poder (talk) 20:57, 6 March 2014 (UTC) Reply

force-refresh a discussion page?

[edit ]
Latest comment: 10 years ago 10 comments4 people in discussion

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. F.trott (talk) 12:38, 28 March 2014 (UTC) Reply

New comments appear in Special:NewMessages as well, no need to go to your talk page. Ciencia Al Poder (talk) 11:29, 29 March 2014 (UTC) Reply
Well, maybe I should get sent a link to my Special:NewMessages then. F.trott (talk) 16:17, 29 March 2014 (UTC) Reply
Sent where? It's in your personal tools. Nemo 09:05, 31 March 2014 (UTC) Reply
Sent to me by email instead of the link to the discussion page where the new comment is not showing up. F.trott (talk) 09:08, 31 March 2014 (UTC) Reply
That's bugzilla:34247. LQT is unmaintained, remember. Nemo 13:47, 31 March 2014 (UTC) Reply
Ah, thanks! Did not find that bug.
Do you know the general plans for LT? Is it even worth looking into bugfixing? F.trott (talk) 13:54, 31 March 2014 (UTC) Reply
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. Nemo 19:36, 31 March 2014 (UTC) Reply
"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.) Woozle (talk) 11:54, 30 October 2014 (UTC) Reply
Sorry, I meant that it won't be installed on any new Wikimedia wiki. Nemo 13:52, 30 October 2014 (UTC) Reply

How to disable section editing

[edit ]
Latest comment: 11 years ago 5 comments2 people in discussion

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? Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 09:13, 16 June 2014 (UTC) Reply

That's a bug. Alternatively, you can put __NOEDITSECTION__ on a message with sections Ciencia Al Poder (talk) 09:39, 16 June 2014 (UTC) Reply
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. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 10:27, 16 June 2014 (UTC) Reply
The bug has been filled already: bug 46284 Ciencia Al Poder (talk) 19:59, 16 June 2014 (UTC) Reply
Okay, that's good to know. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 11:07, 17 June 2014 (UTC) Reply

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

[edit ]
Latest comment: 11 years ago 7 comments3 people in discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


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? Kappa (talk) 14:24, 29 July 2014 (UTC) Reply

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. Ciencia Al Poder (talk) 19:22, 29 July 2014 (UTC) Reply
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";
Kappa (talk) 11:16, 30 July 2014 (UTC) Reply
Can you make screenshots? Nemo 06:47, 31 July 2014 (UTC) Reply
screenshots of what? Ciencia Al Poder (talk) 09:19, 31 July 2014 (UTC) Reply
Of how things look after removing LQT Nemo 12:16, 31 July 2014 (UTC) Reply
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. Kappa (talk) 09:49, 15 August 2014 (UTC) Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

JavaScriptless LQT silently fails to create a new topic

[edit ]
Latest comment: 11 years ago 1 comment1 person in discussion

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. Gryllida 10:56, 31 August 2014 (UTC) Reply

Undefined Index errors

[edit ]
Latest comment: 11 years ago 1 comment1 person in discussion

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? Wmat (talk) 21:04, 7 October 2014 (UTC) Reply

LQT nor formatting properly after changing web host

[edit ]
Latest comment: 10 years ago 10 comments3 people in discussion

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? Lee Bunce (talk) 19:00, 19 November 2014 (UTC) Reply

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. Ciencia Al Poder (talk) 10:18, 21 November 2014 (UTC) Reply
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:
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? Ciencia Al Poder (talk) 10:41, 22 November 2014 (UTC) Reply
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? Lee Bunce (talk) 13:23, 23 November 2014 (UTC) Reply
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... Ciencia Al Poder (talk) 17:21, 23 November 2014 (UTC) Reply
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? Lee Bunce (talk) 10:36, 25 November 2014 (UTC) Reply
As a workaround for you, you can set $wgResourceLoaderDebug to true, which sould do the same as appending debug=true to the URL Ciencia Al Poder (talk) 10:54, 25 November 2014 (UTC) Reply
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. Lee Bunce (talk) 20:59, 25 November 2014 (UTC) Reply
Well, this means it's a bug with ResourceLoader. Please report it. Nemo 07:28, 28 November 2014 (UTC) Reply

AltStyle によって変換されたページ (->オリジナル) /