FANDOM

Welcome

Hi, welcome to Fandom Developers Wiki! Thanks for your edit to the Talk:StarRatings page.

Please leave a message on my talk page if I can help with anything! Cqm (talk) 07:42, August 5, 2014 (UTC)

Existsmod

Would you mind taking a look at—and merging, if you don't see any problems—Module:Existsmod/sandbox?

DarthKitty (talk) 12:06, September 17, 2015 (UTC)

Interesting, but I'm not sure it is as efficient as my implementation. As far as I can remember, one can only use require 100 times (http://dev.wikia.com/wiki/Lua_templating/InfoboxBuilder#Custom_module.27s_code). So if it is actually used in a page with 101  modules that exist it may fail for the last module. 
This is something I haven't seen in the official scribunto documentation, so it might be something that wikia arbitrarily set, or something that wasn't well documented by Wikimedia. I haven't actually tested this limit on a page.
Also, I tested it a bit, it seems to have problems with some modules, e.g. modules with spaces, redirects, and maybe modules in subpages. I'm not sure if these are in the original module or not. But I guess in both cases we need robust test-cases.
Most of your code can be merged as is, but I'm not so sure about the require section... Dessamator (talk) 13:00, September 17, 2015 (UTC)
Performance:
Another problem is that because it uses "require" it loads all those scripts into memory, in fact it was complaining about global variables because of Module:No_globals:
Look at the performance as shown by the wiki:
NewPP limit report
Preprocessor node count: 14/300000
Post‐expand include size: 3399/2097152 bytes
Template argument size: 0/2097152 bytes
Expensive parser function count: 0/100
Lua time usage: 0.093s
Lua memory usage: 2.37 MB
NewPP limit report
Preprocessor node count: 4/300000
Post‐expand include size: 3244/2097152 bytes
Template argument size: 0/2097152 bytes
Expensive parser function count: 0/100
Lua time usage: 0.098s
Lua memory usage: 1.56 MB
Dessamator (talk) 14:36, September 17, 2015 (UTC)

Script Usability and Forum Design Overhaul

Can you make this script useable? and is there a way to do a total overhaul the design of the forum section on a wiki?

User:Dessamator/samplehugescript.javascript

