New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Data Objects] WYSIWYG data-type: use <br> instead of <p> #4411
Comments
Please undo this change asap. It is now not possible anymore to add a new paragraph by hitting the "Enter" key. (Which is the default text editing behavior in all major text editing software such as Word or Wordpress - Why make it different in Pimcore than how most users know it?) See also here "Changing the Enter Mode setting to BR or DIV is not recommended. The default CKEDITOR.ENTER_P mode is fully supported by all editor features and plugins and is also the most correct one in terms of best practices for creating web content." |
I'm in agreement with @ckemptner |
Feel free to continue the discussion, until v7 we have some time left. |
The question is what should be default behaviour. Certainly there are cases where p tags make sense. If you want the old behaviour with p-tags back you can enter But for all cases where users just want to enter some text and format it, p-tags can be counter intuitive in my (and a lot of our customers') experience. |
Please undo this change asap! I work a lot in pimcore and I prefer adding a paragraph by hitting the "Enter" key - the same way as it works in word! |
This is where my experience is the exact inverse of yours, customers expect consistency and paragraphs. And the default behaviour of other systems is now different from Pimcore. |
There are 2 problems which initially got me to issue this:
It would be fine if p-tags where only added if really "enter" got pressed in the GUI - but if you only enter one line, p-tags should not be added automatically. If above problems do not apply for your case and you do want to add a paragraph by pressing "enter", then simply add Perhaps we could add a little more documentation about this or even add a dropdown in the wysiwyg field definition to set the enter mode. |
I think, everyone will later customize editor for what he is expecting "use strict";
// src/AppBundle/Resources/public/js/pimcore/ckeditor.config.js
pimcore.object.tags.wysiwyg.defaultEditorConfig = {
enterMode: CKEDITOR.ENTER_P,
format_tags: 'p;h3;h4;h5;h6;pre;div',
removePlugins: 'stylescombo',
removeButtons: 'Font'
}; // src/AppBundle/AppBundle.php
class AppBundle extends AbstractPimcoreBundle implements DependentBundleInterface
{
public function getJsPaths()
{
return [
'/bundles/app/js/pimcore/ckeditor.config.js'
];
}
} |
@jansarmir, you are right but this isn't even necessary as you could just write
to the wysiwyg field's editor configuration (this is a field in the field definition). Then you would not need any additional files. I will add a paragraph to the docs... |
If the majority votes for reverting the change (in the next bug-fix release), I'd be happy with that as well, but please, do not complain about SemVer afterwards ... |
🙇 thanks I think starting with semver at v7.0 would be most true to the reality of the situation and easiest to do. Even though I hope it can be introduced earlier (and semver includes provisions for BC breaks and restoring them if done in a minor/patch release). |
To all who want |
Hello Blackbit - Imho for the WYSIWYG editor, which is one of the most-used features of Pimcore users, we have to think "user-first" and not "developer-first". The problems you have mentioned might be solved in some other way - The experience for the users in Pimcore should be consistent with what they know and expect. |
Point 1, I think it is an analysis from an incorrect assumption that short paragraphs are not paragraphs. Any and all paragraphs of texts should be wrapped in Point 2, yes, this can be problematic, but entirely possible to solve, for example both Drupal and WordPress has had the _filter_autop and wpautop() respectively since basically forever and it works beautifully. |
@NiklasBr Of course short paragraphs are paragraphs but what if you want to enter a product name which later on gets output as And no doubts that the mentioned problems are solvable - and if there is a solution I am the last to stem against |
I don't understand why you are using a What You See Is What You Get input field for output where what you get is not what you want to see. |
Because the customer wants e.g. to put somethin in italic or bold or change font color of a part of the product name / page title. |
For such highly specialised input fields I would configure a very small subset of editor buttons, removing things like images, styles, links, tables and so on to prevent breaking layouts. I can understand that as a valid requirement, but I do not think it is a good reason to set the default behaviour to something non-standard and something which deviates from best practices. |
This does not help against Whatever, I have written everything I have to say about this topic. When the majority or the Pimcore team thinks |
i think most cases are using my opinion about wysiwyg field is
|
Currently the inserted text of an wysiwyg field of a data object gets wrapped in a p-tag by default. We can disable this by setting
editor configuration
of the field definition to{ enterMode:2 }
In our experience only few customers are aware of this "feature", most just recognize it when output layout gets scrambled.
Imho it would be better to set enterMode: 2 by default as it is much easier to wrap the output in a p-tag whereever needed than to remove the p-tag afterwards.
What do you think?
The text was updated successfully, but these errors were encountered: