Trouble with Markdown and Metadesc plugins

[mattsches]

Recently, I started typing my blog entries using Markdown; I'm also using the Metadesc plugin to create more meaningful <meta>-Tags.

This is quite an obscure combination, I guess; and maybe Meta-Description does not make sense for SEO at all (anymore). The latter point came to my mind just now

Still, I ran into the following situation: The Metadesc plugin extracts the first 120 characters from the entry body (actually, from $GLOBALS['entry'][0]['body'] - d'oh) and writes them to the meta-tag. Of course, the global array still contains my Markdown code.

Markdown code in the meta description looks pretty awful. I noticed when I wanted to post my entry to Google+ because G+ reads the meta description from a given page.

I fixed it for me by adding the frontend_header event to the Markdown plugin and exchanging $GLOBALS['entry'][0]['body'] with "clean" content. I'm not sure if this might break anything for other plugins?

Actually, changing anything in the $GLOBALS array appears to me as pretty stupid in retrospect. It's probably more reasonable to disable the Metadesc plugin in any case.

I haven't committed anything yet. Sooo .. thanks for listening anyway

[garvinhicking]

Hi!

Doing that could lead, in several places, to double-encoding the entry body, or even reverting changes applied at another place. So basically, this could be very harmful.

Accessing the "current" entry body in that case is sadly not really trivial because of the execution order workflow. The best way would be to make the metadesc plugin fetch the blogentry on its own (with serendipity_fetchEntry), respecting the current $id of the current entry ($serendipity['GET']['id']). However that is much, much more performance influencing, and often the markup that is applied is not really that useful for the description in the meta desc.

So, bottom line is: I don't know an ideal solution to this problem...

[mattsches]

One possible way is to make sure the markdown plugin is executed before the metadesc plugin (the markdown should be one the first event plugins anyway) and add an additional key to the $GLOBALS array, like $GLOBALS['entry'][0]['plaintext_body'], that contains only the desired plaintext of the entry body.

The metadesc plugin can check if this key exists, and if so use its contents to fill the description. This feels slightly less awkward to me

This 'plaintext_body' could also be populated and/or changed and/or read by other plugins that want to make use of plaintext contents.

Actually, I can think of possible use cases of the top off my head like word count, semantic analysis et cetera ... hmm, I'll have to think about it

[garvinhicking]

Hi!

That's a workable approach. Metadesc could check if plaintext_body does not exist to fallback to the 'body' field, so that users who place the plugins differently ordered should at least get the current output.

So please, go ahead

Regards,
Garvin

[mattsches]

Ok, since I tripped over this problem again, I finally sat down and fixed it

I added a new global array key

Code: Select all

$GLOBALS['entry'][0]['plaintext_body']

that is currently set only by the Markdown plugin and read only by the Metadesc plugin.

Just pushed the commit, it's just a few lines of code, so not a big deal I hope. Should affect only people who are using both plugins.

Maybe the 'plaintext_body' property can be used for other purposes, too. One thing I might check later is the Facebook plugin which, IIRC, adds an 'og:title' meta property.

[Timbalu]

I just tried to upgrade the Markdown plugin, to use some new markdown versions and or the new lib and discovered that this diversion to setPlaintextBody() did plainly produce a compile error with some smartymarkup entry data by the smartymarkup Plugin.

To get around this, you have to set smartymarkup before markdown in the plugin list, or better need to check some special character rewrites, eg "_", in upper function.

Could you, mattsches, check this in deep with your function, create some workarounds, or use an option to turn this ON and note this behaviour in the description text, to not use Smartymarkup with Markdown (*) and Metadesc without knowing this?!

Thank you.

(*) textile btw does work without having to move smartymarkup up

[mattsches]

Could you, mattsches, check this in deep with your function, create some workarounds, or use an option to turn this ON and note this behaviour in the description text, to not use Smartymarkup with Markdown (*) and Metadesc without knowing this?!

Thank you.

(*) textile btw does work without having to move smartymarkup up

Thanks for the heads up, Timbalu. I will try to look into this issue as soon as possible.

Can you give me an example of smartymarkup entry data that Markdown fails to convert (and an error msg maybe)? Will be easier to reproduce and to debug that way

Anyway, I think it's quite probable that the Markdown parser would try to convert some smarty markup and fail. If it actually worked before the update: When did you last update the plugin before? The last upgrade of the Markdown lib was in 3/2012 ...

[Timbalu]

Well, my old testentry testing smartymarkup is not really something for a public test... I did discover this behaviour, since I never used textile/markdown in my local test entries before. The entries just weren't prepared to avoid this. You have to use backticks and/or block intends (for markdown) to avoid getting bothered by wrong list placements with smartymarkup.