[[[User:MythicConditor|ᛖᛉᛏᚻᛁᛈ]] 20:12, November 24, 2015 (UTC)

In the future, please avoid pasting such big script in talk pages. It makes it very hard to use. Anyway what does the huge script do?

Dessamator (talk) 21:04, November 24, 2015 (UTC)

From the looks of it, it appears to be a copy of the code of bungie.net.
~Curiouscrab (talk) 21:13, November 24, 2015 (UTC)
Which means that it is copyrighted, and maybe that code should be deleted from my profile page. So I guess Mythic wants a similar forum styled and with functionality similar to that?
If so, there are a couple of problems. First the javascript is copyrighted, we can't reuse it here. Secondly, that looks like a huge change, I'm not even sure the terms of use allow such extreme changes. Dessamator (talk) 22:02, November 24, 2015 (UTC)
Yeah, it's copyrighted. I think he meant he wants to style the forum, not change it. The page he used isn't actually a forum page. I'll fix the script a little more to confirm this.
~Curiouscrab (talk) 00:31, November 25, 2015 (UTC)
I wasn't able to get the script to work because once I fixed where everything was loading from, it looked for cookies and got SITEORIGIN errors all over.
~Curiouscrab (talk) 00:44, November 25, 2015 (UTC)
I went to the site and found all of the CSS required for the page.

Well considering that it is copyrighted material. I think it is best that we remove it, as it is violating Wikia's terms of use. Using css to change those pages may be doable, but it would require a lot of time and effort. Wikia is also developing new forum software so that effort might be for nothing.

So unfortunately, I'll have to decline the request, and remove the page... Dessamator (talk) 10:02, November 25, 2015 (UTC)

Clarity, non-dev-style

Hey, Dessamator!

I have a smattering of a programming background, but I'm definitely no modern-day developer, so it's not always easy for my brain to process new code or even documentation. Case in point, from Global Lua Modules/Autochangecat:

Loading modules from dev.wikia
Create Module:Autochangecat in your wiki then add the following code:
local moduleName = require("Dev:Autochangecat")

Template install / usage
Use the code above or replace it with Module:Autochangecat's code in a wiki (for local use), then add this to a template (e.g. Template:Autochangecat):
{{#invoke:Autochangecat|main}}


Here's the same passage again, as viewed by my brain in its desperate yet futile attempt to gain knowledge; ;-)

Loading modules from dev.wikia
On my wiki (NOT the dev wiki!), create a new page called "Module:Autochangecat". Paste into the new page the one line of code below, then save the page.

Template install / usage

  • "Use the code above"
    • Yeah, okay, I already did that part, didn't I?
  • "or replace it with Module:Autochangecat's code"
    • Wait, so the code I just pasted into Module:Autochangecat wasn't Module:Autochangecat's code? Then, what was it?
  • "in a wiki (for local use)"
    • Okay, huh? Now I have to decide whether the code I just installed on my local wiki (NOT the dev wiki!) is for local use or not? What other kind of use would it be?
  • "then add this to a template"
    • Yo, hold the phone! I'm not adding anything else to anything else until I get some kind of grip on the slippery stuff that just slid right past my head.

After about 10-15 minutes of reading, re-reading, head-scratching, and other assorted manipulations, I finally managed to grasp that require("Dev: was a clue that the Module page I created on my wiki still has to pull everything from your wiki, every time it runs. Clicking the appropriate link led me to Autochangecat's actual code. At that point, I understood that I probably need to do the replace thing you mentioned, but that only confused me more. If I have to replace the one line with all this code to make it run locally on my wiki, then why did I even need to bother with the one line? Why all the back-and-forth with dev and local? I don't understand how ANY of this works, and everything I'm reading makes me less excited about Lua and more excited about sticking my head in a toaster.

So now, even though I think I understand your instructions, I'm coming back to you--with all the certainty of a jackalope at a biologists' convention--to see how little I got right and how horribly much I got abysmally wrong. :-(
TheRealPella (talk) 02:22, November 29, 2015 (UTC)

Wow. I didn't realize it is that confusing. Maybe you can help improve the documentation. Like I said before it is easy to create things, but hard to describe them.

Basically, in wikia there are two ways to use modules:

1. Use a module directly from dev.wikia repository without copying all its content and related parts over to your wiki. This means that the code is hosted in dev.wikia. So if for example we change it here, the changes will affect your wiki:

Module:Autochangecat
local moduleName = require("Dev:Autochangecat")
{{#invoke:autochangecat|main|mytemplate1|mytemplate2}}

2. Store the code or module in your wikia - This means copying everything that the module uses to your wiki, giving you full power to change everything and never be affected by any changes we make here. This is much like how one would use a regular template .

To sum up : One can either move everything related to a module to one's wikia or import code from this wikia or both.

Unfortunately, Wikia lacks a particular software update that makes it possible to export Lua modules properly. Making it hard to track down all "pages", templates or modules that  a particular module depends on.

Hope that clears up things. Dessamator (talk) 08:00, November 29, 2015 (UTC)

Chat games

Hello. I was wondering if you could help me with the chat games you created? Jumbles, SpellingBee, and Tictactoe. I've installed them, except I forgot Jumbles so I can only test it right now, and it and Tictactoe doesn't seem to be working, and SpellingBee shows up for me, but nobody else in chat, and I'm not sure how to make it work right. Do you think you could help me? I have a chat party tomorrow night.--Annabeth and Percy~They say you gotta take the good with the bad. I'll take it all as long as I have you. 20:42, July 28, 2016 (UTC)

Hmm, I haven't tested them for a very long time. Last time I successfully tested them out with a couple of people was many months ago. Generally speaking you and others need to refresh the cache because the chat uses a somewhat different system from the rest of the wiki.

TicTacToe did work a long time ago, but had some problems, and is basically incomplete. It also only works with a single user. Spelling bee on the other hand requires new Internet Browsers that support automated audio. So your best bet is probably Jumbles which only requires a keyboard,  a browser that can use Javascript , and the internet.  Also, if you can ask the others to check the browser console to see if there are any messages.

Dessamator (talk) 20:56, July 28, 2016 (UTC)

Follow-up. I looked into it, and the latest version does indeed have a bug. I would suggest copying all versions around June 18 2015, that's when I fixed a bug,e.g. :http://dev.wikia.com/wiki/MediaWiki:Jumbles/code.js?oldid=27037. As I haven't really looked or tested this script all that well for many months and wikia has changed some things related to chat, I would need to do some serious testing to check if it still works.

Dessamator (talk) 22:00, July 28, 2016 (UTC)

Ok. I'll try that out. And, sorry, I forgot to say that this was on the Best Friends Whenever Wiki in case you wanted to check it out.--Annabeth and Percy~They say you gotta take the good with the bad. I'll take it all as long as I have you. 21:52, July 29, 2016 (UTC)

I'm testing it, but it's not working at all. Thanks anyway!--Annabeth and Percy~They say you gotta take the good with the bad. I'll take it all as long as I have you. 00:12, July 30, 2016 (UTC)

You're not the first person that complained this script didn't work (see the script talk page). So I'll try looking into fixing it next week. But as you can imagine testing it is very time consuming because I need to check if two different browsers are getting the same messages, and this was originally tested offline, which made it easier but didn't account for things such as network lag.

Unfortunately, it is such a huge script  ( and largely undocumented) that no other developer would likely be willing to spend the time to understand it and test it ...

Anyway, I can easily make it work for a single user, so everyone would be seeing their own private game, although I suspect that isn't what you want ...

Dessamator (talk) 10:28, July 30, 2016 (UTC)

I guess you're lucky, the fixes were smaller than I expected, and they've been tested by myself and my bot account. They'll probably be approved on Monday or tuesday.

Dessamator (talk) 13:45, July 30, 2016 (UTC)

That's great! Thanks!--Annabeth and Percy~They say you gotta take the good with the bad. I'll take it all as long as I have you. 19:10, July 30, 2016 (UTC)

InactiveUsers

Hi,

I saw the page InactiveUsers on this Wiki. I'm thinking of giving inactive users a special link color. 

In CSS, we got it like this: 

a[href="/wiki/User:Someone"],

a[href$=":Someone"],

a[href$="Contributions:Someone"]

But what do I have to fill in (probably in JS) with inactive users?

Also, this: a[href$="Contributions:Someone"], the Contributions link color doesn't work. Did I do something wrong?

Thanks, Teh Sweggurboi (talk) 07:15, August 22, 2016 (UTC) The appearance is applied to all inactive users as the page itself shows, try something like:

.inactive-user {
    background-color: rgb(180,180,180);
    color: rgb(80,80,80);
}

I haven't look at the script itself or tried to use it, so I have no idea if it still even works.Dessamator (talk) 12:37, August 22, 2016 (UTC)


Thanks for getting back to me.

Does that really change the link color for every inactive contributor? I'm not talking about user tags or changing the color of their user page. I want the links of active users to appear normal (blue in my and this Wiki's case), and inactive users gray. (Sorry if that sounded rude, just checking if we're talking about the same thing)

And you seem to be right about that.

Teh Sweggurboi (talk) 15:08, August 22, 2016 (UTC)

No. This script and UserTags are only designed to change the Profile Tags not the blue links, as shown on the screenshots. You would have to request a script that does what you want either in the forums or in community central if you can't find it in this wiki.

Dessamator (talk) 15:53, August 22, 2016 (UTC)

I thought so. Thanks for your time anyway.

Teh Sweggurboi (talk) 08:47, August 23, 2016 (UTC)

Scriptlist

Can you take a look at Module:Scriptlist/sandbox when you get the chance? Not to boast too much, but I think it's leaps and bounds beyond your implementation in terms of size, clarity, and accuracy. Note that ChatSideRail is messing p.printData() up a bit, since it has a bulleted list in its description. I'm not sure how to fix that, besides updating the infobox. Everything else looks fine, though!

Here are a few snippets I used for testing:

{{#invoke:Scriptlist/sandbox|printData}}
{{#dpl:
| category = JavaScript
| include = {Infobox JavaScript}:cat:Description:Author:Scope:Languages
| format = ,«pre»,«/pre»,
| tablerow = <scriptdata>
    <name>%PAGE%</name>
    <category>%%</category>,
    <description>%%</description>,
    <authors>%%</authors>,
    <scope>%%</scope>,
    <languages>%%</languages>
</scriptdata>
| allowcachedresults = true
}}
{{#tag:pre|{{#dpl:
| category = JavaScript
| include = {Infobox JavaScript}:cat:Description:Author:Scope:Languages
| format = ,,,
| tablerow = <scriptdata>
    <name>%PAGE%</name>
    <category>%%</category>,
    <description>%%</description>,
    <authors>%%</authors>,
    <scope>%%</scope>,
    <languages>%%</languages>
</scriptdata>
| allowcachedresults = true
}}}}

Also, a few thoughts for the road:

  • We might want to use uses = Template:Infobox JavaScript instead of category = JavaScript. It's a little bit stricter, but every script should have an infobox, right...?
  • I'd much rather use Type instead of cat on Template:Infobox JavaScript. Since we have to repair every instance of that template, I think we can afford to be choosy.
  • Speaking of which, we might want to look into consolidating our attribution parameters. Currently we have Author, Using code by, and Other attribution, which seems redundant to me.

There's probably more that I'm forgetting, but I'll try to save it for Talk:List of JavaScript enhancements. :p

DarthKitty (talk) 04:58, August 30, 2016 (UTC)

Not to boast too much, but I think it's leaps and bounds beyond your implementation in terms of size, clarity, and accuracy.

Looks good overall, I'm no dpl expert and generally stay far away from it due to performance issues, although this seems to be a necessary evil this time.

A couple of issues though:

  • Duplicated code - The table formatting of the dpl looks good, but there is quite a lot of duplicated code in terms of pattern matching. This makes it really fragile if the code changes one day. Something like this may help:
local scripts = {}
dplResult = "<scriptdata><name>script1</name> <category>cat1</category></scriptdata><scriptdata><name>script2</name> <category>ca2</category></scriptdata>"
local tmpScriptData = {}
for data in dplResult:gmatch("<scriptdata>(.-)</scriptdata>") do
        
        for tagName, propData  in data:gmatch("<(.-)>(.-)%b<>") do
              tmpScriptData[tagName] = propData
        end        
        if next(tmpScriptData) then
           table.insert(scripts, tmpScriptData)
           tmpScriptData = {}
        end
end
  • Test cases - These will need to be updated
  • Script types - Module:Scriptlist/types need to be in synch with changes to the infobox
  • Localization - Some scripts have translated pages, which mean that we may get duplicate content, e.g. ChatTags/es. So these will also need to be added to the original schema, and filtered appropriately.

Note that ChatSideRail is messing p.printData() up a bit

Yes, I noticed that too, but didn't realize where it was coming from. Solutions include wrapping the description in a <span>, chopping off the long description (120 chars or so), or alternatively use lua to nowiki it.

We might want to use uses = Template:Infobox JavaScript instead of category = JavaScript.

In theory yes, in practice perhaps not, unless the dpl at the bottom of the page is left behind to catch all other stragglers (new developers may not add that). Considering the performance effects of dpl it doesn't seem like a good idea to have too many dpl calls on the page.

I'd much rather use Type instead of cat on Template:Infobox JavaScript

Me too. The cat was added because it seemed like a pain to change so many infoboxes just to test out scriptlist. Personally, the "type" === "Javascript" has never made any sense to me.

Speaking of which, we might want to look into consolidating our attribution parameters.

Agreed. This is cruft left behind from the previous contributors who created the infobox.

Generally speaking, the infobox also needs to change to reject certain values to ensure consistency, e.g. script "cat" != "CHAT" and "Chat Script" AND "Chatroom scripts".

Dessamator (talk) 09:21, August 30, 2016 (UTC)

Hm, I don't think the pattern "<(.-)>(.-)%b<>" will work:

local inspect = require("Dev:Inspect")
local myString = "<outer>We have lots of <inner>data</inner> for you.</outer>"
local tagName, propData = myString:match("<(.-)>(.-)%b<>")
 
mw.log("The tag name is: " .. inspect(tagName) .. ".")
mw.log("The property data is: " .. inspect(propData) .. ".")
The tag name is: "outer".
The property data is: "We have lots of ".

As you can see, it stops matching as soon as it sees something that looks like a <tag>, which could mess up our data if someone has, say, a <br /> in their infobox.

I suppose we could do something like this:

local uglyPattern = [=[<scriptdata><name>(.-)</name><category>(.-)</category>
|<description>(.-)</description>
|<authors>(.-)</authors>
|<scope>(.-)</scope>
|<languages>(.-)</languages></scriptdata>]=]
 
for a, b, c, d, e, f in dplResult:gmatch(uglyPattern) do
    table.insert(scripts, {
        name = a,
        category = b,
        description = c,
        authors = d,
        scope = e,
        languages = f
    })
end

...though that's even more rigid/fragile than what we already have. :/

As for your other concerns:

  • I can update the testcases easily enough. We're just dealing with slightly bigger tables is all.
  • I haven't touched types yet. We need to standardize/repair Template:Infobox JavaScript before they're usable anyway, so no big deal.
  • Dealing with i18n is probably our next goal, after we clean up the infoboxes. We can filter ChatTags/es et. al. out easily enough, but I don't think there's any harm in leaving them in either.

I've also been messing around with a surrogate template. The results are promising, but performance might get even worse, if you can believe that. I dunno if it's worth pursuing further...

DarthKitty (talk) 22:32, August 30, 2016 (UTC)

The first issue is easy to overcome.

local scripts = {}
dplResult = "<scriptdata><name>script1</name> <category>cat1</category></scriptdata><scriptdata><name>script2</name> <category>ca2</category></scriptdata>"
local tmpScriptData = {}
local validTag = {description=1, name=1,authors=1, scope = 1,category = 1}
for data in dplResult:gmatch("<scriptdata>(.-)</scriptdata>") do
        
        for tagName, propData, twinTag  in data:gmatch("<(%S-)>(.-)</(%S-)>") do
              if validTag[tagName] and twinTag == tagName then
                 tmpScriptData[tagName] = propData
              end
        end        
        if next(tmpScriptData) then
           table.insert(scripts, tmpScriptData)
           tmpScriptData = {}
        end
end

Also, we have the Global Lua Modules/Xml parser which is designed to handle XML stuff like this. Although it seems like overkill for this script.

  • Testcases - Good to know
  • Types - I've managed to get them working in a hacky way, in Module:scriptlist
  • i18n - This is not much of an issue, I agree, either strip them or adding them in brackets, or even better use mw.language to show the language name in the language autonym.

I looked at the newpp report for the "javascript list" page and oddly it doesn't even register dpl as an expensive call. Seems very strange as dpl is heavier than lots of other expensive calls, but I suppose caching does help. It seems doubtful that we'll need the surrogate template as long as we simply use the category, and fallback to just adding title when we don't have further infobox data.

Considering the number of pages we are loading, we may want to mark the module as expensive anyway. Dessamator (talk) 22:57, August 30, 2016 (UTC)

Just looked at the surrogate thing. It looks like a good idea instead of using the table hack, which seems fragile at best. Dessamator (talk) 23:35, August 30, 2016 (UTC)

Okay, the sandbox now uses a surrogate template, which is currently stored at User:DarthKitty/surrogate and User:DarthKitty/surrogate.default. Possible performance issues aside, I really like this solution because it gives us complete control over the output format. Well... almost. For whatever reason, if the infobox transclusion ends with more than two }s, at least one of them will percolate through to the surrogate. For example:

Bad Good
{{infobox
...
| param = {{some-template}}}}
{{infobox
...
| param = {{some-template}}
}}

I'm pretty sure this is a problem with DPL itself, but it's easy enough to fix—not that it matters right now, with how we're parsing the results. I also tried using JSON instead of XML, but that took a lot of work (escaping) and seemed way slower.

In regard to types, I think we should move all data validation to the infobox itself. That is to say, Scriptlist should assume that it's getting valid data. There are two reasons for this:

  1. Performance: DPL isn't doing us any favors in this department, so we should try to avoid extra parsing.

  2. User-friendliness: The best time to warn somebody about invalid data is when they're writing it. For example, imagine a template as follows:

     {{#if: {{{param|}}} |
     {{#if: {{{eter|}}} |
     
     <infobox>...</infobox>
     
     | <strong class="error">Error: the <code>param</code> parameter is required.</strong>}}
     | <strong class="error">Error: The <code>eter</code> parameter is required.</strong>}}
     

    If somebody leaves out the param or eter parameters, they'll get a big red error instead of an infobox. As long as we use descriptive error messages, people should have no problems fixing their mistakes.

    This is especially true in our case: if we aren't upfront about their mistakes, script writers might accidentally break List of JavaScript enhancements.

DarthKitty (talk) 23:37, September 1, 2016 (UTC)

The surrogate system is nice but a bit confusing. Anyway, if it is too slow we can always revert back to the table row thing.

That is to say, Scriptlist should assume that it's getting valid data.

That will never work because dpl fetches the template parameters and someone can input any nonsense as a parameter without hitting preview. This would mean that the module would make it easy to vandalise two pages.

>This is especially true in our case: if we aren't upfront about their mistakes, script writers might accidentally break List of JavaScript enhancements.

That's exactly why we need to validate the content before outputting it. People should be free to make mistakes in page X without worrying about breaking page Y. Especially considering that most users won't even realize where the data from List of JavaScript enhancements is coming from. Dessamator (talk) 08:22, September 2, 2016 (UTC)

Ah, you're right. Just because we put up an error message doesn't mean that the data isn't sent. Okay, so what do you think we should do if, say, somebody sets the cat parameter to "JavaScript"? Earlier you said:

People should be free to make mistakes in page X without worrying about breaking page Y.

...which suggests that you don't want to show error messages, but letting incorrect data through would defeat the point of validation, so...

DarthKitty (talk) 10:38, September 2, 2016 (UTC)

There are two kinds of validation, client side, and server side. Lua currently acts as server side validation, and this is very important because while a template with "invalid" syntax may still display something, an invalid lua call will just show an error without any useful content.

There is little that can be done to make people to enter valid content, short of using Extension:abusefilter (which is deployed here) or wikia implementing a server side solution like mw:Extension:templatedata and adding the ability to reject / change invalid parameters, or a javascript tool. The best that one can do for the infobox is provide an error message or tracking category when the template contains mistakes, and let people eventually fix it the "wiki" way.

People may not really know what types of Javascripts we have currently, so if someone enters "javascript" as a type that can be ignored using lua, and the script will simply be grouped under a default heading like "general scripts". Dessamator (talk) 11:25, September 2, 2016 (UTC)

If:

most users won't even realize where the data from List of JavaScript enhancements is coming from

...then scripts that are:

grouped under a default heading

...because of a mistake will never get fixed. The number of scripts under that default heading will increase with time, until everything ends up there. At that point, why bother with categorization at all? That is precisely why I think we need to warn people when they use an invalid type, or otherwise supply bad data.

With that in mind, my proposal is as follows:

  1. Create a new module, something like Module:Scriptlist/validation, that has our error-checking code. For now, it would look a lot like Module:Scriptlist/types.
  2. #invoke that module on Template:Infobox JavaScript 2: Electric Boogaloo, and have it spit out a clear error if necessary.
  3. require() that module in Module:Scriptlist, and only print the scripts that pass.

That way, script writers know if they make a mistake, while script hunters don't have to worry about it. Is my plan completely foolproof? Of course not, but holding out for a perfect solution is dumb.

(Also, can we talk about how stupid these types are?)

DarthKitty (talk) 13:43, September 2, 2016 (UTC)

The number of scripts under that default heading will increase with time, until everything ends up there. At that point, why bother with categorization at all?

I don't mind warning them, but doubt that it will be as effective as you believe it will be. Unfortunately, this is the kind of thing that is best done using a proper interface, which we don't have. The alternative is having people who care enough to put the right categories, and automatically adding all such scripts to a Category:Scripts without a proper category may at least guide future contributors.

Also, once the initial cleanup is done, there will be few issues, because scripts here aren't added that often, and the backlog will be small.

With that in mind, my proposal is as follows

I agree with the proposal except for point 3 because this is meant to be a list of "scripts", not a list of scripts with "types". That's why that dpl call at the bottom exists apparently. 15:07, September 2, 2016 (UTC)



Okay, Module:Scriptlist/validate is just about done now. Here's what we're checking for:

  • name: This is the page name provided by our DPL query, so I don't see much point in validating it.
  • category: This is case-insensitive, but should match one of the following ten values (or whatever decision we reach in this discussion):
    • user tools
    • page and file management
    • site enhancements
    • editing tools
    • user management
    • oasis skin enhancements
    • chat
    • site integration
    • development tools
    • inadvisable installations
  • description: This should be exactly one paragraph (i.e. no newlines). It's supposed to be a short description of your script, so lists and other miscellany do not belong.
  • authors: This should be a non-nested bulleted list.
  • scope: This is case-insensitive, but should match one of the following three values:
    • general
    • personal
    • site-wide
  • languages: This should be a non-nested bulleted list.

I also updated Module:Scriptlist/sandbox to only display valid scripts, of which there are currently... zero! Like you said, this won't be a problem once the initial cleanup is done.

In other news, our page situation is going to be a little bit ridiculous:

  • Module:Scriptlist/sandbox (→ Module:Scriptlist)
  • Module:Scriptlist/validate
  • User:DarthKitty/surrogate (→ Template:Infobox JavaScript/dpl)
  • User:DarthKitty/surrogate.default (→ Template:Infobox JavaScript/dpl.default)
  • Template:Infobox JavaScript/2 (→ Template:Infobox JavaScript)

We'll also have to delete Module:Scriptlist/data and Module:Scriptlist/types.

DarthKitty (talk) 14:28, September 6, 2016 (UTC)

Okay, Module:Scriptlist/validate is just about done now.

Looks good.



I also updated Module:Scriptlist/sandbox to only display valid scripts, of which there are currently... zero!

Wow, that's surprising.

In other news, our page situation is going to be a little bit ridiculous:

Hmm, yes, that was my initial hesitation with the whole surrogate business. It will be incredibly hard for anyone to actually edit this stuff without knowledge of dpl, lua, and the validation. Documenting this stuff will be complicated.



Anyway, I think we can go ahead with the module, I doubt there is actually anyone else interested in how it will end up.

Although now comes the real problem, the new layout. Dessamator (talk) 17:39, September 6, 2016 (UTC)

The way I see it, automating the current layout is our MVP, so it's a little early to worry about a new one. Here's what we still need to do, in order:

  1. Wait a few more days (at least until the weekend, but longer is better) for responses to this discussion; if there are none, update List of JavaScript enhancements and Module:Scriptlist/validate to use the new types.
  2. Write a new infobox template—one that #invokes the validator—and get it reviewed. This is our last chance to fiddle with the parameters we'll use.
  3. Replace every instance of Template:Infobox JavaScript with the new version. This will probably need to be done by hand. :(
  4. Iron out any remaining bugs in Scriptlist, and #invoke it on List of JavaScript enhancements. Aside from all of the new scripts that will suddenly appear, the transition should be as seamless as possible.

I think waiting for input is really important, because it gives us some leeway when if somebody complains about the new types/headers. "I'm sorry that you don't like it, but we already hashed this out and there were no complaints. Maybe you should pay more attention next time?"

Concerning our page madness, I think the best choice for documentation is... another page. In the past month or so, five different people have added their script to List of JavaScript enhancements. Obviously some people visit that page, so I think it makes sense to put up a notification saying, "Hey, we're generating this list automatically now. See <blah> for more information about how it works."

DarthKitty (talk) 22:42, September 7, 2016 (UTC)

I'm not sure why we would need to write a new infobox template when it can be created in a sandbox and once it is tested make an update in the original infobox. Changing templates in 200+ pages is not a good idea in my opinion.

Also, looking into the validate module, I saw that it basically shows errors for a lot of fields. It makes sense to show errors for description, and maybe one other field, but some scripts may have no authors, for example if an IP creates a script, or "gist" on github. Also outputting categories when there are errors would make it easier to track them down and fix them slowly...

Replace every instance of Template:Infobox JavaScript with the new version. This will probably need to be done by hand. :(

If it is just adding new parameters this can actually be done using a script.

I don't mind waiting but the discussion has already been "ongoing" for a month, and remember that it was triggered by someone boldly removing tabbers, and someone else boldly re-adding it. For better or worse, that was the trigger.

Anyway, a notification template seems like a good idea.

Dessamator (talk) 08:37, September 8, 2016 (UTC)

I'm not sure why we would need to write a new infobox template when it can be created in a sandbox and once it is tested make an update in the original infobox. Changing templates in 200+ pages is not a good idea in my opinion.

That's what I meant. Write a new version, stick it in a subpage, replace calls to the original with calls to the new version, use a script to clean up. Standard procedure.

If it is just adding new parameters this can actually be done using a script.

I doubt it will be that simple. Earlier we agreed that we should consolidate the attribution parameters (Author, Using code by, and Other attribution); this is just speculation for now, but I'm sure other stuff will come up once we're rewriting the infobox.

Also, looking into the validate module, I saw that it basically shows errors for a lot of fields. It makes sense to show errors for description, and maybe one other field, but some scripts may have no authors, for example if an IP creates a script, or "gist" on github.

The module currently validates five parameters: cat, Description, Author, Scope, and Languages. We're limiting cat and Scope to very specific sets of values, so validating them is necessary. We want to keep Description short and sweet, so limiting it to a single paragraph makes complete sense. Finally, Author and Languages are both supposed to be lists of things, so I think it's reasonable to make sure of that.

If a script exists, then obviously somebody wrote it—doesn't really matter if they're from GitHub or wherever else, they should still get credit for their work.

Also outputting categories when there are errors would make it easier to track them down and fix them slowly...

Will do! DarthKitty (talk) 17:40, September 8, 2016 (UTC)

That's what I meant. Write a new version, stick it in a subpage, replace calls to the original with calls to the new version, use a script to clean up. Standard procedure.

Just to make sure I understand, we are adding the new code to Infobox JavaScript right? My original plan was just to take over that template, not create a new one in a subpage, the sandbox thing was just to work without disrupting the existing usage but eventually just replace its content. That's what happened when I converted it into a portable infobox ...

Finally, Author and Languages are both supposed to be lists of things, so I think it's reasonable to make sure of that.

Code is sometimes added to the wiki page itself when it is too simple, although this mostly happens with css. So there doesn't seem to be a strong reason to push error messages for those. Anyway, it is a minor thing, so there's no need to worry too much about it.



I doubt it will be that simple.

It is nothing compared to the Macguyvering that I did in Linksweeper to get it to remove links, templates, and categories properly. At its core, it is just a matter of find and replace, e.g. find {{Infobox Javascript and replace with {{Infobox Javascript|type = type1}}. In fact, autoeditpages can remove templates from a page, and append it too.

Anyway, as long as there is an agreement on the types it shouldn't be too hard. Maybe just deciding whether to keep other categories such as chat scripts, and developer tools which are unique tools separate from the others, that aren't really related to "normal wiki" activities. Dessamator (talk) 18:24, September 8, 2016 (UTC)

Just to make sure I understand, we are adding the new code to Infobox JavaScript right? My original plan was just to take over that template, not create a new one in a subpage, the sandbox thing was just to work without disrupting the existing usage but eventually just replace its content. That's what happened when I converted it into a portable infobox ...

Ah, I see where the confusion is. The new code will eventually end up on Template:Infobox JavaScript, yes. If we put it there right away, though, our shiny new validator will add an error to every script on the wiki. 😱

To make the transition more seamless, we can (and should!) perform the operation in stages:

  1. New code goes on Template:Infobox JavaScript/sandbox
  2. Replace calls to Template:Infobox JavaScript with Template:Infobox JavaScript/sandbox, updating the parameters to match
  3. Once every page is updated, move Template:Infobox JavaScript/sandbox to Template:Infobox JavaScript
  4. Run a script to replace the string "{{Infobox JavaScript/sandbox" with "{{Infobox JavaScript"
  5. Delete Template:Infobox JavaScript/sandbox

This is what people at the Final Fantasy Wiki (and presumably elsewhere) have been doing to portable-ify their infoboxes. I've been watching how they do things for insight into my home wiki, and this one struck me as a particularly good idea. :p

DarthKitty (talk) 20:52, September 8, 2016 (UTC)

I see that approach as a lot of work, and particularly inefficient. If all we want is to see how the infobox works in practice, we can either :

  1. Add a parameter to the infobox that will redirect it to use the sandbox
  2. Use preview to make the fixes while temporarily using the sandbox, and discard the changes.
  3. Relax the validation, and make it populate the categories (perhaps a hidden category) when there are errors rather than output red error warnings everywhere.

Editing more than 250+ pages twice doesn't sound even the slightest bit efficient. It has actually given me the idea of a script that can show how a page will look with a different template. This mw:Extension:TemplateSandbox looks a bit similar to the idea. Unfortunately, Wikia doesn't have it, and probably its mediawiki version doesn't support it either.

Hmm, I wonder how much macguyvering that will require... Dessamator (talk) 10:29, September 9, 2016 (UTC)

Codeeditor

I have been waiting for the Codeeditor thing for a long time...

Supreme Lord of Supremeness II 12:21, August 31, 2016 (UTC)

You need to talk to the admins if you want codeeditor rights.

Dessamator (talk) 12:30, August 31, 2016 (UTC)I t

I Tried to talk to Cpm but I got no responce

Supreme Lord of Supremeness II 12:32, August 31, 2016 (UTC)

Maybe that's because they feel you don't need codeeditor rights, and Cqm isn't the only admin as the link above shows. In any case, the only advantage of having codeeditor rights is being able to move pages and editing codeeditor protected pages. 

Dessamator (talk) 12:36, August 31, 2016 (UTC)

Linksweeper Inquiry

Hi Dessamator, I had an inquiry about the Linksweeper script you authored if you could please assist with. So basically, can the script not "remove red-links" completely from a page? Instead of only removing the brackets and leaving the name/file intact on the page? I'm trying to accomplish a complete removal of a red-link on a page. Not sure if the script is capable of doing that but if not, no worries. Thanks for your time. --Ripto 22:27, November 16, 2016 (UTC)

Guess you're lucky to have caught me while I was still logged on. Anyway, yes, it has an option to completely remove a link from a page, e.g. :

 my [[example]] 

To:

 my  

That's actually documented on the script page. Dessamator (talk) 22:30, November 16, 2016 (UTC)

Thanks for responding! Yeah, I tried using "delete mode" (or so I thought I was doing) with ticking the "delete link" on the popup menu, but it would only remove the brackets on the red-link file. I tried it a few times and it's only currently removing the brackets. Not sure if I'm missing something obvious. Ripto (talk) 22:37, November 16, 2016 (UTC)
Hmm, you're right. That's a bug. I'll have a look at it and fix it some time tomorrow. 22:52, November 16, 2016 (UTC)
Ah okay. I'm somewhat relieved to know that as I thought I was doing something incorrectly. I would greatly appreciate a fix at your convenience! Thanks so much! Ripto (talk) 22:56, November 16, 2016 (UTC)
Should be fixed now.
Dessamator (talk) 09:54, November 17, 2016 (UTC)
That was fast, thanks a lot Dessamator! I really appreciate that, thanks for your time looking into that. One last question though, the removal will work for files on gallery pages won't it?
<gallery>
Broken file here.png
Another broken file.png
</gallery>
Example. Ripto (talk) 15:34, November 17, 2016 (UTC)
Yes, review the Linksweeper page to see all its functions or Thread:8704, and feel free to improve the documentation if that's not clear.Dessamator (talk) 18:12, November 17, 2016 (UTC)
Thanks for all your help but I've sadly run into another snag. So I'm testing this out on a gallery trying to remove "Broken file.png". I input "Broken file.png" in the link sweeper, and tick "delete link" followed by remove backlinks. Upon clicking the confirmation OK, nothing happens. It doesn't tell me the link was removed.
I tried switching to inputting "File:Broken file.png" with ticking the delete link and this time it does tell me "link(s) removed" but like last time, nothing has occurred. Am I perhaps doing something incorrect? Thank you in advance for when you can look into this. Ripto (talk) 15:03, November 18, 2016 (UTC)

Yet another bug, fixed. Dessamator (talk) 15:55, November 18, 2016 (UTC)

Alright, so this time it "is" removing the file link no problem the first time. Except, when I go to "remove" a second broken file on the same page it's replacing the previously "removed" broken file link back on the page. I did it twice so far. Apologizes that this is being a difficult bugger. It's also not deleting the "space" where the broken file is removed. If you are willing, could it delete the empty space as well upon removing broken files? Ripto (talk) 16:24, November 18, 2016 (UTC)
There is no issue with the sweeper there. It doesn't actually restore the previous page, what happens is that for performance reasons the wiki takes some time to clear the cache of a page. That will happen if you try to remove content from the same page quickly as the Wiki maintains the old copy of the page for probably 5 to 10 minutes or so. As far as spaces are concerned, it seems like a minor issue that doesn't really affect the gallery itself. Anyway, I've added the code to clean it up, but haven't really tested it all that well, and if it causes issues I'll likely just remove it.Dessamator (talk) 16:59, November 18, 2016 (UTC)
Okay, that makes sense. I think I can work with that. Certainly better than nothing. Thank you again Dessamator for investing your time into that and fixing it. :) Ripto (talk) 17:54, November 18, 2016 (UTC)

Linksweeper stopped working fully

Not exactly sure what's going on suddenly, but when trying to sweep some standard file links and template links on the thread and board_thread namespaces, the script returns '[object Object]' several times and nothing is swept. This has occurred with a number of different links so it appears to be a more widespread issue. Unfortunately, this is heavily inhibiting use of the script. A fix or some help would be much appreciated. Thanks. Hackey5 (talk) 04:38, June 24, 2017 (UTC)

I haven't changed anything related to this script, so if it stopped working, it is probably due to something that wikia staff did serverside. Anyway, considering that they are killing off forums, and the new thing doesn't seem to support wikitext, it doesn't seem useful to fix it. They'll just break it again.

My guess is that they probably tried to intentionally prevent users from editing other people's replies and this was the side-effect. There is probably a way to workaround that. But it'll just be a matter of time until they kill it off completely.21:57, August 18, 2017 (UTC)

I should make it clear, though. The script will continue to work for all other namespaces as long as the API doesn't change. It has never really done anything special for forums or any other namespace (except for lua modules).

Anyway, it has been changed to report errors for unsupported pages, so the [object object] error will go away at some point. Dessamator (talk) 19:53, August 19, 2017 (UTC)

Can I add-

i18n formatting to Global Lua Modules/Datecalc?--*Lac*() 00:41, November 20, 2018 (UTC)

Community content is available under CC-BY-SA unless otherwise noted.