User talk:Poke

poke | talk | contribs | logs
add new section • archive

Wikichu | talk | contribs | logs

GuildWarsWikiTools | talk

DPL fixes

Seeing that you are dealing with these problems, I wandered if you would have the time to fix other related issues such as User_talk:Chieftain_Alex/Archive_5#More_DPL_fixes. Yoshida Keiji(talk) 19:22, 22 January 2013 (UTC)

Those are totally irrelevant to poke's fixes :/ you ask for the impossible really, the dpl can't be trained to look for upto-date skill histories >.< Chieftain Alex 19:39, 22 January 2013 (UTC)

Alex is right, this is kind of unrelated. Nevertheless DPL is sure capable of giving you some feedback if the pages were updated or not. You can use the addeditdate setting to add the edit date of a page to the output; if you put together the format in a smart way then, you could check if that date (accessible via %DATE%) is older than the last update (which you would need to specify somewhere) and control the output that way. An easier way would be to just filter the results using lastrevisionbefore and just get back a list of pages that need to be looked at. Unfortunately, this will neither give you information if that edit was actually correct, or provide you a way to mark off pages that simply do not need a change (unless you edit it somehow of course). So it might not be that useful after all. poke | talk 19:59, 22 January 2013 (UTC)

I will correct myself. I chose bad wording with "related". I meant to say: until today I didn't saw anybody else fixing DPLs. Instead of where these DPLs are applicated and also I didn't check what was changed. I said this because I have no idea at all about such codings. As for the rest, I will play a bit with the Project's DPLs. Yoshida Keiji(talk) 20:24, 22 January 2013 (UTC)

Btw. there is no (longer?) DPL list on the project page, hence me not giving further details/examples. poke | talk 20:38, 22 January 2013 (UTC)

The DPLs are duplicated at Guild Wars Wiki:Projects/Skill history/nav box...and at Guild_Wars_Wiki:Projects/Skill_history#Progress_report tables just below. Yoshida Keiji(talk) 12:55, 13 February 2013 (UTC)

THANKS

No really thank you, what was with that guy? Thanks for fixing my bio user page and watching my back. --Jabhacksoul 11:07, 13 February 2013 (UTC)

DPL and Variables

Note: While writing this I realized that it got a lot longer and a lot more technically than I initially wanted. If you just want a tl;dr read the last two paragraphs.

In any case somebody is interested in this: In the course of the upcoming MW update, I spent a few hours last night trying to figure out what exactly is causing the issues with DPL and the Variables extension, because the problems were still present with the latest versions of all three parties.

The good news is, that I figured out what happens and why it happens. The thing is that the Variables extension attaches its variables to the parser instance on MediaWiki. That way, the variables are accessible during the whole parsing process of a page. In some older version, there was just a simple global object holding onto variables, so they could leak into other pages when multiple parsing processes happened at the same time (this usually isn’t the case, but can happen in the background). As such the separation by attaching it to the parser makes a lot of sense.

To now understand the problem DPL has, I first have to explain how it works when the include parameter is used. That parameter allows to find all invocations of a specified template and change them in some way before DPL then returns the output to the calling page. When used with a substitute template, e.g. include = {Nicholas the Traveler research}.page, it will find all invocations of the original template ({{Nicholas the Traveler research}}) and for each match invoke the substitute template instead ({{Nicholas the Traveler research.page}}). All the specified parameters are kept the same, so the substitute template can work just like the original template but return a customized format for DPL instead. Now each of those invocations results in the (substitute) template being expanded. Template expansion is the standard process when the parser substitutes the template call with the template’s content and inserts all the parameters and stuff. So at this point, the MediaWiki parser is used.

The problem now is that each parsing process clears the internal state of the parser. This resets obvious stuff like the output, TOC information and counters, but this also tells the Variables extension to restart itself. As such all variables are no longer collected together and cannot carry over to the calling page.

Now, one could argue that this is the fault of the Variables extension; why does it need to restart there? As mentioned, this is to prevent variables from leaking from one parsing process into another one. And usually, you would only have a single parsing process, so this should completely work. Now, DPL could check for the existence of the Variables extension and just “manually” keep the variables alive while it’s running. I definitely considered this, but the way DPL is built, this is nearly impossible. There are very many locations where the parser is started, so this would end up in a hunt to find all the necessary locations where copying over the variables would have to be done. And I certainly would miss some locations, without being able to test every possible case. I blame this very much on the architecture behind DPL, which is a huge blob of code, hard to read and very complicated to adjust. As the original author stopped working on the project, this could change in the far future (with other people—like me—working on it), but for now, it’s just not something that can be done well.

I also disagree with the way DPL works in this case. As explained above, every template call is handled separatedly, replaced by a call to the substitute template and parsed individually. So for example for our Nick things, DPL has a lot separate calls like this: {{Nicholas the Traveler research.page|<and then a list of parameters>}}. And nothing else, just that. So a separate parser is run just for a single template expansion. DPL then collects all those results and just sticks them together based on the output parameters of the DPL call on the original page. I see no reason, why a separate parser needs to run there, especially not for a single template. If I have a DPL call that just collects all these substitute template calls and puts them next to each other—and that’s exactly what we are doing with Nick—then DPL could also just put the following as the result of the DPL call:

