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

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

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!!

Title:Support for TinyMCE 4.xSupport 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.

Title:Support for CKeditor 4.xSupport 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.

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 ..

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.

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

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

+1 for support for this

Assigned:Unassigned» TwoD

Will focus on this next.

+1 This would be very nice.

+1

+1

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?

@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.

agreed.

+1

+1

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

This prevents unnecessary noise in the queues / emails :)

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.

Its up to 4.0.1 now.

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).

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.

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.

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.

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.

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

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.

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.

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).

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.

@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.

+1

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

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

StatusFileSize
new26.07 KB

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

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.

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...

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!)

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.

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

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!

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

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.

@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!

@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).

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'.

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

Same problem as @stopshinal

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

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.

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?

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.

curious where this is at right now?

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

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.

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

Why not just use the 3.x version?

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.

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!

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.

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

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?

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.

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

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 :)

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

#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).

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.

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

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

Issue summary:View changes

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

+1

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.

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?

@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 :)

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 ;).

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.

Thanks for your time TwoD, we all appreciate it!

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.

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.

@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.

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.

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

@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.

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

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.

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.

@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.

@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.

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?

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.

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?

@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.

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

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

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.

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.)