[#47326] - [6.1] Add update SQL script for PR #46438 to fix TinyMCE editor default width and height settings on core update
- Fixed in Code Base
- 9 Mar 2026
- Medium
- Build: 6.1-dev
- # 47326
- Diff
- richard67:6.1-dev-add-update-sql-for-pr-46438
User tests: Successful: Unsuccessful:
Pull Request resolves # .
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Summary of Changes
This pull request (PR) adds a new update SQL script "6.1.0-2026-03-07.sql" for each MySQL/MariaDB and PostgreSQL for updating the old default values "550" and ""750" for the "html_height" and "html_width" configuration options of the "TinyMCE" editor plugin to the new defaults "550px" and "100%" like they were changed for new installations with PR #46438 .
It is NOT a fix for issue #47292 with editor = "None" and so not an alternative to PR #47325 , so it only makes sense if that PR is not accepted. Otherwise, if that PR is accepted, this here is obsolete.
Testing Instructions
Update from a 6.1.0-beta2 to the latest 6.1 nightly build for the actual result, and update from a 6.1.0-beta2 or from the latest 6.1 nightly build to the patched package or custom update site created by Drone for this PR for the expected result.
After that, check the "html_height" and "html_width" parameters of the TinyMCE editor plugin in the database.
Actual result BEFORE applying this Pull Request
"html_height":"550","html_width":"750"
Expected result AFTER applying this Pull Request
"html_height":"550px","html_width":"100%"
Link to documentations
Please select:
-
Documentation link for guide.joomla.org:
-
No documentation changes for guide.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | SQL Administration com_admin Postgresql |
its not really an alternative as it doesnt fix the editor none issue
@brianteeman Thanks, I've corrected the description.
@brianteeman please test this PR for TinyMCE only,
Other editors will be fixed in #47305
@richard67 i dont know if this matters or not but before the change from this pr the structure of the field is
{configuration...................},"sets_amount":3,"html_height":"550","html_width":"750"}
After this PR the structure is reversed
{"html_width": "100%", "html_height": "550px", "sets_amount": 3, "configuration": {"
@richard67 i dont know if this matters or not but before the change from this pr the structure of the field is
{configuration...................},"sets_amount":3,"html_height":"550","html_width":"750"}After this PR the structure is reversed
{"html_width": "100%", "html_height": "550px", "sets_amount": 3, "configuration": {"
@brianteeman Yes, that is an effect of using json functions of the database. But as long as only the order or properties change, that is not a problem.
ok just wanted to double check
I have tested this item ✅ successfully on 51cba2e
pr does what it says
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47326.
ok just wanted to double check
@brianteeman No problem. Better double check than single fail.
The only problem I have with this is a UX issue that a user might have changed the setting to 700. It didnt work but as nothing had changed they never changed it back from 700.
so when they update to 6.1 this pr wont change anything for them but as the width suddenly starts to work they will not understand why it happened and think joomla is broken and nhot know that they should go and change the width to 100% (it could have been years since they set the non-working values).
The only problem I have with this is a UX issue that a user might have changed the setting to 700. It didnt work but as nothing had changed they never changed it back from 700.
so when they update to 6.1 this pr wont change anything for them but as the width suddenly starts to work they will not understand why it happened and think joomla is broken and nhot know that they should go and change the width to 100% (it could have been years since they set the non-working values).
@brianteeman Well, the JSON_EXTRACT(params, '$.html_width') condition in the WHERE clause of the 2nd update statement could be refined so it catched any integer value without a "px" suffix. Question: Should is also catch values with a correct "px" suffix? Currently this PR tries to avoid changing user settings.
my gut feeling iws that we should never change a users settings but that doesnt help. i guess we could do a postinstalll message for users with a different value set here or just a wiki known issue post
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-03-09 16:38:13 |
| Closed_By | ⇒ | HLeithner | |
| Labels |
Added:
Release Blocker
bug
PR-6.1-dev
|
||
Thanks, I think not many people will be affected by "set a value and didn't know why it changed now" better to have a change good value than a broken value which annoys people more.
its not really an alternative as it doesnt fix the editor none issue