MySQL Abuse

M_i · 2006-06-28 19:07:16

Sencer wrote:

Textpattern has always fetched and processed the article-body, even in lists that don’t explicitly call the body-tag.

What does that mean, exactly?
Would that mean that if you produce a list of articles that have a whole lot of text in them, that would take a whole lot longer than producing a list of articles with only a little bit of text in them, even if all you’re displaying in the list is the article’s title?

On your recommendation, I went looking for any queries that take a lot longer than the others, and the only ones that really stood out were those called by txp:article (or (chh_)article_custom) to produce lists.
Could that be because the some of my most recent articles happen to have a fair amount of text in them?

Sencer · 2006-06-28 19:58:55

Would that mean that if you produce a list of articles that have a whole lot of text in them, that would take a whole lot longer than producing a list of articles with only a little bit of text in them, even if all you’re displaying in the list is the article’s title?

In almost all cases: No – because Textpattern stores the posts with textile processed. Meaning there will be no measurable difference. Only txp-tags are stored as-is and processed on view, which usually doesn’t have any measurable negative effect either – the exception being plugin-calls that do db-queries. But like I said, this will probably change in 4.0.4 anyhow…

net-carver · 2006-06-29 03:35:59

Sencer wrote:

Textpattern has always fetched and processed the article-body, even in lists that don’t explicitly call the body-tag. Changes had been considered in the past but dropped because we were not sure if any plugins rely on that behaviour. If I am not mistaken Alex finall checked in the change (which will roll out in 4.0.4) after no indication was found that any plugins actually do rely on it. Unless there are complaints before the next release, it’ll probably stay in.

Sencer, that behaviour is currently needed by some localisation plugins, but it could be worked around. Graeme’s recently posted plugin and one I am working on locally need to be able to localise articles for display in multi-lingual sites and both rely on the article body being parsed, even if the body content isn’t displayed. This is needed for switching the article title to the correct language, important in article lists, lists of links etc, where the body isn’t needed.

Thinking aloud about options to get around this…

Would it be possible to make the parsing of article data an admin-configurable option so that those, relatively few plugins could keep the behaviour?
Add a new event, at the end of populating the article data (even if the body and excerpt are unparsed), that plugins could register a handler for, that would allow them to switch the title etc, according to the language settings, before the title is used?
We re-evaluate implementation strategies for multi-lingual plugins in light of this.

Thanks for the warning about this change, hope we can work something out.

zem · 2006-06-29 04:33:18

A simpler solution: plugins that require a parsed article body can simply parse it.

Whatever the solution, the body parse changes are available for all to test and debug.

net-carver · 2006-06-29 08:17:50

Alex,

Will take a look over the next couple of days and post back to your referenced thread.

Thanks for the pointer.

Edit: Some feedback posted here.

Last edited by net-carver (2006-06-29 12:20:59)

graeme · 2006-06-29 16:31:06

net-carver,

zem wrote:

A simpler solution: plugins that require a parsed article body can simply parse it.

For your information this is why my plugin didn’t break after r1303 – a simple return parse($thing);

Textpattern CMS

Textpattern CMS support forum

#25 2006-06-28 19:07:16

Re: MySQL Abuse

#26 2006-06-28 19:58:55

Re: MySQL Abuse

#27 2006-06-29 03:35:59

Re: MySQL Abuse

#28 2006-06-29 04:33:18

Re: MySQL Abuse

#29 2006-06-29 08:17:50

Re: MySQL Abuse

#30 2006-06-29 16:31:06

Re: MySQL Abuse

Board footer