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.
Invisible category links are already possible, use
That's good to know. Do you think it would be a good idea to create a
Administrators can already do this, either
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
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.
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:
Pages would be the maximum number of pages from the trail to embed in the front page.
Actually, now that I think about it some more, it makes more sense as some kind of extension to PageList?. Like
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.
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?
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