Template talk:Scroll data

Oh... my god. Who thought this was a reasonable way to handle things? Any change to something in the game requires an update to this template, and every change to this template means that EVERY PAGE which uses it needs to be rebuilt by MediaWiki. Not to mention that every minor change saves an extra 100+KB. All this data should be kept with the individual pages, with separate templates for formatting the information nicely if desired. If you wanted to keep the data separate from the pages themselves, put it in a Data: namespace or /data subpages. This is just... horrendous. 128.84.125.187 06:36, 16 October 2012 (UTC)


 * The actual reason of doing such a template is that scroll data is to be shared with a lot of pages (not only individual scroll pages, but listing pages, deck pages, ...). So when a scroll is modified, the only page to be updated is this template. The goal is NOT to separate data from the pages (since most of the times it's better to keep data in pages), but it's a downsize of this way of centralizing data.
 * However, if you have a better option, we can change it. But there's one thing I'm sure about: duplicating data in every single page referring to a scroll is not a viable solution either. Wikis working this way often end up being inconsistent because people don't know how or don't have time to update all pages accordingly.
 * By the way, I've talked a bit about this template with EMIBH in the forum (see this thread). Although similar to the current solution, we were considering splitting this template according to sets or updates to be released.
 * "Any change to something in the game requires an update to this template"
 * This is not a downsize but an advantage: only one edit is required.
 * "every change to this template means that EVERY PAGE which uses it needs to be rebuilt by MediaWiki."
 * I know that updates to this template requires all related pages to be rebuilt, but this is only a cost at save time. However, splitting the template into sets would reduce this penalty since newly added scrolls would have their own template while older scrolls are less likely to be modified.
 * "Not to mention that every minor change saves an extra 100+KB."
 * I thought that MediaWiki was working like software for revision control, i.e. storing deltas with incremental version. However, if this is not the case, this would indeed be an issue. Can you confirm what is MediaWiki's architecture?
 * "All this data should be kept with the individual pages, with separate templates for formatting the information nicely if desired."
 * There already are separate templates. Template:Scroll data is only for storing data (there is no output). Formatting templates are Template:Scroll page and Template:Scroll infobox for scroll pages, and Template:Scroll table for listing pages.
 * "If you wanted to keep the data separate from the pages themselves"
 * As stated above, this is not what I want. As an example, in my opinion, Template:Scroll set data should be removed.
 * "put it in a Data: namespace or /data subpages."
 * Unfortunately,  namespace doesn't exist.
 * subpages is an option I considered, but I was thinking that transcluding non-template pages (i.e. out of  namespace) should be avoided (plus some other downsizes). However, if this is a better solution than this template, we can go for it.
 * -- fomtg 15:48, 16 October 2012 (UTC)


 * This post supports my understanding that the full page is stored with each edit. Another issue with having a single large page is that some browsers have difficulty when it comes to editing pages above a certain size. Not to mention: a vandal finding this page would disrupt every scroll page, so we'd want to protect it... except that Curse likes to allow anonymous users as much freedom to edit as anyone, and protecting this page would limit their contribution potential in a major way.
 * This is not a downsize but an advantage: only one edit is required.
 * One edit if required, if you find out everything that's changed before making that edit. However, wiki editing is usually best done incrementally rather than in large sweeping changes (to avoid edit conflicts and to simplify reverting specific edits). Having a "data" page for each scroll, and pulling the information from there, allows these small pages to be updated as new information is discovered. They use this method at the KoL Wiki and it works very well: any templates would reference information using rather than  . As we don't have a Data: namespace, we can always send a request to Curse to add one, or use the sub-page method instead. Transcluding non-template pages is not a problem at all (I know for a fact they do it all the time on Wikipedia with tv episode lists), and I would argue that Template: pages should only be for standardization, formatting, and the like, not storing information.
 * Our main problem here is that the wiki software is not designed to provide a user-modifiable database, but rather a user-modifiable encyclopedia. There are plugins which introduce complicated syntax to have wiki pages emulate MySQL and some such, but that's probably not a great idea here since all editors would have to learn this syntax just so they don't mess up when they're, for example, simply adding flavor text to a scroll.
 * Finally: I think you meant "downside" rather than "downsize" (sorry, had to do it :P). 128.84.125.187 19:54, 16 October 2012 (UTC)


 * You've given enough good arguments to convince me. :)
 * Thanks for this piece of information about MW storage, although I'm quite surprised it's handled that way. I'm pretty sure storing only the last revision as full text and then only saving deltas with older edits (i.e. the opposite of Skizzerz's example) would be more effective since most requests are for latest revisions. But anyway, that's not the point here, we have to deal with what we have.
 * OK, so  subpages seems the best solution. I agree with you about database plugin not being suitable for this wiki. And making a request for adding a   namespace may not be worth it.
 * PS: Yep, I meant downside, sorry for my mistakes. :P
 * -- fomtg 21:17, 16 October 2012 (UTC)