post_content_filtered should be longtext

[ejdanderson]

From my understanding, the post_content_filtered column exists to cache expensive content transformations. Thus, its type should match that of post_content - 'longtext' instead of just 'text'.

[nacin]

Agreed in theory. In practice, this kind of ALTER might get ugly.

[johnbillion]

I wonder if anyone actually uses that field to cache processed post content.

[nacin]

I've used it during content migrations. Mark implemented it for Markdown: ​http://wordpress.org/extend/plugins/markdown-on-save/.

[ejdanderson]

Replying to nacin:

Agreed in theory. In practice, this kind of ALTER might get ugly.

Ugly in terms of run time on a DB such as WP.com? Or the 3 additional bytes per row required?

Replying to johnbillion:

I wonder if anyone actually uses that field to cache processed post content.

I've used it to store XML defined by an additional DTD.

[nacin]

I was referring to run time, yes.

[ejdanderson]

Replying to nacin:

I was referring to run time, yes.

Thanks for clearing that up, I have a strong feeling you have more experience with that than I do :)

Consequently, wouldn't it be better to get this in as early as possible to minimize the size of the DBs it needs to preform the alter on? Or is it a fix that more than likely won't make it into core at any time?

[nacin]

Consequently, wouldn't it be better to get this in as early as possible to minimize the size of the DBs it needs to preform the alter on?

There are quite a few installs out there already. :-)

Our existing database schema API doesn't really allow the flexibility of doing this for new installs only, without touching existing installs. (Which is something that would be easier to swallow.)

I do know it took them about 3 weeks on WP.com to add the commentmeta tables. I don't expect them to ever merge over a change like this one, so it's irrelevant to them, but it's still something to consider. I'm not familiar with the performance aspects here. Someone like ryan who was around during previous schema changes could talk about it a bit more.

[ejdanderson]

$wpdb->posts not wp_posts

[markjaquith]

I got bitten by this issue recently while using a plugin that uses post_content_filtered. We should do the ALTER. It's crazy that it doesn't match post_content, given its intended usage by plugins.

[nacin]

Simply changing it in $wp_queries will be enough for dbDelta() to run the ALTER, so we don't need the separate ALTER in the upgrade routine.

That also means we can't actually apply this only to new installs, and not old installs. I think that will be okay, but we should look into how slow this kind of ALTER is depending on the size of the post table. (Does it help that this field will nearly always be empty?)

[ryan]

In [19863]:

Switch post_content_filtered from text to longtext so that it matches post_content. Props ejdanderson. fixes #19387