Current status:

There is a working patch which makes existing TinyMCE 3 editor profiles work with TinyMCE 4, but a lot of settings have changed between the editor versions so there's no guaranteed "upgrade path".

Users applying the patch but deciding to stay with TinyMCE 3 should notice no difference. Upgrading to TinyMCE 4, testing the editor without saving an editor profile, and then downgrading back to TinyMCE 3, will not alter existing editor profiles or the editor behavior in any way.

Downgrading saved profiles, or profiles created after TinyMCE 4 was installed, is not supported. Downgrading to TinyMCE 3 again and creating new profiles still works as expected.
Note that any settings dropped in TinyMCE 4 will be lost if saving a TinyMCE 3 profile after TinyMCE 4 has been installed.

The value for TinyMCE 4-specific settings may not actually be stored in the profile yet, even though they show up with a default value in the profile editing GUI. but the default values should match what the editor uses as its defaults when no value is explicitly set.

The patch is built for Wysiwyg 7.x-2.x, but the editor implementations in Wysiwyg 6.x-2.x are very similar so the patch should apply there too with minimal changes. Please go ahead and test this if you feel like it, but report problems with the 7.x-2.x patch to prevent a situation where bugfixes have to be applied to two different patches on each reroll and potentially allowing the versions to drift apart. A final backport of the 7.x-2.x patch will be created for 6.x-2.x once it's ready for commit.

Todo:
Compile a list of settings supported by Wysiwyg for TinyMCE 3 and find their equivalents in TinyMCE 4.
Paste [from Word] settings will be dealt with in another issue once this is done.
Compile a list of issues we absolutely need to provide GUI widgets for out of the box. More can always be added later.
Compile a list of features/settings/plugins/buttons which had to be dropped or could not be cleanly migrated when loading a TinyMCE 3 profile when TinyMCE 4 is installed.
Make sure all TinyMCE 4.0+ changes have been accounted for, if needed.
I always forget something here....

=================================
Original post:

TinyMCE 4.0b1 was released yesterday and looks promising. I'm guessing there may be a bit of work to get this working with WYSIWYG module. First step is probably detecting the javascript file. The new location is tinymce/js/tinymce/tinymce.min.js, or you could probably also use the non-minified version which probably has a different filename.

Comments

TwoD’s picture

Thanks, I'll look into it ASAP.
UPDATE: I just got a newsletter from the TinyMCE team, interesting how fast some news spread. ;P

Taiger’s picture

It would be nice to have an error message when you try to add an unsupported editor. It is very confusing as you first blame yourself for doing something wrong until you install one that is supported.
FYI Ckeditor versions 4.x also quietly fail.

Thanks for all the hard work!!

duncan.moo’s picture

Title:Support for TinyMCE 4.x» Support for CKeditor 4.x

If implementing a new site why not look at the module that will be part of core in Drupal 8: CKEditor for WYSIWYG Module most likely to have rapid improvements and development. The module is still in Dev state, but is pretty nice, if it does not work for you you can always switch to another WYSIWYG editor as this module works with the WYSIWYG module.

TwoD’s picture

Title:Support for CKeditor 4.x» Support for TinyMCE 4.x

There are error messages shown if the version of an installed editor library isn't detected, but we can't determine if an editor is supported or not before it has actually been released and tested with Wysiwyg. We just can't know what they'll change and putting in a fixed "max version" limit would mean more or less a Wysiwyg module update for each new library version to keep up.

There might be a "last known good version" column next to the installation instructions, but I think that's pretty much all we can do.

@duncan.moo, please don't change the subject.

sillo’s picture

Hi. any news on how to install TinyMCE4? i had this problem since first day of Release but i could not find anything on it, since it is so new i figure ..

TwoD’s picture

Sorry, I have not had time to get around to this yet (home and work takes too much). If anyone wants to give it a shot, please do.

TinyMCE 4 is still in beta, but I don't expect their APIs to change much more so we should be able to get a patch going fairly easily. The change logs do indicate most/all plugins and themes have been rewritten and some have been added/removed, so we need to make sure toggling each one and their buttons actually works.

The new file structure may require a bit of work in the version detection callback so it is able to detect both TinyMCE 3.x and 4.x versions. I'm thinking we should drop 2.x support by now.

mgifford’s picture

It's at b2 now. No idea what their ETA is for the final release.

sillo’s picture

OK. thank you very much for your hard work .. i wish i had skills to contribute but i am still green at drupal -.-

agerson’s picture

+1 for support for this

TwoD’s picture

Assigned:Unassigned» TwoD

Will focus on this next.

swim’s picture

+1 This would be very nice.

picciuto’s picture

+1

safaruque’s picture

+1

TwoD’s picture

I've got the basic editor running now. Some of the changes between TinyMCE 3 and 4 are not mentioned in the upgrade tutorials so I'm digging through the code to figure out what has actually changed and what parts of Wysiwyg are still compatible.

I wanted to have a first patch ready today but I didn't want to risk having my main computer up during a thunderstorm. Already been burned by that once...

It's all going pretty well though, but I'm considering dropping support for TinyMCE 2 to simplify the branching logic. Any complaints against that?

mrP’s picture

@TwoD -- Thanks for the update

Re: TinyMCE 2 support -- the last release was in 2007 and the branch was closed long ago... I think its safe to remove support.

picciuto’s picture

agreed.

gunwald’s picture

+1

TDi’s picture

+1

Alan D.’s picture

Click the big green button (top right) called "Follow" rather than subscribing directly via comments.

This prevents unnecessary noise in the queues / emails :)

electricanimals’s picture

Following this post (as recommended by Alan D above), but just wandering if there's any update / ETA on integrating 4.0? Noticed 4.0 is official now and setting up some sites, thinking of holding back till 4.0 support gets added.

Thanks.

Rdaneel’s picture

Its up to 4.0.1 now.

TwoD’s picture

Sorry for the lack of updates, I've been quite busy with real life since my last post - renovating the house and getting a new puppy! =) That's not me saying there hasn't been any progress though.

