Quote from FTP on June 20, 2019, 9:55 pm

BTW, I confirm all this is the default behaviour of a brand new WP with Asgaros only, no other theme, no other extension.

But… it’s not the behaviour of the Page & Article editors. Only Asgaros and probably all front-end editors.

Quote from FTP on June 20, 2019, 9:57 pm

Quote from Asgaros on June 20, 2019, 9:55 pm

Actually this plugin should not do anything anymore in the latest version of WordPress because it seems that the option_use_smiliesfilter doesnt even exist anymore inside of the code. At least I dont get any results when searching for it over the sources.

Yep, same for my search. But it works! Install it and you will see it does disable all kind of parsing.
It’s maybe a concatenation that gives this name.

Quote from FTP on June 20, 2019, 10:00 pm

If you just keep “use_smilies” you have 9 results that correspond as it’s all about a former option that was in Formatting removed in WP 4.3…
https://wordpress.org/plugins/keep-emoticons-as-text/

Quote from FTP on June 20, 2019, 10:05 pm

Bingo…

/**
 * Pre-filters captured option values before retrieving.
 *
 * @since 3.9.0
 *
 * @param mixed $value Value to return instead of the option value.
 * @return mixed Filtered option value.
 */
public function capture_filter_pre_get_option( $value ) {
  $option_name = preg_replace( '/^pre_option_/', '', current_filter() );

  if ( isset( $this->_captured_options[ $option_name ] ) ) {
    $value = $this->_captured_options[ $option_name ];

    /** This filter is documented in wp-includes/option.php */
    $value = apply_filters( 'option_' . $option_name, $value, $option_name );
  }

  return $value;
}

And…

  /**
   * Filters the value of an existing option.
   *
   * The dynamic portion of the hook name, `$option`, refers to the option name.
   *
   * @since 1.5.0 As 'option_' . $setting
   * @since 3.0.0
   * @since 4.4.0 The `$option` parameter was added.
   *
   * @param mixed  $value  Value of the option. If stored serialized, it will be
   *                       unserialized prior to being returned.
   * @param string $option Option name.
   */
  return apply_filters( "option_{$option}", maybe_unserialize( $value ), $option );
}

Concatenation of  ‘option_’ . $option_name & “option_{$option}”

Quote from Asgaros on June 20, 2019, 10:16 pm

To summarize it:

• I installed and activated the “Keep Emoticons as Text” plugin
• Writing a new post with a smiley
• Save it
• The smiley is shown as typed and not as an emoticon
• Open the editor to edit the post: The smiley is still shown as typed and not as an emoticon

So actually the problem is: If you at some point edit the post without the activated “Keep Emoticons as Text” plugin, the smiley gets converted into a UTF8-emoticon and saved into the database. At this point its not possible anymore to revert this.

But: Why is it working normally in the backend? Because the entire smiley-option is not included/loaded there. Why? Because its not intended to show smileys or parsed content (e.g. executed shortcodes) in general there. However, in the background the conversion-code is included and it seems that it only can get removed globally and not from the editor only.

Quote from FTP on June 20, 2019, 10:16 pm

2 functions use this option:

convert_smilies() in formatting.php

/**
* Convert text equivalent of smilies to images.

And smilies_init() in functions.php

/**
* Convert smiley code to the icon graphic file equivalent.

One of those 2 must be call before editing posts in front-end while it should not.

Quote from Asgaros on June 20, 2019, 10:19 pm

No, it is not called before editing posts. Basically its called everytime when something happens on the page – like clicking a link or changing some other elements inside it. There is some JavaScript-code included which basically triggers the conversion in this case automatically:

Quote from FTP on June 20, 2019, 10:20 pm

Quote from Asgaros on June 20, 2019, 10:16 pm

To summarize it:

• I installed and activated the “Keep Emoticons as Text” plugin
• Writing a new post with a smiley
• Save it
• The smiley is shown as typed and not as an emoticon
• Open the editor to edit the post: The smiley is still shown as typed and not as an emoticon

So actually the problem is: If you at some point edit the post without the activated “Keep Emoticons as Text” plugin, the smiley gets converted into a UTF8-emoticon and saved into the database. At this point its not possible anymore to revert this.

Correct! And not only smilies. Try with short code it also parse them.

BTW it makes me think to test if “Keep Emoticons as Text” plugin stops the short code parsing or not, as we may have 2 parsing to stop before editing in the front-end editor.

Quote from Asgaros on June 20, 2019, 10:22 pm

This means: This code and event-listeners are available globally all the time for the entire document and not related in any way to the editor. So the only way is to disable it globally – or more specific: if you are inside of the editor-view.

But the problem with this is, that in this case smileys will also be not available for all other (non-forum related) areas on the current site (which contains the editor-view). This can be okay in most of the cases, but could have impacts on other content where smileys are intended to be shown, like in sidebar-widgets or other content-parts inside of the theme.