I’ve found the source of the problem. Still not sure how to fix it. If I turn the Date tab off, the tinyMCE toolbar appears fine for all.
Seems like my comment relating to weird Australian settings might be closer to the truth than I thought. Is there a chance that it worked fine for you Derek because you are in a US timezone and we’re not? Some conflict with date formats perhaps - whether on our machines or on our servers?
The problem seemed to be around the expiration date field, altho it was hard to be 100% certain. I figured it out by copying the source of a publish form, pasting into a new HTML on our server, stripping out the javascript and then pasting each block in until the toolbar disappeared. When I realised that it was the date section causing a problem, I turned that tab off and voila! Toolbar came back.
Obviously not having a date tab isn’t a great solution! Any thoughts on how to progress from here?
Yes I did. But just then, I went back to verify that it was all exactly as I said and the toolbar has disappeared again! I promise you it was there before, as I went to confirm with other users who could see it too. I didn’t dream it!
I was very careful about only turning off the date tab because I didn’t want to add any other potential issues to the equation. (Went into weblog preferences and set the radio button to no under Publish Page Customisation - Display Date Fields).
Sigh, back to more testing/fiddling I suppose.
OK, now 100% sure - forms without the Dates tab display the toolbar. Forms with the Date tab do not. Have tested this on multiple machines, in different browsers, on different websites within our installation (we have MSM) with the same result.
Will do some further testing from my home machine, but I don’t imagine it’ll show much different.
but js_calendar.php is identical in 1.6.3 and 1.6.4? (unless my 1.6.4 package is messed up?)
Derek, when I moved up the order of display of the WYSIWYG field, the problem went away. That could be why you were able to see it. If you’re willing to have another look at it, let me know and I’ll move it back down to position #20. When the field is last or next-to-last in my long form (over 10 fields), the buttons do not appear in IE (for me.)
Derek, thank you for sending me cp.publish.php and js_calendar.php. I moved the field back to the bottom of the page, and now the WYSIWYG toolbar is consistently showing in IE7 for me.
FYI: The cp.publish.php you sent me is different from my 1.6.3 and my 1.6.4 versions. My 1.6.3 and 1.6.4 cp.publish.php do not match.
The js_calendar.php you sent me is different from my 1.6.3 and 1.6.4 versions, which do match.
I’ll keep using these together unless you have another recommendation.
—Diana
::drums fingers on desk::
Ok so that would point to a conflict with the Javascript change made for the calendar in 1.6.4. But not a naming collision or syntax issue or it would affect all browsers.
Guess my foot’s going into my mouth about it being completely external to EE, though I’m still puzzled as to why I cannot recreate the problem. Let me review the changes and see what might be at fault.
Hey Diana. Would you mind if I took a look. I’m responsible for the Calendar changes, so maybe a different perspective would help. If that’s good, then could you email me login info to your CP? I just want to see the error for myself and see if I can recreate it (.(JavaScript must be enabled to view this email address)).
Hey Diana.
OK, I think I have a lead, but nothing “solid” yet. Are you in a position where you’d be able to disable LG TinyMCE Custom Field and enable the first party extension in its place? There is an extraordinarily large “GET” request being throw here, and I’m not familiar enough with tinymce to figure out what its doing, but I do notice that it does not do this with the default tinymce.
I know this isn’t a solution at this point, but it’ll help us narrow things down. Thanks for your patience.
This is done: the LG TinyMCE extension is disabled, and I’ve redefined the publish fields that used it as Textarea with XHTML. (right now this site is in development, if you couldn’t tell, heh! Content has not yet been added.)
So I’m happy to try things out in this installation.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.