The LRR wiki is back! Drop that baby and edit it!

[King Kool]

Down For Everyone Or Just Me says it is down.

Weird.

[King Kool]

Code: Select all

<!--background: url(http://wiki.loadingreadyrun.com/images/a/a9/FeedDumpBack.png) repeat top #666;-->

What does this piece of code do in the Crapshots/Feed Dump navbar thing?

[Robo4900]

I've saved the changes I've made to the video availability article. All Blip links are gone(Along with some leftover Revver links), and I've marked the broken video pages in red. I've also added some explanation for newcomers who aren't aware of the video hosting problems LRR have had over the years.

Anyone have any thoughts on it?

[King Kool]

Evil Alex is the Featured Article for October.

Spooky.

[King Kool]

Uh, what's this Navsidebar thing about?

[MidPhoto]

Hi, I'm new to the wiki (and the forums for that matter). and saw that a request for semantic forms has been made, but the wiki version is also quite old (currently 1.24.0 but 1.25.3 is already out), so if semantic forms gets added maybe it's a good idea to also update the wiki software a bit.

[mtvcdm]

For the longest time, I've been keeping a count of how many episodes of Feed Dump everyone has been in. I finally got around to slapping it on the Feed Dumps Sorted By Host page.

[MidPhoto]

it also seems we are missing the wiki image. i found it back on the webarchive


edit: fixed link

[AdmiralMemo]

Your link is broken.

[MrL]

I flagged some pages for deletion (for someone with authorities)
http://wiki.loadingreadyrun.com/index.p ... r_Deletion

[Paul]

Hey everyone,

So you have probably noticed that the wiki has been having some performance issues lately. I don't know if it is mediawiki itself, one of the extensions or our server configuration, but something is causing what should be routine tasks take massive amounts of server resources to the point where it is not only preventing wiki pages from loading, but it is also crashing the server and killing the restof the LRR site. Obviously this is not an acceptable state of affairs To try to solve the problem, I am going to be taking the wiki down and doing a full reinstall of mediawiki in the next day or two (backing up the database, of course).

If that doesn't work, we may have to look at migrating the wiki to its own server so that it will at least not be able to take down the rest of the LRR site. I am also looking into possible alternatives to mediawiki that might be more reliable.

If anyone has any suggestions for solutions to the mediawiki problems or recommendations for other wiki software, let me know.

[King Kool]

http://loadingreadyrun.com/forum/viewtopic.php?f=7&t=12873&start=1182

I've been noticing that for a long time indeed. That might help us rule out some of the potential culprits, as Semantic Wiki wasn't even installed at that time.

[MidPhoto]

From my experience with MediaWiki it really needs a cache it can write and read from like php-apc(u) or memcached, and the problems you are describing paul I would suspect that the MediaWiki install has no cache it can write or read from. more on this here

php-apc(u) is a better suit for this installation since you won't have to do more configuration if it is already installed and enabled when you install MediaWiki. php-apc can often be installed by running

Code: Select all

sudo apt-get install php5-apcu

for debian based systems or

Code: Select all

sudo yum install php-pecl-apcu

for fedora/RHEL based systems

edit: a word

[MidPhoto]

Also maybe look into the job queue made by MediaWiki it could be it's too full now

[Paul]

Ok, the wiki is offline at the moment and I will try to do the update before GPLP this afternoon, but it might be down until tomorrow.

As a side note, when I disabled the wiki, the server load went from 23 to 0.9, so clearly there is something going on

[King Kool]

As far as I'm concerned, keep the wiki down as long as you need to fix this problem. Because when it takes several seconds to fix a page when it should take one or two, that is a contributing factor in my discouragement from editing.

As I said, I've been pointing out the wiki's been slow for years. I don't know what it is, but there must be something wrong.

Hearing MidPhoto talk about the Semantic stuff is very encouraging that we have someone else who understands this stuff, but again, the wiki could go away for as long as necessary to determine what's gone wrong.

[Paul]

The reinstall is complete and Ashton and I have made some changes to the server and the mediawiki installation in the hopes of improving performance. The primary change is that the wiki is much more aggressively cached now. The server load seems to be reduced and it seems a little faster to load, but I am still not totally happy with the performance. There are a few other optimizations I am going to try in the next few days to see if it can be better.

I am hoping that the new cacheing system won't interfere with actually editing the wiki, but please let me know if you notice anything different (positive or negative).

[AdmiralMemo]

The logo's back! That's different and positive!

Accented characters and various other punctuation marks in page titles appear to be broken, though?

For example, the Reindeer Pâté episode of Feed Dump now displays as Reindeer P�t� instead.

Also, apparently editing a template doesn't appear to update every page that template's on until that page is itself edited. That could just be more of the caching you mentioned, though.

[King Kool]

Here's a thought. Maybe pages with special characters should have their own category on the wiki, so we can find all the pages that break when we mess with the wiki. This could include all the Phailhaus pages, of course, and a few random pages like that.

[Silverfish]

I have a suggestion that might help with performance issues, and be useful in it's own right. It's an extension to mediawiki called Scribunto (https://www.mediawiki.org/wiki/Extension:Scribunto). It allows you to embed a scripting language (Lua) into templates (or directly in wikitext). The idea is that you write the code in Modules that contain functions that can be "invoked" directly in articles in a similar way to templates. Wikipedia uses it on a lot of their templates.

One simple example of a module is this:
https://en.wikipedia.org/wiki/Module:BananasArgs. It shows the code of the Module with functions that perform various tasks, and how to invoke them. The code could be a lot more involved that in that, that's just to give you an idea of how it works.

There are various potential benefits. The main one is that using Scribunto could be a lot faster than using templates alone. See https://en.wikipedia.org/wiki/Wikipedia:Lua_speed as one source. The idea seems to be that calling templates is slow, and to express complicated logic with templates requires using templates that call other templates, which compounds the problem.

Also, Scribunto uses Lua which is a full programming language, so it is potentially a lot more powerful than templates, which weren't designed for complicated logic or calculations. One example of something that would be trivial in a programming language, but very involved and hacky with templates: The template to tag articles with AppearanceBy (Let's say, Graham, Paul and Kate)for the people in the episode. We could create a script that takes the people in the episode, which could be any number of people, and lists them with commas between, and "and" before the last item. So it would list them as "Graham Stark, Paul Saunders and Kate Stark"). The current version has a fixed limit of 4 people, and only separates with commas.

