Announcement

Collapse
No announcement yet.

Users getting script error in WYSIWYG Interface

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Even in Gold the same JS error - I can't use the GUI, nor attach files - what can I do?

    Comment


    • #17
      Originally posted by Orfejs
      Even in Gold the same JS error - I can't use the GUI, nor attach files - what can I do?
      Please start your own ticket with all the relevant details needed to help understand and fix this problem.
      Steve Machol, former vBulletin Customer Support Manager (and NOT retired!)
      Change CKEditor Colors to Match Style (for 4.1.4 and above)

      Steve Machol Photography


      Mankind is the only creature smart enough to know its own history, and dumb enough to ignore it.


      Comment


      • #18
        I'm getting the same wysiwyg smiley problem.

        I can use the drop down smileys on this forum, but they don't work on my own forum. I'm using vbulletin 3 gold.
        BTW everything did work ok to start with, but for some reason the wysiwyg smiley thing and font picker have stopped working.

        Never mind, i think i've fixed it.

        Here's how i fixed it :-
        http://netaddition.com/forums/showth...?p=207#post207
        Hope that helps.
        Last edited by NetAddition; Tue 13th Apr '04, 5:00am.

        Comment


        • #19
          This is a vBulletin bug present in v3.01 as upgraded from 2.x.x. The problem is that you are failing to call editInit() for IE browsers in the editor_toolbar_standard template with the following code:

          Code:
           
          <if condition="is_browser('ie')">
          <!-- initialization script -->
          <script type="text/javascript">
          <!--
          editInit();
          //-->
          </script>
          </if>
          [NOTE: to fix the problem, add the above code to the bottom of editor_toolbar_standard]

          I saw the same problem and did an upgrade from vb2.3.5 to vb3.0.1 and my editor_toolbar_standard template was unmodified.

          I hope this helps resolve the issue, since CTL+F5 will not work to fix this problem. So far, after adding the appropriate js init code to standard template, it seems to be working.

          Also, in your respective editor clientscript files, "theform" is the name of the variable you set to document.forms.vbform in vbcode_init(), called by editInit(), which is why the browser reports that the theform.whatever is invalid, since it is uninitialized.

          As above, this may be an artifact of the v2.x.x update process, since it did not happen in my other site, which was a clean 3.0RC-based install. Is there a problem with the installer?

          Comment


          • #20
            editInit should be in the onload for the body tag. Have you edited the header at all?

            the reason for this is IE wont execute the editInit until after everything up to that point is loaded where other browsers would execute that before images before it were fully loaded, hence the reason for the call only to IE.

            I just tried all 3 editors in FireFox, IE and Opera without problem. Clicking smilies etc. All had the hovering ability though it was indeed broken when I removed the onload event. This is usually caued by drop down menu scripts.
            Scott MacVicar

            My Blog | Twitter

            Comment


            • #21
              Ahhh...*light goes on*...OK - I see what you're doing - I searched the 3.01 sources and found the dynamic onload event setup for editInit() in functions_editor.php in the DOTOOLBAR conditional. So, just for the benefit of others reading this thread, the way it works is that when someone opens up the editor window, an onload=editInit(); is automatically inserted in the body tag of the editor's html (or whatever is using the toolbar, I guess), which should invoke the correct javascript initialization.

              Fair enough - so I checked my standard edit body tag by viewing the page source, and oddly enough, the onload=editInit(); is where it is supposed to be, so it seems like it should have worked, right? But no!

              We include the vb3 forums beneath a custom navigation panel which already has its own set of DHTML menus (with onload code) and its own body tag (with no onload event, however) and all of it gets loaded before vb, as SM suggests, from the header include in vb. When you dump the HTML for the page, there are 2 body tags, but only the 2nd vb <body> has an onload event. However, it's possible that the DHTML is stealing the event, or the browser is processing it for the "wrong" body tag.

              I'm not exactly sure what to do about this, other than the earlier fix, or adding vb's call to editInit() in our body tag, which would not be a very self-contained or clean way to address the problem, especially since it would be called on every page, rather than the targeted std. editor page.

              Also, since my post with the code fix above, I have had confirmation from everyone previously getting javascript errors that the problems are now resolved. They're happy, so I'm happy.

              So...does this extra info help? It looks like you might need to account for other things stealing your onload event or body tag out from under you. If there's anything else I can do, let me know. I probably don't need to rip out all the live forum changes - it's easy to see that it will work similar to what you saw in your testing, based on looking at the code and html dump.

              Comment

              Loading...
              Working...
              X