Can't detect empty field

[totoff]

Hi all,

I have a field "sidebar" which is a simple textarea with Markdown Extra and Image Tags applied. If I perform the usual check for an empty field

<?php if($page->sidebar): ?>
<div class="sidebarItem"><?php echo "$page->sidebar"; ?></div>
<?php endif; ?>

It echoes div.sidebarItem even if the sidebar field has no content.

Any thoughts? Thanks.

[SiNNuT]

I just copied and pasted your code into a test template on a page with a sidebar field of type textarea, and it works as expected. If the field is empty nothing is being output.

Are you sure that there is not some stray whitespace or another invisible character in your sidebar field? Maybe check html view, or even in database.

I don't have experience with the modules you mention but i don't think they would be causing this.

[SiNNuT]

Another thing: have you tried disabling the TextFormatters one by one to check if one of them is actually causing problems?

[totoff]

Hi and thank you SiNNut,

I have tracked this down: It is definitely caused by the markdown text formatter. Made a textarea field "debug" and tried it once with and once without markdown enabled. Worked as it should without but not with markdown enabled.

The installation in question is 2.4. I'm going to double-check with a 2.5 and if it is the same will file a bug.

[adrian]

Out of curiosity - does 

if($page->sidebar != '')

work with the Markdown formatter enabled?

What do you get if you:

echo '"'.$page->sidebar.'"';

Is there anything ouput between the double quotes when the field is empty?

[totoff]

Tested on 2.5. Same as before.

@adrian

Case 1:

if($page->sidebar != '')

Same as before.

Case 2:

echo '"'.$page->sidebar.'"';

outputs the double quotes and nothing else if field is empty.

Should I file a bug? What do you think?

[SiNNuT]

On a sidenote

I just noticed that the Markdown Extra textformatter uses a quite old Markdown parser. I'm not sure if this module is used a lot but maybe it would be beneficial to update to a more modern, actively developed Markdown parser like http://parsedown.org/ , which also has a Markdown Extra extension.

It seems to be fast as well: http://kzykhys.com/blog/benchmarked-markdown-parsers-written-in-php/

[Soma]

I used if(trim(page->field)) while waiting to get fixed. But it must be 1 or 2 years since then and was reported I thought or known.

[Martijn Geerts]

There are more instances where saved empty fields still contain tabs.

Sorry that I don't remember what fields and in which context.

[totoff]

I used if(trim(page->field)) while waiting to get fixed.

That doesn't work for me unfortunately. There ain't no whitespace in my code. :-(

[netcarver]

What do you get if you do this...

echo "<pre>Len: ", strlen($page->sidebar), "</pre>"; 

...?

[totoff]

What do you get if you do this...

<div class="sidebarItem"><pre>Len: 1</pre></div>

EDIT: So, that means, there is a string in it, does it? Weird.

[netcarver]

And what about...

echo "<pre>Len: ", strlen(trim($page->sidebar)), "</pre>"; 

If it's still len: 1 then there are some chars in there that the trim function isn't removing. It that's the case I'd do this...

$ord = ord($page->sidebar);
echo "Ord: $ord";

[totoff]

And what about...

Len: 0

:-(

Edit: I tried this without(!) the trim function. Wasn't that right?

[netcarver]

So doesn't this solve your problem...

<?php if (strlen(trim($page->sidebar)) > 0): ?>
<div class="sidebarItem"><?php echo "$page->sidebar"; ?></div>
<?php endif; ?>

...?

[totoff]

So doesn't this solve your problem...

Wow, works! Thank you so much!

As I'm not a PHP pro but would like to learn more: The if() still relates to $page->sidebar (true/not true) while the strlen counts the string and trim removes whitespace. Is that right?

Thanks for your help again.

[netcarver]

Wow, works! Thank you so much!

Good to hear!

...The if() still relates to $page->sidebar (true/not true) while the strlen counts the string and trim removes whitespace. Is that right?

Not really. The if, as a whole, applies to whatever is in the brackets following it. Yes, $page->sidebar is in the mix, but not as a true/false evaluation any more. So, you've got this bit;

if (some-boolean-expression) {
    // If the expression evaluates as true do this stuff...
    echo "True!";
}

Now you have to peel the if "onion", from the outside in, to find what's happening...

if (strlen(X) > 0) :  // Checks if the string length of X is greater than 0. This is the true/false decision.

// Now let's peel another level and look at what X is...

trim(Y) // X is the trimmed version of Y

// And Y is?

$page->sidebar

Putting it together again, from the inside out, the if statement says...

 

1) Read the contents of the $page->sidebar field. (Even when this string field is empty in PW's admin page it's coming to us with length 1 after the textformatter - probably the TF adding whitespace)

2) Trim it - The trim function trims leading and trailing whitespace (amongst other things) - so now we have an empty string.

