Page MenuHomePhabricator

for template tag does not support {{int:}} in the label
Closed, ResolvedPublic

Description

Hi Yaron!

It looks like the for template tag does not parse the argument of the label:

This will not work, no <fieldset> is created arount the multiple-instance template

{{{for template|Contact Point|{{int:SA Contact Contact Point}}|label={{int:SA Contact Contact Point}} ||multiple|minimum instances=0 }}}

If I replace the {{int label with a plain string, it works:

{{{for template|Contact Point|{{int:SA Contact Contact Point}}|label=Contact Point ||multiple|minimum instances=0 }}}

Best,
Simon

Event Timeline

Fannon assigned this task to Yaron_Koren.
Fannon raised the priority of this task from to Low.
Fannon updated the task description. (Show Details)
Fannon subscribed.

I've seen that you're refactoring this part of the code anyway. I can't get the current master state to run (it crashes), but this patch should hopefully make labels work:

patch
Index: includes/SF_TemplateInForm.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- includes/SF_TemplateInForm.php	(revision 23ac3fc921967334873a5406568eafcc8ec055e1)
+++ includes/SF_TemplateInForm.php	(revision )
@@ -360,7 +360,7 @@
 			$sub_components = array_map( 'trim', explode( '=', $component, 2 ) );
 			if ( count( $sub_components ) == 2 ) {
 				if ( $sub_components[0] == 'label' ) {
-					$tif->mLabel = $sub_components[1];
+					$tif->mLabel = $wgParser->recursiveTagParse($sub_components[1]);
 				} elseif ( $sub_components[0] == 'minimum instances' ) {
 					$tif->mMinAllowed = $sub_components[1];
 				} elseif ( $sub_components[0] == 'maximum instances' ) {

Hello Yaron!

The previous patch didn't fix the problem. It seems that $sub_components[0] is not correctly split when parser functions are used. If I only look that the string -contains- label instead of checking for equality, it works for me.

patch
diff --git a/includes/SF_TemplateInForm.php b/includes/SF_TemplateInForm.php
index 1fad687..4c1e140 100644
--- a/includes/SF_TemplateInForm.php
+++ b/includes/SF_TemplateInForm.php
@@ -359,6 +359,7 @@ class SFTemplateInForm {
 	public static function newFromFormTag( $tag_components ) {
 		global $wgParser;
 
+
 		$template_name = str_replace( '_', ' ', trim( $tag_components[1] ) );
 		$tif = SFTemplateInForm::create( $template_name );
 		$tif->mAddButtonText = wfMessage( 'sf_formedit_addanother' )->text();
@@ -371,9 +372,10 @@ class SFTemplateInForm {
 				$tif->mStrictParsing = true;
 			}
 			$sub_components = array_map( 'trim', explode( '=', $component, 2 ) );
+
 			if ( count( $sub_components ) == 2 ) {
-				if ( $sub_components[0] == 'label' ) {
-					$tif->mLabel = $sub_components[1];
+				if ( strpos($sub_components[0], 'label') !== false ) {
+					$tif->mLabel = $wgParser->recursiveTagParse( $sub_components[1] );
 				} elseif ( $sub_components[0] == 'minimum instances' ) {
 					$tif->mMinAllowed = $sub_components[1];
 				} elseif ( $sub_components[0] == 'maximum instances' ) {

The use of strpos() makes me think that there's a problem with the parsing of the parameters. Is that possible?

Yes, that was my impression, too. Something probably went wrong with the array explode

Change 451619 had a related patch set uploaded (by Thai; owner: Thai):
[mediawiki/extensions/PageForms@master] Allow {{int:}} for template name and label in {{{for template}}}

https://gerrit.wikimedia.org/r/451619

The previous patch didn't fix the problem. It seems that $sub_components[0] is not correctly split when parser functions are used.

Using your original code, the use of parser functions seems to work now. I assume, there were changes in the parsing of parameters since 2016 that fixed the problem. Please review, test, and merge. https://gerrit.wikimedia.org/r/451619

Change 451619 merged by jenkins-bot:
[mediawiki/extensions/PageForms@master] Allow {{int:}} for template name and label in {{{for template}}}

https://gerrit.wikimedia.org/r/451619

Aklapper added a subscriber: Yaron_Koren.

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see https://phabricator.wikimedia.org/T228575#6237124 for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)

Yaron_Koren claimed this task.

I assume the patch five years ago fixed this problem...