{{Nicholas the Traveler research.page|<parameters of call 1>}}{{Nicholas the Traveler research.page|<parameters of call 2>}}{{Nicholas the Traveler research.page|<parameters of call 3>}}{{Nicholas the Traveler research.page|<parameters of call 4>}}{{Nicholas the Traveler research.page|<parameters of call 5>}}…

So it would not need to parse each of those template calls separately; it could just put the template calls within the defined output format and leave the actual template expansion to the parser which is parsing the original page. That way, variable definitions inside those templates would be left intact and could be processed by the original parser, and as such would be available on the original page.

It’s possible (and likely) that I don’t see the whole picture of DPL here. As you know, DPL can do a lot more than just this template substitution, and it’s possible that there are cases where such a simple way would not work. But I’m quite sure that it would work for this case, and for many—if not most—other cases as well. And maybe those cases which do not work like this could be then handled as separate cases where parser state patching would be possible again.

In any way, to come to an end here, DPL and variables set within substitute templates will not work, and it won’t get “fixed” either. Based on the implementation of both DPL and the Variables extension, this is completely expected behavior and not a bug. It’s just an inconvenience we have to remember, that variables set within templates which DPL includes do not carry over to the original page.

Fortunately we have a very simple workaround for this: DPL variables. They are much inferior to the variables available from the Variables extension, in the way that they work mostly in the same way the Variables extension worked in the beginning (global variables, that can possibly leak everywhere). But thanks to this, they do work within DPL includes. As such, when you want to set variables within DPL include templates, use {{#dplvar:set|<name>|<value>}} and {{#dplvar:name}}. But outside of DPL calls, please refrain from using them, and use the variables from the Variables extension.

So yeah, that’s it on this topic. If you have further questions, just ask away. poke | talk 14:34, 27 April 2013 (UTC)

(Ok its not really related to variables, but it is related to leaky parser states.)

Perhaps you recall how using DPL in the middle of articles with the Cite extension causes it to only pick up the references after the dpl invocation? e.g. [1] (dpl clears the internal parser that cite was using). Do you know if that will be fixed when the MW version gets upgraded? (i.e. will we get v2.01 to replace 2.0?) -Chieftain Alex 12:24, 29 April 2013 (UTC)

Yes, I don’t know which part exactly prevents this from working here right now, but yeah with the version combination, we will be running with the update, this issue is gone forever. The current version of DPL contains special code for the Cite extension that basically undoes the state clearing for the citation data. It’s really a ridiculous hack, but it works… We will get the 2.01 version, yes (although the .01 is not why the citations work), which is the final and last version from the original author. poke | talk 17:00, 29 April 2013 (UTC)

Deletion drop down fix

After seeing your fix on gw2w gw2:MediaWiki:Common.js I thought I'd try and implement the same fix here...

I can get it to work in firefox scratchpad preview but when I try and glue it into the common.js it doesn't have any effect. (yeah I'm still a failure with .js - maybe its because in the js on this wiki we load everything using one function) -Chieftain Alex 14:19, 19 May 2013 (UTC)

You know, comparing the diff from one wiki with the diff you get here should tell you if you made the same changes or not :D poke | talk 18:29, 19 May 2013 (UTC)

I thought it was wierd to invoke load function twice for the same item (once at the top of the list, one halfway down.. ) Also damn I was one bracket out xD Thanks for fixing! -Chieftain Alex 19:14, 19 May 2013 (UTC)

hookEvent('load', x) just registers x to be executed when the load event fires. So you can attach as many functions as you want. And actually, only a single function is attached, as the first part is never executed when the action is delete (thus it needed to be moved out). poke | talk 14:17, 20 May 2013 (UTC)

ugh

pling 17:23, 23 October 2014 (UTC)

Ugh your face. poke | talk 17:28, 23 October 2014 (UTC)

In unrelated news, pling should fix his signature by adding link=User talk:Pling -Chieftain Alex 17:34, 23 October 2014 (UTC)

Skill Nav Revamp

Requesting advanced formatting assistance and feedback on Skill Nav Revamp. --Falconeye (talk) 21:37, 26 May 2015 (UTC)

Sig

Sorry, I was just trying to change it. Wasn't thinking about it breaking stuff. Drogo Boffin 07:23, 2 September 2020 (UTC)

No worries. You can always change it for your future signatures, or you could even go back and change all existing references (but that would probably be painful). Having a red link from a missing signature icon on discussion pages is a bit distracting though :) poke | talk 07:29, 2 September 2020 (UTC)

Okay so I made a mistake and uploaded the wrong new sig and for the life of me I cannot remember how to upload a new image but smaller. Remembered how to fix it. Drogo Boffin 07:35, 2 September 2020 (UTC)

Plinging

Why have you forsaken me? - Tanetris (talk) 20:56, 26 September 2020 (UTC)

Don’t worry, I haven’t! I’m just drowning in work at the moment. Will get back to you tomorrow. poke | talk 01:57, 27 September 2020 (UTC)

So abandoned. So alone.

Hope you're doing okay buddy. - Tanetris (talk) 01:12, 29 September 2020 (UTC)

request for comment

Hello! I hope you are doing well - you are listed as a Standby administrator, which I hope means you are willing to step in and give your input as an editor (or former editor) on an ongoing wiki discussion (located here) - thanks, and sorry to bother you!

Thanks, horrible 21:40, 30 June 2023 (UTC)

Thanks for the heads-up Horrible, I’ll take a look :) poke | talk 23:31, 30 June 2023 (UTC)