While working on this I realized our current settings GUI pretty much sucks all through. While that in itself isn't much news, - just look through the issue queue for issues about sorting/grouping buttons and tweaking advanced settings - I found that much of the reason TinyMCE 4 support is taking so long to get done is because of TinyMCE 2. Not the old library itself, and not because we'd still have to support it (I didn't see any disagreement on that earlier in this issue), but because Wysiwyg originally only supported TinyMCE 2 and based the entire settings structure around it. All editor integrations currently start off with the original TinyMCE 2 settings form, including having the names of form elements based on the names of settings from a single old editor. Some integrations have begun chipping away at the form and putting in new widgets or altering the behavior of existing ones, to better suit the needs of that editor library.

The problem is keeping track of which GUI widgets actually control which editor settings, if they're even used[!], and how this has changed between editor versions. Getting back to TinyMCE 4; several old settings available in TinyMCE 2 & 3 have now been dropped either completely or replaced by different settings. To make sense of the new TinyMCE 4 integration I had to compensate for all these changes, which turned the code in the settings form callback into a huge mess with names of settings meaning different things in different versions.

Since I had already started working on cleaning up some of the settings in a different issue, see #1963766: Improve support for paste related options, I decided to get rid of much of this problem in one go. Basically, I'm moving all editor-specific settings out to the integration files to clean up the profile form and slim it down, letting the integration (and later plugins) supply only the form items needed for them. This should significantly reduce the complexity of the changes needed to add TinyMCE 4 support and transitioning from existing editor profiles created for TinyMCE 3. At the cost of putting together one big patch affecting every supported editor, most of which I have already done.

To make the TinyMCE 3->4 transition easier, I've also been thinking about storing the library version - as detected when the profile was saved - inside the editor profile, so I can use that to determine if the profile was created with the current version of the library installed, or perhaps with an older one. If an older library is detected, it could pass the profile through a small update/conversion callback designed to make the required changes (or bail out with a warning message telling the user to double-check the new editor version is working as expected). This should also, in the long run, help indicate to users which version(s) of an editor Wysiwyg module supports. If you currently create a profile and then remove the library, Wysiwyg doesn't know which widgets to display if they differ from version to version. When a version number is recorded in the profile itself we could then show the widgets from the "last installed" version and recommend reinstalling that (or a newer) version of the library. This part is all theoretical for now, and should really be in its own thread, but input is welcome.

As for an ETA, I suck at those... maybe once I get a patch up, which should be some time during next week (working this weekend, then vacation).

deggertsen’s picture

I vote that you start a new 3.x branch if that would make it any easier. Drop support for older editor versions and support only newer versions. I expect that most people aren't using multiple versions, and it's not like it's that difficult to uninstall Wysiwyg and reinstall and set it up (depending on how many profiles you have I guess). If I had a site setup with one version of an editor I wouldn't be too likely to upgrade, and if I did I would expect to have to reconfigure it anyways for the new editor version. There's my 2 cents.

Great work on this TwoD.

TwoD’s picture

Thanks for the input deggertsen. I'll have some more time to work on this later this week and I'll see if [re-]starting a 3.x branch will help keep things more clear.

TwoD’s picture

Here's finally a patch. Sorry for the delay.

Note that this issue now depends on #2018439: Move editor-specific options out of the default profile UI., but I have included that patch in this patch for now to make testing quicker.
That does make this patch huge, but I'm also attaching an interdiff between the patches for those interested in just the changes required to get TinyMCE 4 working.

I have not yet tried to deal with the content filter introduced in TinyMCE 4, similar to the Advanced Content Filter introduced in CKEditor 4.1. Do not try this in production You may experience data loss if the editor tries to load content not allowed by the filtering mechanism. You may also see problems similar to those encountered with CKEditor 4, as in the Media module inserting false instead of its normal media tags. This is to be expected for now and will be fixed before a Wysiwyg module release is made.

I just noticed only the interdiff contained a small change made to the YUI integration. But that is unimportant and will correct itself once the other patch has been committed.

TwoD’s picture

Status:Active» Needs review

I suppose people might want to start reviewing this. Feel free to focus either the large patch or the interdiff, but if you go with the large patch, please comment in #2018439: Move editor-specific options out of the default profile UI. unless the change is included in the interdiff too.

gregarios’s picture

As a side note, TinyMCE is now hosting their own scripts via a CDN.
Maybe with the new 4.x capability, support for this could be added too:

http://www.tinymce.com/wiki.php/Tutorial:Using_CDN

TwoD’s picture

Yes, I've thought about that, but Wysiwyg currently assumes there will be local files to serve, so adding that would make this patch even larger. Let's just focus on actually making it load the old fashioned way first.

fizk’s picture

Status:Needs review» Reviewed & tested by the community

#25 works for me with TinyMCE 4.0.2.

Marking RTBC, not sure if you'd like more people to test before marking RTBC.

fizk’s picture

Status:Reviewed & tested by the community» Needs work

Opps, I just noticed a PHP warning:

Notice: Undefined index: language in wysiwyg_tinymce_settings() (line 424 of /var/www/drupal-7.22/sites/all/modules/wysiwyg/editors/tinymce.inc).

greggmarshall’s picture

I hate to be asking this, but any plans to back port the patch to D6? I have an existing site that could really use the improved Paste from Word in TinyMCE 4.

TwoD’s picture

@greggmarshall, Yes, I'll backport as much as possible of the patch.

@fizk Thanks. It's a bit odd it could be unset since it's default is set to 'en' in wysiwyg.admin.inc, but I'll add an extra check for that.

PROMES’s picture

+1

rocketeerbkw’s picture

Status:Needs work» Needs review

Interdiff doesn't apply cleanly against #2018439: Move editor-specific options out of the default profile UI. but it looks like there's not a big diff. I tested the full patch in #25 here and it works, I didn't get any PHP warnings. Just a minor change I saw:

@@ -0,0 +1,234 @@
+ * @param editorSettings

Should be @param settings to match actual variable name

lahode’s picture

Thanks a lot TwoD, #25 works great.

It took me however a while to understand why IMCE was not working anymore with the new version of TinyMCE

If you get the following message when you click on the library to open IMCE : Uncaught TypeError: string is not a function, the you need to hack a little bit /js/tinymce/tinymce.min.js.

Just seek for the the following code :
r(t.getEl("inp").id,t.getEl("inp").value,e.filetype,window)
and replace by
window[r](t.getEl("inp").id,t.getEl("inp").value,e.filetype,window)

Cheers

rocketeerbkw’s picture

StatusFileSize
new26.07 KB

I rerolled #25 interdiff against HEAD with my change in #34 but I didn't test it... hopefully this evening.

rocketeerbkw’s picture

StatusFileSize
new31.16 KB
+++ b/editors/tinymce.inc
@@ -133,9 +148,10 @@ function wysiwyg_tinymce_themes($editor, $profile) {
     'theme_advanced_blockformats' => 'p,address,pre,h2,h3,h4,h5,h6,div',

@@ -146,11 +162,21 @@ function wysiwyg_tinymce_settings_form(&$form, &$form_state) {
     'theme_advanced_resizing' => TRUE,
...
     'theme_advanced_toolbar_align' => 'left',
     'theme_advanced_toolbar_location' => 'top',

as far as I can tell, all of these theme_advanced_* settings can't be used in tinymce 4, I moved them into version <4 section only.

I also fixed the link to the verify_html settings description page. I think that other settings like verify_html don't work in v4 but I'm out of time.

TwoD’s picture

Those settings still exists, they've just been renamed and no longer belong to the old advanced theme. I'm getting tired of trying to preserve backwards compatibility with old settings names so I'm going to try to implement some conversion hook for adapting old settings names to new ones. But that requires that we know which editor version was actually used when the profile was created. It also means we need to include a list of "supported versions" we can convert between. Maybe we can expose a hook for this for other modules too...

Also, I am no longer having any issues with the Media module and TinyMCE 4. It just works and I have no idea why...
I'm pretty sure I had to change some setting so the editor would not remove the placeholder...

IreneKraus’s picture

Speaking from my own viewpoint, I think you're going to have to terminate support for older editors at some point. Otherwise coding support is going to become a nightmare as well as contributing to 'bulk' thus affecting performance issues. I'm not sure if every editors' site provides statistics on active usage, but that could be one deciding factor (where present) on when to cut support. Would there be a polling function you could use to help too? Then again, you're never going to make everyone happy no matter what you do so take that as a given!

Within your project page you've already got a list of what editors you're supporting. Looking at the documentation page for that editor list, modifying that to indicate what versions are supported within specific branches of WYSIWYG shouldn't be hard:
https://drupal.org/node/596966

Then you can decide when and where to stop support within WYSIWYG, rolling things over into a new version branch as seems appropriate. (Let me also say I'm amazed at the number of editors you're trying to support with this one project!)

TwoD’s picture

Oh, yes, we do intend to leave older versions behind as we go (TinyMCE 2 support will be dropped as part of this patch).
The overhead will actually be very small since most API changes only affect the clientside integration code, and each version has its own file in editors/js/editorname-version.js. Changes affecting the serverside code, such as which buttons/plugins or settings are available, is mostly a concern for just the admin pages. If editors change a lot, we can make a new serverside integration too (FCKeditor vs CKEditor), but a few if-statements are usually enough.

What I'm intending for with what I previously mentioned is to at least have a 'last supported version' listed along with the installation instructions for each editor, and possibly a 'oldest supported version' (maybe not even shown to the user), so we can warn them odd things may happen. Actually converting the editor profiles automatically may prove too hard, but I'm still playing with the idea. We can obviously not make Wysiwyg convert a profile to an editor version newer than what existed when the currently installed version was released, but we could have the latest Wysiwyg version convert profiles created for an older editor version once it does support it. Anyway, I'm not really sure how to properly put this into words yet, so it probably sounds very confusing... It's also getting late here and I was just called in for overtime at work tomorrow so I'll need some sleep.

profmikebroyles’s picture

Any movement on this? Would be fantastic if we could use the the Tiny 4.x libraries

ownage’s picture

4.x has a more visually appealing skin and has some great new features. I would also love for WYSIWYG to support these new libraries!

Lemon-Corner’s picture

Yep Tiny 4.X, looks really great !! Any news about Wysiwyg support ?

bmango’s picture

Do I need to run the patch at #37 against the dev version of wysiwyg? I ran it against version 7-x.2.2 and got an error 5 out of 17 hunks failed (running cygwin on windows using the command patch -p1 < tinymce.patch). And tinymce 4 is still not being recognised.

Déja’s picture

@bmango Patch #37 works against the current git HEAD, which you can get via git (instructions: https://drupal.org/project/wysiwyg/git-instructions)

Btw, applied the patch and TinyMCE 4.x appears to be working beautifully. Many thanks!

bmango’s picture

@Déja Thanks for the tip. I had avoided Git so far but I guess now is as good time as ever to start using/learning it.

EDIT: Thanks again Déja. Using Git the patch applied cleanly (once I'd taken account of Windows' line endings).

cycas’s picture

I installed the patch in #37 onto the current dev version, and my Drupal install thinks I have TinyMCE installed, but I can't use it.

I got two errors:
1) unable to find /sites/all/libraries/tinymce/js/tinymce/tinymce.min.js (this was the original location of TinyMCE as provided from the download location, Wysiwyg was unable to find it there, so I renamed the file and directory. )

So, I put a copy of the same file with that name at that location, and that error disappeared (bit messy, but hey I thought it would do for testing).

But I still have two reports of:

2) Notice: Undefined index: language in wysiwyg_tinymce_settings() (line 428 of /sites/all/modules/wysiwyg/editors/tinymce.inc).

and no TinyMCE, in fact, no body form field appearing at all when the module is enabled.

I can see that Fizk reported a similar error earlier, but I'm not sure what is causing it. I didn't have the Locale module enabled when I installed, but I turned that on, and it's set to 'en'.

stopshinal’s picture

Version:7.x-2.x-dev» 7.x-2.2

I'm still having version detection issues - any ideas? Latest version of module as well as latest slug from tinymce

dazz’s picture

Same problem as @stopshinal

So the actual library can be found at:
sites/all/libraries/tinymce/tiny_mce.js
rocketeerbkw’s picture

Version:7.x-2.2» 7.x-2.x-dev
Status:Needs review» Needs work

TinyMCE 4 is not working yet. This issue is about adding it to the next version and it's still very much a work in progress.

rocketeerbkw’s picture

I've been going over the configuration at http://www.tinymce.com/wiki.php/Configuration but I can't seem to find a lot of settings that would be equivalent to the TinyMCE 3 settings. Specifically, it appears that the following aren't convertible to TinyMCE 4:

  • theme_advanced_toolbar_location
  • theme_advanced_toolbar_align
  • theme_advanced_statusbar_location
  • verify_html
  • preformatted
  • remove_linebreaks
  • apply_source_formatting
  • indenting

I noticed that there were some settings in the original patch from TwoD that I didn't find in the docs (like $default_settings['indenting'] = FALSE; and 'resize' => isset($config['resizing']) ? $config['resizing'] : 1,).

Where did you find these? Are more options documented in the code that I need to dig for?

Is feature parity with TinyMCE 3 required?

streever’s picture

Hi there--
It seems to me that the immediate & feasible fix for the problem of user confusion/frustration is to update the project page to say "tinymce VERSION x".

Currently, there is nothing warning people of the problem, and I expect that any non-programmer is going to be a bit confused.

I know you are busy, but I think it is important that you put in the version numbers that you know work. I've seen a lot of support requests, issues posted, and other frustration, and I think it is important that project pages be clear and informative.

I hope that I'm not coming off as ungrateful or insulting: I like this project and appreciate it. I just think it is important that one of the more popular non-core features be informative!

I'm not likely to have the knowledge to actually maintain the module in terms of coding, but I'd be happy to get access to put in version #s on the project page, if I could help with that. I can even test backwards from latest versions and verify how far back one needs to go.

goatvirus’s picture

curious where this is at right now?

FreeFox’s picture

Could some amount of money buy some time to have the 4.x implemented?

courtlandwood’s picture

I am so glad I found this discussion, I was banging my head on the table, following online video tutorials (outdated now I guess) on how to install a text editor, and the tutorial I was following was installing the tinymce, and I was getting nowhere, I'd go to refresh the configuration window and nothing would happen, so I guess it's because it just plain old doesn't work now, does anyone have any suggestions for a text editor in the mean time? Thank you all.

rv0’s picture

does anyone have any suggestions for a text editor in the mean time?

Why not just use the 3.x version?

goatvirus’s picture

re: #56... the 3.x version of TinyMCE is indeed the best overall WYSIWYG editor for Drupal, it's the one we have standardized on for our clients. that's just opinion i know but... i believe you are on the right track. 3.x works just fine. Those of us who need the added features of 4.x are just going to have to wait a bit longer i guess, until this module supports it.

the wysiwyg module should give pretty clear instructions on how/where to install TinyMCE 3.x and it works cleanly if you follow the instructions, trust me.

courtlandwood’s picture

rv0 and goatvirus, I am going to load up version 3.x and see if I can get it working. Thank you for the feedback, both. I'll check back here and state my progress. Thanks!

courtlandwood’s picture

Ok, I removed the 4.x version and uploaded the 3.x version and it is working now, and I am completely excited, thank you guys for your help.
Now that aside, I had attempted the 3.x version before, and it did not work either. Actually, nothing was going to work if I had not discovered that I needed to go one more step and take the tinymce folder out of the tinymce main folder after extracting it. I was loading the main folder into my /libraries folder, so Drupal was not going to pull the tinymce editor from my file structure no matter what.
So I went back and tried to load in the 4.x version after my major discovery and enlightenment, and the 4 did not work period. I then re-loaded up the 3.x and it worked.
I love it, and now I can start to create content!
Now I am on the search for an easy image uploader that I can use within tinymce. I would like the users to be able to load up images by browsing their PC, instead of by url. Thansk again folks.

IreneKraus’s picture

courtlandwood, If the video tutorial you were talking about is the one I did for Packt Publishing earlier this year:
http://www.packtpub.com/building-a-website-with-drupal/video
Yes, the intent was to use the v3 branch of TinyMCE. v4 of TinyMCE was released after those recordings were finished. I'll have to check with Packt to see if they will let me post an addendum or something of that sort over there in regard to TinyMCE and WYSIWYG. Then again, that is typical of the Drupal World!

As to an image management tool, why not check out IMCE that integrates very nicely into TinyMCE via its bridge?
https://drupal.org/project/imce
https://drupal.org/project/imce_wysiwyg

courtlandwood’s picture

Hello Irene, the video I saw and it was done quite well was this video at http://www.youtube.com/watch?v=Hq5NwrIUVrg
Actually the video was fine, it covered it thoroughly, I think the problems were mainly on my end, not understanding the importance of going that extra step to take the tinymce folder out of the tinymce-3.5-10 folder. My ignorance! Thanks guys.
On the other hand thanks Irene for the link to your videos! Those are very compelling! I'll have to mull over the purchase of you video, it is a very reasonable price. Is it basically up to date?

IreneKraus’s picture

courtlandwood, it was at the time everything was recorded. Some of the modules featured have had revisions, come out of beta/release candidate status, etc.; but then that is the way of things. I wasn't able to cover as many as I had planned in my first draft (ran over 4 hours!). My contact at Packt & I had to agree on what was essential for a 'getting started' course in using Drupal (which is what the project was intended to be). For example, I know I made a point of setting up the Text Formats inside Drupal first, then the WYSIWYG profile to match. THAT was one of those things that really confused me when I was getting started.

cuntryperson’s picture

Just wondering when the Wysiwyg module will support tinyMCE 4.x. We're trying to develop a plugin here for tinyMCE 4.x.

smegnal’s picture

I am surprised more people don't just put the quick link into the head. I always used to install Tinymce but I have not seen any reason to since they started using the CDN. I am pretty new to Drupal and one of the first things I did was place:

<script src="//tinymce.cachefly.net/4.0/tinymce.min.js"></script>
<script>
        tinymce.init({selector:'textarea'});
</script>

...in the head of the html.tpl.php document and that was it. I just hard coded that in so it may get wiped in an update or something. I could do with trying to code it into the $scripts list but I have not got that far yet :)