Something more powerful, which might be feasible, would be a filmography script that would generate a whole filmography for someone, only creating headings for series they are credited for.

Also, it seems Scribunto code can be a lot easier to read and probably write than templates, at least when they have complicated logic. When writing the navigation bar for feed dump to find the next and previous episodes, I found it hard to read at times as it had to mix parts that would be displayed as wikitext, parts that called other templates, and parts that had logic to find the next episode, etc. It looks rather ugly, because it has to function as a template. The BananasArg example above however is really nicely laid out, as it can easily keep the parts that are displayed in the article separate from the logic side.

Also, Scribunto code seems to be easily to organise. You can keep related functions in a Module. For our wiki you could have one Module for scripts relating to credits (AppearanceBy, BoomBy, etc), rather than loads of little templates. Also, instead of a template calling another template. One function would use another function in the same Module. You would probably only need a few Modules (Navbars, Credits, Filmographies, Vital Statitics, infoboxes) to cover the major areas of the wiki. You could still have templates, but the real work would be done by the relevant Module.

TLDR: Scribunto lets you embed a full programming language into wikitext, which could be a lot faster, more powerful, easier to read and organise the code that using templates as we do now. See https://en.wikipedia.org/wiki/Module:BananasArgs for a simple example of a Scribunto module and how to "invoke" it.

[King Kool]

As I said earlier, I'm pretty sure the slowdown has been at least somewhat of a problem since before SemanticWiki was installed, so I doubt it's the central problem.

Furthermore, I'm all for making the wiki more complicated to save us work in the long run, but... we shouldn't make it SO complicated that most of us have no idea what's going on. My goal for the wiki is to basically idiot-proof it, so everything about making pages is simple.

Nevertheless, very interesting find.

[Silverfish]

Scribunto wound't just help with Semantic Mediawiki. It could potentially be used by any template (or instead of templates). I used examples from SMW as those are where I thing Scribunto could be useful, or in the case of the Feed Dump navbar, where I found templates rather frustrating to work with. If templates are causing performance issues, Scribunto could help with that, and if not, making them more efficient would still be helpful.

I also don't think Scribunto would have to be more complicated than templates. As an example from https://en.wikipedia.org/wiki/Module:BananasArgs, this is one function from the Module:

Code: Select all

function p.hello(frame)
   local name = frame.args[1] -- in this example, args[1] is the word Fred
   return "Hello, " .. name .. "!" -- .. name .. replace by the word Fred
end

