Recent Changes - Search:



« Return to BlogIt

Summary: Talk page for BlogIt.
Maintainer: DaveG
Categories: Blog

Open Questions

Use this page to report issues, ask questions, or make suggestions for future improvements. If you-d like to leave a quick thank you, or would like to leave a rating, please do that on the ratings page.

In order to keep things readable please:

  • Please place newer comments or issues at the top of the list
  • separate comments or issues with new level 2 headings
  • If you feel that your question has been answered, please move it to the closed questions section below.

off-byn conflict with SourceBlock

Status: Open

There is an off-byn issue when BlogIt is used with the SourceBlock recipe. When I disable BlogIt, or use sourceblock on non-blog pages, the num=n parameters are correct. When BlogIt is enabled, the num=n params are off on all blog-pages. If one source-block is present, the first block is off-by-one (eg, 2). If two source-blocks are present, the first block is off-by-two, and the others proceed in sequence (eg, 3,4). If three source-blocks are present, the first is off-by-three, and the others proceed in sequence (eg, 4,5,6). So it's an off-byn issue, where n is the number of source-blocks present.

SourceBlock uses a global variable to count the number of sourceblocks present on the page; without actually running through a debugger or throwing lots of logging and tracing at the code, it appears the BlogIt is reading/interpreting the pages 'twice causing the count to be doubled.

The point of impact appears at line 58 of sourceblock.php (as of version 2012-07-06 ) :

