Re: [Wikitech-l] Adding of JavaScript from extension not wo rking properly on fresh wiki
Ryan Lane rlane32 at gmail.com writes: The javascript you are outputting is dynamic content, and it is being cached by the parser cache. You can disable the parser cache on pages that use your extension Thank you so much! It seems to be working as expected now after I disabled the parser cache. Cheers! /Micke ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Someone was considering Lua?
* David Gerard dger...@gmail.com [Mon, 5 Oct 2009 19:16:08 +0100]: http://codepad.org/cmQIjdzI I suppose you can do that more easily than in ParserFunctions ... Any language can be abused. The problem is opposite: when you need to have clean, well-readable code, some languages offer better help. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Someone was considering Lua?
2009/10/6 Dmitriy Sintsov ques...@rambler.ru: * David Gerard dger...@gmail.com [Mon, 5 Oct 2009 19:16:08 +0100]: http://codepad.org/cmQIjdzI I suppose you can do that more easily than in ParserFunctions ... Any language can be abused. The problem is opposite: when you need to have clean, well-readable code, some languages offer better help. indeed ;-) Perhaps an International Unobfuscated ParserFunctions Context? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Someone was considering Lua?
* David Gerard dger...@gmail.com [Tue, 6 Oct 2009 12:30:51 +0100]:
2009/10/6 Dmitriy Sintsov ques...@rambler.ru:
indeed ;-) Perhaps an International Unobfuscated ParserFunctions
Context?
I am not expert on this. The readability of templates can be improved:
if there were separate wikitext context and Parser interpreter context,
there would be no need to place additional double curly braces in source
code during every Parser function call, while wikitext would be
insterted in escaped (quoted) strings, something like this:
(imaginary code in NS_TEMPLATE)
{{#if: test string | value if true | value if false }}
{{#ifeq: string 1 | string 2 | value if true | value if false }}
{{#ifexpr: expression | value if true | value if false }}
interpreter
if('test string','value if true','value if false')
ifeq('string 1','string 2','value if true','value if false')
ifexpr('expression','value if true','value if false')
/interpreter
escaping apostroph probably should be enough. Doesn't look much
different at the first sight, but imagine these nested.
where interpreter context syntax is different from wikitext syntax,
but because templates generate the wikitext, they can be presented
inside interpreter as escaped strings. And the default (wikitext)
context is compatible to the existing template syntax. The same
functionality in the interpreter context, but with better readability
for templates and worse readability for wikitext (which is a selectable
trade-off).
Just an idea, probably can be improved.
Dmitriy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Someone was considering Lua?
* David Gerard dger...@gmail.com [Tue, 6 Oct 2009 12:30:51 +0100]:
indeed ;-) Perhaps an International Unobfuscated ParserFunctions
Context?
ah, just forgot to add: template parameters will be $1 in the
interpreter
context, not a horrible {{{1}}} (keep it for the compatibility in
wikitext context) .
Internally, the language is the same, only two different syntax
contexts.
Dmitriy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Someone was considering Lua?
David Gerard wrote:
indeed ;-) Perhaps an International Unobfuscated ParserFunctions Context?
- d.
There should be an alternative way to do:
{{#if: {{{foo|}}}|
{{!}}-
{{!}} Foo
{{!}} {{{foo}}}
|}}
Ie: If parameter foo exists, add it surrounded by a title and a table cell.
We would need an outer {{{foo|}}} syntax.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] A suitable error message for iPhones
Are you *sure* we can't put a narky message when iPhone users click a video? Adobe do! http://twitpic.com/kf361 (assuming it's real - can anyone with an iPhone please check?) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A suitable error message for iPhones
It's real alright. Michel 2009/10/6 David Gerard dger...@gmail.com Are you *sure* we can't put a narky message when iPhone users click a video? Adobe do! http://twitpic.com/kf361 (assuming it's real - can anyone with an iPhone please check?) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A suitable error message for iPhones
2009/10/6 Michel Vuijlsteke wikipe...@zog.org: 2009/10/6 David Gerard dger...@gmail.com Are you *sure* we can't put a narky message when iPhone users click a video? Adobe do! http://twitpic.com/kf361 (assuming it's real - can anyone with an iPhone please check?) It's real alright. Michel I am of course ONLY JOKING and not advocating seriously that we do this. Unless it works for Adobe. Or for the lulz^U - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A suitable error message for iPhones
dgerard wrote: Are you *sure* we can't put a narky message when iPhone users click a video? Adobe do! http://twitpic.com/kf361 I'm not up on the details of Flash, so this comment may be misguided, but *if* the reason Apple restricts these unstated technologies is for security reasons, then I'm quite glad Apple does, and I'd say it's Adobe that deserves the snarky comment. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A suitable error message for iPhones
On Tue, Oct 6, 2009 at 6:35 PM, Steve Summit s...@eskimo.com wrote: I'm not up on the details of Flash, so this comment may be misguided, but *if* the reason Apple restricts these unstated technologies is for security reasons, then I'm quite glad Apple does, and I'd say it's Adobe that deserves the snarky comment. Any security considerations that apply to the iPhone probably apply to Mac desktop as well, so that wouldn't make much sense. Flash doesn't have a remarkable number of vulnerabilities compared to other large web-facing programs (like, say, browsers), and for almost all users, the slight added security threat is worth it. I imagine the actual issues here involve things like that iPhone/iPod uses ARM; Flash uses too much battery life; or insufficient money is going one direction or the other. I would take it for granted that Apple would like iPhone users to be able to view YouTube. I would *like* to say that all this just underscores the danger of proprietary, closed-source technologies like Flash, but of course, Theora isn't in a very different situation here. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A suitable error message for iPhones
On Tue, Oct 6, 2009 at 6:59 PM, Aryeh Gregor simetrical+wikil...@gmail.com wrote: On Tue, Oct 6, 2009 at 6:35 PM, Steve Summit s...@eskimo.com wrote: I'm not up on the details of Flash, so this comment may be misguided, but *if* the reason Apple restricts these unstated technologies is for security reasons, then I'm quite glad Apple does, and I'd say it's Adobe that deserves the snarky comment. Any security considerations that apply to the iPhone probably apply to Mac desktop as well, so that wouldn't make much sense. Flash doesn't have a remarkable number of vulnerabilities compared to other large web-facing programs (like, say, browsers), and for almost all users, the slight added security threat is worth it. I imagine the actual issues here involve things like that iPhone/iPod uses ARM; Flash uses too much battery life; or insufficient money is going one direction or the other. I would take it for granted that Apple would like iPhone users to be able to view YouTube. I would *like* to say that all this just underscores the danger of proprietary, closed-source technologies like Flash, but of course, Theora isn't in a very different situation here. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Fwiw, the HTC Dream and HTC Magic (first Android phones) run ARM processors, so I don't believe that's the sole concern; I believe that the Palm Pre is on ARM as well, but don't quote me :) Granted, doing intensive flash stuff will drain your battery on any phone, but I don't think the processor is the restriction here. I'm not sure how good the reporting is, but: Adobe said that a Flash Player for the iPhone is not being made available because it uses a just-in-time compiler and virtual machine within a browser plug-in to play back website content - technologies that aren’t currently allowed on the iPhone. [1] -Chad [1] http://www.gizmag.com/flash-player-101-for-smartphones/13042/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A suitable error message for iPhones
2009/10/7 Chad innocentkil...@gmail.com: Adobe said that a Flash Player for the iPhone is not being made available because it uses a just-in-time compiler and virtual machine within a browser plug-in to play back website content - technologies that aren’t currently allowed on the iPhone. [1] Apple does not like Turing-equivalent machines being available on their preciou. They rejected the Commodore 64 emulator for having the BASIC accessible! Perhaps it was a SECURITY MEASURE in case someone started WORLD WAR THREE on it. http://is.gd/41eVm Claiming security is about as plausible as their claim they don't want Ogg because of submarine patents. i.e., in no way whatsoever. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] ParserAfterStrip: Bug, deliberate change or incorrect use?
Hi, I have an extension called BugSquish, which I have been happily using on MediaWiki 1.6.10 for quite a long time. I am also aware of other people using it on later versions, but cannot cite specific version numbers where it is known to work. The code works by performing a regex replace on code passed into the ParserAfterStrip hook function that I have set up, to strike out links to bugs that have been marked as fixed. On MW 1.6 this correctly handles nowiki and pre tags, in that text within these tags is not parsed by the extension. On MW 1.14 and above the code within the nowiki tags is parsed and ends up having the regex applied to it, though it is subsequently rendered as plain text by the engine (so the page ends up being filled with HTML/CSS gobbledygook, rendered literally). I am not sure at which revision this change took place. First question: Is this a bug or a deliberate change in functionality, or have I been mis-using the hook all along? Second question: Assuming this is not a bug, how should I rewrite the code to make it behave as it used to? The current code for the extension is available here, if you want to test: http://www.kennel17.co.uk/testwiki/BugSquish Cheers, - Mark Clements (HappyDog) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ParserAfterStrip: Bug, deliberate change or incorrect use?
On Tue, Oct 6, 2009 at 4:47 PM, Mark Clements (HappyDog) gm...@kennel17.co.uk wrote: Hi, I have an extension called BugSquish, which I have been happily using on MediaWiki 1.6.10 for quite a long time. I am also aware of other people using it on later versions, but cannot cite specific version numbers where it is known to work. The code works by performing a regex replace on code passed into the ParserAfterStrip hook function that I have set up, to strike out links to bugs that have been marked as fixed. On MW 1.6 this correctly handles nowiki and pre tags, in that text within these tags is not parsed by the extension. On MW 1.14 and above the code within the nowiki tags is parsed and ends up having the regex applied to it, though it is subsequently rendered as plain text by the engine (so the page ends up being filled with HTML/CSS gobbledygook, rendered literally). I am not sure at which revision this change took place. First question: Is this a bug or a deliberate change in functionality, or have I been mis-using the hook all along? This was changed during the parser rewrite several versions ago. The restructuring of the parser meant that strip markers are now handled differently and can't be routed around using that hook anymore. ParserAfterStrip is essentially a deprecated legacy that now functions the same way as ParserBeforeStrip. Second question: Assuming this is not a bug, how should I rewrite the code to make it behave as it used to? I haven't studied you code in detail, but I would suggest that using the LinkBegin hook (available 1.14+) is probably the right place to look in the current versions of Mediawiki: http://www.mediawiki.org/wiki/Manual:Hooks/LinkBegin This is called whenever an internal / interwiki link is generated and allows one modify the text / destination, apply CSS styles, and/or replace the link with something else entirely. If you are munging external links (rather than internal / interwiki links), the corresponding hook is LinkerMakeExternalLink. -Robert Rohde ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