goatvirus’s picture

re #64 ... well, i was always convinced that the wysiwyg module did some advanced magic that enabled Drupal to use the different editors in the correct manner (including knowing when to launch an editor instance).

what you are saying looks great... and suspiciously simple ;-)

without me having to go through all the code in the module and decipher it, i wonder if the module maintainers could tell us what limitations that approach in #64 has, and why the wysiwyg module is so important. not saying it isn't (i have used it on every Drupal site i have built, which is many), i just realize now that (other than providing a handy interface for configuring editor plugins and css) i am not actually sure what else it does, that is crucial to running wysiwyg editors... if you can just figure out how to include the js yourself as smegnal has done in #64

rocketeerbkw’s picture

#64 is certainly one way to do it.

Here's a tiny list of what you won't get if you go that route:

  • Separate WYSIWYG configs per text format
  • Separate WYSIWYG editors per text format
  • Pick which buttons appear in GUI
  • Need only admins to have WYSIWYG? sorry
  • Integration with media module and/or imce

I could go on and on. Without a Drupal integration module (like WYSIWYG), you're on your own to install, setup and configure TinyMCE (and others).

dehacker’s picture

As we enter 2014, we await a version of WYSIWYG that supports TinyMCE4 and Media for our Open Atrium 2 distribution. From the end users perspective this is a most significant content editing enhancement.

