Loading Profile...
Wygwam (or perhaps EE) is inserting break tags (br /) within any empty custom field I've created.
Since my project does not always require all fields to contain data, conditional programming does not work. I.e., {if custom_field != ""}...data...{/if}. So unused fields are showing simply because of a needless break tag.
Ironically, if I simply click within the blank field and then update, the break tag disappears and it works. But upon re-saving the same page without clicking inside the empty field, the break tag reappears like a stubborn mosquito.
I've tried setting up these fields afresh with a texarea field and then reverting back to Wygwam with the same result. Also, I've gone as far as checking the [exp_field_formatting ] for these fields and manually choosing 'none' for their format.
Please help! It's driving me insane! : /
Help get this topic noticed by sharing it on
Twitter,
Facebook, or email.
Twitter,
Facebook, or email.
I’m
frustrated
Wygwam Inserting Break Tags within Blank Custom Fields
-
What version of Wygwam are you using?Comment
-
-
My apologies...
EE 1.6.8
Wygwam Version 2.0.1
Used in conjunction with Fieldframe 1.4; Playa 2.1.3; nGen File Field 0.9.10; Structure 2.0.8 -
-
In addition to my unsuccessful attempts at resolving this issue, I also tried commenting-out $text = str_replace [br /] tag lines within textile.php... again, without any results.
The [exp_field_formatting] from my earlier post refers to the database table in case anyone is curious. -
-
So, where are you looking in the database? Try going back in, and check the 'field_fmt' column within exp_weblog_fields for the appropriate row, as well as the 'field_ft_XX' column for each of the affected entries' rows in exp_weblog_data.
-
-
Hi, I was browsing the "field_fmt" column in "exp_field_formatting".
I changed the field id's format from xhtml to none without any results... just a hunch.
Sure, exp_weblog_data has break tags inserted in the rows in question...
How and why, though, are break tags being inserted without any interaction in the publish page field altogether?
Thanks for the help! -
-
Confused by your response -- did you check those columns and change the values to "none"?
-
-
Yes. However, I'm finding these break tags inserted in "field_id_XX" rather than "field_ft_XX".
-
-
If field_ft_XX is set to anything besides "none", it would explain why the breaks are being added.
-
-
Brandon,
Yes, there are plenty of entries that somehow have been set to xhtml!
Is there a way to reset all fields through EE, and also, a method to avoid this issue hereon? -
-
As long as the field_fmt column in exp_weblog_fields is set to "none" you should be fine for future entries.
-
-
Brandon,
Upon correcting what we've discussed, the problem still persists.
All "field_fmt" columns are set to "none" in exp_weblog_fields.
After clearing any data and updating a publish page the [br /] tags reappear.
These are always [br /] tags along with a carriage return.
They are not present with a fresh publish page.
Wow, what a bugger!
Thanks for your help... -
-
exp_weblog_fields was only the first step. You also need to update each of the appropriate rows' field_ft_XX column within exp_weblog_data.
-
-
Brandon,
All "field_ft_XX" fields are set to "none". This was accomplished using UPDATE exp_weblog_data SET field_ft_XX='none'. And they all reflect that change.
If I go into an entry and manually delete the break tags within each field, the updated result works and they are no longer present. Upon updating the entry again, they reappear without having touched the field. -
-
Weird.
You haven't set the "enterMode" or "shiftEnterMode" settings to "CKEDITOR.ENTER_BR", have you? -
-
It is strange...
This behavior did not happen with the previous version.
As a matter of fact I tried commenting-out the following without results:
options: { 'CKEDITOR.ENTER_P':'<p>', 'CKEDITOR.ENTER_BR':'<br>', 'CKEDITOR.ENTER_DIV':'<div>' }},
entities: { desc: 'Whether to use HTML entities in the output.', type: 'bool', val: 'y' },
entities_additional: { desc: 'An additional list of entities to be used. It’s a string containing each entry separated by a comma. Entities names or number must be used, exclusing the “&” preffix and the “;” termination.', val: '#39' }, -
-
Which previous version? 2.0.0, 1.1.5, etc?
-
-
I started with 1.1.5 and upgraded to 2.0.0 and finally 2.0.1.
But I honestly can't remember what was going on between 2.0.0 and 2.0.1...
What I can do is downgrade and see the results. Should I? -
-
Yes I'd appreciate that, so I know exactly where to look for the bug.
-
-
Brandon,
The bugger must be sitting in 2.0.1.
I downgraded to 2.0.0 and I no longer have the break tags.
In fact, when I clicked in any fields "source" before updating, the the break tag were not present! -
-
Hi Brandon,
I'm experiencing exactly the same issue with Wygwam 2.0.1, since upgrading from 2.0.0. It keeps inserting a single break tags in a Wygwam field that is empty.
I will follow this thread with interest.
Thanks
Simon -
-
I’m
sad
Hello
I'm experiencing this as well. Real problem for me. -
-
I’m
anxious
OK. So I think I've found a way to fix this problem, however, it does not explain why the issue occurs in the first place and it certainly isn't ideal.
I found that if I clicked inside empty Wygwam fields, it creates some basic formatting for the field that replaces the break tag. In fact, you can see the formatting in the info bar at the bottom of the Wygwam field, i.e. body p.
This seems to replace the break tag when save the publish form.
However, if you have an empty Wygwam field repeated in a matrix grid, you'll need to ensure you click all empty fields otherwise it seems to re-insert the break tag. Weird I know, however, it seems to have fixed the problem for me.
Of course, I appreciate that this is really not an ideal solution, especially if you have lots of entries to manually update in this way, but it is a start to find a solution for this particular problem. -
-
Ok, it's something I can protect against, but I need to know exactly what is getting saved for you. So in your template can you add something like:
>>>{wygwam_field}<<<
And use Pastie to send exactly what the code ends up being, including the >>> and <<s? -
-
Hi Brandon,
I'm not sure if this was directed at Jeff or at anyone who has posted, however, I thought I'd respond to your request anyway.
http://pastie.org/872708
I hope this helps. -
-
Same problem. I'm using 2.01 in a FF Matrix field with EE 1.6.8. -
-
I’m
cautiously optimistic
Brandon -
It appears this may be an issue with ckEditor 3.1.1 (http://dev.fckeditor.net/ticket/5293). I notice that's the version you're currently using in Wygwam.
Update: It also appears, in my testing, that the linebreaks only occur in Firefox with Firebug enabled. Testing in Chrome and Safari resulted in empty fields (no linebreak appended). -
-
Thanks for clearing that up, Mark!
I've added something to fix this for the next release, but if you need the fix right now, just open ft.wygwam.ee1.php (or ....ee2.php, depending), find this line:
if (! $data || preg_match('/^\s*(<\w+>\s*(&nbsp;)*\s*<
if (! $data || preg_match('/^\s*(<\w+>\s*( )*\s*<\/\w+>)?\s*$/s', $data))
#47;\w+>)?\s*$/s', $data))
And change it to:
if (! $data || preg_match('/^\s*(<\w+>\s*(&nbsp;)*\s*<
if (! $data || preg_match('/^\s*(<\w+>\s*( )*\s*<\/\w+>|<br \/>)?\s*$/s', $data))
#47;\w+>|<br
if (! $data || preg_match('/^\s*(<\w+>\s*( )*\s*<\/\w+>|<br \/>)?\s*$/s', $data))
#47;>)?\s*$/s', $data))
-
-
I’m
delighted
Brandon -
I've verified that your fix solves the problem in Firefox with Firebug enabled. Thanks! -
-
I’m
thankful
SweetMarymotherofjesus thank you for this fix, I was going bonkers :) -
-
I’m
thankful
PHEW glad i found this post - this is a huge help!
-
-
I’m
happy
Thanks for this fix! This has been causing me pain via WYGWAM fields within FF Matrices that think they have content when they really didn't. -
EMPLOYEE
