Last modified: 2014-11-20 09:11:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2700 - Pre-save transform skips extensions using wikitext (gallery, references, footnotes, Cite, status indicators, pipe trick, subst, signatures)
Pre-save transform skips extensions using wikitext (gallery, references, foot...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: High major with 37 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 6157 6222 6814 8125 8929 10927 12016 13072 13120 13141 13959 14007 14550 15467 15547 16183 16904 18064 18825 20359 22258 24131 24160 24446 26859 28680 29775 30135 35954 42078 72079 (view as bug list)
Depends on:
Blocks: 24774 UNIQ 56772
  Show dependency treegraph
 
Reported: 2005-07-04 21:53 UTC by David Benbennick
Modified: 2014-11-20 09:11 UTC (History)
59 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
a patch to allow extensions to output wikitext (5.68 KB, patch)
2009-03-22 20:13 UTC, bluehairedlawyer
Details
Patch to allow extensions to specify a function that is executed during preSaveTransform (4.62 KB, patch)
2012-01-05 01:11 UTC, Nikola Kovacs
Details
Some parser tests (12.51 KB, text/plain)
2012-04-22 20:18 UTC, bluehairedlawyer
Details
Allow extensions to specify tag contents can be passed through preSaveTransform without being escaped (3.26 KB, patch)
2012-04-22 20:29 UTC, bluehairedlawyer
Details

Description David Benbennick 2005-07-04 21:53:44 UTC
See [[User:Dbenbenn/sandbox#Gallery_pipe_trick]], for example.  A 
link in the caption of a gallery image ending in |]] is broken.
Comment 1 brianna.laugher 2006-04-25 09:10:47 UTC
Can't be too hard to fix... can it? :)
Comment 2 Rob Church 2006-06-06 17:11:41 UTC
*** Bug 6222 has been marked as a duplicate of this bug. ***
Comment 3 goldom 2006-06-06 17:47:24 UTC
sorry bout 6222, I did a search for <gallery> first but that wasn't in this
one's name.
Comment 4 Brion Vibber 2006-06-06 19:39:19 UTC
*** Bug 6157 has been marked as a duplicate of this bug. ***
Comment 5 Magnus Manske 2006-06-13 10:11:39 UTC
Fixed in SVN.
Comment 6 brianna.laugher 2006-06-13 12:21:44 UTC
So... when should this take effect? (
http://en.wikibooks.org/wiki/User:Pfctdayelise has a gallery with these pipes)
Comment 7 Rob Church 2006-06-13 12:40:36 UTC
When it's been reviewed and upon the next synchronisation, like all other fixes
and additions.
Comment 8 Brion Vibber 2006-06-13 18:13:14 UTC
Patch is bogus, does not fix reported cases.
Comment 9 baumanns 2006-07-13 10:04:32 UTC
It seems to work for me. Doesn't it?
Greetings
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-03 02:26:27 UTC
*** Bug 8125 has been marked as a duplicate of this bug. ***
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-03 02:26:48 UTC
*** Bug 6814 has been marked as a duplicate of this bug. ***
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-02-09 17:01:29 UTC
*** Bug 8929 has been marked as a duplicate of this bug. ***
Comment 13 Brion Vibber 2007-08-14 20:53:12 UTC
*** Bug 10927 has been marked as a duplicate of this bug. ***
Comment 14 Brion Vibber 2007-12-05 21:37:58 UTC
*** Bug 12016 has been marked as a duplicate of this bug. ***
Comment 15 Raimond Spekking 2008-02-19 17:00:13 UTC
*** Bug 13072 has been marked as a duplicate of this bug. ***
Comment 16 Brion Vibber 2008-05-05 17:58:15 UTC
*** Bug 13959 has been marked as a duplicate of this bug. ***
Comment 17 Brion Vibber 2008-05-07 02:45:02 UTC
*** Bug 14007 has been marked as a duplicate of this bug. ***
Comment 18 Nicolas Dumazet 2008-05-07 16:43:14 UTC
Seems that it is broken again :)

http://fr.wikipedia.org/w/index.php?title=Alaska&diff=prev&oldid=29263402 references is a good example of [[title (disambig)|]] not showing properly
Comment 19 Brion Vibber 2008-05-11 00:34:05 UTC
*** Bug 13120 has been marked as a duplicate of this bug. ***
Comment 20 Adam Cuerden 2008-05-12 00:57:17 UTC
So, with all the closing down of other bugs as duplicates of this... when is someone going to make an attempt to fix it? 
Comment 21 Brion Vibber 2008-07-05 00:07:50 UTC
*** Bug 14550 has been marked as a duplicate of this bug. ***
Comment 22 Lejonel 2008-09-10 12:25:52 UTC
*** Bug 15547 has been marked as a duplicate of this bug. ***
Comment 23 Majid Abder Rahman 2008-09-10 12:49:38 UTC
Still not working subst within reference (e.g.: http://it.wikipedia.org/w/index.php?title=Hardcore_punk&diff=18368819&oldid=18364416 )
Comment 24 bdk 2008-10-30 20:15:26 UTC
*** Bug 16183 has been marked as a duplicate of this bug. ***
Comment 25 bdk 2008-10-30 20:20:37 UTC
*** Bug 15467 has been marked as a duplicate of this bug. ***
Comment 26 bdk 2009-01-06 21:42:38 UTC
*** Bug 16904 has been marked as a duplicate of this bug. ***
Comment 27 bluehairedlawyer 2009-02-28 20:17:51 UTC
This one's been around for quite a while...

The problem here is that MediaWiki treats all extension tags as if they don't contain wikitext, so extensions that do contain wikitext, such as Cite, have to call the parser themselves. And in so doing miss out on the pre-save transformations.

Ideally we should be able to set extension hooks so that their wikitext output gets parser along with everything else.
Comment 28 Splarka 2009-03-20 02:14:23 UTC
*** Bug 18064 has been marked as a duplicate of this bug. ***
Comment 29 Umherirrender 2009-03-20 17:41:10 UTC
#tag allows you to use that trick in refs and other tags

see [[mw:Help:Magic words#Miscellaneous]]
Comment 30 Rich Farmbrough 2009-03-22 09:27:40 UTC
I have moved the severity up to normal.  This bug causes problems with using apparently standard wiki-syntax in certain places where it could be expected to be usable.  As such it requires special case handling or adoption of sub-optimal approaches to certain tasks.  I would have thought that extensions could be flagged as requiring or  not requiring pre-save processing.
Comment 31 bluehairedlawyer 2009-03-22 20:13:14 UTC
Created attachment 5952 [details]
a patch to allow extensions to output wikitext

This patch allows extensions to specify that they contain and output wikitext. The result being that such extensions don't have to invoke the parser themselves and the pre-save transformation work as they should do.

Unfortunately this doesn't work for either gallery or imagemap tags as they don't contain pure wikitext.
Comment 32 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-05-17 23:50:34 UTC
*** Bug 18825 has been marked as a duplicate of this bug. ***
Comment 33 CBM 2009-05-18 00:13:04 UTC
Note that the syntax {{#tag:ref|{{subst:today}}}} works as expected.
Comment 34 Alexandre Emsenhuber [IAlex] 2009-08-22 22:12:23 UTC
*** Bug 20359 has been marked as a duplicate of this bug. ***
Comment 35 bluehairedlawyer 2009-08-24 13:13:19 UTC
CBM +  Umherirrender:

The whole point here is that we're trying to keep it as simple as possible. There's no point trying to tell people about #ref when a fair number of people over at enwiki can't figure out relative links. The best thing to do is to make work what most editors think should work. This bug is now 4 years old and has 19 deplicates. That should tell you enough.
Comment 36 Jesús Martínez Novo (Ciencia Al Poder) 2010-01-04 19:54:22 UTC
*** Bug 13141 has been marked as a duplicate of this bug. ***
Comment 37 Alex Z. 2010-01-25 06:48:05 UTC
*** Bug 22258 has been marked as a duplicate of this bug. ***
Comment 38 Conrad Irwin 2010-02-06 15:07:20 UTC
The pipe-trick part of this is now resolved. subst: can be fixed by using safesubst: instead, so it's just signatures left.
Comment 39 Solitarius 2010-03-17 05:50:30 UTC
For information only, this bug and the use of {{subst:...}} inside a <ref> is mentioned in [[fr:Wikipédia:Guilde_des_Guides/semaine_11_2010]].
Comment 40 Mormegil 2010-05-29 09:14:55 UTC
Just a note: Conrad’s changes mentioned in comment 38 had been reverted in r62689.
Comment 41 Rich Farmbrough 2010-06-19 19:40:29 UTC
" subst: can be fixed by using safesubst: "

So we tell all editors everywhere to use safesubst: instead of subst: ? Or what?  I don't see this as a fix, more a work-around - but then I haven't experimented with safesubst: so perhaps I'm missing the point.
Comment 42 Alexandre Emsenhuber [IAlex] 2010-06-28 14:50:25 UTC
*** Bug 24131 has been marked as a duplicate of this bug. ***
Comment 43 Alexandre Emsenhuber [IAlex] 2010-06-28 17:34:00 UTC
*** Bug 24160 has been marked as a duplicate of this bug. ***
Comment 44 [no longer active user] 2010-06-28 23:14:57 UTC
no, safesubst can not
testcase:
<ref>{{safesubst:formatnum:12321123}}</ref><references/>
Comment 45 Roan Kattouw 2010-07-19 19:44:07 UTC
*** Bug 24446 has been marked as a duplicate of this bug. ***
Comment 46 Krinkle 2010-07-19 19:50:05 UTC
If the bug is not present when using {{#ref instead of <ref> then I asume the bug isn't as big as we might think ? They should both render the same, right ?
Comment 47 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-07-19 19:54:15 UTC
They'll render the same if passed the same input.  <ref> is passed input without the PST being run, {{#tag:ref}} is passed the input after the PST is run on it.  Something like that.  I'm pretty sure some people know exactly what the bug is and have some idea how to fix it, but I'm not one of them.
Comment 48 Roan Kattouw 2010-07-19 19:58:31 UTC
(In reply to comment #47)
> They'll render the same if passed the same input.  <ref> is passed input
> without the PST being run, {{#tag:ref}} is passed the input after the PST is
> run on it.  Something like that.
That's exactly right: PST runs on {{stuff in braces}} but not on <tags>.

> I'm pretty sure some people know exactly what
> the bug is and have some idea how to fix it, but I'm not one of them.

What I think happens is <tags> get armored before PST; <nowiki> needs this treatment, but for other tags it causes this bug.
Comment 49 db [inactive,noenotif] 2011-01-22 11:21:25 UTC
*** Bug 26859 has been marked as a duplicate of this bug. ***
Comment 50 Platonides 2011-02-16 23:44:28 UTC
The simple way to fix the original problem is to accept the pipe trick natively. So even if they are not done in the PST, they render as if they were. And just ignore things like signatures/subst inside references.

The other option is to start using a transparent hook.
Comment 51 Happy-melon 2011-04-24 10:12:08 UTC
*** Bug 28680 has been marked as a duplicate of this bug. ***
Comment 52 Huji 2011-05-09 23:58:13 UTC
(In reply to comment #50)
> The simple way to fix the original problem is to accept the pipe trick
> natively. So even if they are not done in the PST, they render as if they were.
> And just ignore things like signatures/subst inside references.
> 
> The other option is to start using a transparent hook.

I think having subst inside <ref> is something desirable and substs shouldn't be ignored inside references. Templates like {{cite web}} and others used on Wikipedia are an example; if we could {{subst:DATE}} in them, we didn't have to type in the current date in them.
Comment 53 Platonides 2011-05-11 15:36:02 UTC
You can use things like {{subst:DATE}}. But then the {{cite web}} template itself where you include it needs to be substed as well.
Comment 54 Svick 2011-05-11 18:44:59 UTC
(In reply to comment #53)
> You can use things like {{subst:DATE}}. But then the {{cite web}} template
> itself where you include it needs to be substed as well.

You mean something like <ref>{{subst:cite web | … | accessdate = {{subst:DATE}} }}</ref>? That doesn't work.
Comment 55 Platonides 2011-05-11 21:00:21 UTC
Try using {{#tag:ref|{{subst:cite web | … | accessdate = {{subst:DATE}} }} }}
Comment 56 Rich Farmbrough 2011-07-17 07:17:38 UTC
That's great, but subst'ing {{Cite web}} (etc.)  would be a disaster.  Simply for "Subst:" this is a basic problem which people have had to code round in Javascript and bot code.  Leaving this bug unassigned means increasing amounts of resource are used to code for these special cases (which, of course rely on the underlying templates (where appropriate) not changing) as more tools are developed to work on Wikitext. 

For example SmackBot (now Helpful Pixe Bot) used to use "Subst:CURRENTMONTHNAME" to date tags. Mainly because of this bug I had to write code to regenerate the XML for AWB to use the explicit monthname, a side effect being that all changes to the XML had to be back-ported to the component model.  Moreover if I didn't regenerate the XML the wrong month was used.

Now AWB is no longer used for this I use the current system ides of the GMT month, which is pretty good, but still creates an unneeded dependency on my system clock.

Similarly there are probably workarounds for the other extensions which are not processed but the idea of having a mark-up language that works one way on parts of the page and another on other parts, except through design, is a real bad one.

Although it doesn't currently cause _me_ problems -

I'd like to see this prioritized.
Comment 57 Mark A. Hershberger 2011-07-18 15:52:41 UTC
*** Bug 29775 has been marked as a duplicate of this bug. ***
Comment 58 Lejonel 2011-07-30 20:28:45 UTC
*** Bug 30135 has been marked as a duplicate of this bug. ***
Comment 59 billinghurst 2011-08-08 04:32:12 UTC
Can I give another example of what I think is the same issue, the inability to perform the pipe trick within {{#ref:}}

Example that does not work (at enWS)

{{subst:#tag:ref|[[Author:Charles Darwin|]]}}

should expand to give <ref>[[Author:Charles Darwin|Charles Darwin]]</ref> though it just replicates <ref>[[Author:Charles Darwin|]]</ref>. I am not seeing other issues, though I am willing to undertake trials if there are tests that are desire.
Comment 60 Gadget850 2011-08-08 04:45:58 UTC
(In reply to comment #59)
> Can I give another example of what I think is the same issue, the inability to
> perform the pipe trick within {{#ref:}}
> 
> Example that does not work (at enWS)
> 
> {{subst:#tag:ref|[[Author:Charles Darwin|]]}}

That will never work— subst only applies to templates and #tag is a magic word. What you are trying is equivalent to <subst:ref> which will not work.
Comment 61 billinghurst 2011-08-08 06:53:16 UTC
What will never work?  The subst: expansion of the tag?  Seems to work perfectly for me and has been for a while.

My issue is that the piping trick[1] stops working when it is inside either the <ref> or {{#tag:ref|...}}

[1] http://en.wikipedia.org/wiki/Help:Pipe_trick
Comment 62 Helder 2011-12-19 17:32:35 UTC
I just noticed that subst isn't working inside of <ref> tags:
https://pt.wikipedia.org/w/index.php?diff=prev&oldid=28035465

I believe this is the same bug.
Comment 63 Nemo 2011-12-28 13:58:09 UTC
Pipe trick doesn't work with Translate extension popups, I guess it's this bug again. https://translatewiki.net/w/i.php?title=MediaWiki:Bw-desc-freecol/it&diff=prev&oldid=3550365
Comment 64 Umherirrender 2012-01-04 18:54:56 UTC
(In reply to comment #63)
> Pipe trick doesn't work with Translate extension popups, I guess it's this bug
> again.
> https://translatewiki.net/w/i.php?title=MediaWiki:Bw-desc-freecol/it&diff=prev&oldid=3550365

That does not sounds like this, because it is not wrapping within a extension tag. Edit over GUI works for that title, this sounds like a problem with the edit api. You should fill a new bug for that.
Comment 65 Nikola Kovacs 2012-01-05 01:11:24 UTC
Created attachment 9806 [details]
Patch to allow extensions to specify a function that is executed during preSaveTransform

This patch introduces a mechanism similar to the tag hooks, the only difference is that the callback function gets called when the output type is set to OT_WIKI (which normally means during preSaveTransform), and that the enclosing tags with the parameters are not removed.

An extension can register a callback and then do pre-save transformation on its content - this is the best solution in my opinion, since only the extension knows which parts of the content are supposed to be transformed, e.g. in the case of the gallery tag only the description part.

This is a work in progress/proof of concept, in particular the galleryPST function calls parser->preSaveTransform, which might cause problems if it breaks the parser state. This will probably need something re-entrant like recursiveTagParse.

All parser tests passed.
Comment 66 Mark A. Hershberger 2012-02-10 18:53:09 UTC
Thanks for this patch!  We've been in a code slush (http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057313.html) for a
few weeks so we're just getting around to looking at these.

We're also doing a lot of parser work, so I'm not sure how relevant this is,
but I'll ask them to take a look, but I'll still get someone to look.
Comment 67 Gabriel Wicke 2012-02-28 20:43:35 UTC
(In reply to comment #65)

> An extension can register a callback and then do pre-save transformation on its
> content - this is the best solution in my opinion, since only the extension
> knows which parts of the content are supposed to be transformed, e.g. in the
> case of the gallery tag only the description part.

I am not too enthusiastic about encouraging extensions to do their own arbitrary pre-save transform processing. In the longer run, general support for extensions working with parsed (and pre-save transformed) wikitext / HTML DOM input could be cleaner and should offer better opportunities for integration with a visual editor. I am working on something like that in the Parsoid parser (http://mediawiki.org/wiki/Parsoid). There is also a simple and undocumented method for something vaguely like this in the PHP parser (the setTransparentTagHook method).

However, I do not have a good solution for partly-parsed and -transformed extensions like gallery. Will give this some thought, and ask others about their ideas.
Comment 68 Krinkle 2012-03-07 07:36:31 UTC
*** Bug 34999 has been marked as a duplicate of this bug. ***
Comment 69 Mark A. Hershberger 2012-03-09 04:35:46 UTC
(In reply to comment #67)
> I am not too enthusiastic about encouraging extensions to do their own
> arbitrary pre-save transform processing.

lowering priority
Comment 70 billinghurst 2012-03-09 10:41:56 UTC
(In reply to comment #69)
> (In reply to comment #67)
> > I am not too enthusiastic about encouraging extensions to do their own
> > arbitrary pre-save transform processing.
> 
> lowering priority

I am not sure how to equate the "lowering the priority" for a significant issue that doesn't follow normal wiki behaviour?  We get numerous responses akin to "I don't like it" however no solutions.

Cite must be one of the most commonly used extensions in wikipedia space, and one would think that it is used multiple times per page.  We have a fairly common practice with the renowned pipe trick, and now at comment #69, you are saying that we are "lowering the priority".  How about we consider the basic users and solve some of the base underlying issues that bug users every day, or isn't that sexy enough to gather attention?  For some of us this is a large annoyance, where we have to create work arounds, by scripting buttons, or doing significant copy and paste.
Comment 71 Gabriel Wicke 2012-03-09 12:13:05 UTC
@billinghurst: Cite can be covered by something like bluehairedlawyer's patch (attachment 5952 [details] / comment 31), as its entire content is parsed as wikitext.
Comment 72 Michael M. 2012-04-14 08:47:22 UTC
*** Bug 35954 has been marked as a duplicate of this bug. ***
Comment 73 DavidL 2012-04-14 13:54:31 UTC
More than 6 years after this bug as been reported, the bug is still there !
How many time should we wait for correction ?
Priority must not be Low !
Comment 74 DavidL 2012-04-14 13:55:51 UTC
Priority = High because blocking another High priority bug.
Comment 75 Nikola Kovacs 2012-04-20 07:59:01 UTC
(In reply to comment #67)
> (In reply to comment #65)
> 
> > An extension can register a callback and then do pre-save transformation on its
> > content - this is the best solution in my opinion, since only the extension
> > knows which parts of the content are supposed to be transformed, e.g. in the
> > case of the gallery tag only the description part.
> 
> I am not too enthusiastic about encouraging extensions to do their own
> arbitrary pre-save transform processing. In the longer run, general support for
> extensions working with parsed (and pre-save transformed) wikitext / HTML DOM
> input could be cleaner and should offer better opportunities for integration
> with a visual editor. I am working on something like that in the Parsoid parser
> (http://mediawiki.org/wiki/Parsoid). There is also a simple and undocumented
> method for something vaguely like this in the PHP parser (the
> setTransparentTagHook method).
> 
> However, I do not have a good solution for partly-parsed and -transformed
> extensions like gallery. Will give this some thought, and ask others about
> their ideas.

If the problem is that extensions could do arbitrary processing instead of the standard PST, then the only solution I can think of is to allow extension to somehow specify which part of their input should be transformed, and then let the parser do the processing. Implementing that would probably be much harder and more cumbersome.

The only thing that needs to be done on my patch is that I'm not sure the extension calling parser->preSaveTransform is 100% safe. I can give it a go if you want, but I don't want to waste my time if the patch will be rejected because my approach (letting the extension do the PST) is not the correct one.

New parsers are nice and all, but they do not fix the problem that we have right now, and they probably never will if you want to keep the current gallery syntax.
Comment 76 bluehairedlawyer 2012-04-21 22:05:14 UTC
Actually David's wrong. This bug is seven not six years old. If its not fixed soon we'll have to figure out who's going to pay for it to go to college...

What would be wrong with running the all the contents of a <gallery> through preSaveTransform? I realise it's not wikitext but then preSaveTransform isn't the full parser? What particular pre-save transforms would corrupt the gallery syntax?
Comment 77 Nikola Kovacs 2012-04-21 22:19:53 UTC
(In reply to comment #76)
> Actually David's wrong. This bug is seven not six years old. If its not fixed
> soon we'll have to figure out who's going to pay for it to go to college...
> 
> What would be wrong with running the all the contents of a <gallery> through
> preSaveTransform? I realise it's not wikitext but then preSaveTransform isn't
> the full parser? What particular pre-save transforms would corrupt the gallery
> syntax?

I don't know off the top of my head what characters are allowed in filenames (in particular, is [, { or ~ allowed), but in theory:

<gallery>
File:Oh noez [[This is not a link.png|]] yeah, I know, this is a contrived example
</gallery>

There's also replacing tildes, substing and the reverse pipe trick. Replacing tildes would be the most realistic problem (if ~ is allowed in filenames)
Comment 78 Bawolff (Brian Wolff) 2012-04-22 01:14:23 UTC
[ { are both disallowed in any page name (which includes images). Three or more ~'s in a row is also forbidden in page titles. So you don't have to worry about that.


Personally I favour an approach of adding an interface for adding parserHooks that allows specifying options (such as if the parser hook should allow PST).


>Actually David's wrong. This bug is seven not six years old. If its not fixed
>soon we'll have to figure out who's going to pay for it to go to college...

That's still a good 11 years away. We're cross that bridge when we come to it.
Comment 79 bluehairedlawyer 2012-04-22 20:18:31 UTC
Created attachment 10450 [details]
Some parser tests
Comment 80 bluehairedlawyer 2012-04-22 20:29:28 UTC
Created attachment 10451 [details]
Allow extensions to specify tag contents can be passed through preSaveTransform without being escaped

This is an alternative to Nikola's patch. It allows extensions and internal setHook functions to specify that there contents can be run through the preSaveTransform function without being escaped.

It passes all the current parser tests and a few others I've managed to throw at it.
Comment 81 Sumana Harihareswara 2012-05-25 02:46:34 UTC
bluehairedlawyer, could you put this patch in Gerrit?
Comment 82 bluehairedlawyer 2012-06-07 09:06:13 UTC
Dan Collins has already done this (which is just as well as I haven't figured out how to do it yet). Here's the url:

https://gerrit.wikimedia.org/r/#/c/8784/
Comment 83 Platonides 2012-06-08 15:31:54 UTC
That was a smart way to solve it.

Commented some concerns on gerrit.
Comment 84 matanya 2012-08-14 10:52:59 UTC
patch moved to gerrit, removing patch need review.
Comment 85 Ori Livneh 2012-09-16 20:53:31 UTC
Dan Collins has two patches, not one:
https://gerrit.wikimedia.org/r/#/c/8784/ (previously mentioned)
and 
https://gerrit.wikimedia.org/r/#/c/8785/
Comment 86 Bartosz Dziewoński 2012-11-13 19:45:32 UTC
*** Bug 42078 has been marked as a duplicate of this bug. ***
Comment 87 Bartosz Dziewoński 2012-11-13 19:48:13 UTC
Somebdy should really give those patches some love, as apparently the original committer has disappeared.
Comment 88 Andre Klapper 2013-07-23 09:03:52 UTC
Gabriel: As you assigned this report to yourself a year ago, do you plean to rework the two patches?
Comment 89 Andre Klapper 2014-03-11 14:40:38 UTC
Gabriel: As you assigned this report to yourself two years ago, do you plan to rework the two patches? Or are they "somehow" obsoleted in the meantime?
Comment 90 Gerrit Notification Bot 2014-04-05 18:44:51 UTC
Change 8784 abandoned by Siebrand:
(Bug 2700) Pre-save transform inside extension hooks

Reason:
I'm abandoning this patch set as it's been open for a long time without any outlook at the open issues being resolved. 

If the submitter or anyone else would like to work on it again, this patch set can be re-activated by clicking "Restore Change". Please only do this if you are actually going to work on it immediately.

https://gerrit.wikimedia.org/r/8784
Comment 91 Umherirrender 2014-10-15 14:42:14 UTC
*** Bug 72079 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links