Support » Fixing WordPress » How do you prevent the WordPress editor from stripping out certain HTML tags

  • Hi there,
    the wordpress editor strips tags when switching from visual to text mode. How do you prevent this from happening? It’s simple tags like
    <p><span> that are getting stripped.
    It’s a well known issue and I am looking for a non-hacky, non disaple the visual editor, non use this plugin answer.

    Thanks,
    Sascha

Viewing 15 replies - 1 through 15 (of 22 total)
  • looking for a non-hacky, non disaple the visual editor, non use this plugin answer.

    Never switch between the two. However, and for protecting at least a set of links I want to always remain formatted in my own way at the bottoms of pages I have made a php file called from the page template in this kind of way:

    <div class="entry-content">
    	<?php the_content();?>
    	<?php get_template_part('links','bottoms');?>
    	<?php wp_link_pages(array('before' => '<div class="page-links">' . __('Pages:','twentytwelve'),'after' => '</div>'));?>
    </div><!-- entry-content -->

    Thanks for your help!

    But I am really looking for an answer, that does not say ‘never switch between the two’.
    I just want it to not strip tags. And no, I do not want to add a class to a p tag or anything like this either.

    FYI: I have disabled “wpautop”.

    Would love to get this working!
    Should I file a bug/enhancement in trac?

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    Should I file a bug/enhancement in trac?

    No, because it will probably get closed as “wontfix”.

    The Visual Editor is not intended for cases where you want a specific set of HTML. It is intended to be visual, for users that don’t know HTML. It will indeed “mess up” your custom HTML, because that’s it’s purpose: To write the HTML for you. It has a set way of doing things, and it will force any content to conform to its ways.

    In other words, your goals here are in conflict with the purpose of the Visual editor to start out with. WordPress is primarily a tool for publishing “content”. Content is not the same as “custom HTML”.

    If you want to write custom HTML, then use the HTML editor. If you want it to handle this for you, then use the visual editor and don’t worry about the HTML.

    There is no case where the Visual editor will “preserve” your HTML, because it is designed specifically to create HTML without you seeing it or having to deal with HTML in any way.

    Otto,
    thanks for your reply. I value your input on this and understand what you mean.
    Just one more thing though, as that might be a bug:

    With “wpautop” switched off, when I choose some text in the visual editor and make it a paragraph, when I then switch over to the text editor that <p> tag is not showing, it’s just plain text.
    All other tags from the visual editor remain though. I assume it’s to do with wpautop being off, but I would expect text that I mark explicitly as a paragraph in the visual editor to remain a paragraph in the text editor like all other tags do as well.

    NOTE: This is not about switching editors. It also does not show as <p> in the content on the front end.

    But maybe I should open a different topic for that…
    S

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    With “wpautop” switched off

    Two points here:

    1. The case of switching off part of WordPress is obviously going to lead to unusual results. Normal users don’t turn off wpautop, nor do they want to write their own P tags. That’s just not a common use-case. So your results will naturally be different than the norm.

    2. The Visual editor doesn’t use the wpautop function in WordPress. It has its own javascript version in the editor code to basically do the same thing. Even if you’re switching off the formatting helpers on the back end, you’re not switching them off in the editor’s javascript code. It removes the P tags because it assumes wpautop is enabled, like it should be.

    Essentially, you’re making things difficult for yourself here because of your rigid need to be able to define your HTML in ways you prefer. This is a use-case that is outside the norm, so further adjustments will be needed to make it conform to your desires. For which I would say simply: Find an appropriate plugin and use it. Seriously, trying to roll this all yourself is an exercise in frustration. Don’t reinvent the wheel. Use a wheel that’s been tested and has proper tires on, for a much smoother ride.

    Declaring that there is “no use case” to support switching between visual and text mode does not fit the real world.

    Many small companies want SOME customization but do not have staff that understand HTML and CSS. For those cases, web developers such as myself tweak or add some custom code to posts and pages to achieve a certain look for that post or page.

    Everything is not black or white, guys, sometimes things are a shade of grey…

    Declaring there is “no use case” to support switching between visual and text mode does not fit the real world.

    Certainly not everyone’s as far as actual usage is concerned, and there is where various plugins and such can come into play for many even if not for all. For some, the user profile’s “Disable the visual editor when writing” option protects HTML work from being modified, and I mention that not to argue but just to point out that the devs are aware and do care. But since WordPress is not a commercial venture hoping to be everything for everyone and while including the devs as end users, we have what we have until the same or even more volunteer devs perceive a sufficient need or desire or whatever and then (or even simultaneously) assess the matter of the work required for all to have it.

    Hello, I stumbled into this thread while investigating the “do not strip HTML” issue. I shall be grateful to anyone who can help me with my problem which is as follows:

    I am developing a child theme of Twenty Sixteen, so far I’ve had no problems.

    I want to display an image instead of the “Site Title” text (Appearance > Customise > Site Identity > Site Title)

    I have tried the obvious way of inserting an HTML tag of <img> as the Site Title text, but somewhere in the processing of this element either the theme or WordPress itself “sterilise” tags by switching the “<” and “>” to “& lt ;” and “& gt ;” respectively.

    I want to disable this function, at least for the Site Title.

    (I am an old hand at writing code, having started back in 1973; I am not much up-to-date with PHP and it would take me quite a while to figure this thing out by myself, so I would be most grateful to anybody in the community who can help this old man around this small hurdle).

    Stefano Toria, [Email moderated]

    It’s really annoying but you have to make sure you stay in the code view and not save when you are in visual mode. I wish there was a code cleanup option we could just turn off if we liked.

    I wish there was just an option to turn off the code stripping though the settings though.

    So they can’t just put an option in the settings to disable the code cleanup? That makes no sense. WordPress is no longer a simpleton’s platform.

    I have the same problem and I dont know why this has been an issue for so long.
    Its clearly a issue yet no on will admit it.
    I switched back to the visual as it was easier to replace / edit an image reference however upon saving WordPress nicely trashed my formating.
    Removing all paragraphs and leaving me with one block of up-paragraphed text despite what the Visual editor shows its clearly not a case of what you see is what you get!
    WordPress guys you need to fix this and keep propper HTML standards in the mean time I need a way to disable this “Feature” as going forwards I might not be the only one editing our site.

    i just read somewhere from a WP techie that the problem is TinyMCE’s cleanup function, upstream from WP; i distinctly remember a plugin that did it for me a couple of years ago, though.

    they seem to be fairly sparse these days. it’s sure pissing me off though, it adding <p></p> where it wants to if i try to paragraph my own text.

    kind of like the (current) US Government. knows what’s better for us than we do…

    🙂

    Personally, I found the need to have the p tags and other formatting necessary when formatting for the editors/writers we have on staff. My workaround (which may not be useful to all):

    1. Copy all content into the visual editor
    2. Save draft
    3. Go to front-end and view source
    4. Copy applicable source code
    5. Paste into code editor of choice / make necessary code edits
    6. Paste updated code into text editor
    7. Publish

    And yes, I admit that this is a bit time-consuming, but it’s been my workaround for some time and seems to give me the results I want. I’m not a fan of relying on a plugin to do this work…

    Just use this. Put it in functions.php.

    You can add more of your own html tags.

    // Prevent TinyMCE from stripping out html
    function schema_TinyMCE_init($in)
    {
        /**
         *   Edit extended_valid_elements as needed. For syntax, see
         *   http://www.tinymce.com/wiki.php/Configuration:valid_elements
         *
         *   NOTE: Adding an element to extended_valid_elements will cause TinyMCE to ignore
         *   default attributes for that element.
         *   Eg. a[title] would remove href unless included in new rule: a[title|href]
         */
        if(!empty($in['extended_valid_elements']))
            $in['extended_valid_elements'] .= ',';
    
        $in['extended_valid_elements'] .= '@[id|class|style|title|itemscope|itemtype|itemprop|datetime|rel],div,dl,ul,ol,dt,dd,li,span,a|rev|charset|href|lang|tabindex|accesskey|type|name|href|target|title|class|onfocus|onblur]';
    
        return $in;
    }
    add_filter('tiny_mce_before_init', 'schema_TinyMCE_init' );
Viewing 15 replies - 1 through 15 (of 22 total)
  • The topic ‘How do you prevent the WordPress editor from stripping out certain HTML tags’ is closed to new replies.