Page MenuHomePhabricator

HTML attribute value can not contain a list of values
Closed, ResolvedPublic

Description

Hello Yaron,

I'm getting this error as of SF 3.5:

HTML attribute value can not contain a list of values

This seems to be caused by a comma in template parameter:

{{Responsibilities RSCI
|Responsible=Role:Abteilungsleiterin/-leiter (AL), alle
}}

My guess is, that the error is thrown by some internal MediaWiki HTML/Wikitext validator. So the error should be where SF generates the Form Edit HTML.

I'm generally using ; as a delimiter, but those settings seem to have no effect on this problem.

On SF 3.4.1 it works fine, on SF 3.4.2 the form is rendered, but I get this error message:

Notice: Undefined variable: delimiter in /var/www/kam-bbs.wiki/wiki-hlahm/extensions/SemanticForms/includes/SF_FormPrinter.php on line 911

Event Timeline

If you change line 927 of /includes/SF_FormPrinter.php from:

$delimiter = ',';

...to:

$delimiter = '';

...does that have any effect on this error?

Yes, that solves the problem!

This diff fixes the delimiter and also fixes the radiobutton issue with value/label distinction:

index 922bb8c..dbcf574 100644
--- a/includes/SF_FormPrinter.php
+++ b/includes/SF_FormPrinter.php
@@ -815,7 +815,7 @@ END;
                                                        // the fields that weren't
                                                        // handled by the form.
                                                        $cur_value = $tif->getAndRemoveValueFromPageForField( $field_name );
-
+
                                                        // If the field is a placeholder, the contents of this template
                                                        // parameter should be treated as elements parsed by an another
                                                        // multiple template form.
@@ -924,7 +924,7 @@ END;
                                                                $form_field->hasFieldArg( 'mapping cargo field' ) ) ) ) {
                                                                // Avoid a PHP notice.
                                                                if ( !is_array( $cur_value ) ) {
-                                                                       $delimiter = ',';
+                                                                       $delimiter = ';';
                                                                }
                                                                $cur_value = SFUtils::valuesToLabels( $cur_value, $delimiter, $form_field->getPossibleValues() );
                                                        }

I didn't notice until now that you had changed the delimiter to a ";", instead of blank - is there an advantage to doing that?

I'm not sure how you handle this internally of SF, but I'm always using ; as separator, as the changes are very low that it will cause issues with page titles

Okay, thanks. I changed the variable to blank in the code; we'll see how well it works. For now, I'm setting this to "Resolved".

A workaround I used was setting delimiter to a different value in my form's field-definition.

Rcdeboer added a subscriber: Rcdeboer.

This bug seems to have reappeared in PF 4.3. I'm running Page Forms 4.3.1 and encounter this error message when a comma-separated list of values is used. I've found another report of someone downgrading to 4.2.1 to 'fix' this. (https://github.com/fuerthwiki/wiki/issues/97)

Is it still a problem in PF 4.4?

Good question. Will check that later this week.

Checked and confirmed: it is still a problem in PF4.4.

@Rcdeboer - what's the exact error message you're seeing?

Also, what does the "Responsible" field tag in the form definition look like?

The error is "HTML attribute value can not contain a list of values". As far as I know, there is no 'responsible' field tag in the form definition.

Okay - what does the form definition look like?

Sorry for the very long delay. I just checked in what I think is a fix. I believe this was only ever an issue for the "text with autocomplete" input type (as opposed to "tokens"), which might explain why I never saw this problem myself. Feel free to re-open if this hasn't actually been fixed.