Formatting bug in 1.2 and 1.3
Here’s the rest of the message…
Currently (in both 1.2 and 1.3), WordPress does not store the type of formatting with the posts. So, when you load the index page, WP gets the posts from the DB and then applies ALL active formatting rules and plugins to the content of a post. This means, that both Markdown and Textile are applied. Even worse, when the content is XHTML, the Textile plugin will still convert linebreaks to <br/> tags.
This is, IMHO, a bad implementation. Are there plans to update the DB to store the formatting type so that only the relevant formatting plugin is applied to the contents of a post?
If line breaks shouldn’t be
then what should they be?
And I’m not 100% sure what you mean by storing the relevant formating. How would it get set in the first place? If both are turned on, which one becomes the relevant one? Not like there’s a place to set “apply this filter, but not this one.”
If a filter does not gracefully deal with existing HTML then it’s a bug with that filter.
ecto kung foo appears to be describing two unrelated problems
1, the wordpress formatting process is to apply formatting on every page load. I use the textile2-new plugin from idly.org and sometimes get 100 second renders for my 20 post index page. I choose to use textile2-new on my blog and mitigate its effect with the staticise plugin.
2. ecto has noticed that textile doesn’t like it when wordpress is set to auto tidy posts.
1 is a design decision
2 is a bug
Also, shouldn’t you be able to set the type of formatting on a post-by-post basis? MT supports this.
And Blogger supports making static pages….. doesn’t mean that WP should too….
It that (formatting post by post) something people feel the need to do on a regular basis?
I have no desire to enable or disable different plugins on a per post basis, possibly because I find that the textile2-new plugin does everything I need. later though I might find a new plugin that I prefer but because my whole archive is textile2-new I cant change over.
what might be interesting though is having a hook that allows a plugin to process the text in a post and insert it back into the database, allowing the user at post creation time to pick a set of plugins to process the text and then only store the final xhtml markup in the database.
of course that would then make editing the post harder at a later date, and would be confusing for new users and a whole host of other design issues which would need to be solved.
I am very very happy with the current system, my only wish would be for the plugin I use to get faster.
Well, personally I never use any other text formatting than XHTML. Textile, Markdown and consorts are nice and all, but using them always means that you have to have a parser that understands that kind of formatting. That means it seriously hampers forwards, backwards or even sideways compatibility.
@allusion: exactly what part of womby’s post is possible with the latest CVS?
Picking a text processing plugin that at post time inserts XHTML into the database?
And if so, is that the _wp_page_template option I see down in the custom field area?
- The topic ‘Formatting bug in 1.2 and 1.3’ is closed to new replies.