function SourceBlockGetCodeInit($pagename, &$opt) {
  global $SourceBlockDivNumber, $EnableSourceBlockGetCode;
  SDV($SourceBlockDivNumber, 0);

This issue has been mentioned at SourceBlock-Talk with less detail.

MichaelPaulukonis August 25, 2014, at 09:35 AM

Cancel on bi_be can send to another page

Status: Open

Steps to Reproduce:

  1. Open a blog page
  2. Edit a blog page
  3. Cancel
    • Behavior is as expected:
      • editing is cancelled
      • and user remains on blog page.
  4. Open a link in a new tab
    • scroll-wheel click on link
    • or right-click >> "Open in new tab"
    • leave this tab open
  5. Edit blog page
  6. Cancel
    • Behavior is not as expected:
      • editing is cancelled
      • but user is redirected to page previously opened in new tab
      • there are now two tabs showing the same page

MichaelPaulukonis July 22, 2014, at 10:48 AM

MichaelPaulukonis' wishlist (created 2014.07.10)

Status: Open

  • fix for cancel-button problem
  • fix for spaces in tags (known issue) Fixed 1.9.5
  • blog-post preview
  • GUI-buttons in ajax edit
  • links on blog pages to non-existent pages in default blogit-group open in blogit editor (or an easy way to add all blogit-entry boilerplate to a page. group.template, perhaps?)
    • example: I'm editing Blog.NewEntry and it contains a link to Blog.NonExistantPage. Instead of this link opening with the standard "page does note exist" message, it should open in the BlogIt entry editor.
  • (optional?) ability to add (change) Summary change on blogit-edit; currently, all edit summaries are blank when viewing history
    • perhaps most users won't do this; I'm using BlogIt as an "Engineer's Journal" so I'm revising the daily entries all day long.
    • still, some users might? If not part of core BlogIt, how about as a plugin?

Posting comment results in Parsing JSON Error *h3%

Status: Pending Response

No Sidebar visible

Status: Pending Response

Jazzvox December 18, 2011, at 05:14 AM: I have the "New Entry in SideBar and Form not showing" problem, therefore searching for a solution. After I've installed BlogIt at the very beginning (my setup at AuthDNS-Talk) it worked as expected.

Now that I've added AuthUser and PmForm I get a regular page instead of NewEntry :( Please check Attach:Cookbook/toPetko.zipΔ to see my config.php - as differing recipe sequence advisories are confusing me.

In addition, the archive contains a completed German language file: Site.XLPage-BlogIt-DE

DaveG 20-Jan-2012: Jazzvox, sorry for the delayed response. Before I spend too much time looking at this could you confirm you still need a resolution?

Confirm delete posts

Status: Open Farvardin 2011-11-11: I don't see a way to add a confirmation dialog before deleting posts (using the non-ajax interface).

DaveG 11-Dec-2011: Added a change request for this.

"Print" issue and some feedback

Status: Bug and request logged

Farvardin 2011-10-16 I'm using this cookbook for some time now, and it's really good.

I've just noticed there is an issue when using the "print" link, the blog content is not shown. This can be viewed there:

For my needs, I found that I wanted to create a default page name for my entries. Therefore I added this to my local/config.php:

function processBlogsPrePagename($src, $auth){
global $_POST,$action;
$today = date("Y-m-d");
	if ($action=='bi_ne')  $_POST['ptv_entryurl']='Blog.'.$today;

I'd also like to be able to save the entry, without leaving the edit form (quicksave)

DaveG 30-Mar-2016: Print bug resolved, added default page name to FAQ.

DaveG 16-Oct-2011: The print bug is interesting, I'll take a look at that. I do know it used to work, so something messed up somewhere. I've logged both the print bug, and the feature request (very useful), and also added the pre-hook code to the faq. Thanks for your input.

Implementing Multiple Blogs

Status: Waiting for confirmation

Bruce K, 30 Aug 11 I can get the suggested code to work properly by hardcoding one of my blogid values to replace MY_BLOG_ID. But I can't figure out where (or how) to define a different blogid value for each Blog. Each of my 3 blogs uses a different dedicated Group, so I've tried building a Group.SideBar (copied from Site.SideBar) with the proper blogid hardcoded in each one. That did not seem to work reliably. Can you be more specific about the best way to implement this?

If you are using multiple blogs, then pass the blogid as a parameter (replacing MY_BLOG_ID):

(:if equal {$bi_BlogIt_Enabled} 1:)(:include Site.BlogIt-SideBar blogid=MY_BLOG_ID:)
<<original sidebar text>>

DaveG 31-Aug-2011: Looks like the link to the 'multiple blogs' section was broken. I've now fixed it, and added an example. Basically you need to define the blogs in $bi_BlogList and they will show up in a pulldown list on the blog-entry screen.

$bi_BlogList = array('blog1','blog2','blog3');

Bruce K, 31 Aug 11 Thanks. That part is working well. I still need to pass the desired blogid value ( blog1, blog2, etc) to the SideBar in order to retrieve the proper list. It all works if I can properly pass the value via MY_BLOG_ID. How would you do that?

DaveG 31-Aug-2011: Use conditional markup in the sidebar. So based on group pass a different blogid. Something like:

(:if [ group Group1 && equal {$bi_BlogIt_Enabled} 1 ] :)(:include Site.BlogIt-SideBar blogid=blogid1:)
(:elseif [ group Group2 && equal {$bi_BlogIt_Enabled} 1 ] :)(:include Site.BlogIt-SideBar blogid=blogid2:)
<<original sidebar text>>

Bruce K, 31 Aug 11 That works great. Finally, I need to set the "initial" value for Pagename from "Blog." to the $Group in order to help eliminate posts to incorrect groups. Is there a straightforward way to do that as well? Thanks for the help.

DaveG 31-Aug-2011: In config.php set $bi_DefaultGroup based on the group of the current page. Something like:

$pn = ResolvePageName($pagename);  #undo clean urls (replace / with .) to make pagename checks easier
list($grp, $nm) = explode('.', $pn);
if ($grp == 'group1' || $grp == 'group2')  $bi_DefaultGroup = $grp;

Bruce K, 6 Sep 11 When a Bloggroup.Main page (blog-summary-pagelist) is openned, the bi_DefaultGroup is initally set to $Group. However, whenever any action is picked from the Side Admin, such as New Entry, Drafts, Published, or Stickies, at that point the bi_DefaultGroup is redefined from $Group to "Blog". This seems to happen regardless of whether this new code is included in config.php. Thanks for helping.

DaveG 9-Sep-2011: If I understand correctly, you're saying that the Admin links in the sidebar always point to blog1? Or is the problem that the group in pathname is not being set based on group? If the former, are you sure the include (for the BlogIt-SideBar) in the SideBar has a blogid parameter specified? (refer to the first 31-Aug reply)

Just to speed things up, feel free to contact me on <<email removed>>.

DaveG 19-Sep-2011: Turns out this is not as simple as first though. A solution was provided, but is a little involved. I've added a request for a future version to simplify this.

Failure with Captcha

Status: Pending response from Brad

Brad Cassidy, 03 June 2011 I have attempted to install Captcha on my wiki in such a way that Captcha operates on the comment forms in just BlogIt. I have made many attempts to get this working without success. What I have done most recently is the following:

Put captcha.php in my cookbook/ directory. Placed the following code in local/config.php:

	$EnablePostCaptchaRequired = 1;
        (used this code because I wanted to see it operating on my monitor regardless of my edit

Placed the following code in Site.EditForm

	Enter value:  (:input captcha :)
        (I don't think this is the right place for it? should it be in pmforms.php?)

Placed this code in local/config.php


Activated blogit.php

What I have now is: no Captcha on the blog comment form. However, if I click on the page edit button below the form, when it converts to the edit mode I see a broken attempt at loading Captcha (only "Enter value" and a small text box – no value to enter or submit button). I've pretty much run out of ideas of other things to try. I'm pretty new to this, thanks for your patience.

DaveG 3-Jun-2011: First thing is to start simple, and just get captcha working, and remove these bits:

  1. don't do an include of captcha.php, this is where problems will start.
  2. You don't need to add anything to Site.EditForm -- BlogIt will handle the placement of the captcha field.

Once that works, then we can modify for your environment.

Brad Cassidy, 06 June 2011 All day trying variations and have BlogIt working fine, but with absolutely no sign of Captcha. I don't think I'm understanding what you mean: "don't do an include of captcha.php" ? In the section captcha working it says, "add this line to config.php before including blogit.php."

   if (!CondAuth($pagename,'edit')) $EnablePostCaptchaRequired = 1;

Is this the include you are referring to? I've tried it both ways and it doesn't seem to make any difference. I have 'edit' and 'admin' passwords defined on the site, I've reloaded /blogit to my cookbook four times and I've pretty much run out of other things to check and tinker with. Sorry if I'm missing the obvious.

DaveG 10-Jun-2011: Try disabling blogit by commenting out the blogit include, and see if you can get captcha working without blogit. That will at least tell us where the problem lies. If you send me your config.php (pmwiki at solidgone dot com, obfuscate passwords) I'll take a look as well.

Drafts Keep showing in Rss Feeds

Status: Pending response from Edwin

Edwin Marte 2010-Dec-28: I am using Trevor approach using the recentchanges in group Blog to create Rss Feeds, so far so good but the drafts. I used the suggested code but the drafts keep showing in the recentchanges:

if (@$_POST['target']=='blogit-comments' || $_POST['ptv_entrystatus']=='draft') {
  unset ($RecentChangesFmt['$SiteGroup.AllRecentChanges']);

Any suggestions ?

DaveG 29-Dec-2010: I haven't looked at Trevors method for a while, so can't comment on that immediately. However, recent versions of BlogIt have RSS feed support builtin. Do you have the same issue when using this method?

Edwin Marte 2010-Dec-29: I did that time I could not import my feeds into my facebook notes account. It just kept failing. At this moment I can't remember if blogit feed support was working (including draft) or not. I will try it later on today and post results. The thing with Trevor approach using recentchanges is that it works with facebook notes.

Thanks, Edwin.

Edwin Marte 2011-Jan-1: Well, I made a fresh install only with blogit enabled. Blogit anda the feeds work but then when I try to import it as notes in facebook account I receive following message:

Sorry, something went wrong.

We're working on getting this fixed as soon as we can.

That is why I am not trying to use built Rss support. Any more thoughts on this ? If I could use recent chances without showing drafts then I am saved.


DaveG 2-Jan-2011: As long as you have the unset code before the BlogIt include (beware of config order precedence if you're using a farm) you should be good -- I'll do a test today to confirm. I'm interested in fixing the RSS feeds though. Pergaps we could continue this offline. Could you shoot me an email describing how you're pushing the RSS feed to Facebook, as I'm not familiar with that. Thanks.

Edit to see Tags

Status: Pending response from Amos

Amos Satterlee 2010-08-05: If I create a new entry and save it, the tags are not registered but when I then edit and save, they do. For example: I create a new entry with the tag 'blue'. I save the entry. The tag 'blue' displays below the entry (Minimous skin). I click on the tag and get the Blue tag page, but this entry is not listed. I then open the entry in the edit form (do nothing) and save it. When I click on the tag and go to the Blue tag page, there the entry is listed. Using 2010-06-12 version of BlogIt.

DaveG 6-Aug-2010: I've seen this usually when caching is enabled, in which case, it's the 'expected' behavior. Does this still occur if you disable caching?

Amos 08-08-2010: I have not turned on caching in my config file

DaveG 9-Aug-2010: I've logged this as a bug -- no idea what's causing it right now.

DaveG 9-Aug-2010: The only way I'm able to replicate this behavior is for Draft entries. Entries of status Draft do not get listed in the Tag page. That's to ensure there are no links to pages that are not yet Published. Are your pages non-Draft?

Also, just to confirm, by caching I mean use of either $EnablePageIndex, or $PageListCacheDir.

The only other thing I can think of is that other recipes may be conflicting somehow. Are you able to replicate this is a 'clean' install?

Amos Satterlee 2010-08-05: In my case, it happens with Publish status. No other cookbook is active, and neither $EnablePageIndex nor $PageListCacheDir is active. Mine is pretty plain vanilla install - just PmWiki and Blogit.

DaveG 31-Aug-2010: I have seen this before in earlier versions of BlogIt, and assumed ti was due to PmWiki .pagelist delayed updates, but it doesn't sound like that if you need to edit in order for tags to show up. I'm not able to replicate this problem, so if you are able to narrow down a cause, or re-create the steps that will help.

Closed Questions

If your question is in this closed section, and you think it should still be open, please move it back to the open section with a note explaining the issue.

demo site login not working

Admin password is "blogadmin"; Edit password is "blogedit".

I tried today (2014.07.22) and was unable to login.

MichaelPaulukonis July 22, 2014, at 10:48 AM

Download server error

SteP 2011-12-09: I've been trying to download the zip/tar balls from github in the past couple of days but I get a server error. It might be temporary but I thought I'd let you know.

DaveG 11-Dec-2011: Looks like it was a temporary Github problem, looks to be okay now. Seems to be no record of it on their blog though. Thanks for the heads-up; if it continues, may need to find alternatives.

New Entry in SideBar and Form not showing

Status: Issue Resolved Linda U, 23 Sept 11 I've implemented BlogIt on a farm, and the field where it's used is having problems. New Entry is missing from the BlogIt SideBar, and if you try to write Site.Blogit-NewEntry in the address bar, you get a regular page. There's no BlogIt form. How can I fix this?

DaveG 23-Sep-2011: In order to create a new entry you need the appropriate permissions. So the most likely problem if you are not seeing the New Entry link at all is that you either haven't logged in as someone who has New Entry permissions, or have setup the permissions incorrectly. The approach depends on whether you are using AuthUser or not.

If you have followed the steps listed, if you could send me your config I'll take a look. pmwiki at solidgone dt com.

Linda U, 26 Sept 11 I haven't changed a thing since this didn't work, but now it's working. Thanks for the response.

Deleting comments opens pmwiki.php

Status: Issue Resolved

Johan, 19 August 2011 Same issue as Peter reported below. Deleting works, but it does not show the ajax effect after I installed latest version (by copy/paste). Instead, it tries to open the file pmwiki.php. Tried the fix that Peter did, but that did not help.

DaveG 31-Aug-2011: Johan, I somehow missed your question being posted. Let me know if this is still an issue for you.

  • Did deleting work before you upgraded? Which version did you upgrade from/to?
  • I'm not quite sure what you mean by 'tries to open pmwiki.php'. Do you mean the ajax response is the pmwiki.php file? If so there may be an issue with your .htaccess redirects.
  • Is the site online somewhere I can take a look?

Johan, 2-Sep-2011: Yes, still an issue. It worked before. Not sure which version I updated from, fairly recent version. When I press delete, my browser downloads the file pmwiki.php and asks if I want to save it somewhere or open it. It contains the text message that Peter talked about (but in english { "msg": "Delete successful.", "result": "success" }). The comment is deleted, so the functionality works. Site here

DaveG 2-Sep-2011: Looks like there is some problem with your setup of the blogit paths. All other paths are fully-qualified; all blogit paths are relative to /blogit. For example: <script type="text/javascript" src="/blogit/jquery.min.js"></script>

This means that $PubDirUrl is not being set correctly -- normally it's pretty automatic. Are you setting $PubDirUrl in config.php? If not try: $PubDirUrl = 'http://'.$_SERVER['HTTP_HOST'].'/pmwiki/pub';

Also make sure the blogit include is the last recipe to be included.

Johan, 5-Sep-2011: I was missing a farmpubdirurl (thought I added it before, must have made a typo or something), which blogit uses and appends before jquery.min.js etc. Works now! Thank for your work.


yD June 5, 2011, at 6:20 PM:

Everything OK (as in April 2010, see bellow) till I wanted to upgrade my wiki : everything but BlogIt is now up-to-date and all works fine as before. Now, if I try to update BlogIt from 2010-14-3 to latest (1.6), I lose the link to "new entry" (sidebar), I can't comment, I can't write something, etc... but I can read everything. I read somewhere that you simplify BlogIt security, but I can't fix it !
(Is the example Security with Using AuthUser up-to-date ?)
Thank's for your help !

DaveG 5-Jun-2011: There have been quite a few changes since 1.4, in particular 1.5.0 introduced a lot of changes. Check the BlogIt/ReleaseHistory#recent-changes? to make sure you handle the changes required for each release.

The authuser instructions are up-to-date, so don't think it's that. Could be though -- if you want to send me your config.php (with passwords obfuscated) I'll take a look. Is the site somewhere I can view it?

Specifically to your problem, are you seeing any blogit links in the sidebar, or has the whole thing gone? If the links are there but don't work, it suggests you may have edited the blogit sidebar at some point, and so your changes are overriding the new version from blogit. Version 1.5.0 changed all the action= links for blogit, to prevent conflicts with other cookbooks. In order to check:

  1. if you have a file Site.BlogIt-SideBar in wiki.d then you're version is overriding the blogit version. temporarily rename it Site.OLD-BlogIt-SideBar, and then copy your changes over to Site.BlogIt-SideBar

I'll be out of town for the next few days, but will try to respond as soon as I can. You might try emailing me at <<removed>> if you still have problems.

yD June 6, 2011, at 10:00 PM: Works fine again, thank you. Was Site.BlogIt-SideBar in wiki.d (I've just commented out Tags, too many item).

BlogIt sidebar displays throughout the main wiki.

Brad Cassidy, 01 June, 2011 Regarding the query below by Craig Watson, February 09, 2011 ("Can I apply BlogIt cookbook to a single group within my wiki while maintain wiki format elsewhere"). I have a similar situation, I want to add BlogIt to my already existing main wiki. I have placed the blogit pages in a seperate group - fine. However, when I changed the sidebar in the blogit group it also changed the sidebar in the main wiki - this is not fine. Is there a work-around or should I look at a wikifarm or set up two seperate wikis on my site? Thanks.

DaveG, 1-Jun-2011 The easiest way to do this if you have BlogIt active on a single group is to add an if condition around the display of the sidebar. So if you're using the standard sidebar include, then you'd use something as below, replacing BLOG-GROUP appropriately:

(:if equal {*$Group} "BLOG-GROUP" :)(:include Site.BlogIt-SideBar:)
<<original sidebar text>>

Brad Cassidy, 02 June, 2011 Problem solved - works beautifully. Huge appreciation for your help.

Missed title of blog entries.

Claudio Agostinelli, April 11, 2011, at 5:20 PM: I installed successfully blogit to my pmwiki with equilibrium skin (see However, the title of each entry blog is not displayed, nor at the beginning of the post nor in the Recently written bar nor in any other place. What is wrong with my installation?

DaveG 12-Apr-2011: How did you create the blog entry? When you login, you should see a link in the sidebar for creating a New Entry -- did you use that? Also make sure that the blogit config is towards the end of the config file.

If you edit the blog page directly (using a PmWiki edit rather than a typical blog-edit), what do you see? You should see a bunch of PTV value being declared, something like:

[[#blogit_pmmarkup]](:title Blog Test:)[[#blogit_pmmarkupend]]
(:entrytitle:Blog Test:)
[[#blogit_entrybody]]This is a test of the Blogit system for PMWiki[[#blogit_entrybodyend]]

Claudio Agostinelli, April 13, 2011, at 9:51PM: Thanks for your suggestions.

  • I always use the New Entry link to create blog entry.
  • This is the last part of my config.php file
'=>'.comments a','comment'=>'.commentwrap');


$HandleAuth['source'] = 'edit';  #Prevents non authorized users from viewing com
ment source email address
$HandleAuth['diff'] = 'edit';  #Prevents non authorized users from viewing comme
nt source email address
$MaxIncludes=500;  #BlogIt makes heavy use of includes, so this needs to be incr
  • and this is the first part of my blog entry
[[#blogit_pmmarkup]][[!Teaching]](:title MSc Program in Computer Science:)[[#blogit_pmmarkupend]]
(:entryauthor:Claudio Agostinelli:)
(:entrytitle:MSc Program in Computer Science:)
[[#blogit_entrybody]](:if userlang EN:)

!!`MSc Program in Computer Science 

(:if userlang IT:)
  • it seems, the problem is independent on the skin, I used the classical pmwiki, abitmodern and equilibrium.

Did you see something wrong? If you need more details just let me know. If you would like to test it I can provide you an admin password on my pmwiki installation

DaveG 12-Apr-2011: Nothing obviously wrong there. If I copy/paste the entry you have into the test environment, everything works. Perhaps if you could send me your config file (obfuscate passwords), I'll take a look (pmwiki at solidgone dt com). I'm out of town for the next few days though, so you may not get a response until early next week. Can you also confirm you haven't made any code change to BlogIt, or BlogIt templates?

Claudio Agostinelli, May 4, 2011, at 8:48AM: The problem was on the use of multilanguage.php cookbook which seems to be incompatible with blogit. For multi language website it is possible to use langviews.php. Many thanks to DaveG to point out it.

Allow a retry if captcha fails?

Status: Logged as issue

Peter Bowers February 10, 2011, at 11:05 AM: I just got captcha configured on my system. (Looking forward to not having to delete a bunch of spam every day!) I tested with correctly entering the captcha code and life is good. Then I tested with an incorrect captcha code (blank - as if I didn't notice the field) and it appropriately does not register the comment. However, if it is a real person who typo'd the code or didn't notice it then there is no message telling them it failed, no opportunity for them to re-enter the captcha (presumably without having to re-type their comment & ID info), etc. Do I have a mistake in my configuration or is this a current limitation of the captcha system? If the latter, any possibility we could include a change on that on the roadmap (although I understand that captcha is not your recipe and so that may be a limiting factor).

(I saw some comment in the release notes about this being included in the DOM or something, but I didn't know how to take advantage of this. Is this a feature of the skin and I need to change skins in order to take advantage?)

Hmmm... I just tried to go in and delete some comments. Instead of deleting them it downloads a file index.php which contains this:

{ "msg": "Nuk mund te fshihet", "result": "error" }

(translation: Cannot delete) I think I'm running into problems with having a non-blogit skin. However, it may be worth either (a) make the documentation a little clearer about the difficulties encountered with a non-blogit skin (currently says: "These skins can still be used with BlogIt, with or without the stylesheets") or (b) figure out some way to recognize non-blogit skins and make the text appear, even if not nicely styled, rather than having the text disappear so-as to actually lose functionality. (I'm making assumptions here -- maybe there's some other problem in my configuration that is making captcha not work right and comment-delete not work right and etc.)

Could it have something to do with running a non-English configuration? That was my problem before...

Looks like anything ajax-related isn't working... Did I need to do something during the upgrade to enable ajax?

I just went ahead and installed the blogit-triad.css thinking that would help. Doesn't seem to have made any difference. Anything I can try to make sure I got the installation done properly?

(Could this be related to this in the roadmap:

I am using a farm...)

YUP! That was it. I went through blogit.php and changed all references to $PubDirUrl to $FarmPubDirUrl and all of a sudden I have all these neat things happening that weren't happening at all before (ajax & other js effects)! May I suggest a $biPubDirUrl which is SDV'd to $PubDirUrl but could thus be over-ridden for people who prefer to use the farm config? Theoretically it could even be done automatically, but maybe that's more work than it's worth if it can just be clearly documented as a part of the install/config instructions...

My problems seem to be solved. I'll leave this in the "open" section just because DaveG probably doesn't look at closed questions too often and the $biPubDirUrl may be helpful. But other than that being read, this question is closed now.

Can I apply BlogIt cookbook to a single group within my wiki while maintain wiki format elsewhere.

Status: Issue addressed

Craig Watson February 09, 201 Hi, I am new to pmwiki. I would like to have the best of both worlds, i.e. a blog/wiki hybrid with Blog home page linking into wiki structure and I wondered if I could achieve this with BlogIt by applying BlogIt to a single Group and leaving other groups in wiki form?

DaveG 9-Feb-2011: Yes. In fact you don't really need to do anything at all to achieve this. Just install blogit, define a group to be the one to contain blog pages (although really this is optional, and just ensures things are processed quickly). That's it. Use other groups (or even the blog group) for normal wiki pages.

Request for technical documentation / troubleshooting

Status: Logged as issue

Peter Bowers February 07, 2011, at 05:03 AM: Every time I try to change/configure/troubleshoot something in BlogIt I get hung up on how the whole thing works. All these (:includesection ...:) that go to unnamed pages (at least unnamed in the markup) and etc. Is there any place where there is a type of "site map just for blogit" that shows where these things are found, how they go together, etc.?

DaveG 9-Feb-2011: There is not. It's on the todo list, but unfortunately it's been there for a while now. I'll try to prioritize it up a little higher.

Using $FarmPubDirUrl instead of $PubDirUrl

Status: Logged as issue

a.l.e, 15-Dec-2010: if you have a wikifarm, you have to put blogit in each additional wiki. By using $FarmPubDirUrl instead of $PubDirUrl in blogit.php this wouldn't be the case (and it works... I've tested it. If you don't want to change the code, it would be at least good if this would be mentioned somewhere in the documentation (I have not found it there).

DaveG 17-Dec-2010: Good point, and I'll add something to the docs, and also to the known issues for future investigation. This does depend on each specific setup though. For instance, I use BlogIt in a farm environment with a single install of BlogIt, and do not use $FarmPubDirUrl.

predefinition of [[#break]] anchor

Status: Logged as issue

rivaldo, 26-Nov-2010: is it possible to predefine the break for a given line?

DaveG 26-Nov-2010: It's not currently possible to automatically have the introduction restricted to the first n-lines -- you need to insert the [[#break]] directive. I'll add this to the request list.

Main blog page header error

Status: Issue closed

Carlos, 10/10/10: I get the following error on my main blog page ([(approve links) edit diff]).

Warning: Division by zero in /home2/carlosme/public_html/songplugging/scripts/markupexpr.php(100) : eval()'d code on line 1
Warning: Division by zero in /home2/carlosme/public_html/songplugging/scripts/markupexpr.php(100) : eval()'d code on line 1
Warning: Division by zero in /home2/carlosme/public_html/songplugging/scripts/markupexpr.php(100) : eval()'d code on line 1
Warning: Cannot modify header information - headers already sent by (output started at /home2/carlosme/public_html/songplugging/scripts/markupexpr.php(100) : eval()'d code:1) in /home2/carlosme/public_html/songplugging/pmwiki.php on line 1120

Any ideas? I'm not a very technical person, but will try my best to understand. Your help is appreciated.

DaveG 10-Oct-2010: I don't think this is a BlogIt error, but more likely a skin error, or another cookbook. Which skin are you using? If it's Equilibrium, make sure you define the number of columns to use, using something like cols=2 on the includesection you have on your page.

Do not require email address (nor CAPTCHA) for comments

Status: Logged as issue

David R 2010-09-24: Maybe I overlooked it, but is there a way to make commenting possible without requiring an email address (nor anything else)? My blog is only accessible by password anyway and not fully public. Thanks.

DaveG 24-Sep-2010: Usually you can override BlogIt template elements within Site.BlogIt-SkinTemplate-SKINNAME. However, in this case there is some client-side javascript validation which enforces the required fields, so that approach won't work. So, at the moment it's not actually possible to do this. I'll add it to the Issues list.
SteP 2010-09-25: David R, as a temporary work-around, you could duplicate the #comment-form section of Site.BlogIt-CoreTemplate into Site.BlogIt-SkinTemplate-SKINNAME and change
'''$[E-mail]''' $[(required, will not be published):]\\
(:input text $:email id="comment-email" tabindex=1:)\\
(:comment '''$[E-mail]''' $[(required, will not be published):]\\ :)
(:input text $:email hidden value="" id="comment-email" tabindex=1:)\\
Omit comment and hidden if you still want to show the pre-compiled e-mail field.

Older/Newer post navigation does not work

Status: Logged as bug

Marco Lehnort 2010-09-22: When using a specific count for the #blog-summary-pagelist template, the page navigation links appear, but clicking them results in the same entries being shown again. E.g.:

(:includesection "#blog-summary-pagelist blogid=blog1 status='publish' count=6":)

The problem seems to be due to the count parameter passed on to the pagelist markup inside the template:

count={(bi_ifnull '{$$count}' "{$bi_EntryStart}..{$bi_EntryEnd}")}

As bi_ifnull returns the first (i.e. [0]) argument itself if it is not null, the count parameter passed to pagelist will never be ".." if the count parameter passed to #blog-summary-pagelist was defined. I redefined the #blog-summary-pagelist template in Site/BlogIt-SkinTemplate-dropshadow (I'm using the dropshadow skin) changing the mentioned line into:


However, the count parameter passed to #blogit-summary-pagelist seems to be ignored and $bi_EntriesPerPage is used instead because of the way the $bi_EntryStart and $bi_EntryEnd page variables are calculated in blogit.php. Seems that this calculation expects a "?count=..." parameter in the URL. If this is missing it resorts to $bi_EntriesPerPage.

Cheers, Marco

DaveG 22-Sep-2010: Thanks for reporting this. I've logged this as a bug.

change default status to publish

Status: Logged as issue

rivaldo, 18/11/10: When creating a new entry in the status pop-down menu "draft" is the default. how to change this to publish? - BlogIt is great!

DaveG 19-Nov-2010: There isn't a quick setting for this -- I'll add the request to the list. In the meantime you'll need to add this section to Site.BlogIt-SkinTemplate-SKINNAME, replacing SKINNAME with the name of your skin. This is a copy paste of a section from Site.BlogIt-CoreTemplate, with the default status line changed to "publish". You'll have to keep an eye open for changes to this section in future BlogIt upgrades.
!!! #blog-form-control
(:if false:)[[#blog-form-control]](:if:)
(:div1 id="wikiedit" class="blogit-blog-form":)
(:input pmform target="blogit-entry":)\
(:input default source="{*$FullName}" request=1:)\
(:input default $:entrystatus "publish":)\
(:input default $:entryauthor "{$Author}":)\
(:input default $:entrydate "{(ftime fmt='$[%d-%m-%Y %H:%M]' @{$Now} )}":)\
(:input default $:entryurl "(:if equal '{$Action}' 'bi_ne':){$bi_DefaultGroup}.(:else:){*$FullName}(:if:)":)\
(:includesection "#blog-form":)
(:input end:)
(:include {$SiteGroup}.EditQuickReference:)


difficulties setting up BlogIt

rivaldo, 16/11/10: I copied the installation files to the cookbook and pub folder, edited the config.php with
$HandleAuth['source'] = 'edit'; #Prevents non authorized users from viewing comment source email address
$HandleAuth['diff'] = 'edit'; #Prevents non authorized users from viewing comment source email address
$MaxIncludes=500; #BlogIt makes heavy use of includes, so this needs to be increased.

which I placed at the end of the config.

I also set $EnableRelativePageVars = 1; and
$AutoCreate['/^Category\\./'] = array('ctime' => $Now);

I have set admin and edit passwords. do I have to do something about Set $bi_AuthPage Permissions?

Now I just don't know, what to do, to really get this blog working. my site is: [removed]

How exactly is the main Blogpage generated? I created a Blog.Main? page and put in:

(:includesection "#blog-summary-pagelist blogid=blog1 status=sticky":)
(:includesection "#blog-summary-pagelist blogid=blog1 status=publish":)

well, but where is the blog? :-)

I noticed I can't access cookbook/blogit/blogit.php as it seems to be protected. is this normal?

thx guys

DaveG 16-Nov-2010: It looks like you have everything setup okay, I don't see any obvious errors -- the blogit code is on your page, ready to go. You now need to add the blogit control panel to the sidebar, and then create some blog entries.
18-Nov-2010: thx!

Article uploads on the main page

Status: Closed, non-BlogIt

Xavier Glattard 2010-08-25: I cannot get an article attachment display on the blog homepage unless I use $Fullname in the Attach: link. I'm using the Equilibrium? skin ((:featured_image:)) var and the Mini recipe. Mini does not work at all in this case: I had to use an Attach: to the generated thumbnail. TIA for your help

DaveG 25-Aug-2010: I don't quite follow your example, and I'm not familiar with the Mini cookbook, but it's possible that the order of PmWiki markup/PTV evaluation is causing issues. What happens if you try to pass a PTV variable (using the Attach:xxx Δ format) to Mini outside of BlogIt?
a.l.e 2011-01-06: i guess i have the same problem: in the blog list i don't see the image...
->a.l.e 2011-01-06: the solution is to insert the images with their full path: Attach:{$FullName}/panettone.png ({$FullName} will be replaced by the current path to the page)

Xavier Glattard 2010-08-26: PTVars are properly handled in included pages. I'm afraid this is not a BlogIt issue. An Attach: link in an included page needs a fully specified page: it is said at the bottom of the pageImages. And Mini uses Attach:, with some more issues. I cannot see a solution. (NB: I use per-page attachments)

Why not specifying the {{$FullName} in the mini code, if possible ? On some pages, I use Thumblist (not mini) with (:thumblist {Cookbook.BlogIt-Talk} blabla :), so that I can grab and show pictures on other page. (my case). gb August 26, 2010, at 01:05 PM

jQuery conflicts

Status: Logged as enhancement

Marco Lehnort 2010-08-31: I was playing around with BlogIt when I realised that it breaks my experimental version of Galleria (created from Cookbook.Galleria, using the latest JavaScript Galleria). With BlogIt enabled, some of the functionality of Galleria does not work, e.g. the integrated lightbox does not show images, navigation is partially broken, etc.

So far, I tracked problems down to jQuery, which is also loaded by BlogIt. I was able to fix the issue by moving the <script> element loading jQuery (specifically jquery.min.js) to the header, such that essentially all scripts on the page use the same instance of jQuery.

I'm not completely sure what the actual problem is, but I assume that loading galleria.js affects jQuery in some way. It looks like loading jQuery again later on resets things Galleria set up earlier. The problem is not in particular with BlogIt or Galleria. It's a potential problem for all plugins/scripts using a common library such as jQuery - and probably relying on some globally visible things. I also tried wrapping the galleria stuff into a separate closure with the specific jQuery instance to be used - no success. I don't know the details of the javascript behind Galleria and BlogIt.

To this end, a workaround seems to be to load jQuery in the header, possibly multiple times (last one would win) when using multiple plugins on the same page, to ensure all scripts see the same instance at all times. Of cause, if the plugins need different versions you're still screwed.

Could you make BlogIt load jquery.min.js in the header again? What's your suggestion?

DaveG 31-Aug-2010: Rather than switching BlogIt back to using the header, I'll probably move Galleria javascript down to the footer. In the meantime this include these unset statements after including galleria, and then add the $HTMLFooterFmt after blogit. Ending up with something a little hacky like:
# Remove galleria Header javascript/css statements:

# Other config statements...


# Add Galleria header statements back in, excluding the galleria jquery:
$HTMLFooterFmt['galleria'] = '
<script type="text/javascript" src="'. $PubDirUrl. '/galleria/jquery.galleria.pack.js"></script>
<script type="text/javascript" src="'. $PubDirUrl. '/galleria/jquery.jcarousel.pack.js"></script>
<link rel="stylesheet" type="text/css" href="'. $PubDirUrl. '/galleria/galleria.css" />
<link rel="stylesheet" type="text/css" href="'. $PubDirUrl. '/galleria/jquery.jcarousel.css" />
<link rel="stylesheet" type="text/css" href="'. $PubDirUrl. '/galleria/skins/'. $galleria['skin']. '/skin.css" />

Marco Lehnort 2010-09-01: Thanks for the quick reply. I tried your suggestion. Moving the Galleria scripts to the footer works, but omitting jQuery completely in the header (both with BlogIt and with Galleria) will render the (:galleria:) markup generating javascript somwhere in the middle of the page broken. It generates "$(document).ready(...)", which needs jQuery loaded before.

Now, loading jQuery in the header as part of Galleria and loading jQuery in the footer as part of BlogIt seems to break things in the same way as before. The only way I could figure making it work is to load jQuery only once in the header (or at least any place before using jQuery the first time) and not loading it later a second time again.

Whenever jQuery is needed, it would probably be a good idea to load it only if it is not already there to avoid conflicts with other plugins also using jQuery.

Maybe this is going a little off-topic here. If you wish I can send you a tarball with my version of Galleria (I'm not using jquery.galleria.pack.js, but galleria.js from Galleria. There's quite some chance that I'm missing some trick plugging this in appropriately. However, making sure jQuery is loaded only once and early enough solves my problems.

DaveG 1-Sep-2010: Ah, I forgot Galleria embeds js in the middle of the page. Once the new version of Galleria javascript library is done, I'll update the Galleria recipe, and make sure to move everything to the footer, including the gallery generation js.

The way PmWiki headers and footers work is that elements declared later win, so in theory as long as each recipe uses the same name for a jquery element, you only have one jquey declaration.

For now you approach works, so I'll close this out, and address the issue in the next release of the Galleria recipe.

Marco Lehnort 2010-09-02: Sounds good. Thanks!

blogid vs. blog group

Status: Questions addressed

Xavier Glattard 2010-08-25: I'm evaluating pmwiki+blogit and I'm new to both. Here are some questions.

  1. What the differences between the blogid var and the (pmwiki group as) blog group? I cannot understand the need/usage of blogid…
  2. blogid is not only hardcoded in Site.BlogIt-SideBar but also somewhere else. What is the usual hack to get a control panel using the same blogid than the current post or group?
DaveG 25-Aug-2010:
  1. In short there is no direct relationship between PmWiki groups and BlogIt blogs -- they are independent. BlogIt blog entries can reside in any PmWiki group. BlogIt allows more than one blog on a given instance of PmWiki. This allows (but doesn't force) multiple blogs to use a single PmWiki group to store blog entries. The blogid allows BlogIt to differentiate blog entries when there are multiple blogs.
  2. blogid is actually not hard-coded in Site.BlogIt-SideBar, but defaults to 'blog1'. You can pass a blogid parameter into the sidebar include statement, which then passes through to the control panel embedded on the sidebar, refer to the sidebar documentation.

Xavier Glattard 2010-08-26: Thank you! I think I understand now.

Comments do not show...

Status: Problem resolved with 1.6.0

correa 2010-08-04: when displaying a blog entry. Comment form appears immediately below the entry. I'm able to enter new blog entries and comments, but not able to see the comments. I'm using monobook skin. Thanks for advices...

DaveG 6-Aug-2010: Are the comments approved? Do you have captcha installed, and active? By dfault if captcha is not installed, then comments need to be approved before they appear. If captcha is installed, then comments are approved by default. You can see comments needing approval if you login as an admin used, and use the "Unapproved Comments" link in the sidebar. You can override the default approval status, by setting this before including blogit -- in this case comments will be automatically approved:

correa 2010-08-09: Thank you for your reply. All comments are approved, but the problem remains. Indeed, I see a list of all comments in the side bar, but when I click on a comment in this list, I get the corresponding blog entry without its comments. Then, if I click on the "x comments" link, I get nothing new (I stay in the blog entry page without comments). Thanks again for advices.

DaveG 9-Aug-2010: What PmWiki group are your blogs, and comments stored in? If you could send me the BlogIt related portions of your config, and/or if you have a url I could look at, that might shed some light on what's going on. Send to <<email removed>>.

Date problem with Strato webhosting

Status: Problem should be resolved with 1.6.0

Timo 2010-06-19: I'm having this really weird problem (with this really weird webhoster, I must admit): When I post a blog entry, the date that I enter is not being picked-up by BlogIt, but a different publication date is given. As an example: Posting an entry with the date 19-06-2010 results in November 30, 2024. Furthermore, when I then edit the post, the date changes again. And again:

September 11, 2034 -> March 26, 2017 -> September 07, 2031 -> March 23, 2013 -> September 02, 2028 -> March 20, 2008 -> August 29, 2025 -> February 15, 2035 -> August 27, 2020 -> February 09, 2033 -> August 26, 2014 -> February 04, 2032 -> August 24, 2009

Do you see a pattern? I don't really. I believe to have traced the bug to somewhere around lines 355 of blogit.php . Unfortunately, my php-skills are rather limited, so that I don't know what the error is.

Notice, that the post's time is entirely correct and does not change in "edit cycles". Also, when I give no date and time at all, the time is automatically set correctly.

DaveG 19-Jun-2010: This happened to one other person a while back, but an upgrade from PHP 4 to PHP 5 solved the problem, and we never identified the actual cause after that. BlogIt *should* work fine under PHP 4 though.

First thing to confirm is what BlogIt config settings do you have, and what version of PmWiki and PHP are you using?

If you're willing to help find the bug feel free to contact me on <<email removed>> -- hopefully we can track it down this time.

Small bug in BlogIt RSS (with version 1.5)

Status: Addressed in 1.6.0

MKonrad July 20, 2010, at 07:04 AM: I recently updated my blog to the news BlogIt version and by then it didn't work any more. I found out that there's a small bug in line 128 of blogit.rss: bi_Auth('*') won't work when $bi_OriginalFn['AuthFunction'] has not been initialized, yet. Moving this line to line 135 solved the problem: The bi_Auth('*')-Call is now after the initialization of $bi_OriginalFn['AuthFunction']. Hope this helps, if anyone encountered the same problem...

DaveG 6-Aug-2010: Thanks for the information. The next version of BlogIt will have RSS configuration built in, to make setup a little simpler.

Problem with BlogIt 1.5 when iconv is not available

Status: Fixed in 1.6.0

Timo 2010-06-19: as mentioned above, I'm stuck with a weird webhoster, which makes you pay an extra fee for using iconv. Because of this, the current BlogIt fails for me in line 756. The way that I read the comments around that area, iconv should only be called when using AJAX, albeit, neither posting ajaxy nor with a regular POST command works for me. I've tried to trace where bi_decodeUTF8 is called, but couldn't really make anything out of that.

(As a work-around: Replace line 757 with $a[$k]=$v; -- and hope for the best...)

DaveG 19-Jun-2010: As a temporary workaround your fix should be okay, if you don't use accented characters. There is already a request to allow the user to specify an alternate conversion routine for cases where iconv is not available; I'll bump up the priority of the request, and put it into the next release.

As an aside, how about a host that doesn't mess you around? :) I can recommend the host I use,

Removal non-latin UTF8 characters in Comment when displayed in sidebar

Status: Fixed in 1.6.0

Dalek June 07, 2010, at 05:24 AM: If comment contains non-latin UTF8 characters, it is removed when displayed in sidebar. I replaced

    preg_match('/^.{0,' .$m .'}\b/', $text, $match);
    return trim($match[0]);


    $match = mb_strcut($text, 0, $m, 'UTF-8');
    return trim($match);

in blogitMU_cleantext function. It is work now, but I'm not good at php, and so it may be not a good solution. And I'm not sure that strpos function work correctly.

DaveG 7-Jun-2010: It looks like you're using UTF8, is that correct? I suspect you are correct, there may be an issue here with multi-byte character sets. I'll need to look into this to see what the best solution is. Thanks for letting me know.

Dalek June 23, 2010, at 8:20 AM: Yes, I'm using UTF8. I am glad to help.

DaveG 27-Jun-2010: If you get an opportunity could you check the development version, which should fix this problem.

Tags overriding Categories

Status: Issue resolved

Amos 14-Jun-2010: Sent this to the list-serv - not sure the best place. I want to have a site that includes both a blog capability (note taking) and the PmWiki capability (essays). The BlogIt Tags engine seems to override the PmWiki Categories engine. The Tags engine doesn't seem to recognize the tags/categories set on normal wiki pages.

DaveG 14-Jun-2010: Looks like this is a bug. It should be possible to do what you want, which is to use categories on non-BlogIt pages, but you are correct, the categories pages are not being created, and even display the backlink results sporadically. Thanks for letting me know.UPDATE: This is incorrect -- the problem was the CategoryGroup is not shared between blogit/pmwiki.
DaveG 16-Jun-2010: By design BlogIt uses a different group for categories (Tags) than the usual PmWiki group (Categories), to ensure you don't get PmWiki categories listed in your blog sidebar. If you want to share categories between blogs and PmWiki set:

At the moment there is no automated way to use a different group on blog pages; this is partly because there is no way to determine what a blog page is when it's not a blog-entry or comment. For instance the blog list page would need to be defined as a BlogIt page, but isn't a blog entry or comment. You can attempt to force this if you know which groups are blog related, in which case you can modify something group based, like this:

if (!preg_match('!^(Blog|Comments|Tags)(\.|/)!', $pagename))

What this says is if we're not in the Blog, Comments, or Tags Groups then override $CategoryGroup to the standard PmWiki setting. When we are in those groups then let BlogIt handle tags.

Do I have to specify every user?

Status: Issue resolved

~MTS? May 18, 2010, at 03:39 PM : I want to simply do $AuthUser['@blogs']='id:*'; but BlogIt seem to only respect actual usernames. I don't need all this granularity, I'd like to allow any authenticated user to have full blog privileges. Is this possible?

DaveG 18-May-2010: The documentation for AuthUser seems a little ambiguous. I managed to get this working by adding this line to SiteAdmin.AuthUser, rather than trying to set it in config.php. Also, when doing this it seems that authuser configuration steps 3 and 4 are not needed.
@blogs: * 

Division by zero error

Status: Issue resolved

Amos 11-June-2010: I'm new to both PmWiki and Blogit. I believe I have set everything up properly, but on my Blog.Main page I get "Warning: Division by zero in C:\Users\Patricia\Documents\web\pmwiki\scripts\markupexpr.php(100) : eval()'d code on line 1" three times for each blog entry.

Occurs with the Equilibrium skin, not with the PmWiki skin.

DaveG 12-Jun-2010: You need to specify the cols= parameter on the BlogIt pagelist when using column based skins like Equilibrium?.

Amos 14-Jun-2010: Thanks. Swamped with other stuff right now. Hopefully will get to it in the next day or two.

Amos 14-Jun-2010: Found a moment - simple fix. Thanks.

authuser problems (again)

Status: Issue closed

Peter Bowers May 17, 2010, at 02:24 PM: I set things up the way I described (below) with authuser. Unfortunately my users that do not have admin privileges find themselves unable to add a new entry. At the moment they try to submit a new change they are prompted for another username/password. At this point only admin users are accepted. Maybe I've just got attr set up wrong for a given page or something -- anything in particular I should be checking?

DaveG 17-May-2010: Using the same setup from your May 11, 2010, at 03:29 AM post, I'm able to create new entries, as user1.
  • Check that the ordering in config follows this general pattern:
    1. Set authuser settings and blogit privs:
      $DefaultPasswords['blogs'] = array('@blogs');
      $bi_Auth['blogs'] = array('comment-edit', 'comment-approve', 'blog-edit', 'blog-new', 'sidebar', 'blogit-admin');
    2. Include authuser.php
    3. Include blogit.php
  • BlogIt does need to be one of the last cookbooks included, and does have issues when called from Group config files. Those are the main things.
  • It's possible that other cookbooks or config setting might be setting password caches before you call authuser. Typically calls to ResolvePageName, PageVar, or PageTextVar are culprits.

Hmmm... I've got a pretty extensive farmconfig.php which includes things like resolvepagename, pagevar, etc. Then I only implement BlogIt in one of my farms, so I've got that in the config.php. Authuser is also set up and included in config.php, but again after all those calls to ResolvePageName and etc. I guess my best bet is to install BlogIt for all my various farm sites by putting it in the farmconfig.php? But that means I've got to decide *either* just-password *or* authuser on *all* my sites where right now I have some of them one way and some another way... Gonna have to think on this one... Peter Bowers May 18, 2010, at 07:47 AM

DaveG 18-May-2010: For reference to future readers, this discussion centers around PmWiki processing of various configuration files.

In general you want to do password configuration before any other processing, particularly before use of functions which might populate caches. In order to determine which group you're processing use something like below rather than PageVar:

list($x_Group, $x_Name) = explode('.', $pagename);

Typically I create a single separate config file with password configurations for all groups/farms, and include that from each group/farm config file. That way I'm sure of setting passwords before populating caches with calls to PmWiki functions.

You should then be pretty safe in calling BlogIt from farm configs. If you're feeling particularly ambitious, and not using BlogIt in a heavy use environment, you might try the Development version, which should be a little more forgiving in terms of where it can be included. Of course it's a dev release so you'll probably hit myriad other issue, so buyer-beware :)

This is getting off-topic since it's not really BlogIt's problem, but rather the way I've configured my own sites, but could you give some more details about how you do those separate config files with passwords? Presumably you call that from the farmconfig.php but it is unique to a given site? --Peter Bowers May 18, 2010, at 01:43 PM

DaveG 20-May-2010: The 'security' config file only stores the authuser/cookbook (or whatever) security setup, usually not passwords. Only use separate 'security' config files if several farms share the same configuration style, otherwise just include the security setup direct in the farm config.php. Then include_once the security config from the farm config file, since farm configs are first in order of processing.

bi_encode weirdness

Status: bug

Peter Bowers May 11, 2010, at 03:55 AM: I've entered my first blog entry and it works great until I go back to Blog/Main. There the title has (bi_encode ...) surrounding the title. See [(approve links) edit diff]. What could cause this? UPDATE: I edited the author name (using action=edit which may be a no-no) and now I get the bi_encode() surrounding my blog author as well on all (?) pages.

DaveG 11-May-2010: This is caused by the parenthesis (brackets) in the title being interpreted as an embedded PmWiki markup expression. Unfortunately the only work around at the moment is to not use parenthesis. I'll fix this as soon as I can work out a solution.

True enough - getting rid of parens got rid of my problem. That workaround is satisfactory for me. Thanks! --Peter Bowers May 11, 2010, at 03:37 PM

Can I configure BlogIt so that the BlogIt sidebar is only visible on certain pages/groups

JR? May 25, 2010, at 22:25 PM : I already have a brief wiki and want to use blogit to add the blog functionality. What this means is that I don't really want the blogit sidebar to be displayed for every page on the site. Is it possible to only display it on certain blog pages rather than the all or nothing approach that is suggested in the blog sidebar part of the documentation.

DaveG 25-May-2010: The BlogIt sidebar is no different to other wiki pages. So to conditionally include the sidebar wrap it in an if statement:
(:if group MyBlogGroup:)(:include Site.BlogIt-SideBar:)
(:else:)(:include Site.SideBar:)(:if:)

JR? May 26, 2010, at 10:12AM : Many thanks Dave. That was exactly what I was after. If anyone is interested, here is what I've got in my Site.SideBar:

(:if [ ( equal {$bi_BlogIt_Enabled} 1 ) And ( group Blog Or name Blog ) ] :)(:include Site.BlogIt-SideBar blogid=blog1:)
non blog sidebar stuff

Titles do not show on main page

Status: Needs more info

JanBrejcha May 12, 2010: Does not show titles of entries on the main page, nor the sidebar under PmWiki 2.2.16

DaveG 13-May-2010: I'm not seeing this behavior with 2.2.16. Can you confirm that this is specific to 2.2.16; was it working under 2.2.15 for example? Can you provide more detail on your setup?

Solved. The problem was caused by a conflict with the Cookbook.Multilanguage recipe.

DaveG 14-May-2010: I know there are other BlogIt users using MultiLanguageViews, which seems to provide the same functionality.

Edit link does not work

Status: Needs more info

JanBrejcha May 12, 2010: Edit entry link does not work under PmWiki 2.2.16

DaveG 13-May-2010: I'm not seeing this behavior with 2.2.16. Can you confirm that this is specific to 2.2.16; was it working under 2.2.15 for example? Can you provide more detail on your setup?

Solved. The problem was caused by a conflict with the Cookbook.Multilanguage recipe.

DaveG 14-May-2010: I know there are other BlogIt users using MultiLanguageViews, which seems to provide the same functionality.

authuser setup help

Status: Docs updated (thanks)

Peter Bowers May 11, 2010, at 03:29 AM: I had a little trouble understanding the authuser instructions. Finally got it working, but a simple example for an existing authuser site might be a good idea... Two users, members of a group which has default privileges for the whole blog. In Site.AuthUser:

user1: $1$BNF/9RQt$H8v7iP23qTluc3191yzfF1
user2: $1$Mew8Etct$tPAXqklSJiUSyNTGqzQi30
@blogs: user1, user2

Then in config.php:

$DefaultPasswords['blogs'] = array('@blogs');
$bi_Auth['blogs'] = array('comment-edit', 'comment-approve', 'blog-edit', 'blog-new', 'sidebar', 'blogit-admin');

I could update the docs myself, but I don't know if you prefer to do that yourself as author...

DaveG 11-May-2010: There is an example setup in the docs, but if it's not clear, or you can add a variation, absolutely feel free to update the docs.

Default Value for new blog entry

cee-pop 02-May-2010: I'd like to have BlogIt insert the current timestamp as a default value for "Blog Title" (= pagename). Since I don't know in advance what i am going to blog. Also, i'd like BlogIt automatically publish the blogs.I tried to solve this issue by myself with hacking the Site.BlogIt-CoreTemplate but apparently that does not work. This is what i tried in the section: "blogit-entry":

(:input default $:entrytitle "{$Now}":)\%0a(:input default $:entrystatus "publish":)

Could you help me here, please?

DaveG 2-May-2010: A default for "Blog Title" or "Pagename"? There is a feature request to be able to default the pagename; this would then automatically also name the blog title as well (if the Blog Title is blank, then the pagename will be used as the Blog Title). That sounds like it would produce the result you want. That is currently planned for a subsequent release; not the one coming in a week or so, but the one after that.

I'll add a request to default the Status, as there isn't currently an easy way to do that.

If you can't wait for that, then rather than changing CoreTemplate, create a PmWiki page called Site.BlogIt-SkinTemplate-SKINNAME (replace SKINNAME with the name of the skin you are using); don't change CoreTemplate as PmWiki will not use the new CoreTemplates when you upgrade. Then copy/paste this (note, pagenames cannot start with a number, hence the 'd' prefix):

!!! #blog-form-control
(:if false:)[[#blog-form-control]](:if:)
(:div1 id="wikiedit" class="blogit-blog-form":)
(:input pmform target="blogit-entry":)\
(:input default source="{*$FullName}" request=1:)\
(:input default $:entrystatus "publish":)\
(:input default $:entrytitle "d{(ftime fmt='$[%d-%m-%Y %H:%M]' @{$Now} )}":)\
(:input default $:entryauthor "{$Author}":)\
(:input default $:entrydate "{(ftime fmt='$[%d-%m-%Y %H:%M]' @{$Now} )}":)\
(:input default $:entryurl "(:if equal '{$action}' 'bi_ne':){$bi_DefaultGroup}.(:else:){*$FullName}(:if:)":)\\
(:includesection "#blog-form":)
(:input end:)
(:include {$SiteGroup}.EditQuickReference:)


cee-pop: thanks. that's it.

blogit/wikilib.d pages are not showing in page lists

Status: Logged as bug

HansB 6-May-2010: Blogit's default pages are not showing in page lists due to a bug on line 155 of blogit.php, which sets $Group and $Name globals.

DaveG 6-May-2010: This one is logged as a bug in the Known Issues list, and is fixed in dev. Production fix should be in a week or so.

HansB May 06, 2010, at 01:00 PM Thanks, sorry, I missed reading that (probably because it is strikethrough). You can delete this Talk item! Cheers!

How to list page links for post's tags

:Status: Already logged as feature request

nibl 4-May-2010: How can I iterate through the tags of a post and list all page links for each tag below the post. Like this:

 Post text
 Other pages on topic tag1
 Other pages on topic tag2
DaveG 5-May-2010: There is not currently a specific way to do this in BlogIt -- although it has been logged as a feature request. However, BlogIt uses basic PmWiki categories, so it should be doable with a pagelist or two; if you need it sooner, then the mailing list might be able to help -- you basically want to list pages which have the same tags as found on the current page.

Date showing start of Unix epoch

Status: Logged as bug with skin.

nibl 4-May-2010: The timestamp in my posts always shows: "January 01, 1970, at 01:00 AM" When I edit the post then it shows the correct timestamp, e.g.

DaveG 5-May-2010: A few quick things to check:
  • Make sure you're running the latest version of BlogIt
  • If you're not running the latest version of PmWiki, let me know what version you are using.
  • What version of PHP are you using? BlogIt should work with either 4 or 5, but we had a recent date related problem that was miraculously fixed when upgrading from PHP 4 to 5. Not saying an upgrade is necessary, just might help us track down what's going on.
  • Have you changed any date formats in the XL page?
  • What BlogIt settings have you set in config.php?
  • Feel free to email me on <<email removed>>.

Missing Categories

Status: Problem addressed.

nibl 4-May-2010: I'm using the equilibrium skin. I have added tags to posts and clicking on them shows the category. But there are no categories listed in the sidebar.

DaveG 5-May-2010: This is probably due to a change in PmWiki 2.1.4+. The next release of BlogIt will correct this. In the meantime add this to config.php:

Default permissions

Status: Logged as change request

RyanVarick 24-Apr-2010: I noticed line 89 changes the auth level for diff and source. In my config.php file, I define my security settings before cookbook recipies. I had already set the auth levels for these actions to admin, and installing BlogIt reduced those levels back down to edit. BlogIt should respect my existing settings, if possible. For now I simply commented out line 89.

DaveG 24-Apr-2010: Valid point. Unfortunately it's a consequence of a philosophy of requiring minimal configuration. In this case the only real alternative would appear to be to remove $HandleAuth config from blogit.php, and require/suggest it for inclusion in BlogIt. For now I'll log this as a change request, and work out how to handle it for the next release.

Tags with Titles

Status: Logged as bug

Dalek 19-Apr-2010: I'm trying to use non-latin characters in the tags names. It seems to be better to use title markup. When I create a title to the tag page, I see it on the sidebar. But on the Blog page I see a tag pagename. Can I improve it? Thanks

DaveG 19-Apr-2010: Not entirely sure I follow. I think this is what you're saying is unrelated to non-latin character sets -- tell me if this is correct.
  1. You add a (:title...:) markup to the tag pagelist page, like Tag.Non-Latin-Character. In the Tag list on the side bar you see the title provided by the markup.
  2. On the blog page tag list you don't see the title provided by the markup, but see the original tag pagename instead?

I can confirm this behavior, and agree it's not consistent. Question is how to handle it. I'm not sure. It seems like we'd want to show the overridden title on the blog entry tag list. That would at least be consistent for readers. For blog authors they would see something different when reading and editing the blog entry. I prefer consistency for the reader over the author in this case. Feel free to let me know if you have thoughts around this, or if I mis-understood your problem

Dalek 20-Apr-2010: You understand me very well. Of cource, it is unrelated to non-latin characters, but I think it is no need for this future, if using tags names only with latin characters. But ... last time I created tag "BlogIt", that was converted to "Blog It" on the SideBar. In this case we also can easily use title markup. I think it wood be better to show the overridden title on the blog entry tag list. Authors would see different, like they see different, when using [[pagename|+]] markup.

DaveG 24-Apr-2010: I've added this to the bug list, should be in the next release. Thanks for reporting it.

Can't reedit old posts.

Status: Issue resolved

yD April 18, 2010, at 9:54 AM: On a fresh reinstall of entire PmWiki, BlogIt (with PmForm) and skin Triad (nothing else), I can't re-edit old posts with AuthUser enable (all other actions OK). With AuthUser disable, everything's OK too.
Note: I can edit (Pm edit, not blogit edit) the post, and if I put in it a "(:if bi_auth blog-new:)(:pmform blogit-entry:)(:if:)", I can reedit ("blogitedit") it, but of course not in good conditions. What's wrong ? Thanks for advices.

DaveG 18-Apr-2010: Could you let me know what versions of PmWiki and BlogIt you are using. Also could you post/email you blogit/authuser config to <<email removed>>.

If you are using 2.1.4+, you may try this setting in config.php:

DaveG 18-Apr-2010: Problem was due to incorrect ordering of settings in config.php. Correct sequencing should be as below, added to docs:
  1. Define passwords, password groups, and auth user configs.
  2. Include auth_user
  3. BlogIt configs
  4. Include blogit

yD April 20, 2010, at 9:54 AM: Works fine, thank you.

No Category and Recent Written in SideBar?

Status: Logged as bug

Dalek? April 11, 2010, at 10:36 AM: In SideBar and in Site.BlogIt-SideBar page I see nothing Recent written and Category entries, but I see Recent comment entires. $EnableRelativePageVars is set to 1. Can smb advice me something? Thanks

DaveG 11-Apr-2010: So you do not see anything listed under either Recently Written or Categories, but you do see a list of Recent Comments?
  1. The major difference between the comment and blog pagelist is that the blog pagelist is looking for blog entries of 'publish' status. So make sure you have set the status correctly, or that you have changed the sidebar pagelist to reflect the appropriate status.
  2. If you have the blog entry dates set to the future they will not be displayed by default. Change that behavior with the $bi_DisplayFuture setting.
  3. Have you changed the value of $bi_BlogGroups? If you have set this value in config.php, then only the PmWiki groups you specify will be searched for blog entries. So blog entries in other groups will not be listed. If you have not changed this value then your blog entries will be searched for in 'Blog' group. Or, if you set this to an empty string then all groups will be searched for blog entries, except for Site, SiteAdmin, PmWiki.
  4. What version of PmWiki/BlogIt are you using?

Dalek 16-Apr-2010: Thank you DaveG for reply, and sorry for late answer. I've found that it don't work on the latest pmwiki version (2.2.15). It work on the 2.2.0 (2002000) correctly. The blog-it version is 2010-14-3. I'm using pure config for testing:

$EnableRelativePageVars = 1;
$DefaultPasswords['admin'] = crypt('123');
$DefaultPasswords['edit'] = crypt('123');
$MaxIncludes=500;  #BlogIt makes heavy use of includes, so this needs to be increased.
DaveG 16-Apr-2010: This is due to a change in PmWiki 2.1.4+. The next release of BlogIt will correct this. In the meantime add this to config.php:

Dalek 16-Apr-2010: Thanks, it work. The question is closed

Date gets changed on New Entries

bilu? 02-Mar-2010: I got blogit working, however, when i create a new entry, the automatic date in the format 02-03-2010 11:28 gets changed when I save it to 31-08-2007 11:28. I looked at a similar situation below but that didn't seem to apply to the new version. Comment on the test blog if you have advice or a suggestion.

DaveG, 3-Mar-2010: Based on your blog entry it sounds like the date did change to 31-Aug-07, but then subsequently changed to another date after another edit? I'm not quite following the sequence. If you start from a new blog entry, and enter the date, 31-08-2007 11:28, what happens?
  • Have you made any changes to blogit.php?
  • Could you send your blogit config settings to pmwiki at solidgone dt com?
  • If you are willing, would you mind sending me an edit password to your blog?

bilu? 04-Mar-2010: That's correct. Each time the entry is saved, the date changes again. Sometimes to dates in 2038 which do not list becaus I have DisplayFuture set to False. So by leaving 30-08-2008 in, it changes to 29-01-2036. Then 29-07-2034 and so forth.

  • Only added SDV($bi_BlogGroups, 'Blog | Karton'); and SDVA($bi_BlogList, array('blog1', 'karton'));
  • I'll send along the blogit config
  • and an edit password. Thanks.

bilu? 05-Mar-2010: FIXED. The Webserver PHP needed to be upgraded. Once I installed PHP 5 the problem was resolved.

DaveG, 14-Mar-2010: Just recording that we're not actually sure what the root cause was, and that it's possible that the upgrade was the solution, but it might not have been. BlogIt should work find under PHP 4.

Delete a post

Status: Added to 1.4.0

valeh? February 17, 2009: Is it possible to delete a post (after it has been published and when it is saved as a draft). Thanks.

DaveG, 17-Feb-2010: There is not currently a built in mechanism to delete entries- I'll add it to the todo list. For now, use the built in PmWiki delete mechanism: use the PmWiki edit link, and then delete the page content and type the word delete, and save the page.

Entries don't display

bilu? 20-Feb10: Not sure why... set up a Farm site on a sub directory of my main site. Followed the basic install for BlogIt but all of the pagelists for the main page, categories, recent posts in the side bar and main page are empty ? I'm guessing i have a bad path set somewhere or I have missed somthing obvious. New entry works, and wiki.d shows the pages in the file system. Blogit/pmwiki can't find them. Sorry for the newbie question, but I'm stuck. thanks..

DaveG, 20-Feb-2010: So things to check:
  • Can you view new entries just by visiting the page? If not, disable blogit (comment/remove out the include_once line), try to view the page. BlogIt entries are normal PmWiki pages, so if you can't see the page you have a non-BlogIt config problem.
  • If you can view entries outside of pagelists, then could you post what you have as you pagelist for the main blog entry summary page.
  • Did you change the name of the blog, ie, have you set any BlogIt variables in config.php, like $bi_BlogList? If you did you need to adjust the pagelist accordingly.
  • Make sure you set the 'Status' of the entries to Publish, or to match whatever status you used in the pagelist.
  • If none of this helps, is there a url I can see, and can you send me your config.php settings? email: pmwiki at solidgone fot com.

bilu? 20-Feb10: Thanks for the info. The entries are viewable with BlogIt disabled. Helpful! My pagelist is exactly as indicated on the install page. My concern is that I have it in the wrong place/group or something. I went to the home URL and edited that page to insert:

(:includesection "#blog-summary-pagelist blogid=blog1 status=publish":)

The only change I made and it was to the blogit.php file was to the User Settings, changing SDV($bi_DefaultGroup, 'blog'); to SDV($bi_DefaultGroup, 'vlBlog'); I'll send the url/config shortly. Thanks. I think I have rooted the blog in the wrong path in my FS. That's my hunch.

bilu? 02-Mar10: Tried a new install on a new farm wiki and didn't muck with any files this time. And it worked. FIXED.

Issue with posting: author name required whereas field populated

Status: Bug fixed 1.3.2

swissc4 February 11, 2010: I've just installed Blogit locally for evaluation purpose. I've posted several messages + comments attached to. Since Yesterday, when I try to create an new entry / a new comment on an existing post, I get the following error: "An author name is required. Unable to save page" whereas fields "name" + "email" are correctly filled in. Config.php has not been altered since the initial install. I'm using the skin "dropshadow" but I've already tried to de-activate it but no positive effect. Same issue occurs with Firefox and IE7. Thanks for any suggestion.

DaveG 11-Feb-2010: The error "An author name is required." is generated by the Require Author recipe, which makes me think you might have a config problem. BlogIt doesn't check for the Author. The only way I can replicate this error is if I use the PmWiki edit link, rather than the BlogIt edit link. Can you confirm that you get this error when using the BlogIt edit link for comments/blogs? It sounds like you do as you note you get the error on blog creation.
  1. Are you using AuthUser?
  2. Do you have $EnablePostAuthorRequired = 1; set? If so, does setting it to '0' change the behavior? Where is it being set in relation to the include of BlogIt and AuthUser? How are you setting the $Author variable?
DaveG 12-Feb-2010: One more thing I thought of. Are you setting $action anywhere? Possibly, as a result of checking it's value, but with a typo of '=' rather than '=='?

swissc4 12-Feb-2010: I've not activated authuser. Having set $EnablePostAuthorRequired to 0 has fixed my issue, thanks! Does this param relates to a PMwiki's recipe?

DaveG 12-Feb-2010: $EnablePostAuthorRequired is a PmWiki setting, and should not have any effect on editing/creating either blogs or comments. I've tested that, and don't get the effect you describe. If you have time/desire to experiment it might be useful to find out *why* it's affecting BlogIt. Could I take a look at your config (minus passwords, etc)? Let me know.
DaveG 16-Feb-2010: Identified the problem, and logged as a bug. In the meantime if you are not using AuthUser, and receive this error when posting, set $EnablePostAuthorRequired=0;.

Delete a Comment after it has been approved

valeh? February 12, 2010: I am using the captcha recipe to automatically accept non-spam comments. I was wondering how can I delete a comment if it is a spam and is not detected by the captcha. Additionally, despite I am logged in and I have set the authorization in the config.php, I have not been able to view anything in the Blog Admin page (But I can post new entries). Can you please provide more detailed steps.

DaveG 12-Feb-2010: If you are logged in with edit privs (or if you are using AuthUser, then you need the comment-approve role) then you should see links next to each comment, for un/approve, edit, and delete. If you are unable to view anything in the Admin page, that suggests a problem with the security setup/config. If you can provide me details of your settings (or send your config.php to me at <<email removed>>) and I'll do what I can to help. Things to check:
  1. The most likely cause is that you need to have edit access to a page called Blog.{$DefaultName}, which usually resolves to Blog.HomePage. If you don't have a Blog.HomePage page, and are using a different page (it can be any page, but usually the main page which lists your blog summaries), then add this to config.php, before including BlogIt: $bi_Pages['auth']='Group.YourPage';
  2. If you are using AuthUser make sure you declare the roles, and passwords *before* including AuthUser.
  3. If not using AuthUser, you simply need edit privs, unless you have made other changes to $bi_Auth settings).
  4. Make sure BlogIt is towards the end of config.php.
valeh 15-Feb-2010 Thanks for your quick reply. The problem was with the authentication. I was trying to use a group that was declared in the htgroup file. Here is the corresponding piece of the config.php that did not work:
$AuthUser['htpasswd'] = 'wiki.d/htpasswd';
$AuthUser['htgroup'] = 'wiki.d/htgroup'; //defines the editors group
$DefaultPasswords['edit'] = array('id:*');

//some stuff here...

// [1] Define BlogIt roles, and associated actions
// Actions: 'comment-edit', 'comment-approve', 'blog-edit', 'blog-new', 'sidebar', 'blogit-admin'
$bi_Auth = array(
	'blogs'=>array('comment-edit','blog-edit', 'blog-new', 'sidebar','blogit-admin'),
	'comments'=>array('comment-approve', 'sidebar','blogit-admin')

// [4] Assign roles to security groups
$DefaultPasswords['blogs'] = array('@editors');
$DefaultPasswords['comments'] = array('@editors');

I ended up defining the editors group in the config.php.

Body displayed twice

Status: Issue resolved

johan? February 13, 2010: The body of blog items are displayed twice on my setup (lastest versions of everything, installed from scratch). Any idea?

DaveG 13-Feb-2010: I haven't seen this with the more recent versions of BlogIt, and I was unable to replicate the behavior, so I'm not sure of the cause. Some ideas:
  • I notice also that the page header is missing, as is the Recent Entries list on the sidebar. Did you include the BlogIt Sidebar? Did you use a (:notitle:) directive on the blog entry?
  • Are you calling any 'advanced' PmWiki functions before the include of BlogIt? For instance a call to PageTextVar, or possibly CondAuth?
  • Could you either open up ?action=source, or post the base PmWiki markup from one of the blog entries. It's possibly something is not saved correctly.
  • Would you be willing to send me any config.php files (with passwords masked). Perhaps I can replicate the issue.

johan? February 13-Feb-2010: I just realized I had made a change. On our server, split is not allowed. When split is used, I get errors when trying to create new entry. After googling a bit (I know nothing about php) I replaced it in blogit.php with explode instead. Then new entry works, but I get the double body text display instead. After some trial and error of replacing only some of the splits, it works ok.

Unstyling entries in the sidebar

Status: Closed

SteP January 15, 2010, at 03:09 PM: Found an answer to an old question. Comments in the sidebar pick up styles from comment entries. For instance, if the comment text starts with %red% then the comment in the sidebar will be red. I played with recipe MarkupToUnstyled, and it seems to work well in obviating this issue. Just set $bi_UnstyleFn='MarkupToUnStyled'; before including blogit.php, and include recipe MarkupToUnstyled in your configuration. I have also added an optional patch to MarkupToUnstyled.

DaveG 18-Jan-2010: This is also documented in the FAQ.

Links with spaces in them broken when viewing blog entries due to hyphenation

Status: Resolved in 1.2.2

Peter Kay January 06, 2010, at 01:59 PM: Stumbled across this yesterday:

  1. Create new installation of blogit
  2. Create Blog/Blog page with entry: (:includesection "#blog-summary-pagelist blogid=blog1 status={$bi_StatusType_PUBLISH}":)
  3. Include blogit sidebar in Site.SideBar.
  4. Create new Blog entry "First test blog".
  5. Go to new blog entry.

Any link with a space in it (e.g., Documentation Index in the sidebar) is broken as PmWiki now hyphenates in it (Documentation Index?).

Quick workaround is to put $bi_TitleSeparator=''; before the cookbook entry for Blogit.

DaveG 7-Jan-2010: I don't see that behavior. If I add [[PmWiki/Documentation Index]] to Site.SideBar, before my included Site.BlogIt-SideBar]] the link is displayed as it should be. I do recall this being a problem in earlier BlogIt versions though. Are you using 1.2.1, or an earlier version? Are you setting $MakePageNamePatterns anywhere, or have some other clean url configuration which may be causing this interaction?

I'm using pmwiki-2.2.7 with CleanUrls. BlogIt is the Nov 18th 2009 version.

Peter Kay January 07, 2010, at 03:36 PM: My Site.SideBar has [[PmWiki/Documentation Index]] after the included Site.BlogIt-SideBar. I don't know if that makes a difference.

If I comment out the line bi_setMakePageNamePatterns(); in function bi_SaveTags($body, $user_tags, $sep) then it seems to work fine for me. FWIW.

8-Jan-2010, DaveG: before or after works fine on my installations. Commenting out the bi_setMakePageNamePatterns() is the routine that converts the spaced title into a hyphenated title, so that makes sense. What doesn't make sense is why viewing a title with spaces shows hyphens. I'm thinking there might be a PmWiki setting you have which is having this effect. Would you mind sharing your config file?
UPDATE: I don't actually see this behavior on your test site. Links seem to be displayed correctly. Did you fix this?

Peter Kay January 09, 2010, at 01:43 AM: Sorry about test site problems - moved it while I was running out the door w/o making sure it ran. I created a blog entry; you can see the problem at: [(approve links) edit diff] Not sure why removing the line in the SaveTags function makes the problem go away.

9-Jan-2010, DaveG: Okay, I can now replicate this problem. I'll work on a fix.

blogid in sidebar problem in default installation.

Status: Resolved

Peter Kay January 06, 2010, at 02:29 PM: Sidebar blogid variable problems...not sure how this works for you on your example site, and doesn't for me, but I have a workaround for me, so I'm happy!

Default installation as described above, put in a few blog entries, go to Blog/Blog. I expect to see some entries under Recently Written...but nothing. I dig around a little and find out what's happening: blogid is not being set! If I'm not looking at Site/Blogit-SideBar, it's failing. The Drafts, etc links don't work either - they send one to pages like:


And of course "blogid=blogid=" doesn't work.

Straightforward workaround for one-blog site: in Site/BlogIt-SideBar, set blogid=blog1 explicitly in every call.

DaveG 7-Jan-2010: In Site.Blogit-SideBar the second line should read (:blogid:{$bi_BlogList_BLOG1}:) -- this sets the blogid, based on the values in $bi_BlogList. Have you changed the values of $bi_BlogList? Could you also confirm the version of PmWiki, and BlogIt that you're using?

Your workaround is also reasonable. But you should only need to set the blogid once in the SideBar, so not sure what you mean by "explicitly in every call".

Peter Kay January 07, 2010, at 03:36 PM: I'm using the default Site.Blogit-SideBar that comes with BlogIt, so the 2nd line indeed reads: (:blogid:{$bi_BlogList_BLOG1}:). Again, using pmwiki-2.2.7 and the Nov 18th 09 BlogIt. No changes to any $bi_foo variables.

I'm not sure if it's general failure of PmWiki variables (maybe in included files?), or what...blogid seems to not be being set there :-/ I see it set if I look at the page Site.BlogIt-SideBar?, but not when included in Site.SiteBar?. So my workaround replaces each instance of blogid={(bi_ifnull '{$$blogid}' '{$:blogid}')} with blogid=blog1

I can set up a wiki somewhere public, so you can poke at it, if you think that'd help. [(approve links) edit diff] ; passwords are the same as the admin password for your example site; will keep it up for a little bit?

8-Jan-2010, DaveG: Interesting that the variable replacement happens when you view the page directly, but not when the page is included.

That seems to suggest a PmWiki setting somewhere. I'll take a look at your sample site, and do some investigation.

UPDATE: Looks like you have some .htaccess errors, so I can't view the config.php, nor edit pages on the test site.

Technically, it was a problem of the wrong $ScriptUrl and failure to preserve permissions. Fixed now. *blush*

UPDATE2: Some notes from a quick poke around.

  1. PmWiki will honor the last variable declaration. So the last variable declaration 'wins'. See that in action on this test page?. Also note that variables declared on an included page are not automatically seen by the including page -- you can use a 'full-reference' to do that.
  2. You need to be careful with quotes when using bi_ifnull. I seem to remember having issues if the second paramter has quotes. So use:
{(bi_ifnull "{$$blogid}" {$:blogid})}
{(bi_ifnull "{$$blogid}" "{$:blogid}")}

Peter Kay January 09, 2010, at 01:43 AM: Interesting, but the problem here seems to be that even within the page itself, the variable isn't "sticking". Trying the unquoted versions didn't seem to help - just checked that.

8-Jan-2010, DaveG: What happens if you disable BlogIt and then try to do a test like the one on DaveG/TestVariable? Does the variable assignment occur then? This might go quicker if we communicate via email. Feel free to contact me on <<email removed>>.

12-Jan-2010, DaveG RESOLUTION: Issue was resolved by setting $EnableRelativePageVars = 1; in config.php. Added this info to the FAQ.

Pagename Invalid XL Error?

Status: Fixed in 1.2.2

SteP December 16, 2009: PmWiki or BlogIt seem to miss translating a specific XL message, "Pagename already exists, or is invalid/blank." in file Site.Blogit-CoreTemplate. Since the markup seems correct, I included PmWiki in the list of suspects. I could also include my XL file, but I'm reasonably sure that I didn't misspell the source string. This error message comes up when a new entry has a blank title. By the way, I think it would be more clear if the message was "Title already exists, or is invalid/blank."

18-Dec-2009: The problem is a syntax error in Site.XLPage-BlogIt, so I've logged this as a bug. I also agree that the term "Title" is better.

Restrict comment to authenticated users?

Status: Issue closed

SteP December 04, 2009: Is it possible to restrict the permission to write comments to authenticated (AuthUser) users only? Unauthenticated users should still be able to read all comments, but they shouldn't see the enter-comment form nor be able to write comments otherwise. Thanks.

DaveG 5-Dec-2009: At the moment there is no built in authentication options for 'new comments'. One way to do it might be to assign a new role 'comment-new' to appropriate users, and then override the #comments-pagelist in a skin template, checking to see if the user is assigned to the role in order to display the comment form.

Override #comments-pagelist in a skin template file, using this line in place of the existing check -- note the new bi_auth check:

(:if [ bi_auth comment-new {$bi_AuthPage} && equal "{$$entrycomments}" "{$bi_CommentType_OPEN}" && equal {$bi_CommentsEnabled} true ] :)\

And in config.php, something like this:

# New action 'comment-new' to the 'comments' role
$bi_Auth = array(
  'blogs'=>array('comment-edit','blog-edit', 'blog-new','sidebar','blogit-admin'),
  'comments'=>array('comment-new', 'comment-edit', 'comment-approve', 'blog-edit', 'blog-new', 'sidebar', 'blogit-admin')

# [2] Define users passwords
$AuthUser['daveg'] = crypt('daveg');  #set daveg password
$AuthUser['step'] = crypt('step');  #set daveg password

# [3] Add users to the roles
$AuthUser['@blogs'] = array('step');
$AuthUser['@comments'] = array('daveg');

# [4] Assign roles to security groups
$DefaultPasswords['blogs'] = array('@blogs');
$DefaultPasswords['comments'] = array('@comments');

How to stop comments from showing up in AllRecentChanges?

Trevor November 25, 2009: Is it possible to stop comments from showing up in AllRecentChanges? I'm using the following code in my local/config.php, which works for other groups, but not for the Comments group:

$group = PageVar($pagename, '$Group');
if ($group == 'Comments') {
  unset ($RecentChangesFmt['$SiteGroup.AllRecentChanges']);
DaveG 25-Nov-2009: This should do it:
if (@$_POST['target']=='blogit-comments') {
  unset ($RecentChangesFmt['$SiteGroup.AllRecentChanges']);

Note: Also be careful using PageVar within config.php, as it reads and caches the page, which some scripts which need to change a page content (BlogIt for example) are going to have problems with.

It did indeed do it, thanks! Any suggestion on how to find the group of the page when editing pages without PageVar? I.e. to replace if ($group == 'SiteAdmin') more safely?

DaveG 25-Nov-2009: Here's what I use:
list($Group, $Name) = explode('.', ResolvePageName($pagename));

That makes a lot of sense. Thanks again!

Trevor November 29, 2009: Sorry to reopen this question, but is there a similar method to ensure that unpublished drafts don't appear in AllRecentChanges as well?

DaveG 29-Nov-2009: This should work -- combined with the check for comments:
if (@$_POST['target']=='blogit-comments' || $_POST['ptv_entrystatus']=='draft') {
  unset ($RecentChangesFmt['$SiteGroup.AllRecentChanges']);

Trevor November 29, 2009: Fantastic, that worked perfectly, as usual. Can't thank you enough. I'm not sure if it would be helpful, but I made a tutorial for how I set up my blog's RSS feeds here and here; you're more than welcome to take anything you think is useful, or point me to where best to post it myself.

DaveG 29-Nov-2009: Nice information. I'll incorporate it into the BlogIt docs.

CleanUrls problem

Status: Resolved in 1.2.0

Peter Kay November 14, 2009, at 12:00 AM: I add this recipe (looks great, BTW, except for this one problem), and it works fine if I set my browser to http://mysite/Main/HomePage, but I'm using CleanUrls, and when I got to http://mysite/, I expect to get my HomePage, but instead I get an error:

  ?invalid page name

  We are sorry for any inconvenience.

  Return to http://mysite

Well, that's not what I expected! I don't even know where it's trying to send me :-( Any help on avoiding this?


DaveG 14-Nov-2009: Yeah this is a known issue. I'll be publishing a new version that resolves this, today. If your need is more urgent, try this workaround (suggested by Twylite below): add $pagename = ResolvePageName($pagename); to config.php after setting $WikiDir (for a custom page store or folders) and $PagePathFmt (customise group home page), and before blogit.php.

Realized just as I was putting the computer to sleep last night that this was probably the same issue. Thanks for getting a new version out there so quickly! Peter Kay November 14, 2009, at 10:25 AM

Group navigation breaks

Status: Resolved in 1.2.0

Twylite? Nov 11, 2009: blogit.php calls FmtPageName() before ResolvePageName(). This means that a URL like ?n=Site (which should be resolved as a redirect to the Site home page, typically Site.Site) is translated by FmtPageName() to "." which resolves to a 404 Page Not Found. This in turn breaks the "navigation trail" above the page name in the default skin (and others).

Workaround: add a line $pagename = ResolvePageName($pagename); to config.php after setting $WikiDir (for a custom page store or folders) and $PagePathFmt (customise group home page), and before blogit.php.

DaveG 11-Nov-2009: Thanks for the work-around. This has been fixed in the development branch, and a fix will be public soon.

use of undefined constant assumed

Status: Fixed.

MikeBishop Nov 4, 2009: Setting up a new site, decided to use BlogIt with the colormetry skin---and everything seem to be working, but I get those blasted

(date| ... |commentid)\s?(.*?):\)(.*?)\(:blogit-skinend:\)/esi Use of undefined constant commentdelete - assumed 'commentdelete'

across the top of the skin (and in sidebar). Tried altering error reporting toggles in php.ini to no avail (and couldn't change that file on my hosting provider anyway). Google gives numerous examples of this error, but none that I could grok in a blogit context. Tested on Apache 2.2.8/PHP 5.2.4-2 and Apache 2.2.14-1/PHP 5.2.10

DaveG Nov 4, 2009: What you're seeing appears to be the uninterpreted markup, suggesting blogit is not actually enabled. It seems like you are also seeing a PHP error, but you didn't say what error message you see -- if you are seeing a php error, let me know. In the meantime, some things to check -- some of which I have no doubt you already did, but listing just in case: The error above is repeated for most of the variables identifiedin the blogit-skin markup.

  1. Does blogit actually seem to be enabled? Do you see any evidence of blogit, perhaps in the sidebar, or a blog entry being shown, etc? Yes, all blogit features tested to date work as advertised. And yes, it's a PHP error: ERROR: pat=/\(:blogit-skin (date|intro ... commenttext|commentid)\s?(.*?):\)(.*?)\(:blogit-skinend:\)/esi Use of undefined constant edit - assumed 'edit' If you're not in a production environment, the easiest way to check might be to simply add a print ('ENABLED'); at around line 12 of blogit.php -- you should then see that at the top of the browser (plus a bunch of error messages). If not, then check you have blogit in a folder called blogit inside the cookbook/ directory, and that privs are set correctly. Double check that the include statement in config.php refers to the correct directory. Yep
  2. Did you increase the number of includes in config.php, by $MaxIncludes=500; -- if so, you *may* need to increase it more, although I've not seen a need to do this on any other instance. Yep
  3. BlogIt needs to be the last cookbook included, so check that it is. Yep
  4. Just in case... what version of PmWiki are you running? Latest version, pulled on Tuesday.

DaveG Nov 5, 2009: One other thing I thought of: is there a problem with the way in which the blogit.php files is saved, with newlines/carriage returns? Try opening/saving the file in the environment your working under. The file is fine. But I did restate the blogit-skin markup for one test, just in case I had a weird character somewhere.

Thanks for your prompt response. If it matters, testing was on an up-to-date Arch linux box, and on an Ubuntu (Hardy) laptop.

DaveG Nov 5, 2009: As you note, the issue appears to be with the setup of your server PHP environment expecting explicit declaration of constants. For example an array being indexed with a constant (ie, without quotes, like $x[y], rather than $x['y']).

As you note, you can hide this warning by changing the error reporting level in php.ini. Even though you don't have access to the php.ini file, you can create the file in the same directory as pmwiki.php, and it should get read in. So copy the original php.ini into the pmwiki.php directory, and make changes to that file. However, this is simply going to mask the underlying problem, not address it.

The real problem is the constant being used as an array index. I don't see an instance of this in blogit, but it may be occurring in conjunction with values being passed to blogit markup. Are you using any of the blogit markup? If so what text are you using it with? My guess is you have some text being passed to a blogit markup that contains a quote, and this is not being handled correctly.

Is this basically an empty install of pmwiki, or is there exiting content (either blogit or normal pmwiki pages), or other recipes/markup that may be conflicting?

New install PmWiki, blogit, capcha. Just cleaned wiki.d, added an initial page, entered a single blog entry with one para of Lorem Ipsum, and the error appeared. Note that pmwiki.php has error_reporting(E_ALL ^ E_NOTICE); as its first line. Commenting that out, and with display_errors = Off in php.ini does not prevent the error display. Runninng out of ideas ...

Does the same error occur when using the default pmwiki skin? Yes

DaveG Nov 5, 2009: Ah, so the error only occurs when displaying a blog entry. Not when displaying the sidebar with no blog entry in the main page? btw, if you'd rather continue this by email, reach me on <<REMOVED>>.

Also, try this.

  1. Include blogit as normal.
  2. On a non-blogit entry page -- so just a normal pmwiki page -- use the markup that seems to be causing problems, for example:
(:blogit-skin date fmt='long':)4324244(:blogit-skinend:)

And lastly... on line 164 of blogit.php add single quotes around the $1, so it reads:

"blogitSkinMU('$1', PSS('$2'), PSS('$3'))");

BINGO! That fixed it, thanks. If I had a dollar for every time quoting had screwed me up ...

DaveG Nov 5, 2009: Glad it's fixed. Odd how we've never seen this error before. Looks like your server ignores the warning off setting, so you saw the notifications.

Comments don't work with PerGroupSubDirectories

29-Oct-2009: Issue resolved - use current (Sept 2009) PerGroupSubDirectories recipe

Twylite? 29-Oct-2009: I was having trouble getting BlogIt comments to work. The short version is:

  • I created a fresh pmwiki-2.2.6 installation and installed only BlogIt, RecipeCheck and Blix. The blog functionality seemed to be fine.
  • I enabled PerGroupSubDirectories, adding the line $WikiDir = new PageStore('wiki.d/$Group/$FullName'); to local/config.php and moving the files in wiki.d into appropriate subfolders.
    • Normal Wiki pages are present and everything except the blog works fine.
    • The blog summary/recent page is empty, and although I can access individual blog posts each reflects 0 comments.
  • Tried rebuilding the .pageindex just in case, but no change.


  1. When I include blogit.php in my local/config.h, pagelist can no longer see groups in my PerGroupSubDirectories PageStore (only the ones in wikilib.d). If I remove blogit.php pagelist works fine.
  2. This is definitely caused by something in blogit.php: including pmform.php or guiedit.php (the only files included from blogit.php) directly in my local/config.h does not cause problems.
  3. Current thoughts: blogit.php is either messing with the PageStore or altering the behaviour of pagelist somehow?

Update #2:

  1. M'kay ... so I copied the new PageStore line from a site that was set up in August 2009. And in September a change was made to PerGroupSubDirectories: $WikiDir = new PageStore('wiki.d/Cookbook/Cookbook.BlogIt-Talk'). This causes $Group to get substituted at the right time, and solves the problem.

Read More... not showing on the Main Blog Summary Page

Issue resolved.

13-Oct-09, Allan?: Hi, I followed the BlogIt installation instructions and put the following on the Home page:

... :includesection "#blog-summary-pagelist blogid=blog1 status={$bi_StatusType_PUBLISH}...

The main page seems to always display entire articles, not summaries (I put in several test entries, each with around 5 paragraphs worth of Lorem ipsum). i.e., no "read more...". I can't seem to get that to work. Am I doing something wrong? (I've installed pmwiki 2.2.4 and BlogIt v1.0.0.). Thanks for any help.

p.s. I like this recipe, thanks so much. And the BlogIt-friendly skins are terrific.

DaveG 13-Oct-2009: Glad you like BlogIt, and the skins, thanks! You need to tell BlogIt where the split is between intro and the rest of the entry. Do that by adding a [[#break]] anchor. (This is not actually documented anywhere yet, so don't feel bad -- docs will be coming soon.) If things still don't work after that, then make sure you're using the latest version of the skin. If you still have problems... let me know!

14-Oct-09, Allan?: Thank you! That did it. Working great now. I noticed someone else raised the same "read more" issue on the Equilibrium-Talk page. I can confirm that this works on the Equilibrium skin and Glossy Hue. (I moved this to Closed Questions - I hope that was the right thing to do.)

BlogIt and Captcha permissions (Insert a comment require a password)

Issue fixed (1.0.0)

fabrizio?, 6-Sep-2009: Dear Dave, I am sorry to bring this up again but despite the very long list of answered questions in this page, I could not find a solution to this problem. I've got Captcha, BlogIt and the skin Equilibrium to work but I have a problem with permissions that I dont understand. When somebody tries to leave a comment on a post and enters the correct Captcha code, he is prompted with an Edit password and that should not happen (anybody can leave a comment). Could you please advise on how to fix it?

Secondly, is it possible to bypass the comment validation part in automatic, so that anybody can leave a comment on the web without needing the owner of the site to validate them?

thanks a lot for your help

DaveG, 6-Sep-2009:

  1. This is a known issue, and I'm working on a fix. Are you using AuthUser? Is BlogIt one of the last cookbooks? What other cookbooks are you using (if you can list in the order they are used that would help)?
  2. No at the moment bypassing the comment authorization mechanism is not possible. The only time I can think that this is even remotely desirable is if the blog is being run on an internal network -- in which case this is a valid scenario, and I'll add it to the feature request list. If this is intended for internet use, then this scenario will become over-run with spam.

fabrizio, 7-Sep-2009: Dave, thank you for your reply, understand point 2. For point 1, I am not using AuthUser... I guess that since you ask, I should... All my cookbooks where downloaded 3 days ago.

This is what my config.php file right now:

# include the Captcha feature                      
if (!CondAuth($pagename,'edit')) $EnablePostCaptchaRequired = 1;

## add the blog feature

# Script to obfuscate e-mail address

Admin and edit passwords have been set properly (at the beginning of config.php). Could you please advise how to used AuthUser so that people interested in leaving a comment are not requested to enter a password? I've tried to get this info by myself luck. cheers fabrizio

7-Sep-2009, DaveG: It's certainly not necessary to use AuthUser. Reason I ask, is the other person with this problem is using AuthUser, and I thought that might be a common link.

The problem in your case is likely to be that CondAuth check. Doing a CondAuth means PmWiki reads the page, which means that BlogIt cannot now change passwords to allow anonymous login. I'm trying to get a work-around for that, but for now simply remove the if condition but retain the $EnablePostCaptchaRequired=1 -- BlogIt handles this for you.

fabrizio, 8-Sep-2009: oh, ok I see, I changed the config.php as suggested but password is still required. Here the new content of the config file:

# include the Captcha feature                      
$EnablePostCaptchaRequired = 1;

# add a blog feature

# Script to obfuscate e-mail address

the blog is on line here:

let me know if I can help in some how. Cheers fabrizio

fabrizio, 21-Sep-2009: Dear Dave, I still do not understand if it is normal for a person interested in leaving a comment to expected to have an edit password. Could you please let me know if this is a bug or if it is possible to enable this option. Thank a lot fabrizio

DaveG, 21-Sep-2009: Sorry, I guess I wasn't clear. It's definitely a bug, and one which I've now fixed, but not yet released. I'm just finishing a few things up, and should have a new release 'real-soon-now'.

DaveG, 22-Sep-2009: If you are interested I can send you the latest development release, and make sure that resolves your issue. Let me know <<email removed>>.

Hyphenated Titles

Issue resolved

29-Aug-2009, johan?: After installing the 2009-08-20 version, my titles get hyphenated when displayed, and when I press on the edit link, I get a blank page. Reverting back to older version, and the titles remain hyphenated, but if I create new items, they look right. Edit works in older version too. The blog is here

29-Aug-2009 DaveG: Could you verify that you have the latest BlogIt installed by checking the value of $RecipeInfo on line 8 of blogit.php. It should be:

$RecipeInfo['BlogIt']['Version'] = '2009-08-08';

This is an old bug that was fixed, so just want to make sure. Also:

  1. make sure that BlogIt is one of the last cookbooks you include
  2. Are you using any recipe that sets, or are you setting $MakePageNamePatterns, or using any internationalization recipe?

30-Aug-2009, johan: Put it as the last to include, line 8 reads august 20, still same issue. The blog items have hyphens in their filenames, but when I edit them they have the correct names (in the old version as I cannot reach them in the new version as described above)

Don't think I am setting $MakePageNamePatterns, or use any internationalization recipe.

31-Aug-2009, DaveG: The edit page being blank is what happens when PmForms is included before including BlogIt. BlogIt does the include of PmForms for you, so you don't need to include it in config.php. If you need it for some other purpose, then include it after blogit.

1-Sep-2009, DaveG: What version are you upgrading from? The storage format has changed, so it's possible you're using an older storage format.

2-Sep-2009, johan: Aha, one step closer. Removed the pmforms include, and the edit link works now. Title is still displayed with hyphens though. Last version was 2009-03-02. Should I run the upgrade function which I noticed now? Thank you for your patience, and great cookbook and skin.

6-Sep-2009, DaveG: If you have only a few blog entries, then creating new entries and copy/pasting the content is likely to be the most effective way to handle this. Let me know if you have more, and I'll verify the Update mechanism fixes this problem.

8-Sep-2009, johan: Setting the posts as drafts, saving, and then changing back to publish cleaned up the data.

Custom Blog Styling - Unique style for Blog Page - Creating a third sidebar for Blog page only?

Issue closed

23-August-2009 K4?: I suppose I'm just curious about styling for a blog page on a site with lots of other pages. My main interest, however, is in creating some sort of third sidebar on the right (my main sidebar is on the left) where I could display a Twitter feed. I've looked at the styling page for some individual themes, but I'm _very_ unsure how to go about editing them. Any thoughts? my email: Thanks!

29-Aug-2009 DaveG: This is not so much a BlogIt question as a general skinning question -- you might get more approaches posting on the mailing list. Here's a few suggestions:

  1. Modify the skin to include the div column, including a page based on the name of the current page: <div id='commentpage'><!--wiki:Twitter.{$Name}--></div>
  2. Simply copy the skin you are using, and modify it to include a third column. Then set that skin if the current page is a blog page (ie, within the Blog group). Remember, you can use any skin with BlogIt, not just those that provide the BlogIt skin layer.
  3. Set the skin for the MyGroup group, by creating a file MyGroup.php, in pmwiki\local\: $Skin='myskin';

Tags for drafts being shown in the Blogit Sidebar. Bug?

Issue fixed (1.0.0)

July 26, 2009 AnibalRojas: Looks like the tags added to draft posts are finding their way to the BlogIt SideBar, they end linking to nothing adding noise.

27-July-2009 DaveG: Thanks for taking the time to comment. I logged this issue as a bug. I suspect there are a few other places where this occurs as well (probably RSS feeds, maybe others).

Captcha troubles

17-Jul-2009: Issue resolved.

SteP July 13, 2009: How is the captcha feature supposed to work overall? I mean I was able to enable a captcha for the the #comments-form, but now that captcha is enabled pmWiki wants me to enter a valid code in #blog-form too. Is this how it works for you? As a workaround I changed the #blog-form template to add captcha input
(:div class="indent" style="overflow:auto;width:800px;border:1px dashed gray":)

(:if equal {$EnablePostCaptchaRequired} 1:):$[Enter value:] {$Captcha}:(:input captcha:) (:ifend:)\


but I having to enter a catpcha every time I add/change a blog entry is a bit of a nuisance, especially since I'm already authenticated.

Another issue is that if I want to directly edit a blog entry page - action=edit instead of action=blogedit - pmWiki shows a "must enter valid code" message immediately when it loads the edit form. I didn't try if adding captcha markup to the site edit form would work around this issue, as I don't want a captcha every time I edit a page. Note: I'm using the Triad skin, perhaps this issue is specific to Triad, I haven't tested Skittlish.

DaveG July 13, 2009: This isn't how it works for me, so looks like we have a different configuration. You should be able to normal edit with no captcha, and if you are the admin then you should not be prompted to enter a captcha. I'll document the settings I used to obtain that behavior. It sounds like you created a new skin level BlogIt template -- make sure your format is based on what is in CoreTemplate. Perhaps this is related to the point you raised earlier about the hard-coding in the PmForm declaration? (I have some work on skins to finish up, then I'm going to start addressing the many points you've come across -- sorry for the delay!)

I verified my setup. I use the following configuration, before I include BlogIt. If you use the Admin password, then the captcha will not be displayed. Does this problem happen when you don't use your custom skin (ie, is this related to the other problem you notes regarding PmForm hard-coding?)

$EnablePostCaptchaRequired = 1;

SteP July 13, 2009:''' I use skin Triad with a skin level BlogIt-SkinTemplate. I created it as Site.BlogIt-SkinTemplate-triad in pub/skins/Triad/wikilib.d/Site.BlogIt-SkinTemplate-triad taking BlogIt.CoreTemplate as a base and adding selected overrides from Site.BlogIt-SkinTemplate-skittish. Then from wiki I edited Site.BlogIt-SkinTemplate-triad - which placed a copy of the page in wiki.d - and added my own overrides that relate to the multi language issues as documented below plus the captcha workaround which we are discussing in this paragraph. I log in with admin password. My configuration loads the captcha recipe exactly as your setup does. As you requested, I tested what happens when Site.BlogIt-SkinTemplate-triad isn't loaded (to do this test I renamed both wiki.d/Site.BlogIt-SkinTemplate-triad and pub/skins/Triad/wikilib.d/Site.BlogIt-SkinTemplate-triad to dummy names. It didn't fix this issue. I _can_ post an entry without being asked for a captcha. But if then edit the same entry, when I press "Post" I get "Must enter valid code" "Unable to save page" messages.

DaveG 13-July-2009: The easiest way to remove the triad template from the picture is to switch to the default skin. That way we know we're only using basic BlogIt functionality.

In terms of the admin password. Just want to make sure we're on the same page. I load no specific authentication cookbooks. I set the admin password using the $DefaultPasswords['admin'] = crypt('admin'); format in config.php.

It may be easier to continue this via email, as this page is getting a little unwieldy. Feel free to contact me on email.

DaveG 17-July-2009: This issue was discussed off-line. The problem was that BlogIt was not active for a group where there was a blog-page. So when attempting to use PmWiki functionality to edit the blog-page, the captcha kicked in (normally suppressed by BlogIt).

Comments group name

17-July-2009: Issue closed.

SteP: When I tried changing the default group name with $bi_CommentGroup new comments disappeared.

I could see their page being created in wiki.d with the changed group name, but the wiki page didn't show any comment entries.

1-Jun-2009, DaveG: Logged as a bug. When you say 'wiki page' I assume you mean the blog entry?


16-Jul-2009, DaveG:
  1. You have a blog-entry with comments. The comments were created under group Comments. You change the blogit $bi_CommentGroup to "New-Comments". The comments originally created under "Comments" no longer appear, either linked to the page, or on the SideBar.
  2. You change $bi_CommentGroup to "New-Comment". Create a new comment under a blog-entry. It dos not get listed in either the blog-entry or the SideBar.

If [1], then that's expected. You need to manually change the name of comment files reflect the name of the new group. I will clarify the documentation.

If [2], then can you provide more information on what you do to repeat this.

17-Jul-2009, DaveG: Neither SteP nor I are able to repeat this issue. Issue closed.

Fixed title in #unapproved-comments page

16-Jul-2009: Problem addressed

SteP July 14, 2009: Here the title of each unapproved comments in Site.BlogIt-Admin always was "#unapproved-comments" instead of the blog entry title. I changed Site.BlogIt-CoreTemplate slightly to fix this issue:
(:div class="indent" style="overflow:auto;width:800px;border:1px dashed gray":)

this line in #unapproved-comments
  !!! [[{(bi_base {=$FullName})} | {{(bi_base {=$FullName})}$Title}]](:ifend:)
  !!! [[{(bi_base {=$FullName})} | {{(bi_base {=$FullName})} $Title}]](:ifend:)

I just added a space before $Title. Perhaps my configuration loads some recipe that parses the markup expression slightly differently?

DaveG July 16, 2009: Problem has been identified as an issue with the MultiLanguage cookbook.

Category.GroupFooter vs. Tags.GroupFooter

15-Jul-2009: Logged as enhancement

SteP July 13, 2009: Just a heads-up that BlogIt overrides the GroupFooter page of the tags group, whatever markup you have in that page will not be used. The change is hard-coded in the php code, so it can't be undone from page markup. This becomes a problem only if you want to reuse your existing Category group for BlogIt tags - by setting $bi_CategoryGroup - because an existing pagelist in Category.GroupFooter page will be replaced with the BlogIt pagelist. I tried lots of workarounds but I couldn't come up with one good enough to let BlogIt tags (group Tags) and my existing categories (group Categories) work together smoothly. So I decided to merge tags and categories into group Categories, place my Category.GroupFooter markup into Category.GroupHeader - which BlogIt doesn't override, and live with the double pagelist output - one from my markup in GroupHeader, and one from the hardcoded BlogIt markup for GroupFooter.

DaveG July 13, 2009: The problem here is we can only use one footer. Either the one defined by the user or the one defined by BlogIt. What we could do is only use BlogIt's group footer if there isn't one already defined. Or maybe just let the user define $GroupFooterFmt.

DaveG July 15, 2009: Version 0.2.0 will allow GroupFooterFmt to be over-ridden in config.php -- that will allow for the use of BlogIt categories, and existing categories. You'll need to define your own GroupFooter to display categories appropriately.

Date/time formats in Skins

20-July-2009: Addressed in 1.1.0

SteP July 09, 2009: NOTICE also that I removed custom time formats here and elsewhere in the template because the existing hard-coded time format makes localization of the template harder, i.e., changed

(:ftime fmt="%a, %d %b %Y @%H:%M" when=...:) 


(:ftime when=...:) 

it doesn't look as pretty, but it works with all languages (when the localized XLPage specifies a localized time format).

at #meta-data-foot: comment(s), tags:,

at #comment-view: on:, approve,

at #comment-form: Comment,

DaveG July 16, 2009: Skins sometimes want to achieve a certain look -- part of this is what style date is displayed. I'll add some form of skin-date setting, that can be overridden.

Dash in blog group name

16-Jul-2009: Logged as bug

SteP July 09, 2009: I am using BlogIt with Skittlish and Triad skins. Triad is a good experiment because it forces me to look closely at how BlogIt works. It's a nice architecture. Now I need to report an issue. I found subtle bugs when using "Blog-en" as the blog group name. For instance, deleting a *comment* to an entry titled "Article-eng" - by entering the word "delete" in the edit form - put me back into the non-existent page Blog.En-Article-eng. You see that the group name is wrong, "Blog" instead of "Blog-en". And the unapproved-comments link in


also pointed to a non-existent URL. When I renamed the blog group to "Blogxen" all issues disappered. So I think it's prudent to stick to alpha(numeric?) characters only for blog group names.

How to approve links in comments?

16-July-2009: Logged as an enhancement

SteP July 09, 2009: If the ApproveUrls recipe is used - by including scripts/urlapprove.php in local/config.php - I can't find a way to approve links that are included in comments to posts, including, for instance, the "website" form field link. Not even if I point my browser to the virtual page name with action approvesites, i.e. approvedsites url. Help.

DaveG 15-July-2009: UrlApprove only allows approval of URL's actually on the page, not those that are included on the page. Since comments are included as part of the blog-page, they can't be approved from the blog-page using UrlAppprovals. At the moment rather than approving Urls, you Edit the comment, and then manually edit/remove the urls.

In theory you could view the comment page and UrlApprove. However, BlogIt doesn't currently allow direct viewing of comment pages, but re-directs to the blog-page. This is so that after editing a comment, you jump back to the blog-page, rather than the 'normal' PmWiki way of returning you to viewing the page you were editing (the comment-page), at which point, there is no smooth way to get back to the blog-page.

Suggestion 1: We could provide a new link along-side the comment, to include 'View for URL Approval' (so Edit, Approve, View). That would let you view the page, approve URLs -- but there would be no easy way to return to the point at which the approval process started.

Suggestion 2: When clicking the 'approve sites' link, display the comment in view mode. Allow user to now approve links. Still need a good way to say "take me back to the blog-page". Maybe use a GroupHeader on comment view to jump back to the blog page.

I think Suggestion 2 is the way forward. I'm open to other suggestions -- but we need to keep the workflow seamless.


14-Jul-2009: Documentation fixed

Following the installation directions, I added the optional settings for clean URLs, but then when I tried to add a new entry I was stuck in a full circle, wiki kept sending me to a "page <title> doesn't exist" page, and the new blog entry was never added (although it was tagged). To solve this issue I commented out in my local config file:

  $FmtPV['$PageUrl'] = '($group=="Blog") ? "$ScriptUrl/$name" : "$ScriptUrl/$group/$name"';

Could this issue have something to do with the CleanUrls recipe, which I haven't implement in my wiki?

1-Jun-2009, DaveG: I'm a little confused. You say you're not using clean-urls, but the code above appears to be doing some clean-url work. I'm not sure exactly what effects setting $PageUrl might have, but BlogIt does use PmWiki routines to determine whether the page already exists -- it's possible that either I'm, not using the routines correctly, or that $PageUrl is somehow causing a conflict. I achieved the same basic result from within .htaccess.

2-Jun-2009, SteP Just to clarify that the code above is taken from the BlogIt installation instructions (optional settings).

14-Jul-2009, DaveG: I removed this from the documentation, as it's too specific to a particular way of implementing clean urls. Users wanting clean urls should follow the advice given on the CleanUrls page.

Template error messages not localized

Issue fixed (1.0.0)

SteP July 09, 2009: I noticed that, unfortunately, template error messages - as provided by parameter errmsg in #comment-post-control and #blog-post-control - don't seem to honor localized strings.

SteP July 11, 2009: I think I figured out why.

  • Lines Blogit.php::110 and 112 use $bi_CoreTemplate, which I have not modified, as I prefer to group all mods in wiki page Blogit.SkinTemplate-skinname,

and rely on $FPLTemplatePageFmt to resolve template overrides.
* Could you change this part of blogit.php to use $FPLTemplatePageFmt?

DaveG July 11, 2009: Very good point. By hard coding the PmForm to use form=$bi_CoreTemplate the skin template form will never get used. Definitely a problem. As long as PmForms makes use of $FPLTemplatePageFmt in it's searching for the section then this looks like a good solution. Just need to test to verify. If it doesn't then I'll think of an alternative, as the current way isn't what I intended.


Issue fixed (1.0.0)

SteP July 09, 2009: I found several spots where $[text] could be used to facilitate translating text messages into another language. For instance, in blogit.php, line 32, instead of

SDV($bi_ReadMore, '%readmore%[[{$FullName}#break | Read more...]]'); 


SDV($bi_ReadMore, '%readmore%[[{$FullName}#break | $[Read more...]]]'); 

so "Read more..." can be easily translated in a localized XLPage.\\Here's a list of other files/pages where the same considerations apply:

in Site.Blogit-SideBar: Site Admin, Recently Written, Recent Comments, Categories,

in Blogit-CoreTemplate #control-panel: Unapproved Comments:, New Entry, Drafts, Published, Stickies, Statistics,

at #common-blog-head: By, on, Filed under:,

at #blog-list-view: edit,

at #comment-view: By, on,

at #comment-form: Leave a comment, (required), Enter value:,

at #no-results-found: No more pages found, Click, here to return to first page,

in Site.Blogit-SkinTemplate-skittish, same as above plus:

at #meta-data-head: written, by:, on,\\

'''NOTICE that I replace "by:" for "by" to avoid clashing with an already existing "by" in my localized XLPage.

To ease up internationalization, ideally a list of all messages should be provided in an XLPage. I know it's a lot of work to maintain, but it makes a big difference to enable translations and when upgrading the recipe. BlogIt uses several templates in addition to the core recipe, so the strings to be translated are scattered over several files/wiki pages. Anyway, this is the list that I came up with, suitable for a localized XLPage. This list assumes the modifications that apply $[text] consistently, as discussed above.

  • Note:* This list covers probably 90% or more of the strings that should be translated. I'm still hunting down a few uncovered areas.

List for XLPage follows:


pre blocks

2-Jun-2009: Problem addressed

The >>pre<< markup and its indented equivalent don't seem to work in a new entry. All text turns out in a single line. To enter preformatted text I have to use a [@ @] multiline block.

1-Jun-2009, DaveG: I haven't looked into this, but it sounds like it might be skin related. Does the same thing happen when using the standard skin?

2-Jun-2009, SteP: It appears to be a PmWiki limitation, unrelated to the skin or your recipe.

local/group.php support

1-Jun-2009: Logged as a bug

SteP: I tried, but failed, configuring the blog in a local/group.php. It seems to me that BlogIt's design relies on being called from Site group pages, so blogit.php has to be included in config.php directly.

Multilanguage support

Issue fixed (1.0.0)

None so far, as far as I can tell. If I get the time, I will experiment with multilanguage recipes and report my findings.

update1: BlogIt doesn't work when Cookbook.ISO8859MakePageNamePatterns is enabled. Try enabling it and creating a blog entry title with an accented character. The wiki page is created with the accent in its filename, but then BlogIt looks for an entry without the accent and can't find it. A supportive behavior would be for BlogIt to strip the accent from the filename it creates. Even better support, IMO, would be for BlogIt to strip the accent from the filename but somewhat retain the accent in the blog entry title.

1-Jun-2009, DaveG: This is probably due to the re-write rules BlogIt applies to page titles.

Date field does not validate correctly

Issue fixed (1.0.0)

Anon?: The date-field on the NewEntry/edit forms does nt work as expected. Whenever the form is opened, the date-format is "dd-mm-yyyy hh:mm", but the field need to be changed to "yyyy-mm-dd hh:mm" for the date to be understood correctly. How can it be fixed to at least have the same format showing up as expected; preferably that would be the former one, but that's not really important.

DaveG: Interesting. That's a bug -- seems to be specific to certain installs. Have you changed any blogit settings in config.php? In the meantime you can change the display and entry date formats by setting $bi_DateDisplayFormat and $bi_DateEntryFormat in config.php. It's a little experimental at the moment, but give it a try :)

Blog title with spaces do not display correctly

Issue fixed (1.0.0)

Anon: Whenever I add a space into the Blog title, the display stops at the space. How can I create Blog-titles containing spaces?

DaveG: Sounds like another bug. I've not seen any problems with spaces in the blog titles -- in fact most blog titles fo have spaces. Just to confirm: By blog title you're referring to the very first field on the blog entry page "Blog Title"? This should allow spaces. They will get 'translated' to hyphens when the pagename is constructed which you'll see in the "Pagename" field under the main text area on the blog entry form.

Repeat site title on blog pages

21-May-2009: Problem addressed

Is there any way to pick up a main title/header that could appear even if I click to a specific post, because when I link to a post, I just lose the (:Title:) that I created for the Blog/Blog page.

21-May-2009, DaveG: Again here you could just add that to the skin template, and again in the #comment-blog-head section. Although in this case, I think you might want to consider putting the title in the actual page header, in which case add it to the skins .tmpl file.

Spaces in blog title

14-Jul-2009: Further info requested

Hello! I'm runnig a website for my architecture firm (, powered by PmWiki since Jan 2006. Meanwhile, I'm still a rookie in PmWiki Software (as in English, like you mostly notice) and what I had done for all these years was scrutinizing the trying to figure out all my needs.

Lately, I've been trying to put something like a blog into my website. After read some features in the CookBook directory, I've opted for BogIt but, after some tests, I'm still surrounded with dumb questions about correct configuration of this cookbook receipt.

(if you have time to take a look, here you have the address: Since this is (yet) a test blog, please, don't look into info itself)

Sorry about all these (seems to me) silly questions but i just don't figure out how to handle with them. Finally, since this is my first intervention on, I wish to take the opportunity to thanks to all you guys that had providing such magnificent job, specially to Patrick R. Michaud, DavidG, Petko and HansB...

1-Jun-2009, Tomita: Concerning the blog title with spaces: In the single-entry-view the title appears ok but when in the multi-entry-view the blog just pick the first word of the title.

14-Jul-2009, DaveG: Closing this issue until we can get further information or the problem recurs.

1-Jun-2009, DaveG: At this point I'm not sure what your configuration is. Could you email me the Site.BlogIt-SkinTemplate-SKINNAME, and your config.php file? I'd like to try your config on a base version of pmwiki.

14-Jul-2009, DaveG: Closing this issue until we can get further information or the problem recurs.

No comment author being displayed

14-Jul-2009: Bug fixed

1-Jun-2009, Tomita: The name of the comment author didn't show on the comments header but just a single "By (empty space), on June...".

1-Jun-2009, DaveG: Is it possible that you used an author name of something like " " (ie, a space)?

14-Jul-2009, DaveG: It's possible there was an issue in the CoreTemplate that has since been fixed. Closing this issue.

Adding comments count/status

1-Jun-2009: Logged as documentation

Tomita 2009-05-21': How can I make available a (comments count/status) in the Post header in Blog/Blog page, because comments, if any, are only shown at the footer of the post page when we link directly to it.

21-May-2009, DaveG: I think what you're wanting to do here is to include a comment count on the header of each post displayed on the Blog/Blog page. If so, you could include the count code within the post, but that would mean doing it on every post. Instead BlogIt provides a skinning layer -- unfortunately this is the least documented area of BlogIt, so what follows is a very quick intro.

Tomita 22-May-2009: Yes, it's something like that but with a link on it (a shortcut to commentaries list and the fill-box to make one), something like on your personal blog (or in any blogger). I've put the “comment line” as you said in the Site.BlogIt-SkinTemplate (my skin is just the default skin with some changes in the pmwiki.css, so, I've just saved the Site.BlogIt-SkinTemplate with that line) but in the Blog/Blog page the header is just added with a comment status with 0 (zero) count. I suppose that this is a “core” problem coming from inability (to be kind to myself).

DaveG: Simply make the line a normal PmWiki link. You might want to download a BlogIt skin, and take a look at its Site.BlogIt-SKINTEMPLATE file for some examples, until I can update the documentation. Here's an example:

[[{$$Group}.{$$Name}#commentblock | (:includesection "#comments-count-pagelist entrygroup='{$$Group}' entryname='{$$Name}' commentstatus=true":) comment(s)]] »

The default skin layout is in a file called Site.BlogIt-CoreTemplate. Look for a section #common-blog-head, which controls the layout of the blog entry summary, specifically the header part.

Generally you don't want to change Site.BlogIt-CoreTemplate though. Instead use the BlogIt skinning layer. It looks like you created a new skin, so create a BlogIt skin file called Site.BlogIt-SkinTemplate-SKINNAME (SKINNAME is the name of your skin), and then create a section in that file that basically duplicates the #common-blog-head from Site.BlogIt-CoreTemplate, but with an additional line to show the comment count:

Comments: (:includesection "#comments-count-pagelist entrygroup='{=$Group}' entryname='{=$Name}' commentstatus=true" :)

So the page should look something like:

!!! #common-blog-head
Parameters: listformat (show header or not), entrydate, entrytags, fullname, entryauthor, showcount
(:if false:)[[#common-blog-head]](:ifend:)
(:if equal "{$$listformat}" "true":)!! [[{$$fullname}|{$$title}]](:ifend:)
(:div9991 class="blogit-meta-data":)\
(:if !equal "{$$entryauthor}" "":)By (:if exists {$bi_AuthorGroup}.{$$entryauthor}:)[[{$bi_AuthorGroup}/{$$entryauthor}]](:else:){$$entryauthor}(:ifend:)(:ifend:)\
(:if !equal "{$$entrydate}" "":)(:if !equal "{$$entryauthor}" "":), on (:ifend:)%blogit-date%{(ftime fmt="{$bi_DateDisplayFormat}" when=@{$$entrydate})}%%(:ifend:) \
(:if !equal "{$$entrytags}" "":) | $[Filed under]: %blogit-tags%(:blogit tags:){$$entrytags}(:blogitend:)%%(:ifend:)  \
(:if auth edit:)%blogit-edit-link%%item accesskey="$[ak_edit]"% | [[{$$fullname}?action=blogitedit | $[(edit)]]]%%(:ifend:)  \
[[{$$Group}.{$$Name}#commentblock | (:includesection "#comments-count-pagelist entrygroup='{$$Group}' entryname='{$$Name}' commentstatus=true":) comment(s)]] »

The line which includesection #comments-count-pagelist near the end is what shows the comment count. The commentstatus is true (to count approved comments) and false (to count unapproved comments).

1-Jun-2009, Tomita: When I add the above line in the #common-blog-head, in the blog appears a "Comment(s)" link to a Group\Name page. I don't realize how to get these variables ({$$Group} and {$$Name}) assume the correct link to Blog/"blog title"#commentblock;

Another thing that I have noticed is that the (:includesection "#comments-count-pagelist entrygroup='{$$Group}' entryname='{$$Name}' commentstatus=true":), shows, in the Blog, a comments count of all the posts instead of a single count for each post.

How to use caching

21-May-2009: Problem addressed

I had created “a work.d at the same level as wiki.d” as you mention in the installation note – but I haven't noticed any activity in such directory. This is maybe because I don't now here to put these lines.

$WorkDir = dirname(__FILE__).'/../work.d';
$PageListCacheDir = $WorkDir .'/';

21-May-2009, DaveG: This goes into config.php

14-Jul-2009: Control panel links don't seem to work

Logged as bug.

The Site Admin > Unapproved Comments: 0 , Drafts, Published, Stickies didn't seem to work for me and just show a blank page with Site/unapproved-comments or Site/blog-grid even when I have drafts or comments to approve (I have to dig to find this drafts or approve the comments directly in the post's link).

21-May-2009, DaveG: Sounds like you might have a problem with the setup in config.php. Can you list the BlogIt specific entries you have. I suspect you might have set $bi_BlogGroups.

Tomita 22-May-2009:The "include_once("$FarmD/cookbook/blogit/blogit.php");" is at the bottom because the site was editable without passwords when it was on the top.

DaveG 22-May-2009: Your config.php looks fine (I removed it from this post) -- you're not changing any blogit settings.

For some reason it looks like the blogid variable is not getting picked up inside the control panel. Take a look a this direct link where I passed in the blogid and things work fine. Have you changed the control-panel? Check that this line is still there (:blogid:{$bi_BlogList_BLOG1}:). Alternately include the blogid in the control-panel include statement:

(:includesection "#control-panel blogid=blog1":)

14-Jul-2009, DaveG: Release 0.2.0 will simplify the way in which the sidebar is incorporated.

Why Should I Use BlogIt? ;-)

14-Jul-2009: Documentation to be updated

RAM? 06-Apr-2009: I found a wiki page where you compare different PmWiki blog cookbooks (BlogSimple2, BalusBlog and XESBlog). I think you would not have written another blog cookbook if one of the others had fitted your needs. So what does BlogIt better than the others and why should I prefer it? I know silly question but still interesting...

14-Jul-2009, DaveG: I'll update the main page with this type of information.

Broken AuthUser+Login

16-Mar-2009: Problem fixed.

DavidS? 16-Mar-2009: Have a reasonably (few hours) fresh install here. Whenever I uncomment blogit in config.php i can no longer authenticate with the site (neither DefaultPasswords from config.php nor AuthUser). I'd gladly let you ssh/screen in and we can have a peek together, but it does seem strange. At one point i even had to go back to a backup because whatever it did, it was permanent and I couldn't get in again.

DaveG 16-Mar-20099: For authentication, make sure you define passwords before including BlogIt. If you define passwords after BlogIt then things get messed up, as BlogIt has to read the page, and can't since no credentials are available.

Zip file compatibility

16-Mar-2009: Fixed

DavidS 16-Mar-2009: Also, there are CR/LF lines on all your .php files... minor stuff but anyway... oneliner to fix it:

tmp="/tmp/bla-$(date +%s)" ; for files in $(find . -type f) ; do (cat "$files" | sed 's/.$//' > "$tmp" ; cat "$tmp" > "$files" ) ; done

and yes, if you're going to make a zip please make it correctly or just use 7z please..

DaveG 16-Mar-20099: As of 0.1.1, the zip files should be fine on Linux systems -- if not please let me know. I was not aware of any issue with CR/LF -- however, I'll try to prevent this in the next version.

Summary doesn't want to work for blog no 2

28-Mar-2009: Problem addressed

linda? 2009-03-11: My first blog seems to work just fine (blogid blog1), but the next one (blogid blog2) won't list the posts even though I think I've done what I'm supposed to do. I've created a page named Blog.Blog which uses the same code for listing posts as News.News (which works). The only difference in the code is the blogid. I have no problem adding or editig posts with this blogid, but they won't list properly. Could you have a look? Regards Linda

DaveG 2009-03-11: I think this might be a problem with groups. Try setting $bi_BlogGroups to include a comma-separated list of the groups you're saving entries in. Something like:


linda 2009-03-28: I set it to this: SDV($bi_BlogGroups, 'News, Linda, Lilith, Blog1');

It now works, thanks.

Convert entries from Pivot

28-Mar-2009: Logged as enhancement

linda 2009-03-28: Is there a way to convert entries from pivot?

DaveG 2009-03-28: BlogIt basically uses PmWiki markup, so the real question is whether there's a way to convert from Pivot to PmWiki. If you can do that then you can use the BlogIt Conversion utility to convert the pages to BlogIt PTV format.

Pivot provides an export mechanism to Moveable Type. However, I couldn't find anything that moves from MT to PmWiki. Depending on your skill level you might be able to adjust the MT export to convert to PmWiki. I suspect if you post to the mailing list, you may get some other ideas. Good luck!

BlogIt-able skins are mostly similar

7-Mar-2009: Documentation clarified

cmstrekker? 2009-03-03: The BlogIt-able skins have more or less the same layouts and waste horizontal space. I need something like Maguila for browser and design techniques, if not layout/looks. See NetstreamsCMS comments for my design interests. I do not want blog look, except for a news page, nor any wiki looks. Will have to roll my own skin, more or less. Would like statements how to make a skin BlogIt-compatible. What's the bare minimum?

DaveG 2009-03-03: BlogIt will work with any skin, no changes needed. However, if you want to change the position of elements of the page that normally appear within the pagetext itself, then you can use the BlogIt skin mechanisms to do that. If you let me know specifically what you want to achieve on Maguilla I might be able to help. Alternately, install something like Blix, and take a look at the file called Site.BlogIt-SkinTemplate-blix, which is what BlogIt uses to determine the layout and styling of the page content. I'll write more detailed descriptions in the future.

cmstrekker 2009-03-04: (sane css typography from Maguila, gut the wiki crud like search and action bars, then a top tab nav, and a footerStickAlt at bottom that won't crawl up as in Maguila)

DaveG 2009-03-04: All of that is normal skin development, unrelated to BlogIt. Take a look at the skinning guidlines -- hopefully that can get you started. Post to the mailing list if you need help changing the skin for what you need.

Most skins make use of directives that let you disable elements of the skin. Refer to the directive part of the guidlines page.

cmstrekker 2009-03-07: Sure, but your skins all advertise full support for BlogIt. If all skins have full support, that bullet should go, or rephrase. Also, skins should use a proper CSS framework, giving features for free. None on PmWiki do?

DaveG 2009-03-07: The listed skins support BlogIt -- that is correct; this means that they have additional templates to control the layout of page level elements: date, author, title, comment-counts, and others. It does not mean that only BlogIt compatible skins work with BlogIt; any skin will work -- you just won't have automatic styling of those page level elements. And you're seeing this in action when you use Maguila, a skin which doesn't have the BlogIt compatibility layer, but works fine with BlogIt.

All the skins make use of css, BlogIt compatible and others, so I'm not sure what your point is there. If you're suggesting that css can be used to move page-level elements around, then to a large extent that is true -- but it then means the page author needs to manually add those elements, and include the css class styling to them. BlogIt provides templates to remove this step for the authors.

cmstrekker 2009-03-07: About CSS, PmWiki has silo syndrome; what I am suggesting is Google: "CSS framework"

ZIP File extract fails in Linux

Problem fixed.

cmstrekker 2009-03-02: On Linux the early March BlogIt .zip file names extract funny, with embedded backslashes in the file names. The files don't go into folders. Test from any Linux live CD; 7-zip is Windows/Linux and better compression, but it handles PKZIP format too.

DaveG 2009-03-02: I don't have a live CD to hand, so I'll check tomorrow. Can you let me know what command/switches you're using?

cmstrekker 2009-03-03: "7z x" or "7z e" from Linux terminal. Same problems with your skin uploads, I found.

DaveG 2009-03-03: Okay, looks like this is a known issue with IZArc, which is what I used, so it affects all my PmWiki cookbooks. I'll re-zip with something else in a few days.

DaveG 2009-03-04: I uploaded a new version 1.1.1, using a different zip tool. Let me know if this one worked okay.

cmstrekker 2009-03-07: (Blix skin, yes; BlogIt package, no.)

How to create a list of the newest log entries?

Question answered.

I understand how to create a full list of all blog-entries: (:includesection "#blog-summary-pagelist status=":) However, how can I create a list of only the last (newest) n entries?

DaveG: Simply add count=8 to the includesection statement or for a global setting set $bi_EntriesPerPage in config.php.

bi_EntriesPerPage = 10; #default is 15

Import/Export from Google Blogger

Logged as an enhancement.

Marte, 22.01.09: What About if I am already using Blogger? are there plans for a import/export mechanism between Pmwiki BlogIt and the blogger service ? If not, any suggestion if I'd like to migrate from blogger to BlogIt cookbook?

DaveG: I think your question isn't so much how to migrate content from Blogger to the BlogIt cookbook, as it is how to migrate content from Blogger to PmWiki. I'm not familiar with Blogger to know if they have an API available -- if they do it should be relatively simple to create an import mechanism. I'll add this to the list of future features.

AuthUser compatibility

Logged as an enhancement.

JL, 19.01.09: Your BlogIt demo site looks very promising. Does BlogIt work nicely with AuthUser, so that only users who are in a specific group can create new blog posts?

DaveG: At the moment anyone with Edit privs can create, and Admin privs can approve/edit comments. So if you restricted blogs to a certain PageGroup, and restricted Edit access to that PageGroup, then that would work. I'll take a look at AuthUser, and see if/how we might need something more sophisticated.

Talk page for the BlogIt recipe (users).

Edit - History - Print - Recent Changes - Search
Page last modified on March 31, 2016, at 10:52 AM