TracLinks cut when specifying max_size in BlogList

[whitelynx]

When using the BlogList macro and specifying max_size, it simply trims the raw wiki text, which will sometimes cut TracLinks in half.

[osimons]

Yes, I know - and might I add: It was a concious decision to just do it that way. It is a very complex thing to trim it without interfering with any markup - be it links, pre-formatted text or whatever. You do not necessarily know what the wiki markup will render as before actually rendering it. Regardless of how it is done, it is quite likely that it won't be sufficient in all circumstances.

I did look at what pacopablo did for his TracBlogPlugin - see tracblogplugin/0.10/tBlog/web_ui.py@3516#L622​. I pondered nabbing that code some 6 months ago, but decided against it.

Now that pacopablo come on board the FullBlogPlugin team for 0.11+, he might feel it is worth porting that code or some variation of it? I haven't used that plugin and don't really now how successful that trimming actually is. John, what do you think?

[John Hampton]

Well, my solution worked pretty well. I never received any bugs with it. The biggest problem is that it wasn't a hard cut. I always cut at the end of the line. This saved me from having to deal with most of the wiki markup. However, if someone has a long paragraph that is a single line, then the post can be much longer than the max_size

[osimons]

Replying to pacopablo:

Well, my solution worked pretty well.

Nice. Reading through it again I think it represents a fair trade-off between avoiding unexpected output without too much complexity.

However, if someone has a long paragraph that is a single line, then the post can be much longer than the max_size.

Or some macro like [[TicketQuery]] in table mode is part of the content that gets rendered. Or using the [[Include]] macro pulling in a full page resource from somewhere else....

Anyway pacopablo, feel free if you want to port that code to a new util method :-)

(PS! As a possible alternative, one could render everything first and then trim at the HTML level - open (and push onto a heap) the discovered tags and traverse the tree until max_size from text() length is exceeded, and then just pop off and close the tags that are left on the heap. Perhaps... Or maybe it just introduces new kinds of corner-cases...)

[osimons]

#6347 closed as duplicate.

[Dan Sheridan]

Trivial port of pacopablo's splitting function

[Ryan J Ollos]

Screen capture of sidebar.

[Ryan J Ollos]

Screen capture from my Trac installation demonstrating the issue.

[anonymous]

Has any changes with this problem?