Missing number sign # for first occurrence of a special character

[gizmecano]

I just discovered an issue concerning special characters.

Strangely, the very first occurrence of such a character is rendred without the number sign #, which of course causes a display problem.

For example, a specific string (1) is converted in meta name="description" content and meta property="og:description" content as (2) and will be displayed in a link as (3) :

1. « texte entre guillemets »
2. &171; texte entre guillemets »
3. &171; texte entre guillemets »

I have to add that I use the plugin Smartypants (wondering it may be a compatibility problem between the two plugins).

[paulmassen]

Hmmm, I'm not sure I really understand the problem.
If you take a look at this page, you will see the word "Congratulations" between quote. and this is rendered correctly as below:

<meta name="description" content="Say Hello to Grav!. installation successful...Congratulations! You have installed the Base Grav Package that provides a simple page and the default Quark theme to get you started.!! If you see a 404 Error when you click Typography in the menu, please refer to the troubleshooting guide.Find out all about Grav. . Learn a" />

Do you have some more details?

[gizmecano]

Your example disorients me even more. 😕

Indeed, the word "congratulations" is rendered with (English) quote marks in your HTML page (I haven't any issue with HTML display).

But, even in your own example, the content of the meta description content is rendered without any quote marks:
Say Hello to Grav!. installation successful... Congratulations!

When would be expected:
Say Hello to Grav! installation successful... "Congratulations"!

In my case, quote marks are not entirely erased as in your own example, but it's only the first occurence of a special entity which got its number sign # skipped.

So, when a meta content have to contains « texte entre guillemets » it is rendered as &171; texte entre guillemets » (because the first number sign is skipped).

Hoping to have been clearer...

[paulmassen]

Ahh, I see, I think I understand and that actually it is expected behavior.

The plugin will pick the content from the markdown editor and will performs several action to remove any special character from markdown content, including the #, ** etc.

[gizmecano]

I'm not sure to understand : if the expected behaviour consists in fully removing all special characters (from Markdown input to HTML output), why in my case is it only the very first occurrence which actually seems to be really performed? All others special characters following this first one are correctly rendered as HTML entities..