Bob Newby’s picture

Totally agree with comment #67. The same goes for my LuthierBuilt.net site.

goatvirus’s picture

re: #66 ... thanks, i knew there had to be a bunch of magic going on there, now i realize what's involved ;-)

Conlele’s picture

Issue summary:View changes
bmango’s picture

Is there a patch that will work for 6.x to get tinymce 4 recognised?

maki3000’s picture

+1

rocketeerbkw’s picture

There is still no progress on this AFAIK. I'm still hoping to get feedback on my #51 and maybe I can get more work finished on this issue.

dpearceMN’s picture

Just in case anyone was interested, I just tried tinymce_4.0.14.zip and WYSIWYG 7.x-2.2+24-dev dated 2014-01-21 and TinyMCE is still not recognized.

Where do we stand TwoD? How can we help?

DamienMcKenna’s picture

@dpearceMN: Please note that each issue has a "status" that indicates the progress being made on that issue. The status of this issue is "needs work", which means that the patches provided (above) to resolve this issue have not been committed and need further work. As a result, you should not expect to be able to download the WYSIWYG module and have TinyMCE 4 work with it.

To help, please read through the comments above and see what needs to be done to make the patch (from #37 above) work correctly, then upload a new patch and see if it works for others. Only when several people say that a patch works for them can the ticket status be changed to "Reviewed and Tested By the Community", i.e. "RTBC", and (probably) only then will the maintainers commit the patch so that the subsequent release (and dev builds) will include the fix.

In short, if the issue status is "needs work" then the problem isn't fixed yet :)

metzlerd’s picture

Whereas I agree the status of the issue is clear... its also clear form comments in #38 that TwoD was doing some pretty heavy refactoring. Unless he has stopped work on this it would seem to be counter productive to submit competing patches. I would echo the call to see if TwoD, who clearly has the ball on this one can recommend where we can help. He is after all the current one assigned to the issue. If he has abandoned it perhaps he could unassign from the issue?

As a module maintainer myself, I don't start submitting competing patches with a maintainer lightly, particularly when he has already started thinking about how he'd like the patch to look.

@TwoD If you have a strategy in mind and need some code monkeys out there know that there are some who are willing to help.

It seems to me like this has gotten stuck in a "we've got to refactor the code and don't have time" loop. Which I've been in several times a maintainer ;).

TwoD’s picture

I have not stopped working on this, but other things (outside of Drupal) had to take priority for a while. I'm now getting back to picking things off the top of the issue queue. I don't want to delay issues with recent activity in favor of those which have already been dormant for a while, especially if the new issues are relatively quick to resolve, or I can quickly determine they're related to a previous issue, or if I simply don't have enough info and have to hand them back to the community so they/you can work in parallel with me getting back to issues further down the queue.

Now, since this issue has recently been bumped up and contains enough useful info for me to push it closer to a commit, it is a very good canditate for me to invest time in. Of course, the very nature of this issue makes it very important for Wysiwyg module, but that also means I may need more input from others, to make sure we're going down the right path and not forgetting something really important.

And yes, metzlerd, that does tend to happen. ;)

