HTML tags displaying in article when using Formbot

[timhoward]

I am employing the form mambot to display a form in an article. The correct record is being displayed but he HTML tags are also displaying as content rather than being parsed.

This is literally all that the article body field contains: "{includeFabrikForm form=4 rox=3}"

Shouldn't I be able to display HTML tagged form content in this way?

J 1.0.15
Fabrik 1.0.6
TinyMCE

 

[cheesegrits]

Can you point me at an example page?

-- hugh

 

[timhoward]

Example page

http://www.pdpnet.us/cix/dev3/

Login with xxxxx / xxx and click Profiles International in the main menu.

Also, I presume that I should be able to edit a CSS file so that the data column is wider?

Thank you!

 

[cheesegrits]

Hmmm, strange. I notice that if I use the prev/next buttons, the formatting sorts itself out. I'll have to dig around and work out why its not formatting on the initial page load.

Yes, you can tweak the CSS. It's inheriting .readonly from the standard Joomla template.css, so you can either change that, or customize your Fabrik template and override it only in fabrik tables like this ...

.fabrikForm .readonly {
width: 400px;
}

... or whatever you need.

NOTE - remember to clone a new template if you go that route, details in a FAQ forum post somewhere. If you just edit one of the out-of-box ones, your changes will get blown away next time you update.

-- hugh

 

[timhoward]

Sure nuff. Paging away and back causes the HTML to parse. Just refreshing the page had no effect. Might it be J1.0.15 specific (ugh)?

Looking forward to your ides for resolution. Let me know if I need to supply you with anything else.

 

[cheesegrits]

No, it should "just work", I don't think it's anything to do with J!.

We recently made some changes to the way the read only forms get loaded and how the prev/next stuff works. I suspect it's to do with how we add the content to the DOM.

We'll get it sorted out. But note that I'm out of town this weekend, so it's probably going to be next week before I can do anything about it. I'm already at capacity for todays To Do's.

-- hugh

 

[cheesegrits]

OBTW ...

We don't encourage providing usernames/passwords in the forums, even for non-privileged accounts. Bots can still harvest and use those, as it lets them bypass any CAPTCHA type protection you have on your registration proocess. And even a non-priv'ed account can be used for spamming.

So for future reference, if you need to supply a username/password, PM (Private Message) it to the person helping you. And remember to include a link back to the relevant thread in your PM.

-- hugh

 

[timhoward]

Thank you for the great product, great, real world timely support, and the PM reminder.

Have a great weekend! I'll plung ahead with the confidence that you'll find a resolution next week.

 

[cheesegrits]

I'm confident we can fix it. I'll raise a support ticket on it so it gets in the official bug fix list. That should show up at the top of this thread.

-- hugh

 

[lena]

Hi,

try this: select no text editor from configuration pannel and from your user account.
enter the code {includeFabrikForm form=4 rox=3} in the text box and save.
then put back the editor in both place this should fix it.

a+

 

[timhoward]

Thank you Lena. That was actually the first thing I did before I submitted the case. The content of the article (including the field in the DB) contains only:

{includeFabrikForm form=4 rox=3}

The issue has been recognized as a bug with " . . . the way the read only forms get loaded . . .".

Hugh is confident they will get it addressed--hopefully this week.

Tim

 

[cheesegrits]

I'm still hopeful, although I'm somewhat swamped right now.

BTW, y'all keep saying rox=3, I assume you mean row=3?

== hugh

 

[timhoward]

Yes. "row=3"

Swamped I understand.

I'll hold out long as I can for that fix before I may need to take another approach. Using the formbot will make it easy for me to do side-by-side comparisons. Company A's sales positioning along side Company B's sales positioning. Using the formbot will make a lot of things easy to pull off--but I'll need to be able to present the taged content correctly.

Thank you!

 

[cheesegrits]

Tim, can you PM me a backend login to that site?

-- hugh

 

[timhoward]

Attempted IM without success. Created a login for you and sent credentials to hippo@alaweb.com. Need anything elase from me?

Thank you!

 

[cheesegrits]

PM means 'Private Message', the system built into the forums. Look under Quick Links near the bottom, or the Notifications menu top right. Then send a PM to 'cheesegrits'.

I really try to avoid using IM or email for support, it makes it ten times easier for me if everything is self contained on this site, either in the forums or in PM.

-- hugh

 

[cheesegrits]

OK, after some head banging on this one ... the fix is to specify editable=false in the formbot incantation.

For some reason, the HTML formatting renders fine when using a component link and task=viewTableRowDetails (i.e. read-only template), but when viewed through a mambot and relying on permissions to work out whether it's read-only or not, the formatting in textareas isn't applied.

So ... I changed all three of your mambot lines in the content page and added the editable=false to it. HTML formatting in text areas now works.

-- hugh

 

[timhoward]

[Submit] button was displaying on readonly formbot form

An additional detail I had not mentioned previously. Any read only form displayed via the formbot was also displaying a [Submit] button. Including "editable=false" in the formbot tag also hides the [submit] button.