Opened 10 years ago

Closed 10 years ago

#447 closed defect (fixed)

Displaying blog entries with a certain tag on a page that has this tag too leads to a neverending recursion

Reported by: tdad Owned by: pacopablo
Priority: normal Component: TracBlogPlugin
Severity: critical Keywords: recursion blog tags
Cc: chief@… Trac Release: 0.9


i wanted to display blog-entries tagged with trac on a certain page. i saved the page and wondered why the original content was then displayed about 30 times in series. then i realized that i tagged the page, i wanted to display the entries on, with trac too. so it tried to "include" itself on and on. shouldn't there be some possibility to differentiate between wiki-pages and blog-entries? i don't want to get wiki-pages displayed in a blog-listing that are accidentally tagged with the same tag, the blog "listens" on.

Attachments (0)

Change History (6)

comment:1 Changed 10 years ago by tdad

  • Summary changed from Using "trac" as a blog-tag leads possibly to a neverending recursion to Displaying blog entries with a certain tag on a page that has this tag too leads to a neverending recursion

fixed the title a bit.

comment:2 Changed 10 years ago by pacopablo

  • Status changed from new to assigned

Well, I'll agree that the recursion is definitely a bug. I'll try to fix it in the next day or two. As a work around, you can add the BlogShow to the Macro Blacklist option of the ini file. (Easiest to do so through webadmin plugin).

Now, on the next point, what would you suggest? Blog posts ARE wiki pages. The tag is the only thing that *sort of* differentiates the two. I'll also add that it's intentional that there is no real distinction between wiki pages and blog entries.

However, that being said. It doesn't make since to include the page that is trying to display the blog. If I can determine which page is calling the BlogShow macro, then it'll be easy enough to simply remove that page from the results. Would that be sufficient? Or were you thinking about something else?

comment:3 follow-up: Changed 10 years ago by tdad

i don't know the one and only truth. i was first thinking of some special database flag for blog pages but i wasn't sure about his one because i didn't know the reason why you're handling blog pages as normal wiki pages (convinience?). maybe some hint in the readme-file to not tag wiki pages like a blog would be enough?

comment:4 in reply to: ↑ 3 Changed 10 years ago by pacopablo

You can think of the tags as those special database flags :)

Convenience is one reason that I decided to use wiki pages. The other reason is that I don't see why blog pages really have to be different. I like the idea that I can create a "blog" of any topic in my site.

I'll try to make a note in the documentation that makes the difference a little clearer. I'll also try to implement the changes that I mentioned in my last comment

comment:5 Changed 10 years ago by tdad

don't get me wrong. i like the idea, too. i was just thinking of an additional flag that prevents "normal" wiki pages from being included in the blog listing. as the wiki engine wouldn't (hopefully?) care about this flag, the blog entries could still be displayed as wiki pages as well.

comment:6 Changed 10 years ago by pacopablo

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [935]) Part of the reason for not including a special flag is the whole complexity deal. Right now the blog plugin doesn't have to update the enviroment in anyway. This is nice. Also, normal wiki pages aren't tagged with anything by default. Blog pages should be tagged with 'blog' by default, unless you specifically go into webadmin and change the 'Default Tag' setting.

  • Added BlogShow macro to the macro blacklist. It need not be specified in the 'Macro Blacklist' webadmin option.
  • Added a check for recursive reference. The BlogShow macro will not render the page from which it is called if it happens to be one of the pages in the list of tagged blog entries
  • Closes #447

Add Comment

Modify Ticket

as closed The owner will remain pacopablo.
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.