To get back on actually do that pushing forward: I'm currently at work and will have limited free time this weekend, but I have already written code for some of the things I mentioned after the last patch, so I'll post that when I get home and write a new summary of what's left.

I do believe I can port the old settings names to TinyMCE 4, but the code may look a bit confusing. For a _future_ patch, I'll draft out that editor-profile-upgrade-callback-for-new-editor-releases-stuff, because I need to commit an actual patch which keeps track of the installed editor version in the profile first. There's an issue for that part, so I'm dropping focusing on that in here.

Also for a _future_ patch: support for detecting which plugins were actually bundled with the editor. In other word; more flexible editor "variant" detection. May need to cache that data, which is a whole topic on its own. Why mention that here? See earlier notes on the new TinyMCE 4 (and CKEditor 4) packaging processes.

Thus: The patch here - once committed - will require you to download a specific package of TinyMCE 4, much like for CKEditor 4, at least if you want everything that worked with Wysiwyg and TinyMCE/CKEditor 3 to be available. Future patches, maybe after a release, will aim to let you be more flexible about which editor package you download.

fizk’s picture

Thanks for your time TwoD, we all appreciate it!

TwoD’s picture

StatusFileSize
new37.1 KB

Here's a new iteration with what I think covers all the removals of settings - compared to TinyMCE 3 - mentioned earlier.

I don't know where I got that "indenting" setting from, maybe I confused things or misread the code.
verify_html should still work though.

I got home a lot later from work than I had planned, so I didn't have time to incorporate all changes, but the editor should at least load.

fizk’s picture

Nice work! It works very well for me.

Just some minor notes:

- when setting the "Interface language" on admin/config/content/wysiwyg/profile/filtered_html/edit to a language that doesn't have its language .js file installed, the editor doesn't appear. I'd recommend adding an error message on the profile edit page preventing the user from changing to a language that doesn't have its .js language file already installed.

- add a section to the profile edit page to allow customization of the TinyMCE Format menu, or automatically sync it with the buttons selected. For eg. if the only button selected is bold, then the Format menu should only show bold.

TwoD’s picture

@fizk, thanks for testing!

The language thing is a known issue. TinyMCE has always crashed if you picked a language which either the editor or any one if its plugins did not have a translation file for. I'll eventually get to fixing that...

The Format menu is independent of the buttons. Even if you don't have a button enabled, you can always apply one of the predefined formats. This is a feature of TinyMCE, which could be useful if you want to limit the editor to a very narrow set of style changes.

bunnicula’s picture

Perhaps you should mention on the module download page that tinymce 4 is not yet supported in the recommended release? That would save a lot of folks the trouble of finding this thread.

goose2000’s picture

