You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/ROOT/pages/8.4.0-release-notes.adoc
+51-7Lines changed: 51 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -56,17 +56,43 @@ For information on the **<Open source plugin name>** plugin, see xref:<plugincod
56
56
== Accompanying Premium plugin changes
57
57
58
58
The following premium plugin updates were released alongside {productname} {release-version}.
59
-
=== <Premium plugin name 1> <Premium plugin name 1 version>
60
59
61
-
The {productname} {release-version} release includes an accompanying release of the **<Premium plugin name 1>** premium plugin.
60
+
=== Media Optimizer
62
61
63
-
**<Premium plugin name 1>** <Premium plugin name 1 version> includes the following <fixes, changes, improvements>.
62
+
The {productname} {release-version} release includes an accompanying release of the **Media Optimizer** premium plugin.
64
63
65
-
==== <Premium plugin name 1 change 1>
64
+
**Media Optimizer** includes the following addition.
66
65
67
-
// CCFR here.
66
+
==== SVG images can now be uploaded.
67
+
// #TINY-13708
68
+
69
+
Previously, SVG images could not be uploaded through the Media Optimizer plugin because Uploadcare placed restrictions on SVG file handling. Users who needed to include SVG graphics in content were unable to upload them directly.
70
+
71
+
In {productname} {release-version}, SVG images can now be uploaded through the Media Optimizer plugin. Some CDN operations may have limitations on SVG files; for details, see the link:https://uploadcare.com/docs/cdn-operations/#limits[Uploadcare documentation on CDN operation limits].
72
+
73
+
For information on the **Media Optimizer** plugin, see: xref:uploadcare.adoc[Media Optimizer].
74
+
75
+
=== Full Page HTML
76
+
77
+
The {productname} {release-version} release includes an accompanying release of the **Full Page HTML** premium plugin.
78
+
79
+
**Full Page HTML** includes the following fixes.
80
+
81
+
==== Pasting an HTML document was vulnerable to XSS attacks
82
+
// #TINY-13673
83
+
84
+
A cross-site scripting (XSS) vulnerability was discovered in the Full Page HTML plugin. Previously, malicious code within the document `<head>` was able to be executed when pasted.
85
+
86
+
This vulnerability has been patched in {productname} {release-version} by ensuring that content in the document `<head>` is properly encoded.
87
+
88
+
==== New argument `fullpagehtml` to `editor.getContent()` and `editor.setContent()` APIs to only get/set the body of the content while the full page plugin is active.
89
+
// #TINY-13744
68
90
69
-
For information on the **<Premium plugin name 1>** plugin, see: xref:<plugincode>.adoc[<Premium plugin name 1>].
91
+
Previously, setting and getting the editor content while the Full Page HTML plugin was active could be troublesome due to the presence of the full HTML document on all API calls, even when not needed. Attempting to get and act only on the body content (for example, for saving) was undocumented and required workarounds.
92
+
93
+
In {productname} {release-version}, the `fullpagehtml` option has been added to the `editor.getContent()` and `editor.setContent()` APIs. When set to `false`, this option allows getting and setting only the body content while the Full Page HTML plugin is active, without interfering with the full document structure. The document is now more resistant to accidental changes, and content can be retrieved or updated without including the full HTML document. For details, see xref:fullpagehtml.adoc#fullpagehtml-getcontent-setcontent[`fullpagehtml` option for getContent/setContent].
94
+
95
+
For information on the **Full Page HTML** plugin, see: xref:fullpagehtml.adoc[Full Page HTML].
70
96
71
97
=== Comments
72
98
@@ -83,7 +109,6 @@ In {productname} {release-version}, the save logic now resets the saving state t
83
109
84
110
For information on the **Comments** plugin, see: xref:introduction-to-tiny-comments.adoc[Comments].
@@ -139,6 +164,12 @@ For information on using Enhanced Skins & Icon Packs, see: xref:enhanced-skins-a
139
164
140
165
// CCFR here.
141
166
167
+
=== New `view_show` option to display a specified view on initialization.
168
+
// #TINY-11967
169
+
170
+
171
+
In {productname} {release-version}, the new xref:custom-view.adoc#view_show[`+view_show+`] option allows specifying which view to display when the editor is initialized. The option behaves similarly to `+sidebar_show+` but takes precedence for views; both sidebars and views can be configured to show on init.
172
+
142
173
143
174
[[changes]]
144
175
== Changes
@@ -171,6 +202,19 @@ For information on using Enhanced Skins & Icon Packs, see: xref:enhanced-skins-a
171
202
// #TINY-vwxyz1
172
203
173
204
// CCFR here.
205
+
=== Directionality of Hebrew was incorrect
206
+
// #TINY-13667
207
+
208
+
Previously, right-to-left (RTL) directionality was not correctly set for Hebrew in the language pack. This caused the editor to render the wrong directionality when Hebrew was set as the language.
209
+
210
+
In {productname} {release-version}, this issue has been addressed by ensuring that the directionality is correctly set for Hebrew in the language pack.
211
+
212
+
=== Bundled content CSS is now loaded into preview iframes
213
+
// #TINY-13190
214
+
215
+
Previously, when the editor content CSS was bundled, it was not loaded into preview iframes. This caused a visual mismatch between the editor content area and what users saw in the Preview dialog, Suggested Edits view and Revision History view.
216
+
217
+
In {productname} {release-version}, the fix checks if the content CSS is available as a bundled resource and applies it to the Preview Iframe through style tags. Bundled content CSS is now correctly loaded in the Preview Iframe.
== `+fullpagehtml+` option for `+getContent()+` and `+setContent()+`
3
+
4
+
When the {pluginname} plugin is active, `editor.getContent()` and `editor.setContent()` return and accept the full HTML document by default. The `fullpagehtml` option allows getting and setting only the body content when needed.
5
+
6
+
Pass `fullpagehtml: false` in the options object to bypass full-page processing and work with body content only:
7
+
8
+
* `editor.getContent({ fullpagehtml: false })` — Returns only the `<body>` content.
9
+
* `editor.setContent(content, { fullpagehtml: false })` — Sets only the body content without modifying the document head.
10
+
11
+
This option is useful when saving or loading body content separately (for example, when storing content in a database or when integrating with systems that expect body-only HTML). Unlike `fullpagehtml_hide_in_source_view`, which affects only the source code view display, the `fullpagehtml` option affects API behavior and requires no configuration.
This option allows the specified view to be displayed on editor initialization. It behaves similarly to xref:customsidebar.adoc#sidebar_show[`+sidebar_show+`] but applies to views and takes precedence when both are configured. Views and sidebars can both be set to show on init, with the sidebar shown once the view is closed.
5
+
6
+
The value must match the name of a registered view. Premium plugins that register views include:
0 commit comments