BlogFeatures

This is a follow-on to PITS:00028, requesting blog support in PmWiki

Many people have expressed that they prefer PmWiki to stay "lean" and not become overloaded with blogging support; this page leaves that question for PITS:00028 and the mailing lists. Instead, assuming that we're to support blogs in some form, what features do we need to have (and how important is each)?

Let's start with just a bullet list of possible features (and priority voting for each), with discussion about individual feature items lower on the page.

Descriptions	Votes
Features for the posting to the blog
XML-RPC support for standard APIs. (Started in the cookbook.)	554333 322
Ability to have both Draft and Posted statuses for blog entries, and to easily move from Draft to Posted. (see PmWiki.Drafts)	55554 4433
Ability to set (:title:) and categories in separate boxes on the edit form. (see Cookbook.EditAttributes)	55444 444
(next)	-
Features for presenting the blog
A front page showing the most recent X articles, sorted chronologically	55555 55555
Article categories independent of presentation. Invisible category links, basically (see Cookbook.Bloge-Tags)	55444 443
A calendar in SideBar with days with articles indicated (--Kab)	55553 53331
(next)	-
Features for interacting with the blog
Display of incoming trackbacks (see Cookbook.Bloge-Linkback)	54444 331
Means of posting via email	54331
Comments form which does not require the user to be familiar with Wiki editing or to be authorized to edit the full page	55555 5555
Some captcha-type or other-type mechanism to prevent comment spam	5555
(next)	-
Features for connecting to other blogs and other software
Outgoing and incoming trackback support (see Cookbook.Bloge-Linkback)	54443 331
RSS for the whole blog, or for individual categories	55555 5541
RSS for comments pages	55544 4331
RSS for either all comments, or comments on specific posts.	5
(next)	-

---

Invisible category links are already possible, use %comment% [[!SomeCategory]]. -- Pm

That's good to know. Do you think it would be a good idea to create a %category% style that administrators could modify to control whether or not to display category links? --Russell

Administrators can already do this, either %define=category comment% or else $WikiStyle['category']['display'] = 'none'; .

I actually meant "would it be a good thing to put in the recipe?" :) --Russell

Can someone give me a clear explanation of trackbacks? I've read numerous online articles about them but I've never understood exactly what they are or how they're supposed to work. --Pm

http://en.wikipedia.org/wiki/TrackBack has a short description and some links that might help (I think I know what they are, but not how the protocol is defined ;) Balu

The more I think about it, the more it seems to me that the best way to manage the blog (and perhaps the comments) is to use a WikiTrail.

Yes, I've been planning that the comments feature would need to be able to support comments as a WikiTrail, or an easy way to index the comments. --Pm

Posting an article would update an index trail, which would look like something like this:

* 9/2/2005
** 10:45 AM
*** [[Articles.SoTodayWasAReallyWeirdDay]]
** 12:01 AM
*** [[Articles.NewsFromTheJobHunt]]
* 8/29/2005
** 4:34 PM
*** [[Articles.ServerUpgradeResults]]

The front page of the blog, then, would use a directive something like this:

(:includetrail pages=$1:)

Pages would be the maximum number of pages from the trail to embed in the front page.

--Russell

Actually, now that I think about it some more, it makes more sense as some kind of extension to PageList ?. Like (:pagelist trail=Blog.Index order=trailsAsDateTime count=10:). --Russell

Yes, I see extending the PageList directive as a much more easy and elegant. I've played with inserting the pages inside the pagelist, altough it is a bit tricy it works (need to insert formating as wiki markup instead of html). "Pages" is just the same thing as "count", why have another name? MarcioRPS

If one's going to use a trail, why not simply use the RecentChanges page? I mean, just like the cateories thing, it is very possible to make this without any modification whatsoever to the wiki... MarcioRPS

I'd like to be able to maintain the date and other information used by the index separately from the actual date of the file modification. For example, if I change my article from January to fix a spelling mistake, I want the RecentChanges page to show the update, but I don't want the entry to suddenly jump forward to today.