I guess this is not in the dev version yet 8(

TwoD’s picture

@goose2000, no it's not. I'm trying to work out how settings names changed between 3.x and 4.x and how to move as much of any existing 3.x configuration to 4.x - to avoid everyone having to make a completely new profile for 4.x.

Any help mapping that out would be appreciated.

GiorgosK’s picture

#79 works great
but shouldn't there be a setting for
PASTE CLEANUP from WORD documents ?
or is that editor specific ?

goatvirus’s picture

I assume that #79 is for the 7.x version of wysiwyg module? is there an equivalent patch for 6.x, ready for testing? or do 6.x users have to wait until the actual module release.

not trying to pressure you, i am just checking to get an idea of what the timeframe is before we can run TinyMCE 4 on Drupal 6.x ... and if there's anything i can do to help with testing.

TwoD’s picture

Issue summary:View changes

@GiorgosK, Pretty much all settings are editor-specific. The only one I could find for TinyMCE 4 related to Word was paste_word_valid_elements. Since this is part of the Paste plugin, and there's already an issue for improving this type of settings for all editors, I'm going to roll that into #1963766: Improve support for paste related options if possible. This patch would have to land first though so that patch can be rerolled. I'm currently juggling several patches with direct or indirect dependencies on each other. There are a lot of things I would like to improve to make dealing with newer editor versions a lot easier, some requiring substantial changes to how Wysiwyg treats the editor libraries, which is part of why I've been quite cautious about committing support for the newer editor versions.

@goatvirus, The #79 patch should apply to 6.x-2.x with minimal changes (if any), since these versions are very similar.

I've updated the summary description with some notes on where we are.

goatvirus’s picture

@TwoD, re: #87 Well... based on what I know of patches, it probably won't be applicable automatically with a patch program unless 6.x-2x was line-for-line IDENTICAL to the 7.x version, in all the places shown... which I'm sure it isn't :-)

but we have a client who really needs this issue fixed, so I am willing to give it a shot, probably within the next week (possibly even today), and I will of course let y'all know how it goes. I have never created a patch file myself but I'm sure I can figure out what would need to be different in the file from #79, and can post it here for someone to roll properly.

thanks for all your hard work on this TwoD, a large percentage of the Drupal world waits with baited breath ! I mean seriously, who DOESN'T have a wysiwyg editor on their Drupal site, right? :-)

I am curious what the usage stats really are but I am guessing TinyMCE is one of the leading editors, our extensive testing certainly determined it to be a "best of breed" at this time.

TwoD’s picture

@goatvirus, Actually, git's pretty good at working out how to apply patches to similar branches if you let it fall back to a 3-way merge:
curl "https://drupal.org/files/issues/wysiwyg-tinymce4.1968318.79.patch" | git apply --3way
The regular patch -p1 filename.patch works pretty well too.

I do not have any statistics about editor usage (Wysiwyg doesn't collect anything), but judging by the activity here it's indeed all about CKEditor and TinyMCE. Perhaps a bit more about CKEditor since it got into D8 Core.

dags’s picture

Just applied the patch in #79 with patch -p1 and all is good. But the IMCE browser still wasn't working with TinyMCE due to a JavaScript error: "TypeError: string is not a function" lahode's suggestion in #35 works but it requires hacking tinymce.min.js directly. Is there a better solution? The discussion here on tinymce.com makes me wonder if the module isn't scoping/initializing TinyMCE correctly?

TwoD’s picture

IMCE itself works, but IMCE Wysiwyg Bridge module does not work with TinyMCE 4 because TinyMCE 3 allowed the file_browser_callback setting to be a string (the name of a global callback function), while TinyMCE 4 requires it to be an actual function reference. Delivering a function reference from the server over JSON directly is not possible because JavaScript function references can't be created or serialized from PHP.

I'm testing a workaround for that which will preprocess the settings object in JavaScript and convert placeholder objects into real function references for callbacks, but it may require imce_wysiwyg module to be patched to support TinyMCE 4, unless I add some special treatment for that setting. It will become useful for other plugin integration modules, or custom site-specific modules, which would like to set JavaScript callbacks from the server side.

TerrorKiwi’s picture

I've used the git instructions, and applied the patch #79 after that, but when I put tinymce in the libraries folder: sites/all/libraries/tinymce/tinymce.min.js it gives me the error that the version of TinyMCE could not be detected. How am I supposed to fix that?

TwoD’s picture

@TerrorKiwi, that's the wrong folder. Just unzip the TinyMCE package directly under sites/all/libraries, don't move any files around after that.
Then you should end up with tinymce.min.js at sites/all/libraries/tinymce/js/tinymce/tinymce.min.js.

TerrorKiwi’s picture

Thanks, that worked for me. Is there already a way to install plugins to TinyMCE 4 with this module?

TwoD’s picture

Additional plugin metadata is handled the same way as before, by implementing hook_wysiwyg_plugin() in a tiny module.

goatvirus’s picture

hi people, sorry, just remembered that i didn't report in!

i managed to apply the patch from #79 to the 6.x-2.x-dev version (from 2014-Feb-18 ) with minimal changes, yay!

and at first glance it seemed to work! at least, it loaded without error messages ;-)

however, two immediate problems:

1) The layout is substantially different than 3.x (buttons are larger and in some places seem to be menu items instead of buttons) and the toolbar is being cut off on the right hand edge, rather than wrapping around to another line of toolbar, the way it used to.

2) The integration with the IMCE file uploader/manager doesn't seem to be working either, the "insert image" function doesn't show the icon to launch the IMCE window.

TwoD’s picture

StatusFileSize
new49.15 KB
new17.34 KB

@goatvirus, Thanks for the update!
1) Should be possible to work around with the "Use default toolbar grouping" checkbox under the appearance settings for now.
2) See #91.

I've just committed the callbacks [and Regular Expressions] workaround I mentioned earlier to all of 7.x-2.x, 6.x-2.x, and 5.x-2.x, so the -dev snapshots should be updated within 12hrs.

I've rerolled the patch, based on the upcoming -dev snapshot, so it now converts the callback name from a string to a Function reference for TinyMCE 4, which will maintain backwards compatibility with TinyMCE 3.
If IMCE Wysiwyg bridge is updated to use the new wysiwyg_wrap_js_callback() function for passing JS Function references in the JSON settings structure this will still work, but they would break backwards compatibility with TinyMCE 4 (unless they return different values for the file_browser_callback setting based on the $version parameter sent to hook_wysiwyg_plugin(), of course).

This version of the patch should also work better with existing TinyMCE 3 profiles.
The previous patch did not account for some buttons being moved to other plugins unless the profile was saved and now it's better at doing this when an old profile is used with the new editor. Those buttons/plugins will still be unchecked when editing an old profile though because Wysiwyg does not yet perform the same conversions there. This would be so much easier to do reliably if we had only stored the editor version number in the profile...

