Skip to content
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

WYSIWYG field not picking up last used visual vs text setting, not loading in text can change some HTML #6176

Open
dweuste opened this issue Oct 18, 2021 · 7 comments · May be fixed by #6179
Assignees
Labels
Component: DFV Issues related to the Pods DFV JS that powers form fields Keywords: Regression Type: Bug
Milestone

Comments

@dweuste
Copy link

dweuste commented Oct 18, 2021

In the WYSIWYG field, there are times you have to use the Text Editor rather than the Visual Editor. It is still superior to the standard code editor because clients can still highlight and bold and italicize and link and not have to worry about paragraph tags, but when the editor switches to Visual, it breaks the code if there were some non-standard things. An example of this is adding text in between list items (text

  • text
  • ). Normally this isn't an issue because once the editor is in Text mode, it doesn't switch unless you tell it to. But after 2.8, that's no longer the case, now after each page refresh, it reverts to Visual Editor and breaks that previous code, so you have to re-do whatever you previously did every single time you want to edit. This is mainly an issue in WooCommerce pages if that matters.

    @sc0ttkclark sc0ttkclark added this to the Pods 2.8.1 milestone Oct 19, 2021
    @sc0ttkclark sc0ttkclark added Type: Bug Keywords: Regression Component: DFV Issues related to the Pods DFV JS that powers form fields labels Oct 19, 2021
    @sc0ttkclark
    Copy link
    Member

    The field was recently revamped with React and it looks like the Visual/Code views are not maintained on each page load.

    I wonder if there's a way to offer the WYSIWYG field without the Visual tab option and just use the quick tags code version.

    @JoryHogeveen
    Copy link
    Member

    Yes there is. We could add two fields to the Editor settings: tinymce and quicktags (both enabled by default) and let users decide what to do.
    See available settings in: https://developer.wordpress.org/reference/classes/_wp_editors/parse_settings/

    @JoryHogeveen JoryHogeveen linked a pull request Oct 19, 2021 that will close this issue
    4 tasks
    @JoryHogeveen
    Copy link
    Member

    @sc0ttkclark @zrothauser
    I've created a starting point PR: #6179

    @sc0ttkclark
    Copy link
    Member

    I've got an initial fix for the setting of the default editor on the page -- however it's not running at the right time to switch the editors.

    Code is in this change: 7f0aa07 (and subsequent commits on 2.8.1)

    @sc0ttkclark
    Copy link
    Member

    I'm removing the defaultEditor handling for now, the solution would still present the problem reported since it loads as visual editor and then switches to the HTML editor (causing the HTML mess up).

    I suggest using the Code field type for now @dweuste

    @sc0ttkclark sc0ttkclark modified the milestones: Pods 2.8.1, Pods 2.8.2 Oct 20, 2021
    @JoryHogeveen
    Copy link
    Member

    I'm also not fond of the default editor option.
    As seen in #6179 I've added the possibility to enable or disable each editor. This is part of the WP editor functionality so it would be a solid enhancement IMO.
    As for the "default" handling. I'm wondering how the_editor or wp_editor did this. I think it's best if we do the same.

    @sc0ttkclark sc0ttkclark changed the title WYSIWYG field issue WYSIWYG field not picking up last used visual vs text setting, not loading in text can change some HTML Oct 25, 2021
    @sc0ttkclark sc0ttkclark modified the milestones: Pods 2.8.2, Pods 2.8.4 Oct 25, 2021
    @sc0ttkclark sc0ttkclark modified the milestones: Pods 2.8.4, Pods 2.8.5 Nov 5, 2021
    @dweuste
    Copy link
    Author

    dweuste commented Nov 9, 2021

    A question as this is still being worked on. Is there a way to make the code editor add or interpret line breaks? Getting clients to wrap all text in spans hasn't been super consistent, and years old code end up doing some strange things without them.

    @sc0ttkclark sc0ttkclark modified the milestones: Pods 2.8.6, Pods 2.8.8 Nov 24, 2021
    @sc0ttkclark sc0ttkclark modified the milestones: Pods 2.8.10, Backlog Jan 21, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    Component: DFV Issues related to the Pods DFV JS that powers form fields Keywords: Regression Type: Bug
    Projects
    None yet
    Development

    Successfully merging a pull request may close this issue.

    4 participants