And that's exactly what I *would* like it to do. So this better be optional. ;) I have lots of stories/lists that I would like to see on top (and on the frontpage) after having edited them again, even after years. Or at least see listed as recently edited in some column left or right. Maybe mentioning its creation date (next to its current position, last edit) would be a good thing. ~jult

Actually, I don't think the main blog-tool is really listed there! A simple way to set and read the date of a page. This way a blog would be just a matter of tweaking the New Page Form recipe to allow correct date setting and cretating some new FPL functions for the blog (a custom simple list for the sidebar, one that includes the actual pages, one that lists pages grouped by month, etc...).

-- MarcioRPS September 22, 2005, at 04:28 PM

This is why I was suggesting using a trail- it allows us to keep the article modification date separately from the date the article is displayed for. --Russell

As for the Draft/Posted feature, I think the way to offer this is to allow the user to easily change the Group of an article, and to base the trail-indexing on the group a page is saved into.

--Russell

I finally invented an implementation idea (or has anyone done that before?) how to solve the problem of A front page showing the most recent X articles, sorted chronologically, which I believe to be the biggest problem implementing a blog on a flat-file based wiki (as PmWiki is). I explained the idea on the Cookbook.Bundle4Blog page, as a sentence there made me think of that. However, I'm not so sure now if you all also think that is The Problem. Still, I'm very keen to see my idea implemented, especially as that'd ease the 'RecentNews'-kind of pages creation, what I'm interested in. I may even implement it myself, but now I'm completely out of time.

Hey, and what do you think about this idea?

Greetz
Mateusz

Category: Blog

By Graham 29 MAR 07 What about multi-blogs. Each user has there own blog. OR are you thinking in terms of traditional wiki and let everyone edit the blog. If so, would it still be a blog?

I still support the notion that most of the features above are available to PmWiki already, and I have the XESBlog recipe to showcase it -- but it is pulling together several recipes and I think Patrick still hasn't looked at it :) One disappointment is that currently the XML-RPC recipe is broken -- so some change to PmWiki must have rendered it unable to work. I'll have to see if I can go over the changelog and determine what it might be. I think I emailed the recipe author but haven't heard back. The other possibility is migration from PHP4 -> 5. Anyway, the XML-RPC recipe was a VERY powerful way to manage a large wiki or MANY large wikis and it's a shame it's not working right now.

Trackbacks: 1) a URL in a metatag that would be used to let PmWiki know "Someone blogged about this post" -- then PmWiki would grab a snippet & link for the post, and essentially add it to the comments area. 2) when a post is posted, external links are checked for the same metatag, and the information "Hey, we blogged about this webpage" is sent to the remote server, which then picks up some text from the page in question (or perhaps the info is sent....).

XES January 11, 2009, at 11:38 PM

Edit: XMLRPC is STILL a very powerful feature -- PmWiki however probably didn't break it. PHP5 did. It involves tons of tedious PHP4 XML parsing which changed in PHP5 (probably for the much-better). I would have loved it to be something simple I could do, but I don't understand PHP5's XML or XMLRPC enough to write this package again myself. There's always the possibility that there's an easy XMLRPC class waiting out there that could use a modified version of the PmWiki-compatible xmlrpc.php (the XML parsing was in separate external class files in a subfolder....). I can poke around and see if there's something easily integrated out there but it sounds like a project outside my current capability and time. *sniffs* XES March 01, 2010, at 06:14 PM

We should add scheduling as a feature to the vote. Above there's mention of "drafts"->"posted" status. There should be a way to give a time at which a post moves from draft -> posted that requires no further human interaction. What I've done is postdate entries and filter my pagelists based on today's date. Scheduling posts allows "publication" of posts (podcasts, etc.) on a set schedule (every Tuesday) and is vital for businesses and professionals. XES September 20, 2017, at 05:26 AM