Project blog - A pyblosxom macro/plugin

[anonymous]

I think a project specific blog would be an excellent addition to Trac.

[daniel]

Agreed.

What actually i was planning, is to have a macro plugion for pyblosxom.

on http://blog.edgewall.com/ we have a simple wrapper script for pyblosxom and it works quite well.

A pyblosxom macro would allow including a part of a blog on any wiki page, to for example display "project news" etc...

[anonymous]

wiki + blog would be perfect. Aslo it would be nice for each user to have it's own front page.

[cmlenz]

See TracPluggableModules.

[anonymous]

Hi Guys,

Like most people, I was *very* impressed with Trac and the seamless way it's integrated into everything else at edgewall.com -- it's very hard to tell where Trac stops and other code picks up. Hence the problem...

After spending a lot of time drooling over projects.edgewall.com, then installing trac, then configuring for multiple projects, I realized trac didn't include the blog features seen on projects.edgewall.com. I just now spent over an hour googling around trying to figure out what was going on. I finally found http://lists.edgewall.com/archive/trac/2004-November/001212.html (a well-written post which it looks like nobody answered), which mentions pyblosxom and points here. Whew.

But after reading this ticket I see the priority has gone from "high" back to "normal", the milestone has been put off 'till "someday", and the TracPluggableModules page looks like it's nowhere near a consensus on design as of this writing... Uh oh. This all tells me I shouldn't wait for any sort of blog integration, not this year anyway.

So... I'll repeat the question Dirk posted on the mailing list last November: "In the ticket #607 you mention a script to wrap pyblosxom. what does this script actually do? Is it available somewhere? Can you give further information about the blog installation on edgewall[?]".

I think if you were to attach here even a stripped-down version of that wrapper script it would hold off the maurauding hordes long enough for you to have the time to think through a longer-term plugin architecture. I think many folks would be satiated by at least being able to emulate what they see at Edgewall, and can live without embedding for the time being. I for one would be able to make good use of that script, no matter how simple. Right now I'm frankly mystified as to where and how it hooks in -- I've gotten as far as thinking that '/' is being handled by the script, and over time could probably work out the rest, but... I'd rather spend my time helping to contribute code to Trac rather than duplicating something you've already done.

Am I making any sense?

(If you can provide that script, feel free to drop the priority on this back to something lower, at least as far as I'm concerned.)

Steve -- http://www.stevegt.com, stevegt@…

[anonymous]

Note for fellow travelers -- also see http://projects.edgewall.com/trac/wiki/MacroBazaar#Blog -- not yet sure how it's related to all this, looks like Edgewall's site might be using it in conjunction with http://projects.edgewall.com/trac/wiki/MacroBazaar#WikiCalendar (is pyblosxom even still in use there, or is this bug talking about ancient history?)

I think I'm going to stop thrashing about uselessly now, and go get some sleep. ;-)

[mgood]

#1658 has been marked as a duplicate of this ticket.

[ECKHART.CURT@…]

blog.edgewall.com seems to be dead now. What is the status of this ticket?

[cmlenz]

This kind of feature can now be done relatively easily as third-party plugin.

[athomas]

TracBlogPlugin is just such a plugin.

[spamfaenger@…]

Trac needs a good blog module in the standard distribution. Solutions like TracBlogPlugin kinda work, but they develop very slowly and most projects end up combining Trac with a blog like wordpress.

Which instantly looses all the great trac-features enabled by its link feature.

Therefore:

• Trac should have a blog module in its core
• It should support posts, with images (as attachements to the pages)
• real comments with specific righs BLOG_COMMENTS_POSTER
• topics (kinda provided by trac-tags but needs categorie display and rss feeds for categories)
• great rss support, with rss-feeds for specific subsets of the blog
• Access to these tools via XML-RPC (livejournal.com or atom api)

These are good reasons to consider making blogging a strength of trac, instead of the weakness it currently often is.

So please reconsider adding native blogging to Trac

[sid]

I don't agree that Trac needs a blog module. We use Trac for our internal software development, and have no need or use for a blog as part of the package. The ticket/SVN/wiki combo is very powerful and handles 90% of our needs (the others needs are more process based). Personally, I think a blog plugin is the best option, and there are a few out there already. If those don't work, perhaps you want to start building a better one?

[eblot]

Replying to sid:

I don't agree that Trac needs a blog module.

+1.

[mgood]

None of those features require the plugin to be part of the core, and integrating it would simply mean that it was tied to the Trac release cycle, so any updates would take longer to get to users. Also, absorbing a plugin into the core because it has stagnated is simply going to bloat the core with unmaintained code.

So, instead please file tickets on the plugin for any feature requests. If pacopablo doesn't have the time to work on these right now, ask on the MailingList to see if other users would be interested in working on patches for those features, or ask for help on the developers MailingList if you'd like to work on a patch yourself.