So, update to the latest -dev snapshots before applying the patch. (The interdiff is probably only useful for seeing what changed in the patch and not for an actual upgrade since it doesn't contain the changes made to the -dev snapshots, sorry.)

mgifford’s picture

@TwoD What testing do you want done on the patch in #97?

TwoD’s picture

I've gotten quite a lot further with this since my last post and I'll soon post a new patch really soon which I think covers pretty much everything we can do for TinyMCE 4 for now.

One major problem crept up though... The toolbar in TinyMCE 3 only "worked" because we applied some hacky style overrides, which still conflicted with a couple of custom themes out there. The editor behaves very well under Wysiwyg now, but if you want all buttons enabled you need two screens side by side just to make the toolbar fit.

Since this has taken so long, and a little bit more time won't hurt if it makes UX infinitely better, messing it up in the last minute with another CSS hack wasn't worth it. I don't want to maintain a mess like that again.

Therefore I've got an ace up my sleeve which I'll reveal at the same time as the improved TinyMCE 4 patch. The editor is pretty much unusable without it, and all that's left before I can create the patch is to merge a couple of my local branches.

mgifford’s picture

Great to hear that there is progress and indeed known (and unknown) improvements to come! Thanks...

rootwork’s picture

Yes, that's great news!

Please let us know if we can test/review patches, or anything else to help.

goatvirus’s picture

I am excited to test your patch when it's ready, @TwoD ! :-)

fugazi’s picture

this is wonderful, thank you for your indispensable work. I am happy to test me

johntang’s picture

Great, it should be on next Wysiwyg update?

DamienMcKenna’s picture

Status:Needs work» Needs review

@johntang: No, TwoD said in comment #99 that he was still working on a fixed patch.

sillo’s picture

i dont get it ... why wouldnt you just release it with a WYSIWYG module update instead of patching everything?
For ppl who cant drush on their server, patching is a really big process.. so is there any good answer to why it doesnt get released with an update? :/

sillo’s picture

i dont get it ... why wouldnt you just release it with a WYSIWYG module update instead of patching everything?
For ppl who cant drush on their server, patching is a really big process.. so is there any good answer to why it doesnt get released with an update? :/

TwoD’s picture

@sillo, "Updating the module" means creating a patch which applies to the development branch, tagging a commit on that branch, and finally create a new release based on that tag, so we need a patch to make an updated Wysiwyg module release.

I know patching is tedious on shared hosts etc, I have that same issue on some projects, but there's not really much I can do about it.

It's still at the "only a patch" stage because it doesn't fully work yet. Do you want me to create a new release while knowing it will break existing TinyMCE profiles as soon as users install a TinyMCE 4 library? Even if you create a new profile, the toolbar looks terrible and several buttons will be unusable because they don't fit.

I just got home from a night shift so I need some sleep, but after that I'll start posting patches which make Wysiwyg better at transitioning between editor versions, dealing with settings and the toolbar, and then we can finally rebase this TinyMCE 4 patch on top of that. Once that's in 7.x-2.x, any backports needed to bring 6.x-2.x up to the same level of compatibility will be taken care of so that both 7.x-2.3 and 6.x-2.5 can be released at the same time (or upgrades between D6 and D7 won't be possible).

goatvirus’s picture

well... i am sad that we have to wait longer, but GLAD that you are doing this the "right" way, with stability and rigorous testing a priority! thanks @TwoD !

mglaman’s picture

StatusFileSize
new48.98 KB

Here is re-roll of #97 against latest dev.

mglaman’s picture

StatusFileSize
new49.02 KB

Updated patch, is_string($settings['file_browser_callback']) throwing notice since it may not always be set. Adding isset() check.

I used this patch to test on Panopoly 1.6. Can verify it worked find with existing TinyMCE 3 profile, except.

I think the above can be expected since WYSIWYG has not yet supported TinyMCE 4.

ocastle’s picture

Patch #111 works for me on WYSIWYG Dev Release.

ofry’s picture

Thanks for patch #111.

goose2000’s picture

Hi, uh I do believe I got the patch (#111) to apply okay, had to make some odd /a /b directories to make things happy. Dumb question probably, do I download the regular package or the JQuery package? Or does not matter? I have it installed now but it doesn't display the UI.

C:\patchstuff\wysiwyg>patch -p0 -b --verbose --binary -i support_for_tinymce_4.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/editors/js/tinymce-2.js b/editors/js/tinymce-2.js
|deleted file mode 100644
|index 61a60ad..0000000
|--- a/editors/js/tinymce-2.js
|+++ /dev/null
--------------------------
Patching file a/editors/js/tinymce-2.js using Plan A...
Hunk #1 succeeded at 1.
Removing file a/editors/js/tinymce-2.js
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/editors/js/tinymce-4.js b/editors/js/tinymce-4.js
|new file mode 100644
|index 0000000..59b2510
|--- /dev/null
|+++ b/editors/js/tinymce-4.js
--------------------------
Patching file b/editors/js/tinymce-4.js using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/editors/tinymce.inc b/editors/tinymce.inc
|index 81bc2b6..5a14693 100644
|--- a/editors/tinymce.inc
|+++ b/editors/tinymce.inc
--------------------------
Patching file a/editors/tinymce.inc using Plan A...
Hunk #1 succeeded at 15.
Hunk #2 succeeded at 41.
Hunk #3 succeeded at 63.
Hunk #4 succeeded at 93.
Hunk #5 succeeded at 104.
Hunk #6 succeeded at 137.
Hunk #7 succeeded at 151.
Hunk #8 succeeded at 191.
Hunk #9 succeeded at 200.
Hunk #10 succeeded at 316.
Hunk #11 succeeded at 372.
Hunk #12 succeeded at 406.
Hunk #13 succeeded at 429.
Hunk #14 succeeded at 453.
Hunk #15 succeeded at 466.
Hunk #16 succeeded at 518.
Hunk #17 succeeded at 536.
Hunk #18 succeeded at 578.
Hunk #19 succeeded at 628.
Hunk #20 succeeded at 946.
done
ofry’s picture

I downloaded development package :) All working.

goatvirus’s picture

Question: if this patch #111 works, what is the likelihood that a backport to the Drupal 6.x wysiwyg module will be happening anytime soon? Like, within the next six months? :-)

KoshaK’s picture

within 6 month you can upgrade to Drupal 7 ;o))))

goatvirus’s picture

re: #117... LOL yes i know that, but for various reasons there are sites i administer that might have to stay on D6 a while longer... but you are totally correct about that ;-)

ofry’s picture

But why this patch drops support TinyMCE 2?

TwoD’s picture

It will drop support for TinyMCE 2 because it's a very old editor, it is no longer developed, and you can't even find it under "Older releases" on the TinyMCE website. Supporting this old editor version also means that Wysiwyg module has to contain lots of version checks and metadata about an editor which has had two major version come after it, both having API changes and different plugins/buttons/settings.

Lastly, I'm the only active maintainer for this module and I can't afford to spend time testing so old versions with all the newer changes. Testing TinyMCE 2 also means the current browser versions I'm able to use were released long after TinyMCE 2 was updated, increasing the risk of encountering browser-specific bugs I can't do anything about.

goose2000’s picture

Does the dev version now include this work? I got the patch to work but editor would not display in Drupal. I was using the latest 4.1.6 of TinyMCE. Or is this for an older 4.x version ? The top post mentions TinyMCE 4.0b1.

TwoD’s picture

No, it's not in yet. When applying the patch and enabling a lot of buttons there's a problem with the toolbar going off screen because they're all in one group, and a few other issues related to "upgrading" existing editor profiles.

ofry’s picture

StatusFileSize
new45.1 KB

I rerolled patch #111.

