I use Bower to install/keep track of my libraries, and for whatever reason, the Bower version of TinyMCE 4 installs without the '/js/tinymce' path structure. I'm going to attach a patch to account for this.

CommentFileSizeAuthor
#2 wysiwyg_tinymce4_bower-2852729-1.patch1022 bytesAmbient.Impact
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Ambient.Impact created an issue. See original summary.

Ambient.Impact’s picture

Ambient.Impact
they/them
Primary language English
Location Toronto
CreditAttribution: Ambient.Impact as a volunteer commented
Status: Active » Needs review
FileSize
wysiwyg_tinymce4_bower-2852729-1.patch1022 bytes
Ambient.Impact’s picture

Ambient.Impact
they/them
Primary language English
Location Toronto
CreditAttribution: Ambient.Impact as a volunteer commented
Issue summary: View changes
TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD as a volunteer commented

What does your Bower file look like?

Ambient.Impact’s picture

Ambient.Impact
they/them
Primary language English
Location Toronto
CreditAttribution: Ambient.Impact as a volunteer commented

Thanks for getting back to me.

This is my bower.json:

{
	"name": "Ambient.Impact",
	"dependencies": {
		"underscore": "1.8.3",
		"backbone": "1.2.0",

		"tinymce": "4.5.1",
		"geshi": "https://github.com/easybook/geshi.git#v1.0.8.18"
	}
}

This file sits just outside of the Drupal root directory. I also have a .bowerrc alongside it with these contents:

{
	"directory": "drupal/sites/all/libraries/"
}
TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD as a volunteer commented

I've tested a couple of package managers and it seems most of them, if not all, leave out the 'js' folder but some (like composer) will still have a nested 'tinymce' folder. (I only tried installing it into the default 'vendor' folder though so that may be possible to adjust.)

Your patch unfortunately breaks paths to plugins and themes when not using a package manager as they're all relative to 'library path'.

You can implement hook_wysiwyg_editor_alter(&$editors) to change the library definition to work around this in your installations.

Ambient.Impact’s picture

Ambient.Impact
they/them
Primary language English
Location Toronto
CreditAttribution: Ambient.Impact as a volunteer commented

Thanks for pointing me in the right direction, I'll do that.

Ambient.Impact’s picture

Ambient.Impact
they/them
Primary language English
Location Toronto
CreditAttribution: Ambient.Impact as a volunteer commented
Version: 7.x-2.x-dev » 7.x-2.4

HI there. I finally got around to trying your advice, but it didn't seem to stick, which made me fall back to relying on patching the module. First off, I modified the TinyMCE info via hook_wysiwyg_editor_alter(). I updated the library path and also added my own version callback since the one you have hard codes the '/js/tinymce' path. :( That all worked, in that the info was correct and updated, but for whatever reason the module wasn't reflecting my changes, despite clearing the cache and all. Yes, I did check that the function was running, using dpm() to check that I had changed the info correctly, and &$editors was indeed a reference (I hadn't forgotten the ampersand), but no luck. Let me know if this is something you'd be able to look into. Thanks.

dkh’s picture

dkh CreditAttribution: dkh at NREL commented

I tested this patch and it works great with asset-packagist.

"require": {
"bower-asset/tinymce": "4.5.7",
}

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD as a volunteer commented
Status: Needs review » Needs work

Hmm, I should have left this as "Needs work" due to #6.

@dhk, does asset-packagist keep the same folder structure as the normal TinyMCE releases do?
I've had issues with some packages there being severely bloated and holding the source, release builds, minified release builds, and zips of both release builds so I've seen it as too much of an overhead compared to simply manually downloading and committing in the libs to git directly. You don't get automated updates that way, but there's also no risk of deploying all the bloat (example scripts allowing insecure file uploads, anyone?).