[#15059] - Problems with tinyMCE width and height, joomla 3.7
- Closed
- 23 Jun 2017
- Medium
- Build: staging
- # 15059
- Diff
- schnuti:tinyMCE-height-and-width
- Success continuous-integration/drone/pr the build was successful Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
User tests: Successful: Unsuccessful:
I think there are some confusions about the computed values of the width and height values for the tinyMCE editor. Personally I categorize this as a bug.
In theory there could be a lot of default settings but this is more simple.
We get the values from user editable system wide parameters (with some funny results like height=750, the tinyMCE default )):
- tinyMCE editor default values
- tinyMCE editor settings
- this overrides the parameters from the form in all components and views.
Article edit
A second field in article edit as in PR 14520.
Article frontend editing.
The Joomla editor form field will never get any settings from external sources as default.
My propasal is to set the width hardcoded to 100% (or auto) and the height from:
- Joomla editor form field default settings
- the field's settings in the form field XML
- tinyMCE default setting in the code (if no value available). I'm not quite sure about this.
- override in a system plug in - onBeforeRender() method
Expected result
As tinyMCE automatically gets the height values from the hidden textarea field, we don't have to explicit set any values in the tinyMCE options. As well, we don't have to set any editor instance values as in #14520.
If you want a width per field, this has to be added to each editor instance as in PR #14520. As far as I could see there is no automatic loading as with the height.
In this PR I have removed the parameters in the tinyMCE editor, removed the tinyMCE options, added defaults in tinyMCE code and deprecated the language strings. I did not change the legacy part. Width is now overridable with a custom template/layout and height by using a custom system plugin - method onBeforerender().
Test instructions:
- Add an extra editor field as in #14520 with height. The original article text field has no expicit value, default 500px height from the form field.
In the article form XML administrator/components/com_content/models/forms/article.xml add one more editor element (somewhere after line
<fieldset name="basic" label="COM_CONTENT_ATTRIBS_FIELDSET_LABEL">)
<field name="text2" type="editor" hide="menu,module,contact" label="Text2" description="" filter="JComponentHelper::filterText" buttons="true" height="250"/>
-
Check the result without adding the patch. Play with the tinyMCE editor settings a bit. Go to the tab(s) advanced in tinyMCE and modify Width and Height to what a user could enter. e.g. width 50%, height=200.
Have a look to the new second field in article edit, backend categories and frontend article edit/creation as well. -
Apply this patch.
There are no settings so just reload the article edit page and .
Check and compare the results.
@Fedik Is it easy to add the width if !100% as in PR 14520? The width could then be set in the form field. Needed?
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration Language & Strings Front End Plugins |
I have tested this item
Patch ok for me.
Thanks
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15059.
yes, also I hope we can solve the tinyMCE width problem in 3.7.0 or 3.7.1
| Labels |
Added:
?
?
|
||
@brianteeman I've reverted the language change and added a remark
I can't think of any situation where a width <> 100% (see images above) is needed. If you know one, I've now tested a solution using Fediks editor instances that works fine.
I have tested this item
Error on "Articles: Edit" in Backend:
System information
3.7.1-dev
macOS Sierra, 10.12.4
Firefox 53 (64-bit)
MAMP 4.1.1
- PHP 7.0.15
- MySQLi 5.6.35
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15059.
@franz-wohlkoenig
Could you please check if you have the JS file in the directory.
media/editors/tinymce/plugins/jdragdrop/plugin-min.js
It has obviously bin moved to media/editors/tinymce/js/plugins/dragdrop/plugin-min.js
As far as I can see this PR has nothing to do with this javascript loading error.
Related? #15057
media/editors/tinymce/plugins/jdragdrop/plugin-min.js
jdragdrop/plugin-min.js doesn't exist.
media/editors/tinymce/js/plugins/dragdrop/plugin-min.js
Folder exist.
@franz-wohlkoenig
I think you somehow got out of sync.
see e.g.
https://github.com/joomla/joomla-cms/tree/staging/media/editors/tinymce/js/plugins/dragdrop
@franz-wohlkoenig
Do you really find it on your instance? Do you override the tinyMCE settings? (personally I love it!)
As I said "This PR do not change anything regarding Javascript""
Do you really find it on your instance?
Do you override the tinyMCE settings?
Clean Install of latest nightly Build. After applied PR got Error described in Comment
@franz-wohlkoenig
That's as far I go, I have my solution - override-. I do NOT need this patch.
By!
@franz-wohlkoenig
I have to apologize! There are no conflicts above - but there should be,
My PR overrides somehow #15057 that moves the js to an "external" path.
I get no differences with staging.
How can I fix that? New PR?
As I understand this should not be possible.
As I said - when I compare with JoomlaCMS/staging I get " Able to merge." and an update is not possible!
My guess for now is that the PatchTester is the problem copying the old PHP file to the test system and that a commit to Joomla staging would work.
But I would need some advise.
Yep, Patchtester can cause some funny results if the PR branch doesn't have conflicts but is outdated neverthless. Because it copies the files instead of merging the changes.
You can merge (or rebase) the staging branch into your PR branch to fix that issue.
@Bakual
Thanks for the hint. I found a way to merge the staging changes into the PR branch using the GitHub web interface.
@franz-wohlkoenig
Could you give it another try. I've tested and it works for me using the PatchTester.
Thanks for testing and finding the problem in the first place!
brianteeman
- | Milestone |
Added: |
||
| Milestone |
Added: |
||
| Milestone |
Removed: |
||
| Milestone |
Removed: |
||
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-06-23 11:28:42 |
| Closed_By | ⇒ | schnuti |
sorry, not very understood your question,
14520 already merged