3) Measure how long the trimmed version is (Now it's 0)

4) If that length is > 0 then do this stuff (This stops us showing the empty string as the length is no longer greater than zero.

 

You might find this, simpler, if statement works for you too...

<?php if (trim($page->sidebar) != '') : ?>

...and I think that's what Soma was suggesting earlier in the thread. 

Hope that helps.

[Martijn Geerts]

@totoff, are you willing to make a bug report for this? As this behaviour is not intended behaviour. 

And to your questions: Yes

but the order is important.

Edited October 24, 2014 by Martijn Geerts
read Steve's post that's way better :-)...

[totoff]

@netcarver: thank you so much for this comprehensive tutorial. Really appreciate.

@Martijn: I did already.

[Martijn Geerts]

Big thanks !

[horst]

There are more instances where a saved empty fields still contain tabs.

Sorry that I don't remember what fields and in which context.

I remember that this is also with configurable modules, if you have a textarea in a config screen where you should add params one per line, for example, and if you simply end the last line with a "new-line char",

line one (new-line-char)
line two (new-line-char)
line three (new-line-char)

hit submit, you will get back your content with three tab characters added!

If you do nothing but only hit submit once again, you will get three more tabs added, and so on and so on.

Whereas if you let out the last "new-line-char", you will get back only the content you want, without added tabs:

line one (new-line-char)
line two (new-line-char)
line three

This is with PW 2.3, 2.4 and 2.5, you can test this simply by make the HelloWorld Module configurable:

class Helloworld2 extends WireData implements Module, ConfigurableModule {

	public static function getModuleInfo() {
		return array(
			'title' => 'Hello World 2',
			'version' => 2,
			'summary' => 'An example module used for demonstration purposes.',
			'href' => 'http://processwire.com',
			'singular' => true,
			'autoload' => true,
			'icon' => 'smile-o'
			);
	}

	public function init() {
	}

        static public function getModuleConfigInputfields(array $data) {

            $form = new InputfieldWrapper();

            $field = wire()->modules->get('InputfieldTextarea');
            $field->label = 'Textarea';
            $field->attr('name', 'textarea-value');
            $field->attr('value', $data['textarea-value']);
            $field->columnWidth = 100;

            $form->add($field);

            return $form;
        }

}

[horst]

This with the Textareas in COnfigurable Modules I have tracked down to this line: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/InputfieldWrapper.php#L300

Before this line the content of $ffout looks like:

"\n<textarea id=\"Inputfield_textarea-value\" class=\"InputfieldMaxWidth\" name=\"textarea-value\" rows=\"5\">line one\r\nline two\r\nline three\r\n</textarea>"

and after processing the preg_replace, $ffout holds

"\n\t\t\t<textarea id=\"Inputfield_textarea-value\" class=\"InputfieldMaxWidth\" name=\"textarea-value\" rows=\"5\">line one\r\nline two\r\nline three\r\n\t\t\t</textarea>"

I have filed an issue at GitHub: https://github.com/ryancramerdesign/ProcessWire/issues/759