Changing Markup Plugins for an already existing blog?

[Zugschlus]

Hi,

obviously, the s9y database stores the raw text of the blog entries, and the HTML representation is rendered from that raw text at page view time according to the current Markup settings, which is pulled from the Event Plugin configuration, an installation-wide setting.

Thus, when I decide to change markup in a blog that has already a couple of hundred entries, it is likely that formatting of all existing articles needs manual work to adapt.

May I ask why the choice of markup is not an entry-based configuration, with a default being pulled from the installation configuration?

Is there a trick to change markup plugins without having to manually touch all entries?

Any hints will be appreciated.

Greetings
Marc

[garvinhicking]

The reason for this is easy adding of new markup plugins that will affect all entries. And a performance decission, because checking each individual entry with a new property field costs more overhead.

Plus, when you edit an entry, you usually want to edit the version without markup transformations in it's usual form.

You could use the entryproperties plugin to create a cache version of your entries with markup plugins, then remove the markup plugin and use a SQL query to transform all 'body' and 'Extended' field to their cached, parsed versions.

Regards,
Garvin

[Zugschlus]

The reason for this is easy adding of new markup plugins that will affect all entries.

I do not understand this. The chance of an already written entry to be compatible with a completely new markup plugin stikes me as quite slim.

And a performance decission, because checking each individual entry with a new property field costs more overhead.

Looks acceptable to me. The current form of implementation makes it next to impossible to change plugins for an existing blog.

Plus, when you edit an entry, you usually want to edit the version without markup transformations in it's usual form.

Agreed here.

You could use the entryproperties plugin to create a cache version of your entries with markup plugins, then remove the markup plugin and use a SQL query to transform all 'body' and 'Extended' field to their cached, parsed versions.

If I understand this correctly, this works only if the target format is HTML.

Greetings
Marc

[garvinhicking]

Hi!

I do not understand this. The chance of an already written entry to be compatible with a completely new markup plugin stikes me as quite slim.

If I turn off Emotication, I don't want to have smilies in my blog anymore, but instead I do want to see ": - )" characters...

If I understand this correctly, this works only if the target format is HTML.

Yes, but the target format always is HTML, for being displayed on a HTML blog?!

Regards,
Garvin

[Zugschlus]

Hi!

Not if I intend to drop Wiki Markup and change, for example, to BBCode instead.

Yes, sure. Many markups cannot be used interchangingly. Which is the reason why whatever route we take, we always screw up the other.

If we store the HTML rendered version, it might break going from BBCode to Wiki. If we store the raw input version (like now), the format will not be displayed in the other format...

Regards,
Garvin