PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

HTML block on 1.3.13 beta

  1. drlelong
    Member

    Hi,

    I'm trying to use the the HTML block on one of my forms. I can add it to the form, but I don't see how I can add HTML content to it. When I put it in edit mode, the Properties and Advanced tabs appear, but they are blank.

    I have a number of conditional conditional drop down fields on this form.

    David

    Posted 13 years ago on Tuesday July 20, 2010 | Permalink
  2. You should be able to hover over it and select Edit. It should then show options available, including an Advanced tab. It should look like this:

    http://grab.by/5w9N

    If it doesn't look like that then you may be experiencing some sort of plugin conflict or javascript issue. You will have to check for plugin conflicts.

    If you send us a WordPress admin login for this site via our Contact Us form we can take a look at it for you and see what is going on. Reference this forum post.

    Posted 13 years ago on Tuesday July 20, 2010 | Permalink
  3. drlelong
    Member

    Any luck with logging into my site? I sent you credentials via the Contact Us form.

    Posted 13 years ago on Wednesday July 21, 2010 | Permalink
  4. David,

    Just had time to get to your request. I see you sent us the authentication info, but I don't see your site URL. Can you post that real quick?

    Posted 13 years ago on Wednesday July 21, 2010 | Permalink
  5. I can edit the HTML Block on Safari but not on Firefox. I tried turning off other plugins but it made no difference. Firefox 3.6.6 on a Mac running 10.6.4. Latest version of WP.

    Posted 13 years ago on Wednesday July 21, 2010 | Permalink
  6. @JohnO

    I can't recreate the issue. I've tried on 2 different machines both MAC running Firefox 3.6.6

    admin screenshot

    If you'd like to send an admin login to your site via the contact form I'll be happy to take a look at it ASAP.

    Posted 13 years ago on Wednesday July 21, 2010 | Permalink
  7. @JohnO

    I logged into your site and tinkered with the form there, but still wasn't able to replicate any problems with the HTML block. I'm really not sure why you're having difficulties with it. Just a guess - could be some kind of local browser cache issue. If you were running the beta version of the plugin, it might have cached some older versions of the files.

    http://screencast.com/t/ZDFlM2Y3YW

    Posted 13 years ago on Wednesday July 21, 2010 | Permalink
  8. Well this is odd. I restarted Firefox after your test, went back to editing that form, and got the same result: tabs showed up but the block didn't expand much -- I only got a quarter inch of white space under the tabs.

    Then I went into Firefox preferences. The only thing I did was the uncheck "Block Pop-up Windows." Then I went back and forced a reload of the form and voila, there was the HTML Block edit fields. I had done a force refresh of that page numerous times before so that wasn't it. Then I went back and rechecked the "Block Pop-up Windows" but it still works. I never got as far as manually clearing the cache.

    Strange mystery javascript behavior...

    Posted 13 years ago on Thursday July 22, 2010 | Permalink
  9. Yeah, I run into that mystery javascript myself from time to time. I usually just convince myself that magical beings fixed it somehow when I wasn't looking. I'm not sure that's the best way to look at it, but I enjoy my delusion :)

    Posted 13 years ago on Thursday July 22, 2010 | Permalink
  10. drlelong
    Member

    Yep, that did it for me too. I can now edit the HTML Block content.

    Posted 13 years ago on Thursday July 22, 2010 | Permalink
  11. @drlelong - Thanks for the update. Glad that cleared up for you.

    Posted 13 years ago on Thursday July 22, 2010 | Permalink
  12. blafarmm
    Member

    Same problem here with Firefox and HTML
    Unchecked "Block Pop-Up"
    Cleared cache
    Reloaded Firefox and GF form
    Problem solved

    Posted 13 years ago on Monday July 26, 2010 | Permalink
  13. blafarmm
    Member

    Actually, these problems are evolving.

    Worked on the form for about an hour ... and then experienced HTML fields that open all the way -- and then shut by themselves -- with no time to type or paste into any fields.

    Can't work this way -- going back to Chrome -- which I left due to a host of other documented problems.

    Wondering if IE is a safer overall choice in the long-run -- at least for development.

    Is there a browser that is known to have the least number of issues?

    Posted 13 years ago on Monday July 26, 2010 | Permalink
  14. We haven't been able to reproduce the issue here and the only issues reported so far are the ones in this thread. I'll test some more and see if I can recreate the problem you're having.

    Posted 13 years ago on Monday July 26, 2010 | Permalink
  15. blafarmm
    Member

    Hi Kevin,

    Actually, it has just begun happening with Chrome. Very frustrating. And, yet, there seems to be an observable pattern -- as it has happens only in a certain form structure scenario.

    Here is a possible way to reproduce it:

    Create 5 Paragraph fields in series. Enter a Field Label, enter text in the Default Value and enter a Conditional Logic if you can (although I'm not certain this is absolutely necessary).

    Create 5 HTML fields (that are intended to replace the Paragraph fields). Drag them up one-by-one so that there is a new HTML field BELOW each of the Paragraph fields that you already created.

    Then, starting at the top, copy the information from each Paragraph field -- to the HTML field that is directly below. Copy the Field Label, the Default Value and the Conditional Logic. There's no need to delete the obsolete Paragraph fields as you go -- as it appears to not play a role in the problem.

    If you are luck (so to speak) by the time you get to the third field -- you may experience this HTML "open/shut" "seesaw" behavior that prevents any information from being entered into the HTML field. The HTML opens all the way -- and then shuts all by itself.

    On top of that, this phenomena causes the forth and fifth HTML fields (which you haven't yet used) to be completely un-openable.

    And, for the record, saving the form does not make the problem go away.

    What does work, is saving the form, deleting the offending HTML fields, creating new HTML fields, moving them to the correct locations under the Paragraph field -- and using them normally. So, at least there is a workaround.

    I don't know why it started happening the Firefox -- and why I was able to switch to Chrome to fix the problem. And, now I don't know why it has started in Chrome. I guess I'm going to have to migrate to IE.

    Please let me know if you are able to replicate the problem. Otherwise, I'll give you a login to my WP installation again (if you want).

    Note: Edited several times for clarity

    Posted 13 years ago on Monday July 26, 2010 | Permalink
  16. blafarmm
    Member

    For the record, this is now happening Single Line Text fields. And, once again, it is following the pattern described above.

    It may be the length of my form, but you can probably replicate this problem by creating 4 Single Line Text fields in a row at the bottom of your form.

    Fill them out -- starting with the top field.

    By the time you get to the third field -- you will likely experience this open/close seesaw effect. And if you do, you will find that the fourth Single Line Text field is completely unresponsive.

    If you delete the third and fourth fields -- and create new ones -- the problem will disappear.

    This suggests (but has not comprehensively tested) that creating four or more fields in a row (at least HTML and Single Line Text, if not more) -- and filling them out starting at the top --will likely cause the third field to automatically open and close by itself -- and the fields below the third field -- will be DOA.

    Can you replicate this problem on your end?

    Posted 13 years ago on Wednesday July 28, 2010 | Permalink
  17. We are unable to replicate this issue on our end. We can add 4, 5, 6, 10 single line input fields in a row on our form and edit them one by one from the top down without a problem. We are doing so in Chrome, FireFox and Safari without an issue.

    Nobody else is reporting this issue which leads me to believe it's possible it could be some sort of javascript related issue with your WordPress install with a plugin conflict being the cause.

    Have you checked for possible plugin conflicts causing interference with the Javascript?

    Can you export your form and place it somewhere where we can download it so we can import your exact form configuration on our end?

    So far nobody else has reported this issue and we are unable to replicate it so it's very difficult for us to determine what the problem is.

    Also, are you clicking the actual "EDIT" icon/link to open the editor interface? While clicking anywhere can fire the javascript, you are really supposed to click the "EDIT" icon/link to open the editing interface.

    Posted 13 years ago on Wednesday July 28, 2010 | Permalink
  18. blafarmm
    Member

    Carl,

    I have exported the form in question to my desktop -- then imported it to another GV installation that is living on a different domain. I created 4 new Single Line Text fields -- and the open/close problem has "traveled" to the new domain.

    But, interestingly, this time it is happening on the first of the four new Single Line Text fields -- and the three new fields below it are DOA. As mentioned, they can be deleted and recreated -- as a workaround. And, for the record, I am clicking directly on the Edit link -- not just on the field in general.

    Then I decided to create two brand new forms -- on both domains. I tested by creating 4 new HTML fields in series -- and 4 new Single Line Text fields in series -- and neither of the new forms displays the open/close problem. This leads me to believe that the problem may be isolated to the form I am working on -- or to forms that are of a certain length or complexity.

    For the record, both WP installations have the EXACT SAME complement of themes and plugins installed. Neither domain is "live" -- and no other plugins are being actively used.

    I suspect opening my form on your GV installation will allow you to see the problem first hand. I hope you can isolate it -- as I'd very much like this form to be free of any amount of corruption.

    I will email you the form right now at your rocketgenius.com address.

    Posted 13 years ago on Wednesday July 28, 2010 | Permalink
  19. I received your form export file and imported it to my test site. I was able to edit it in Chrome, add fields, edit fields, etc. without a problem.

    In my test I added 4 single input fields, edited each one of them and then I added 4 HTML blocks and edited each one of those. I then randomly open and close the editor on various fields I added and made a few additional changes.

    Everything works as expected.

    Here is a screencast of exactly what I did using Chrome:

    http://screenr.com/SeX

    One thing to note is javascript is run client side, not on the server. It relies on your computer to process it in the browser. With a large form it is going to mean more javascript to process.

    If your local machine has a hard time processing it, or lacks memory of system resources to do so... your browser could have issues. So it's possible this is an issue specific to your computer setup.

    As I mentioned, i'm not able to reproduce it (video above shows it in action) and nobody else has reported this issue.

    Posted 13 years ago on Wednesday July 28, 2010 | Permalink
  20. blafarmm, you say "same plugins and themes" but "no plugins actively being used". So, what theme are you using, and what plugins are installed? Sounds like it has to be a conflict with either theme or plugins.

    Posted 13 years ago on Wednesday July 28, 2010 | Permalink
  21. blafarmm
    Member

    Response sent via email.

    Posted 13 years ago on Wednesday July 28, 2010 | Permalink
  22. blafarmm
    Member

    For the sake of clarity, it has been determined to be a local Javascript issue.

    Other computers at the same location do not display the same problem.

    Posted 13 years ago on Wednesday July 28, 2010 | Permalink