You use it in wikitext like this: {{#invoke:BananasArgs|hello|Fred}}, with the result "Hello, Fred!". That is a basic example, but to use a Scribunto function the code (#invoke) is almost identical to using a template. The code itself looks very readable, at least to me, as it is nicely laid out, with comments, which are possible as only the result returned by the function is displayed. In contrast, the current version of the Feed Dump navbar is this:

Code: Select all

<!--background: url(http://wiki.loadingreadyrun.com/images/a/a9/FeedDumpBack.png) repeat top #666;-->
{|style=" background: #666; border: 1px solid #a6a6a6; width:100%; margin: 1em auto; color: #fff"
|-
| style="text-align: center" |[[EpisodeCategory::Feed Dump|<span style="color:#666">I</span>]] [[Image:Feeddump-navbar.jpg|link=Feed Dump]] <span style="color:#666">I</span><br/>{{#if: {{SMWFeedDumpPreviousEpisode|{{{Episode-Number}}} }} |'''◀ ●∙∙∙''' '''{{FeedDumpFormattedWikilink|  {{SMWFeedDumpPreviousEpisode|{{{Episode-Number}}} }}  }}''' | }} &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{{#if: {{SMWFeedDumpNextEpisode|{{{Episode-Number}}} }} | '''{{FeedDumpFormattedWikilink|  {{SMWFeedDumpNextEpisode|{{{Episode-Number}}} }}  }}''' '''∙∙∙● ▶''' | }} <br/>
'''Watch [{{{Video}}} <span style="color: #fff">{{PAGENAME}}</span>] &nbsp;&nbsp;&nbsp; Discuss [http://loadingreadyrun.com/forum/viewtopic.php?t={{{Forum-LRR}}} <span style="color: #fff">{{PAGENAME}}</span>]''' <br/>{{#if: {{{Forum-Esc|}}}| [[Category:The Escapist]] '''Discuss [{{{Forum-Esc}}} <span style="color: #fff">{{PAGENAME}}</span>] on The Escapist''' &nbsp;&nbsp;&nbsp;| }} '''Read [[{{PAGENAME}} Transcript|<span style="color: #fff">{{PAGENAME}}</span>]] Transcript'''
|}
<includeonly>[[Category:Videos]][[Category:Feed Dump]]__NOTOC__</includeonly>
<noinclude>[[Category:Navigation Templates]]</noinclude>

[[FeedDumpEpisodeNumber::{{{Episode-Number}}}|]]


Which is really complicated because it has to mix wikitext to be displayed, calling templates to help with formatting, calling templates to find the next/previous episode, inserting the link to the episode, forum. The Semantic part is just one complication. There is no easy way of making it look nicer or add comments without breaking the template. With scribunto I could split this template into specific parts that each do one thing, and are therefore easier to read, and each formatted nicely like in my example. Then I would have one part that combines each part together. I argue that that would make things much simpler, as each part of the code would only have one job to do.

Basically, Scribunto could make the logic of complicated templates easy to follow, and make it possible to do things in code that would be impossible with just templates, or at least really complicated. Just Loops and variables are very useful to avoid repeating code (see <span style="color: #fff">{{PAGENAME}}</span> in the template example that is repeated multiple times, but could be replaced with a variable, pagename, say).

To be clear, I don't plan on doing anything very complicated with Scribunto, but either simplifying the existing templates, and doing things that Scribunto would make easy, that would be really messy with templates.

[Silverfish]

On a different topic. I've noticed that Paul Saunders Filmography takes around 10 seconds to preview. This seems like quite a lot, and as the page is either plain wikitext and templates running SMW queries, I could possibly improve the performance with a couple of simple steps. I'm going to try creating a Filmography template for each series (as I did for Phailhaus), which can use the appropriate Category in the query, rather than querying for the episode category, which should be more efficient.

Also, I think if we want to query for Unskippable episodes on Paul's Filmography, we should just have a template {{UnskippableEpisodes}}, with no parameters. I understand that could be cached directly.

I don't know how much difference it will make, so this is more of an experiment.

[King Kool]

DialMForMara is wondering how we should make pages for Checkpoint Aftershows.

I don't really have any ideas. Anyone have some suggestions?

EDIT: Aftershow links should be in the navbar, that's for sure, but... do they need their own page?

[Silverfish]

I'm inclined to include any information on the aftershow with on the same page as the episode it follows, as the aftershow feels like part of the same show. When watching the Checkpoint twitch stream they transition pretty smoothly from recording the actual episode, and the aftershow portion of the stream. Also, any trivia or additional notes on the aftershow seem likely to relate to the existing show as well. When someone has time off from Checkpoint, for example, that would affect both the main show and aftershow. Also, they discuss the main show in the after show.

My approach would be to have a section (or multiple sections, for rejected story ideas, Kathleen commercials, etc) of each Checkpoint article that discuss the aftershow. If the aftershow sections got too big then we could split them into separate articles.