Last modified: 2014-11-10 00:08:04 UTC
ext.wikiEditor.toolbar.hideSig.js doesn't work any more, the button for the signature is shown for articles, though I have enabled it on my test wiki. This seems to be an issue with the loading order: The module gets loaded *before* the toolbar is initialized, so it just can't remove the button.
The patch https://gerrit.wikimedia.org/r/102076 for bug 57727 would also fix this problem.
Two months already and still not "fixed"? Look, all we need to do is add... 'filters': [ 'body.ns-talk' ], ... to the 'signature' button's entry in... jquery.wikiEditor.toolbar.config.js ... and you're done. The same approach is used for the 'reference' button btw.(see that same .js file if you don't believe me) This way, all talk pages will automatically generate the 'signature' button while solving the immediate issue of how to stop its generation in the ns-0 namespace. If it was up to me, I'd at least thrown in the Project: namespace (like for Village Pump) along with all the talkspaces... 'filters': [ 'body.ns-talk, body.ns-4' ], ... The above should be the common sense "default" setting. And I suspect all the other "hide WikiEditor type of fixes" floating about would not be affected no matter what this 'filters' setting might be set to - no?
As I tried to explain to you at the other bug, your approach just introduces new problems: 1. It is inflexible and cannot be configured without modifying source code; 2. It does not cater to those wikis requiring signatures in namespaces other than the talk namespaces. While your input is appreciated, I would urge you to think carefully about this issue and the fact that more flexibility is required than you may realise.
Yes I fully understand all that. Yet we're months past the 1st report and you have usurped and/or blocked several pseudo-related buzillas in the process - making any attempt to resolve this by any other means than yours impossible to pursue. So roll-out your fix already or simply apply the one I've proposed and close all the tangent, on-point reports once and for all.
(In reply to George Orwell III from comment #4) > making any attempt to resolve this by any other means than yours > impossible to pursue. I don't mean to be obtrusive; I'm merely being practical. I don't think your suggestion has a chance of being +2'd on Gerrit, for example. (In reply to George Orwell III from comment #4) > So roll-out your fix already I wish I could. Does anyone else have an opinion? It would be good to hear what others have to say.
Your words, not mine ( https://gerrit.wikimedia.org/r/87649 ) > Most wikis only use user signatures on pages set aside from discussion, > (Talk namespaces and sometimes project/main namespaces depending on > the wiki), so having the button available everywhere is confusing. So are we in agreement or not that regardless of the wiki in question - be it Foundation based or otherwise - the signature button should (at the minimum) always be generated in the talk namespaces and (at the maximum) should also be generated in main Project namespace (NS-4) in addition to the talk namespaces as well? You go on to say in the same gerrit as linked above... > The few wikis that need the button (especially non-content, > internal/corporate/planning wikis), can add relevant namespaces to the > $wgExtraSignatureNamespaces array in LocalSettings. Which makes perfect sense to me too, but I don't understand why implementing my base filter setting intrudes or interferes with your 'wg' based solution in any way, shape or form here. Are you saying that there is some scenario, Foundation wiki or otherwise, where any or all of the talk namespaces would NOT be tasked as discussion pages but re-tasked as something else - making the signature button moot in the process? Is it also realistic to expect the Project namespace to be re-tasked in a similar manner? Personally, I don't believe either scenario is likely to ever happen. However, I do believe additional namespaces beyond these two may be added to include signature button generation and your solution could/should cover those instances just fine. So again, what exactly is the harm in adding the filter (talk namespaces only) or filters (talk namespaces plus the Project namespace) parameter & value to the WikiEditor's .js file(s)? Please answer these questions. IMHO, the ~10 month hold up on something as so straight forward as to be included in the extension to begin with & by design is a pretty sad statement all around.
(In reply to George Orwell III from comment #6) > So are we in agreement or not that regardless of the wiki in question - be > it Foundation based or otherwise - the signature button should (at the > minimum) always be generated in the talk namespaces and (at the maximum) > should also be generated in main Project namespace (NS-4) in addition to the > talk namespaces as well? No. Signatures ought to be available in ns2 (for user tests etc); and some wikis even need them in ns0 (eg Meta, pages like [[m:Tech]]). Also, they may be wanted in custom subject namespaces (e.g. WikiProject namespace on some WMF wikis). > Which makes perfect sense to me too, but I don't understand why implementing > my base filter setting intrudes or interferes with your 'wg' based solution > in any way, shape or form here. I thought you wanted only the hard-coded filter, so it seems there was a misunderstanding between us. > Are you saying that there is some scenario, Foundation wiki or otherwise, > where any or all of the talk namespaces would NOT be tasked as discussion > pages but re-tasked as something else - making the signature button moot in > the process? When you put it that way, it does seem unlikely. > Is it also realistic to expect the Project namespace to be re-tasked in a > similar manner? Very much so. Well-organised wikis won't require signatures in any subject namespace.
(In reply to This, that and the other (TTO) from comment #7) > (In reply to George Orwell III from comment #6) OK. We're not so far apart after all. Per your rationale for all subject spaces - including our traditional NS-4 "project" namespace AND with consideration towards external "well-organized" wikis in conjunction with traditional Foundation wikis - why don't we just amend the aforementioned .js file to include the line... 'filters': [ 'body.ns-talk' ], ... so that the signature button generation is limited (but not locked) to just talk namespace instances. Any Project space user will just have to "cope" until your approach becomes a reality - which I fully endorse in case that is still not clear. This could neatly satisfy this particular bug report without revisiting the defunct hidesig.js file at all -plus- any others specifically dealing with the unwanted generation of the signature WikiEditor tool-bar button in any or all of the subject namespaces (particularly the main namespace for Foundation wikis) NOW, while leaving your 'wg' based solution in place (whenever it gets rolled-out) free to include/exclude subject namespaces however administration sees fit. Once implemented, it would be one other scenario to "test & refine" against using the 'wg' approach to boot. All that said, what do you think now?
Regression - a return to a former or less developed state. bug 28149 was the report that set off the changes that first introduced the hideSig.js approach in contrast to the continued usage of the available 'filters:' setting. Here is the specific revision affecting those changes r1=86702&r2=86703">https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/WikiEditor/modules/jquery.wikiEditor.toolbar.config.js?&pathrev=86703&r1=86702&r2=86703 Hopefully that helps persuade at least a re-consideration of the possible solutions at hand; [re]utilizing the 'filters:' approach can close the existing string of related reports without hampering things for the larger concern now weaved into them.
