Forums/Admin Discussion

Jump to: navigation, search

This is a page for wiki admin discussions. Anyone can participate, mostly information about website technical stuff and updates.


Thread titleRepliesLast modified
updated css/js/image loading010:32, 7 December 2015
zoytip extension507:11, 29 April 2015
SMW implementation + MW code drop megathread311:52, 27 April 2015
login issue016:51, 3 April 2015
SliderTag extension for MediaWiki201:03, 30 March 2015
anon create disabled018:52, 3 March 2015
spam prevention011:48, 13 June 2014
Semantic MW Objectives115:39, 19 May 2014
Themes and Customization414:58, 19 May 2014
Updates514:52, 19 May 2014
Multi-Uploads018:17, 16 May 2014
Semantic MediaWiki Installed015:19, 16 May 2014
1Gb Upgrade + Maintenance 5/10015:35, 6 May 2014
Media Wiki - Variables Extension?507:18, 24 April 2014
updates013:08, 23 April 2014
Errors on LotS-pages112:51, 23 April 2014
pending #varpull changes100:34, 13 April 2014
fully anon edit enabled014:32, 23 October 2013
Testing cloudflare113:41, 17 October 2013
Breaking up pages906:05, 17 October 2013
First page
First page
Previous page
Previous page
Last page
Last page

updated css/js/image loading

Cloudflare implemented a new thing to help improve the load speed of pages. Let me know if there is significant improvement or any extreme slowness that is new.

I definitely noticed some of the things loading much faster.

Note: this is not likely going to make super huge pages load faster, just overall navigation most likely.

Zoycite (talk)10:32, 7 December 2015

zoytip extension

Edited by 4 users.
Last edit: 11:22, 13 June 2014

Currently working on a new extension zoytip which creates dynamic tooltips and will eventually be able to pull entire page content or just a specific template and render it as tooltip content. I am currently developing it on User:Zoycite. It will be very similar to the varpull interface. The basic idea for this template is to make it possible to render on hover tool tips for game items similar to the lucy item extension for everquest section, but instead of pulling from the ZAM or other database it uses wiki articles (aka our database). This might mean that templates on articles for item pages might need to be modified slightly for a particular game, but the end result is amazing and a feature i know we all want. Security and performance are the primary concerns.

Zoycite (talk)07:49, 9 September 2012

Am digging the idea.

On a related note, varpull appears to accept parser functions and variables; is there a way to make it accept page names delivered entirely through templates?

