Awesome! Any idea when it will be ready for the public?

Jesse BC,

Ok it’s ready.

www.solspace.com/software

Whoa… that was fast.

Man!
Mitchell you’re a genius.

Thanks for your plug ins and modules.

Thanks EE lover. I hope you’ll let me know if you have any feature ideas or anything.

mk

The field parser is a great idea, but I think I may have found a problem…

If you have the edit textarea set to xhtml, then with each edit the spaces between paragraphs grows. After a couple of rounds, you get something like

<p>Li Europan lingues es membres del sam familie. Lor separat existentie es un myth. Por scientie, musica, sport etc., li tot Europa usa li sam vocabularium. Li lingues differe solmen in li grammatica, li pronunciation e li plu commun vocabules.

</p>
<p>

<br />
Omnicos directe al desirabilit de un nov lingua franca: on refusa continuar payar custosi traductores. It solmen va esser necessi far uniform grammatica, pronunciation e plu sommun paroles.
</p>

And it just gets worse from there. I think it has to do with the way EE adds <p> tags after a line break, rather than immediately following the last word of a paragraph, e.g.

...sommun paroles.
</p>

instead of

...sommun paroles.</p>

But you should try it out and see for yourself, seems like it should be something fixable. Anyway, a cool feature, once it’s working.

Without the field parser, I just turn xhtml off in the stand alone edit (while keeping it on in the new entry form), think of it as a little lesson in basic html for the user

Also having trouble with repeated editing adding extra <p> and <br /> tags. I have tried a million combinations (field formatting versus edit-field format declaration) but nothing. So…

...I’ve been trying some XHTML:Filter combinations from the Filter XHTML plugin, and it nearly works, but doesn’t.

On my edit form, a particular field needs to allow text to be broken into paragraphs by the user, using line breaks. Formatting in Custom Edit Field is XHTML, and this is also declared in the edit form. On the edit form field I include the plugin ref, disallowing use of <p> or <br /> tags:

This stops <p> or <br /> tags appearing on the edit form fields. Great. I then also use the plugin code on the article page, this time disallowing just <br /> tags:

The aim there is to remove any break tags in the published article. I also tried it with <p> tags removed. I notice that when editing, lots of space appears between paragraphs, whether tags show or not. Anyway, the above DOESN’T work, but I’m flagging up the idea to see if Solspace or anyone can use that to make it work. There is a working combination in there somewhere, surely…

This thing is so close…

Has anyone got a solution to the creeping <br /> <p></p> and empty space problem when using the (otherwise life-saving) Form Helper plug-in by Solspace? Solspace’s documentation mentions the use of another custom field to control this, but does not elaborate, which tantalising hint just left me in “duh” mode

Hey JohnD,

The other custom field I think you’re referring to is the custom field that designates the formatting to be used for your custom field. When you create a custom field in EE, automatically an additional field is created in the database that tracks whether you are using XHTML, BR, or none as formatting options.
Noe of that fixes the problem that we are trying to solve. And sadly, I have not had the opportunity to troubleshoot and develop a solution to the bug described above. I’ll knock it out as soon as possible though. Thanks for using the plugin.

mk

Yo Solspace

thanks for the update - wish I could help.

John

JohnD, what I do on some client sites is change the default value from xhtml to either none or br as needed on the exp_weblog_data table.

So that a new entry is set correctly without me having to add the hidden form values to switch formatting types.

Cheating, but it works.

Thanks Sue for that idea - a good alternative for when needs must (or is it when the devil drives?)

Another Form Helper Issue

When I include an e-mail link in an entry, and then put it through the Form Helper update method, the following replaces the e-mail link:

<script type=“text/javascript”>
//<![CDATA[
var l=new Array();
l[0]=’>’;l[1]=‘a’;l[2]=’/’;l[3]=’<’;l[4]=’ 107’;l[5]=’ 117’;l[6]=’ 46’;l[7]=’ 111’;l[8]=’ 99’;l[9]=’ 46’;l[10]=’ 110’;l[11]=’ 111’;l[12]=’ 105’;l[13]=’ 116’;l[14]=’ 97’;l[15]=’ 114’;l[16]=’ 111’;l[17]=’ 116’;l[18]=’ 115’;l[19]=’ 101’;l[20]=’ 114’;l[21]=’ 103’;l[22]=’ 110’;l[23]=’ 105’;l[24]=’ 102’;l[25]=’ 111’;l[26]=’ 111’;l[27]=’ 114’;l[28]=’ 64’;l[29]=’ 110’;l[30]=’ 97’;l[31]=’ 101’;l[32]=’ 115’;l[33]=’>’;l[34]=’”’;l[35]=’ 107’;l[36]=’ 117’;l[37]=’ 46’;l[38]=’ 111’;l[39]=’ 99’;l[40]=’ 46’;l[41]=’ 110’;l[42]=’ 111’;l[43]=’ 105’;l[44]=’ 116’;l[45]=’ 97’;l[46]=’ 114’;l[47]=’ 111’;l[48]=’ 116’;l[49]=’ 115’;l[50]=’ 101’;l[51]=’ 114’;l[52]=’ 103’;l[53]=’ 110’;l[54]=’ 105’;l[55]=’ 102’;l[56]=’ 111’;l[57]=’ 111’;l[58]=’ 114’;l[59]=’ 64’;l[60]=’ 110’;l[61]=’ 97’;l[62]=’ 101’;l[63]=’ 115’;l[64]=’:’;l[65]=‘o’;l[66]=‘t’;l[67]=‘l’;l[68]=‘i’;l[69]=‘a’;l[70]=‘m’;l[71]=’”’;l[72]=’=’;l[73]=‘f’;l[74]=‘e’;l[75]=‘r’;l[76]=‘h’;l[77]=‘a ‘;l[78]=’<’;
for (var i = l.length-1; i >= 0; i=i-1){
if (l.substring(0, 1) == ’ ‘) document.write(”&#”+unescape(l.substring(1))+”;”);
else document.write(unescape(l));
}
//]]>
</script>

You have EE set to automatically turn email addresses into links.  Part of that process is encoding the addresses so they’re much harder for spam harvesters to get them.  You could turn off the “auto-linking” feature for emails under Admin > Weblog Management, but then the email addresses will just be plain text.

Yes, thanks Chris - turning off the automatic e-mail to link conversion via Admin > Weblog Management is certainly an option, but for now I am simply commenting out the hrefs which call the Solpsace Form Helper - seems safer since the creeping spaces <p> and <br/> problems are still a nuisance.

I think the ultimate solution for the “Form Helper” (and, mind you, I say this without having actually tried to use it) is to pull the entry field data straight from the database so that it hasn’t already been processed by EE.  In that way you’d have the raw content just as if you were editing in the CP.

Chris - I wondered about that, but my mysql/php skills are still at the no-confidence stage. I am going to take a look at the database(s) and structure(s) involved to educate myself, and maybe I will have an idea or two. Meanwhile I am still trying to get my head around how to use URL segments to thin out my forest of templates.

JohnD, I did find a workaround.

I used the pi.replacestring.php plugin to replace

’<br />’ => ‘’

Here’s a screen shot with one textarea fixed with the replace string and one without.

http://www.clientstaging.us/staging/brfix.jpg

Ignore the different heights of the text areas. Slightly different code.

This isn’t the real fix. What Chris described is what should be done.

But for the moment, it works.