Why does document.execCommand('undo') not work in TinyMCE? - tinymce

I am working on a chrome extension that lets users pre-configure action sequences.
I noticed that document.execCommand('undo') doesn't work in TinyMCE.
However tinyMCE.execCommand('undo') works fine.
Is there a way to make document.execCommand('undo') work directly in TinyMCE?

Any text or images or other items added to the editor creates an event in the separate, TinyMCE DOM. This is why document.exeCommand('undo'); won't affect added content and returns 'false' in the console.
To see this in action, I contrasted TinyMCE with a standard textarea and content editable section, and tried out the commands in the console: the document.execCommand returns 'true' when run in the console for undoing content in the textarea and contenteditable. But it does return 'false' for TinyMCE.
(As for a way to make document.execCommand run in TinyMCE, I'm not sure it is possible.)

Related

TinyMCE invalid_elements - how to remove from HTML and from DOM

I'm having problems with removing tags from TimyMCE. (last version)
invalid_elements : 'br' or valid_elements : 'p/br'
This delete/replace the tag on ctrl+enter from html source but not from the DOM in the editor.
How can i prevent the use of invalid elements in the Editor DOM?
Simply said i want to prevent using a tag not only in the generated html source, but also in the Editor too.
What do you want to have happen when someone presses shift+enter if you don't want the <br> to be used? You can capture any keydown event in the editor and then choose what you want to do instead.
This TinyMCE Fiddle captures the keydown event and simply ignores shift+enter. You can certainly do something different if needed.
http://fiddle.tinymce.com/vogaab/1
EDIT: Based on your comment I updated the fiddle:
http://fiddle.tinymce.com/vogaab/2
...in this version I modify the event to make the event.shiftKey attribute false and then let the event finish as normal. I no longer get a <br> but instead get a <p> tag whether I use enter or shift+enter

Tinymce wrongly rewriting HTML

I have a custom button that insert some HTML in the editor
First block of code is the button action and the second one is how the HTML is inserted
Any idea why it is rewriting it that way and how to stop it?
I just managed to fix it, in the init function:
valid_children : 'pre[code]'
TinyMCE includes the ability to insert code samples into the editor via its Code Sample plugin:
https://www.tinymce.com/docs/plugins/codesample/
If you want to try to do this yourself you need to do a few things like using the protect configuration option to tell TinyMCE to allow your PHP tags. See this TinyMCE Fiddle for a basic example:
http://fiddle.tinymce.com/Qdgaab

RTE AEM6.2 By default Addition of p tag

I tried removing the p tag from RTE of AEM(6.2) by adding the property removeSingleParagraphContainer :true in rte text node.It removes the p tag from first paragraph but as soon as we enter the next paragarph the p tag gets added.It seems the component needed to be customized from out of box.
Is there any other way can we achieve this.
The functionality which I require is that no tag should get added until users selects a specific formatter tag from paraformat.
Thanks for the Help!
I've struggled with this issue once upon a time. As far as I know there is no way to do it with configuration. You'll need custom code to get rid of these <p>'s.
One thing I can advise is that it's far easier to do it from within your code once already reading the property from JCR - then tweaking the aem component not to add it.
This is the default behaviour of RTE OOTB. removeSingleParagraphContainer is for backward compatibility and not the behaviour you are expecting.
By default, pressing Enter will add a <p> tag but if you press Shift+Enter (at least on Mac, not sure on Windows) you will get a <br> tag which is probably what you are expecting.
The only way to change the behaviour is to overlay the RTE control.

TinyMCE4 icons not displayed when web font downloading disabled

Our product is used by many corporate and government bodies.
Many of them are only allowed use IE and have security policies applied to their IE which they are not allowed adjust.
One such setting is the disabling of downloading web fonts.
We have work around in place to check if the font can be downloaded.
If not, we replace all <i> on the page with <img>.
var haveFont = detectFontIcons();
//Iterate over each icon on the page and replace if necessary
if (!haveFont)
$('[class^="mce-i-"]').each( function(e) {
console.log("Found element = ", this);
// Replace all <i></i> with <img>
....
}
}
This works fine for all our custom Html.
The Problem:
For some reason it will not work for tinyMCE <i> tags.
I have adjusted the class prefeix to allow for the TinyMCE 'mce-i-'.
It finds no elements in the DOM with 'mce-i' even though I can see them using firebug.
I have even set a timeout on the call to do this check, incase it was an issue with the DOM not been fully rendered yet. No luck.
Questions:
1: Any ideas on why no TinyMCE elements are not been found?
2: How can I update tinyMCE to use images directly instead of web fonts?
Thanks
I can't take credit for this, but I found a font-free, custom skin that replaces the fonts with images. I added the skin, updated my init method and it appears to work as I'd hoped.
It can be found here:
- https://pollyshaw.wordpress.com/2014/02/03/a-font-free-skin-for-tinymce-version-4/
- https://bitbucket.org/pollyshaw1/tinymce-4-lightgray-no-fonts-skin

How to stop TYPO3 from stripping <p> tags from RTE content (or touching it at all)

I have a TYPO3 which strips any <p> tags from content I create when the RTE editor is enabled for the field in question before it saves it in the DB. And it seems I cannot find a way to disable this behavior with a TypoScript. As soon as I disable the RTE editor I can save <p> tags and they get correctly rendered in the frontend. They also get correctly rendered in the frontend when I simply add them directly in the database in the tt_content table in the bodytext field.
When I switch to the edit source mode of the RTE I see all <p> tags in place. Before and after a save (also they never make it to the DB) so it looks like they get converted to (linux) line breaks or something and get converted back to <p> tags when the editor loads them in the backend. But those line breaks of course have no effect to in the frontend.
I thought this behavior would be controlled by RTE.default.proc but everything there looks good to me (p is already in the allowed tags and there is no clue why it could be stripped). I've also tried to disable the RTE.default.proc.entryHTMLparser_db and RTE.default.proc.exitHTMLparser_db as I wouldn't mind it if the HTML content as you see it in the edit source mode of the RTE (so with RTE still enabled!) would not be touched at all - in fact I would prefer it - but this had no effect. On the other hand when I add tags to the allowed tags which weren't there before (like <button>) this works so the things I try to add to RTE.default.proc aren't ignored in general.
So how can I stop TYPO3 from stripping my <p> tags from RTE content or touching it at all? I'd prefer a solution with TypoScript but meanwhile I would also be happy about an ugly hack in a sys extension as long as it works...
I'm not sure if this is a bug or not but the solution to my problem lies in p.rmTagIfNoAttrib = 1. At least in my TYPO3 version (v6.1.7 and nearly only built in extensions) I cannot find this setting in the preset TypoScript of the page or the RTE editor so I'm guessing it defaults to 0. In my logic 0 means false so I'd say the default would read as "remove tag if there is no attribute?: no!".
However TYPO3 seems to work after its own logic. Adding the following statement to the page TS sloves my problem and <p> tags are preserved:
RTE.default.proc {
entryHTMLparser_db {
tags {
p.rmTagIfNoAttrib = 1
}
}
}
The reasons for this behavior are explained in the TYPO3 manual:
Many of the transformations performed back and forth in the TYPO3 backend date back to when it was a challenge to incorporate a RTE in a browser. It was then sometimes needed to fall back an a simple <textarea> where rich text had to be presented in a simple enough way so that editors could work with it with no visual help.