Viewing 10 replies - 1 through 10 (of 10 total)
  • Thread Starter jcryan

    (@jcryan)

    As an aside, the Block editor is adding these unwanted line breaks in as well when viewed in Code mode:

    <style>
    .page-header.three{<br />
    display: none;<br />
    }<br />
    .sbheader{<br />
    background-image: url("https://www.jcryan.com/wp/wp-content/uploads/2018/12/HomeHeader.png");<br />
    background-size: cover;<br />
    height: 500px;<br />
    width: 100vw;<br />
    }<br />
    .row-full{<br />
     width: 100vw;<br />
     position: relative;<br />
     margin-left: -50vw;<br />
     left: 50%;<br />
    }<br />
    </style>
    <div class="container-fluid sbheader row-full"></div>

    Hey @jcryan

    This isn’t a total fix, but I can relate, so I hope this helps.

    You might check out this plugin: https://wordpress.org/plugins/advanced-tinymce-configuration/ I use it to change the TinyMCE settings. For example, if a client centers text in visual mode, as opposed to adding an inline style (which I hate), it now adds a class of text-center. Give that a shot and see if that helps.

    As far as the CSS … I often add CSS or JS to a specific page. I got tired of issues with code dropping because clients were using visual mode. So, in every theme I write, I use two opt-in ACFs (conditional logic based on true-false ACFs) that are text fields as opposed to a WYSIWYG (with “no formatting” selected).

    I do not include the <style> or <script> tags in the ACF input, as I include the tags in the PHP (see below). The CSS I pull into the bottom of the head, the JS the bottom of the body. This gives me a place to put CSS or JS that will be pulled into only that page. It is pretty handy.

    CSS:
    wp_head(); if( get_field('add_css') ) { ?><style><?php the_field('additional_css');?></style><?php }
    JS:
    wp_footer(); if( get_field('add_js') ) { ?><script><?php the_field('additional_js');?></script><?php }

    I hope that helps. Let me know if you have questions.

    Cheers

    scotty

    • This reply was modified 5 years, 4 months ago by somecodeiwrote. Reason: Typo

    Possibly related, but possibly not. I also have two shortcodes for div’s. The first shortcode opens the div and supports a class: [open_div class=”CustomClass”]. The second closed the div.

    Open div:

    function Div($atts){ $a = shortcode_atts( array( 'class' => 'NONE' ), $atts ); $DivClass = $a['class']; $Div = '<div class="'.$DivClass.'">'; return $Div;
    } add_shortcode('open_div', 'Div');

    Close Div:
    function CloseDiv(){ $CloseDiv = '</div>'; return $CloseDiv; } add_shortcode('close_div', 'CloseDiv');

    I love these two shortcodes because I can structure a page and not worry about my div’s vanishing due to visual mode.

    Thread Starter jcryan

    (@jcryan)

    Thanks! I will see what I can get that plugin to do for me. Does anyone know if the same hooks apply to the classic editor now that it’s a plugin itself?

    My understanding is that the classic editor plugin is to render the classic editor “indistinguishable” from the way it was before Gutenberg, as in the exact same support – but don’t quote me on that, I am not the plugin developer.

    My dev site is WordPress 5.0, Classic Editor 1.1, and my from scratch theme (stripped-down, minimal plugins) and I am able to use the below without issue. It seems the filters work but this is obviously not a comprehensive list, just a sample.

    Remove editor
    remove_post_type_support( 'post_type', 'editor');

    Allow span, i and other “empty” tags

    function override_mce_options($initArray) {
    $opts = '*[*]';
    $initArray['valid_elements'] = $opts;
    $initArray['extended_valid_elements'] = $opts;
    return $initArray;
    }
    add_filter('tiny_mce_before_init', 'override_mce_options');

    Remove empty tags, like <p></p>

    add_filter('the_content', 'remove_empty_tags_recursive', 20, 1);
    function remove_empty_tags_recursive ($str, $repto = NULL) {
    $str = force_balance_tags($str);
    if (!is_string ($str) || trim ($str) == '') return $str;
    return preg_replace ( '/<([^<\/>]*)>([\s]*?|(?R))<\/\1>/imsU', !is_string ($repto) ? '' : $repto, $str );
    }

    Remove Empty <p></p> tags

    add_filter('the_content', 'remove_empty_p', 20, 1);
    function remove_empty_p($content){
    $content = force_balance_tags($content);
    return preg_replace('#<p>\s*+(<br\s*/*>)?\s*</p>#i', '', $content);
    }

    Remove &nbsp; in <p></p> tags – front end

    add_filter('the_content', 'remove_empty_nbsp', 20, 1);
    function remove_empty_nbsp($string){
    $content = force_balance_tags($string);
    return str_replace('&nbsp;', '', $string);
    }
    • This reply was modified 5 years, 4 months ago by somecodeiwrote. Reason: Weird single ticks
    Plugin Author Andrew Ozz

    (@azaozz)

    @jcryan it looks like there may be a bug in the Block Editor which ignores the wpautop: false setting in some cases and still runs the content through wpautop when loading it in the editor. Then it removes the <p> tags on saving ignoring the setting again.

    For now seems best is to always use the Classic Editor for these posts. It honors the wpautop: false, same as before.

    I’ll look more at this and try to fix it for WP 5.0.1. Also, make sure you don’t have the Gutenberg plugin enabled.

    Swapping from Text to Visual modes in the Classic Editor using the plugin causes TinyMCE to treat all lines as basic text regardless of what the code actually is.

    To fix this in the Classic Editor you need one of the plugins you mentioned to add that wpautop: false setting to the TinyMCE init array. This appears to work properly here, tested with TinyMCE Advanced.

    • This reply was modified 5 years, 4 months ago by Andrew Ozz.
    • This reply was modified 5 years, 4 months ago by Andrew Ozz.
    • This reply was modified 5 years, 4 months ago by Andrew Ozz.
    Thread Starter jcryan

    (@jcryan)

    The Gutenberg plugin was not enabled, I believe the 5.0 update took care of that. I just updated the Classic Plugin to 1.2, deleted the old Gutenberg plugin, re-enabled ‘Dont Much My Markup’ and still have the same issue when I load a page in the classic editor and swap from Text to Visual. I’ll spin up a new vanilla 5.0 instance with no plugins so I can test in a sterile environment.

    Thanks for your attention to this.

    -JC

    Thread Starter jcryan

    (@jcryan)

    So the “issue” was reproduce-able under WordPress 4.9.8 on a fresh stack install of PHP and MySQL so I’m guessing it’s less of an issue and more a showing of my inexperience with the platform. Luckily I found this plugin: https://wordpress.org/plugins/preserved-html-editor-markup/ which mostly did what I wanted the editor to do from the start: stop treating me like an idiot. That plugin worked on 4.9.8 and 5.0 to stop the line breaks but I’m still getting a ridiculous span tag I do not want, so the saga continues.

    Where should I look in order to kill all of TinyMCE’s formatting abilities?

    Plugin Author Andrew Ozz

    (@azaozz)

    Where should I look in order to kill all of TinyMCE’s formatting abilities

    This has nothing to do with TinyMCE πŸ™‚ “wpautop” is built-in WordPress.

    Thread Starter jcryan

    (@jcryan)

    Sorry, I wasn’t being clear. I should avoid writing responses at night when I’m cranky.

    The wpautop issue was cleared up with the ‘preserved html’ plugin mentioned earlier. The new issue was a random span tag with a class of “mce_SELRES_start” that I took care of by adding the following option to the Advanced TinyMCE editor configuration plugin:

    wp_keep_scroll_position false

    So in summary, none of these issues turned out to be caused by the Classic Editor plugin as I had originally surmised. I added the “fixes” to the thread in case someone else stumbles this way. I can now move from the Visual tab to the Text tab and not have my code molested.

    My thanks to all who provided input on this.

    –JC

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘TinyMCE clobbering multi-line tags with line breaks.’ is closed to new replies.