{{#varpull: LotS/experiment/{{#if: {{{1| }}} |{{{1}}} |null}}|Experiment|firstreward}} --> yes
{{#varpull: LotS/{{{reqItem}}}|LotS Item|type}} --> yes
{{#varpull: {{LotS/RaidLink/Centurian Commander}}|raid|type}} --> no

The first two cases work, but the last one doesn't. It would simplify things if varpull could use templates to assemble the page name. I can see potential problems here because a template does not always output a page path. This may be impossible, but I thought I'd ask!

Klaxxin (talk)11:20, 9 September 2012
Edited by another user.
Last edit: 18:02, 29 July 2013
  1. varpull takes an article name and a template name as its primary arguments. The it takes a variable in that template as a 3rd argument. So it basically retrieves the first occurrence of a specific template on a page, then it parses out the variable from there. That is you won't likely get the right result if multiple of the same template are on a page.

your 3rd example won't work because {{LotS/RaidLink/Centurian Commander}} expands to something that is not an article name. And I am not sure Template:LotS/RaidLink/Centurian Commander is even a template. But if it were you'd want to call {{#varpull: Template:LotS/RaidLink/Centurian Commander|TemplateName|variable}} to get the expected result, because varpull doesnt care if the article it is pulling from is in the Template namespace.

varpull is just a fancy text parser that is designed for the "item page" scenario when you want to list a set of the variables in a table with various attributes from the item template on the "item page". granted it can be used for more than just "items", but yeah it is some random text parser function i wrote that gives us the ability to use pages with templates on them as a data source for other pages so that there only need be 1 source of truth for all data.

Zoycite (talk)11:54, 9 September 2012

What ever happened with ZoyTip?

Doomcat (talk)09:16, 28 April 2015

i put it on hold because mediawiki changed how a lot of things work since i started working on it. i just do not have the time to maintain an extension as massive as it was turning out to be. we've taken 4 code upgrades since starting the work on it. not sure how much is still workable or if the js is even compatible with browsers now.

open to an out of the box solution though that works almost as well.

Zoycite (talk)13:52, 28 April 2015

That's fair. I don't see any extensions that immediately look like they do it well, and I don't have a burning need either. Just was curious.

Doomcat (talk)07:11, 29 April 2015

SMW implementation + MW code drop megathread

So I wanted to start the SMW discussion thread ->

I changed Template:LotS Item in an attempt to include variables automatically in every item page (this takes about a day to populate through the cache). Though I am not sure if we have the correct naming scheme for properties yet; i just did 1:1 with variable name. So I have not followed up in seeing it it works yet. We may need additional category pages inserted by the template.

We are destroying the web server's db and I have no more resources I can throw at it. So we have to transition LotS into a SMW model for a lot of the pages to expand. Figuring this out is key, and starting to no longer be an option to rely on #varpull. This is just the next step in evolution of the wiki.

I am taking a MediaWiki and SMW code drop and database sometime on Saturday 3/27. I expect the whole process to be about 10 hours to ensure little to no down time.

So I propose figuring out if the change I made to Template:LotS Item is usable in some form and figure out any changes we need to make.

Also if there is a site already performing some SMW similar to our objective that we look to their model and adapt it to our needs.

Zoycite (talk)16:42, 27 March 2015

MediaWiki 1.24.1 has some major incompatibility problems for us. 1.25 has some promising improvements, but is not yet stable. So for now I have held off on upgrades and taken a look at optimizing settings to work better for us.

SMW initiative seems to be going along fine. I am doing a mass update to the category links: this takes hours to run. This should slowly start trickling in SMW stuff to places it was added.

I am collecting metrics and figuring out where the hardware/software needs are to let the site work best.

Zoycite (talk)03:35, 29 March 2015

I think there are a few of us coming to understand the SMW formats now. One issue that comes up when you're adding SMW to existing Categories is that we have to manually purge or re-save every page in the category to get the SMW variables to populate. If you add a new property or even change the data type of a property, the entire category has to be purged to reflect that change. I'm not sure if there's an SMW action I can't find or if there's some PHP you can personally wrangle that might help on that front.

We worked on it a bit, and got Equipment Sets put together, which I would consider to be a triumph, though the rest of the category Item Set still needs purging.

Doomcat (talk)10:58, 26 April 2015

I've converted to use SMW and reduced 339 expensive parser calls to 0, and cut the generation time by ~80%. There are still a few things left to learn, but I think we're on the right track. If you have a list of priority items that we should focus on first, we can tackle them in order.

Doomcat (talk)11:52, 27 April 2015

login issue

working on resolving login issue. if still having problems send email. Applied some fixes and upped and cleared the session storage limit.

Zoycite (talk)16:51, 3 April 2015

SliderTag extension for MediaWiki

We are interested in adding slider galleries to each of the raid pages; similar to how Dawn's wikia has them:,_Slideshows,_and_Sliders/wikitext

for reference, we added a slider gallery to the bottom of this page as a test:

as follows: "gallery type="slider" hideaddbutton="true"
File:LoTS_lurking_horror4.jpg /gallery"

but it looks like this command/extension is not currently supported. Would it be possible to add support for this extension? Thank you for your help.

Yellow47 (talk)21:11, 19 September 2014

Will add this to next code drop / rebuild list

Zoycite (talk)15:49, 27 February 2015

I do not believe this to be an extension. This is something that can be directly added to the Common.js and Common.css files


Zoycite (talk)01:03, 30 March 2015

anon create disabled

I disabled anon create. Something is not quite right with the firewall and dns blocks that should be in place.

I will investigate where the weak link is in the mean time and continue to ban spam bots.

  • edit*

anon can still edit.

Zoycite (talk)18:51, 3 March 2015

spam prevention

I have updated some setting on ConfirmEdit to hopefully reduce spam. Most notably using the Auto confirmed user settings. New users can register pretty easily. In order to be auto confirmed you have to pass the following

  1. Registered for at least 10 minutes
  2. Made 3 edits

If you are editing and not auto confirmed, you may see a captcha.

Zoycite (talk)11:48, 13 June 2014

Semantic MW Objectives

We need to test out some of the capabilities of the Semantic Media Wiki extension and create a workflow for it.

We might be able to replace/reduce varpull with SMW if properly implemented in templates. We want to come out with a more rapid development approach for site content and potentially replace any slow downs in the process.

MsUpload should also help with that as well.

Zoycite (talk)14:56, 19 May 2014

I'm testing some stuff with regard to LotS. I think we should be able to add semantics to the LotS Item template (probably via #set:) and then replace all of our category pages with semantic search. It seems like SMW can do some really cool things, so definitely worth investigating.

Doomcat (talk)15:39, 19 May 2014

Themes and Customization

This isn't critical or anything, but a couple of us were wondering what the chances that we'd be able to have a custom wiki theme on LotS pages. I don't think it's worth moving to Wikia for, but the Dawn of the Dragons (a similar game) wiki has a pretty nice look. I know we could change the colors within the pages, but the top and left sides would still be default, which would kind of kill the effect.

In a quick Google search, I came across though it would require us moving all LotS pages to a LotS namespace. Anyway, I don't think anyone has any specific designs or themes in mind, just wanted to test the waters to see if that was even a technical possibility.

Doomcat (talk)11:11, 9 May 2014

We can certainly add that function. We do currently have the custom side bars.

Right now I am having some contractors look at redoing the overall site theme.

I am not against skins, but they are a lot of work. So step 1 is create the skin, and step 2 is implement it :)

Zoycite (talk)23:55, 9 May 2014

also you can email me the skin you want and i can test it out, them implement a way for it to exist on LotS only.

make sure all the class names in CSS are specific to the skin so that they dont conflict with the default vector classes. (issue for switching between sites/browser caching).

also we may have to adjust some things in common.css for your skin to work correctly.

Zoycite (talk)03:59, 11 May 2014

Cool. I think we could try to come up with something that works in Stylish (or comparable CSS injection addon) and then give that to you when it's right.

Doomcat (talk)09:58, 19 May 2014

Send me an email and I can send you the Vector Skin. I think you can make a skin which extends Vector and just recolors everything.

I can likely make an extension to use a specific skin on the server if your page name starts with LotS

Zoycite (talk)14:58, 19 May 2014

Site is undergoing major updates.

I am rebuilding the site infrastructure to support the newest version of MediaWiki.

Zoycite (talk)19:14, 14 May 2014

85-95% done with the updates. The might be a few rogue things to do left.

Working on making ads collapse 100% of the time when you choose to use ad blockers. Hey I get it some people don't like ads. Well I like you coming and contributing to the site whether or not you are using an ad blocker. I do this for fun, and so do what works best for you.

I will be installing some additional extensions over the next few days.

We should be running the latest stable MediaWiki core and extensions as of now. I have restarted about everything possible at this point.

Zoycite (talk)19:44, 14 May 2014

Ok, so ads will now auto collapse for people with an ad blocker. I test in chrome with ABP (the most used browser).

So I must be crazy thinking about how the site operates for people with ad blockers and ensuring it is optimal for you :)

The main change to the ads is that there is no longer a footer ad, both ads are displayed in the header. The display is optimized for modern wide screen resolutions. But then again so is the majority of the site. However if you are still running 1680xsomething or smaller the Header ads will be stacked on each other instead of displaying horizontally across.

I care a lot about getting this right, so if the ads are worse now, I need to know. Tell me what is wrong and suggest a fix.

Zoycite (talk)21:26, 14 May 2014

They're stacked at the top for me at 1680 x 1050, but I've intentionally left ABP off for this site only, and they're not really disrupting anything for me.

Doomcat (talk)09:56, 19 May 2014

This is also how I generally feel for the stacked ads on a 1680x1050 resolution. It works and is not interfering too much.

The reason behind this display optimization is it does generate more revenue per ad display for the page. The header generated the most revenue. Placing it below the page title actually increases the value to advertisers of the header ad (according to adsense recommendations). So this is a 2 for 1. More ad revenue does equal more resources we can dedicate to the site expansion.

But I definitely want to make it work for the users rather than making intrusive ads that detract from the content. So I place very high stakes in getting this right. I never want to have BS ads that prevent you from seeing the content unless you watch a video. The only exception to that rule is if we integrate video or playing games more into the site since they are large sources of bandwidth consumption.

Zoycite (talk)14:52, 19 May 2014

Please notify me if something specifically is broken.

Known Problems:

  1. LoH images on cards are broken - hack required ~ Fixed
  2. Some issues with load.php/api.php from Temporary Internet Files cache on local machines - UNKNOWN
  3. Sitemaps may not be auto generating correctly - Fixed
  4. Some static content may not be available (downloads directly off of like a map file zip) - Fixed
  5. Potential permission problems might exist for image uploads - Fixed
Zoycite (talk)19:50, 14 May 2014


Installed an extension for multi-uploads, check it out.

Zoycite (talk)18:17, 16 May 2014

Semantic MediaWiki Installed

Installed Semantic MediaWiki extensions and plugin.

Let me know if we want additional semantic plugins.

Zoycite (talk)15:19, 16 May 2014

1Gb Upgrade + Maintenance 5/10

Upgraded the server connection to 1Gb/s upload. So enjoy the increased bandwidth. This should help with some of the concurrent users load during peak traffic.

Also on Saturday 5/10 I will be bringing down the production site for up to 2 hours.

Other work:

  • Upgraded server monitoring
  • Upgraded security
  • Updated httpd configuration for higher load
  • Contracting out site layout redesign

Keep loving narwhals!


Zoycite (talk)15:35, 6 May 2014

Media Wiki - Variables Extension?

As a practice, we frequently do "double varpulls" in our templates, once to check "Does the page have this key/value defined?" and then a second to act on that value. In order to save #varpulls, which I believe we've said are relatively expensive, I'd like to toss out the suggestion for bringing in the Variables Extension or something which provides similar functionality. Here's an example page where it could make a difference: Item Row Template. In this template, which is used on our most painful pages, we make the following pulls:

  1. color
  2. attack
  3. defense
  4. attack
  5. defense
  6. procRate
  7. procRate
  8. procDmgCap
  9. procDmgCap
  10. procDmgMin
  11. procRate
  12. procRate
  13. procDmgMin
  14. ability
  15. obtained

and we also calculate procRate / 100 * procDmgMin twice. Using variables, we could reduce this 15 to 8 and remove one of the duplicate calculations, which I imagine would help.


Doomcat (talk)13:49, 23 April 2014

the new version of #varpull was caching information. unfortunately there is a bug somewhere and i had to revert it. i was not checking the cached value to see if it was still valid.

I evaluated Variables extension. It can be installed, but it does not solve the problem (which #varpull does solve) and requires more transclusion and parsing than #varpull does to achieve the same result so Variables is less efficient at the task. Also we have to redo every item page to work with Variables. So that is some major negatives.

The use case of #varpull is this:

  1. Data exists in some article such as Game/Item/Awesome_Sword
  2. We want to generate a page which contains all the swords e.g. Game/Swords
  3. Game/Swords must query Game/Item/Awesome_Sword and all other swords to get the data

For Variables comparison of this task: See Is_there_a_way_to_get_a_value_from_one_page_from_another_page?

Where #varpull excels is getting this specific data. Where it fails is having to requery the same data repeatedly. Not a huge problem, but a solvable one using memcached, which is far superior to any transclusion. None of the ready made solutions offer the same functionality.

I will fix the new version of varpull and all will be good to make sure that it refreshes the cache when it has gone stale. Till then reverted to tried and true version that works.

I will install Variables as well for playing with, but I have a feeling that we will not get significant gains except when fields that are calculated are the same in an "ItemRow" template. Be warned there is some over head there as well.

Zoycite (talk)14:54, 23 April 2014

Variables is now installed

Zoycite (talk)15:21, 23 April 2014

I think I might have been a little unclear. I never intended variables to replace #varpull, as #varpull does what it does very well. I was just hoping to reduce the overhead of LotS' intense item list pages which have recently been acting up a little more than normal. Sorry for the confusion, and I hope I wasn't offensive.


Doomcat (talk)22:35, 23 April 2014

not offensive, my main concern is to just avoid installing things without a purpose. if we have a reason for extension that will do things we want -> install.

I could see defining a calculated value variable potentially if that value is needed in other calculations. There is a minor gain there.

I guess i was confused as to the intent of the extension:Variables somewhat. i thought we were trying to do something that it does not do so was stating that it wont really solve the primary problem that varpull solves.

I need to fix the error in the new version of varpull. The problem could have been hardware related i am still researching what went on. But I should still be able to revert to uncached behavior if i can detect when the value returned by the cache is invalid. Also i can likely improve the cached data behavior.

Zoycite (talk)00:07, 24 April 2014

I took a pass at simply extracting out duplicated varpulls from into variables, like {{#vardefine:procRate|{{#varpull:LotS/{{{1}}}|LotS Item|procRate}}}}. I don't know if you have any profiling tools to tell us if that was an improvement. A good place to check would be to see if the creation time of has decreased at all (I believe Helmets is our biggest page that uses that template).


Doomcat (talk)07:17, 24 April 2014

Server was experiencing some weird problems from higher than normal load. RAM has been increased to 16GB as a result.

  1. varpull has been reverted to a pre-cache state as weirdness was resulting from varpull data.

This should address most of the pressing issues over the next hour automatically.

Zoycite (talk)13:08, 23 April 2014

Errors on LotS-pages

There are a lot of errors on the LotS pages (e.g.

Expression error: Unexpected * operator.

What can be done to correct this?, 23 April 2014

I am working on fixing it.

Zoycite (talk)12:51, 23 April 2014

pending #varpull changes

NOTICE: The #varpull extension will be changing!

I am making a major change to #varpull that will improve performance that could impact the accuracy of list pages such as LotS/items/Officers.

This change will leverage memcached on the server side to store article text so that subsequent queries to an article over a period of time do not query the article. This will drastically improve performance on large pages such as LotS/items/Officers.

Accuracy of list pages may be impacted as long as the page lives in memcached. This is pretty much a non-issue though, but should be advised that the cache may take longer to update when changes are made. New items added to the list should be unaffected, unless their source article is updated prior to the cache in memcached expiring.

Zoycite (talk)12:01, 30 March 2014

Changes to #varpull are now live and varpull is correctly pulling data from memcached.

We should see significant improvement on several pages with multiple calls to varpull.

It is important to note that there are 2 different types of cache involving memcached. Each page generation is stored in memcached for approximately 2 minutes. #varpull caches target article text which it retrieves for 15 minutes. So it may take up to 15 minutes for a item table to update even if you forcibly save the item table page. As a bonus though, the page will pull from cache with minor updates so the 2 minute page cache will be generated faster since it will pull its data from the #varpull cache.

Now we can safely continue bombarding #varpull with an obscene number of requests without worrying too much about the performance hit.

Zoycite (talk)00:34, 13 April 2014

fully anon edit enabled

I enabled fully anonymous editing as a test of some new security settings.

If we see a lot of spam, the settings will be reverted.

Zoycite (talk)14:32, 23 October 2013

Testing cloudflare

I turned the site onto Cloudflare for testing to see how well it operates.

Please check it out over the next couple days. I hope that performance increases quite a bit for most people.

Zoycite (talk)11:04, 15 October 2013

the speed now is impressive, only one issue im having, when clicking any link to a page that does not exist yet it reports it cant find the page and gives you a search box instead of taking you to the new page creation, i can get around this by modifying an edit url, not sure if you can change the redirect

Lorak990 (talk)13:41, 17 October 2013

Breaking up pages

It came up in AIM chat that certain pages need to be broken up, or we need a better way of handling them. Particularly for mobile/low bandwidth users.

Figuring out a logical scheme to break up the pages would be nice, if we can preserve the utility of the pages.

Pages that are a problem are like LotS/items/Officers, too much template expansions and expensive parser functions. LotS suffers from it the most, however LoH does have quite a bit of a problem as well.

zoytip may help this problem and we can reduce some of the formatting by removing the description possibly. However this is still in development.

This is only really a problem for huge pages. But these pages do impact overall site performance. Breaking the page up in a logical way seems to be the best bandaid solution to me for now.

Zoycite (talk)23:57, 30 July 2013

Well, the main use of those pages is to compare officers quickly. If I asked a question like: "What's the best Melee officer that a free player can easily obtain?", I can sort by AV ascending and then sort by Role and scroll down to the Melee section. Next, I skim the Obtained column for where I get the officer (Vaults, Expeditions, and Limited Time items are not for free players, so exclude those) and find that 1000 is the best. Furthermore, I can then see in the Ability column that other officers like Acht will boost him even further.

That's really what I feel like the core usage of that page is. If users just want to see a list of Officers, they can use the category page Category:LotS/Officer. I fear, then, that breaking up the page will then pretty much kill the utility it provides unless you can do some kind of like fancy wiki pagination stuff where the sorting happens across multiple pages, in which case I'm cool with that.

To your point, those pages are taking longer and longer to generate, as is illustrated by the fact that I have to purge that page with some frequency.

I guess my opinion is, then, that if we can't keep the page as it is (or with some crazy paging stuff), that it's kind of pointless to keep, and it should just be killed off entirely. Hope that's not too harsh.


Doomcat (talk)15:10, 31 July 2013

I probably wont be able to get sorting across multiple pages working, that just is not feasible.

While incredibly useful that it does display all in one place and is sortable, maybe we can break it up into Type, that seems to be the most logical. Eliminates the need to sort by melee since it is being done already, so saves you a step.

Also maybe we need to have a shorter page that is just name, type, AV. We should probably have the user click on the page to get the obtained info. Lots of reasons for this, but rendering the descriptions are expensive.

Other pages that have lots of entries we should break up into pages by AV (or other stat) if there is no distinguishable type on the item.

Zoycite (talk)22:20, 9 August 2013

The officers work on three main axes: Race, Role, Attribute. I'm not sure which one would be best (or even maybe all of them?) to divide the pages on, but I guess whoever gets around to making the split can just decide and do it, and we'll clean up afterward if it's awful.


Doomcat (talk)15:00, 3 September 2013

Ah, so this is why the item category pages keep getting screwed and needing purging? I was wondering if that was it, just getting too big with too many calls. Just had a message on FB mentioning that a bunch were messed up so I purged them. It would be a pity to split up item category pages... Officers are the only one with as clear a division, but even dividing that makes it harder tracking down officers with bonuses vs various raid types etc. The equipment category pages are too big too.  :-/ I suppose another way to split everything is GS/free, really only causes an issue when people are comparing old GS items and new free items.

As a patch in the meantime, could there be a handy Purge button with the Edit button? DotD wiki on wikia has that, although its far more necessary there since every item page has to be purged after creation or editing due to the nature of the templates.

Feathin (talk)21:07, 2 October 2013

I will see if I can enable a purge.

The main concern is page load time for people. This is what breaking up the page would do.

Categories work a bit different and are a feature of mediawiki. I am talking mostly about the pages that are big lists of things with tons of items on them.

Zoycite (talk)22:22, 2 October 2013
First page
First page
Previous page
Previous page
Last page
Last page