ofry’s picture

StatusFileSize
new45.49 KB

Fixed my mistake.

ofry’s picture

StatusFileSize
new48.84 KB

Oh, sorry. Fixed another my mistake :)

schpinn’s picture

I found a bug in combination with the Media module (specifically Media_WYSIWYG), don't know if it's a problem with this patch, or the Media/Media_WYSIWYG module. You cannot add a link to an image inserted with the media browser - it overwrites the image with just the link (instead of wrapping the <img> tag with an <a> tag, it overwrites the <img> tag). If you then try to select the newly inserted linked text and insert an image there, the image completely replaces the link.

deggertsen’s picture

@schpinn, perhaps related to #1283844: [meta] Improve WYSIWYG integration

schpinn’s picture

@deggertsen, thanks for the link, but it doesn't seem to be related (unless I misunderstood something). I have no problems with inserting media (in my case only images), only when trying to add a link to any of the inserted images via the media browser.

I also tried doing the same with TinyMCE 3 and the latest version of CKEditor and had no problems, I was able to add a link to an image inserted with the media browser with no issues.

EDIT: so I'm guessing the problem has to be in this patch.

mikeohara’s picture

I am having a problem where i will not save button settings on saving the profile on the latest dev with the patch above. Anyone else have this issue?

It pretends to save, but when I go and add new content, it shows the basic button config, when I go back to the settings it has reverted everything to "just installed" state.

danielflippance’s picture

I'm experiencing problems installing the patches #111 and #125 for Wysiwyg 7.x-2.2 on Drupal 7.34. Are these patches valid for this scenario? I experience 2 problems - first, patch can't find the tinymce.inc file although it finds it when I type in exactly the same path. Secondly I get 7 hunk failures. In the first failure, Wysiwyg contains the line

can't find file to patch at input line 454
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/editors/tinymce.inc b/editors/tinymce.inc
|index 3316aa2..b5d9154 100644
|--- a/editors/tinymce.inc
|+++ b/editors/tinymce.inc
--------------------------
File to patch: ./editors/tinymce.inc
patching file ./editors/tinymce.inc
Hunk #1 FAILED at 15.
Hunk #2 succeeded at 40 (offset -1 lines).
Hunk #3 succeeded at 62 (offset -1 lines).
Hunk #4 succeeded at 92 (offset -1 lines).
Hunk #5 succeeded at 103 (offset -1 lines).
Hunk #6 succeeded at 136 (offset -1 lines).
Hunk #7 FAILED at 151.
Hunk #8 FAILED at 209.
Hunk #9 FAILED at 226.
Hunk #10 FAILED at 273.
Hunk #11 succeeded at 145 (offset -147 lines).
Hunk #12 succeeded at 179 (offset -147 lines).
Hunk #13 succeeded at 202 (offset -147 lines).
Hunk #14 FAILED at 373.
Hunk #15 FAILED at 383.
Hunk #16 succeeded at 276 (offset -143 lines).
Hunk #17 succeeded at 294 (offset -143 lines).
Hunk #18 succeeded at 336 (offset -143 lines).
Hunk #19 succeeded at 389 (offset -140 lines).
Hunk #20 succeeded at 707 (offset -140 lines).
7 out of 20 hunks FAILED -- saving rejects to file ./editors/tinymce.inc.rej

In the first failure tinymce.inc in Drupal looks like:
'vendor url' => 'http://tinymce.moxiecode.com',

But the patch is expecting it to look like:
'vendor url' => 'http://www.tinymce.com',

This leads me to think that these patches don't support the version(s) I'm using. Anyone know?
Merry Christmas

DamienMcKenna’s picture

@danielflippance: You should use the -dev release of WYSIWYG.

Morasta’s picture

@danielflippance (#130): I had the same problem when I downloaded the dev branch and tried patch < file.patch to apply it. Worked when I checked out the 2.x branch with git and used git apply -v path/file.patch

mglaman’s picture

Morasta, you need to do patch -p1 < file.patch, that's probably why git apply -v file.patch worked but other did not.

danielflippance’s picture

Thanks @DamienMcKenna, @Morasta and @mglaman, your posts helped fixed the problem I had.

mgifford’s picture

The latest stable release is from October of 2012. When modules don't use our release infrastructure it is a security problem. #2343445: Stable release of Wysiwyg module, please

We really need these patches to be RTBC'd and brought into a stable 2015 release.

Sophie.SK’s picture

The patch in #125 works perfectly for me - it applied cleanly to latest dev although I then had to go back and manually apply it to our several-times-altered copy of the module :)

dags’s picture

Status:Needs review» Needs work

Applied patch to latest dev, using TinyMCE 4.1.7: Wysiwyg fails to load in UI due to JS errors:

Uncaught ReferenceError: tinymce is not defined
Uncaught TypeError: Cannot read property 'editor' of undefined

Lines of code throwing the errors are, respectively:

Drupal.wysiwyg.editor.init.tinymce = function(settings) {
    tinymce.on('active focus', function(e) {
      Drupal.wysiwyg.activeId = e.editor.id;
    });
Drupal.wysiwygAttach = function(context, params) {
  if (typeof Drupal.wysiwyg.editor.attach[params.editor] == 'function') {

Did I miss something in the patching process or is stuff just broken?

ling-drupal’s picture

Hi, with tinyMCE 4.1.9, When I tried to add style formats under css tab in wysiwyg profile, i followed instruction http://www.tinymce.com/wiki.php/Configuration:style_formats, and I placed code like below in style formats, but i got error: "The specified style formats are syntactically incorrect." it didn't add classes in formats drop down list.

style_formats: [
{
title: 'Image Left',
selector: 'img',
styles: {
'float': 'left',
'margin': '0 10px 0 10px'
}
},
{
title: 'Image Right',
selector: 'img',
styles: {
'float': 'right',
'margin': '0 0 10px 10px'
}
}
]

in version 3.4.2, i only just need to placed code like Red color = red in css classes, and it will add those classes under styles drop down list.
Can anyone help me out this issue;
thanks lots!
Ling

wolffereast’s picture

@ling-drupal you dont have valid JSON, you need to remove the style_formats: and enclose all of your strings in double quotes:

[
{
"title": "Image Left",
"selector": "img",
"styles": {
"float": "left",
"margin": "0 10px 0 10px"
}
},
{
"title": "Image Right",
"selector": "img",
"styles": {
"float": "right",
"margin": "0 0 10px 10px"
}
}
]

I used http://jsonformatter.curiousconcept.com/ to validate my formats when I was constructing mine.

ling-drupal’s picture

thanks wolffereast. it works.
Ling