marking highest because this seems like a regression that could affect a lot of users.

IIRC the sidebar is heavily cached; as far as I know something like this would never have worked (or should never have worked!)

Are you sure you didn't have some sort of custom patch or extension replacing the sidebar management?

I was using in a wiki here: http://biocore.crg.cat/w/index.php?title=MediaWiki:Sidebar&action=edit (extensions: UserFunctions and PipeEscape)

I was checking this in MW 1.18:

• navigation

{{#ifeq:2|2|{{#!:

• User:WikiSysop|My Sysop page

}}|{{#!:

• User:None|No user

}}}}

• • mainpage|mainpage-description
  • portal-url|portal
  • currentevents-url|currentevents
  • recentchanges-url|recentchanges
  • randompage-url|randompage
  • helppage|help
• SEARCH
• TOOLBOX
• LANGUAGES

MediaWiki:Sidebar contents behave correctly, but in sidebar both links are presented...

This is something that definitely works in 1.17 and does not in 1.18. Except for the new version of MW nothing has changed in my environment. No sidebar caching is in use and I am not capable of doing custom hacks. I guess it is a true regression.

Note, sidebar caching appears to be off by default (see [[mw:Manual:$wgEnableSidebarCache]]).

However, Parser functions seem to work correctly on 1.19.

The exception mentioned in comment 0 seems to more have to do with the lack of a | to denote what the title of the link was, rather then the parser function itself. (The fact that can cause an exception is rather scary...). On 1.19 this doesn't cause an exception, but totally screws things up in a different way (makes all the title text empty).

In regards to comment 3. I think using parser functions to control the leading ** might not work, which is an issue independent of parser funcs working whatsoever in the sidebar.

The exception issue taken care of in r108145.

Ok, so the remaining issue here is constructions like

{{#if:Yes|**foo{{!}}bar}}

or

{{#ifeq:1|2|
**foo{{!}}bar
}}

Don't work as expected, since the sidebar is parsed on a line by line basis.

However, since

**{{#if:true|page{{!}}title|}}

Would work as expected (an empty leading ** is totally ignored).
(Combined with the fact that parser funcs in sidebar is already evil), I am inclined to wontfix the rest of this bug.

Is there any objections, or any use cases that cannot be done by using parser funcs that span only 1 line and have the ** outside the parser func?

(In reply to comment #7)

Ok, so the remaining issue here is constructions like

{{#if:Yes|**foo{{!}}bar}}

or

{{#ifeq:1|2|
**foo{{!}}bar
}}

Don't work as expected, since the sidebar is parsed on a line by line basis.

However, since

**{{#if:true|page{{!}}title|}}

Would work as expected (an empty leading ** is totally ignored).
(Combined with the fact that parser funcs in sidebar is already evil), I am
inclined to wontfix the rest of this bug.

Is there any objections, or any use cases that cannot be done by using parser
funcs that span only 1 line and have the ** outside the parser func?

Maybe it's not so convenient as before (for many lines), but better than nothing, as it's now. Fine for me. I would try to document this in Manual:Interface/Sidebar once it's fixed.

I would try to document this in Manual:Interface/Sidebar once it's fixed

documented.

(In reply to comment #9)

I would try to document this in Manual:Interface/Sidebar once it's fixed

documented.

Awesome. Thanks Bawolff!

I guess it is a matter of compromise and I am very happy that a fix was made which is usable. Thank you Bawolff for your work on it.

(In reply to comment #11)

I guess it is a matter of compromise and I am very happy that a fix was made
which is usable. Thank you Bawolff for your work on it.

Note, I didn't make that particular fix, that's the way mediawiki:Sidebar worked when I found this bug.

Marking WORKSFORME, since everyone seems mostly happy with the current situation.

redekopmark wrote:

Just my opinion, but this should probably be released as 1.18.1 i tried useing parser functions on my wiki with 1.18 and didn't get any warning or revert the whole wiki just went down. Thankfully I found this bug report and manually applied the fix.