Page MenuHomePhabricator

preload parser should parse <noinclude> (as well as <includeonly>)
Closed, ResolvedPublic

Description

Author: sherman.boyd

Description:
When using the inputbox.php extension to create with preload the script should
parse <noinclude> and <includeonly>. For example if the template includes:

<noinclude>[[Category:Scategory]]</noinclude>

Then the expected behavior is that the new page would not include the above line.

If the template contains:

<includeonly>[[Category:Scategory]]</includeonly>

In that case I would expect that [[Category:Scategory]] would be included in the
new page, sans the <includeonly> tags.

The problem that I am encountering is that I want to use inputbox to create
templates for users that have categories built in. However I can't have these
templates showing up in the categories.

About <noinclude> <includeonly>:
http://mail.wikipedia.org/pipermail/wikitech-l/2005-August/031123.html

I'm using inputbox 1.19 as I had problems with 1.20. See:
http://meta.wikimedia.org/wiki/Help_talk:Inputbox#error_message

Anyway thanks for your help! If there is anything I can do please let me know.


Version: 1.14.x
Severity: normal
URL: http://meta.wikimedia.org/wiki/Inputbox

Details

Reference
bz5210

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:07 PM
bzimport set Reference to bz5210.

Mason11987 wrote:

I am having a similar problem with this, the includeonly works find, but
noinclude does not work. I mentioned it here:

http://meta.wikimedia.org/wiki/Help_talk:Inputbox#noinclude_and_includeonly

I have also encountered this issue on Wikipedia; the templates substituted by this function cannot contain any content other than that to be substituted, meaning that the templates can neither be categorized or documented without that categorization/documentation being included on the substituted page.

For an example, see http://en.wikipedia.org/w/index.php?action=edit&preload=Template%3AInfobox%20Planet&editintro=&title=Wikipedia%3AAbuse+reports%2F10.0.0.1&create=Report+IP - any text between <noinclude>...</noinclude> should not have appeared there.

webmaster wrote:

Today, I installed the latest version (as of Oct 10, 2007) of this extension and MediaWiki 1.11.0 and I am experiencing this issue as well.

Everything in the page to be preloaded is included, regardless if you use either <noinclude> or <includeonly>.

Oddly enough, on one of my other wikis does NOT experience this issue:

http://en.marveldatabase.com/index.php?title=Foo&action=edit&section=&preload=Template:Character%20Template

pulls from:

http://en.marveldatabase.com/index.php?title=Template:Character%20Template&action=edit

where I have lots of other crap between <noinclude> tags...

The working wiki uses older versions of both the extension and MediaWiki (1.10alpha). It is possible that Wikia has hacked up a solution to this problem... I have emailed them to investigate and post their findings here.

  • Bug 13932 has been marked as a duplicate of this bug. ***

herd wrote:

Preload is not actually part of the inputbox extension, change should be made in core. small mod to summary.

herd wrote:

(In reply to comment #3)

It is possible that Wikia has hacked up a solution to this
problem... I have emailed them to investigate and post their findings here.

Yep, they do, Datrio modified it at my request. Here are the relevant lines:

$text = preg_replace( '~</?includeonly>~', '', $text );
// Remove <noinclude> - Datrio
$text = preg_replace( '/<noinclude>.*<\/noinclude>/', '', $text );
return $text;

But this maybe should be done via the actual parser. Possibly the includeonly/noinclude/onlyinclude tags should be stripped/parsed in a function that both preload and the wiki parser can call on?

daniel.brice wrote:

When fixing this bug, please ensure that we can still in some way still actually add <noinclude> and <includeonly> tags to the new page.

One such way around it maybe allowing this form where if the tag is interrupted it does not get parsed (however quite ugly):

<<includeonly></includeonly>includeonly>This text will be placed on the new page and will be surrounded by includeonly tags</<includeonly></includeonly>includeonly>

<<includeonly></includeonly>noinclude>This text will be placed on the new page and will be surrounded by noinclude tags</<includeonly></includeonly>noinclude>

Another suggestion is to add another preload tag that overrides any includeonly/noinclude:

<noinclude>This text will not be in the new page</noinclude><preload><includeonly>This text will be placed on the new page and will be surrounded by includeonly tags</includeonly></preload>

<noinclude>This text will not be in the new page</noinclude><preload><noinclude>This text will be placed on the new page and will be surrounded by noinclude tags</noinclude></preload>

*** Bug 16733 has been marked as a duplicate of this bug. ***

Since this is not really an Inputbox issue, I'm changing component to 'Page editing'.

  • Bug 17723 has been marked as a duplicate of this bug. ***
  • Bug 21472 has been marked as a duplicate of this bug. ***

Splarka already told a way to fix this bug 1 and 1/2 years ago (in Comment #6) so where is the problem, why not fixing it? This one goes on my nerves.
Or are you afraight this could lead to some unexpected issues in some wikis because of wanted <noincludes> which should appear after loading? If that's the case we should add a config variable to set the preload behavior.
But still: There should be no guarantee that bugusing will work in future MW versions. And since <includeonly> works perfectly with preload I can't see nothing but a bug here!

conrad.irwin wrote:

Fixed in r62035

conrad.irwin wrote:

Re-fixed in r63194