• View
• Edit
• History
• Attach
• Print
• Backlinks

« Return to BlogIt

Comments

I have my $ScriptUrl set to “//my.domain.com” (note the absence of an “http:” prefix) [1]. This breaks the alternate-link icons on the sidebar. Here's the solution:

In blogit.php, replace line 714…

	return $pre . str_replace('$$mode$$', ($ajax[0] > '' ? 'bi-ajax-mode ' : ''), $lnk) . $ajax[0] . ' | ' . $txt . ']]' //text link
		. ($ajax[1] > '' ? str_replace('$$mode$$', 'bi-ajax-mode ', $lnk) . $ajax[1] . ' | ' . $FarmPubDirUrl . '/blogit/link.gif]]' : '') //optional second image link
		. $post;

with this:

	$image_link_url = ( preg_match('/^http/', $FarmPubDirUrl) ? '' : ( isset($_SERVER['HTTPS']) ? 'https:' : 'http:' ) ) . $FarmPubDirUrl . '/blogit/link.gif';
	return $pre . str_replace('$$mode$$', ($ajax[0] > '' ? 'bi-ajax-mode ' : ''), $lnk) . $ajax[0] . ' | ' . $txt . ']]' //text link
		. ($ajax[1] > '' ? str_replace('$$mode$$', 'bi-ajax-mode ', $lnk) . $ajax[1] . ' | ' . $image_link_url . ']]' : '') //optional second image link
		. $post;

(Note that this does require your server to be properly configured, else the $_SERVER['HTTPS'] variable may not be set.)

[1] This is so that HTTP or HTTPS is used by requests initiated by a page, automatically, depending on what protocol the page itself was requested with.

Said Achmiz September 12, 2017, at 03:28 PM

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.

Local CSS customization

I am using BlogIt for my professional website. I placed a Blog.Main.css file in the /pmwiki/pub/css/ directory but it seems to be completely ignored. Only the definitions in local.css are taken into account. Do you have any idea why it is so?

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);
  ++$SourceBlockDivNumber;

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: http://wiki.solidgone.org/BlogIt/MySecondTest?action=print

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:

$bi_Hooks['blog']['pre-entry'][]='processBlogsPrePagename';
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:)
(:else:)
<<original sidebar text>>
(:if:)

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?

(: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:)
(:else:)
<<original sidebar text>>
(:if:)

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.

$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 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;
	include_once("$FarmD/cookbook/captcha.php");
        (used this code because I wanted to see it operating on my monitor regardless of my edit
        priviledges.  

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

	$EnableCaptchaImage=1;

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.

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."

   $EnableCaptchaImage=1;
   if (!CondAuth($pagename,'edit')) $EnablePostCaptchaRequired = 1;
   include_once("$FarmD/cookbook/captcha.php");

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.

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 once...by 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.

Edwin

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.

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.

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.

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? linda.ursin@hist.no

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.

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 http://users.isy.liu.se/johanl/yalmip/

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.

Upgrading

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 !

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:)
(:else:)
<<original sidebar text>>
(:if:)

[[#blogit_pmmarkup]](:title Blog Test:)[[#blogit_pmmarkupend]]
(:blogid:blog1:)
(:entrytype:blog:)
(:entrydate:1300732320:)
(:entryauthor:blogedit:)
(:entrytitle:Blog Test:)
(:entrystatus:publish:)
(:entrycomments:open:)
(:entrytags::)
[[#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

$bi_SkinClasses=array('blog-entry-summary'=>'.post-wrap','approved-comment-count
'=>'.comments a','comment'=>'.commentwrap');

$EnableUndefinedTemplateVars=1;

$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
eased.
include_once("$FarmD/cookbook/blogit/blogit.php");

• and this is the first part of my blog entry

[[#blogit_pmmarkup]][[!Teaching]](:title MSc Program in Computer Science:)[[#blogit_pmmarkupend]]
(:blogid:blog1:)
(:entrytype:blog:)
(:entrydate:1302354900:)
(:entryauthor:Claudio Agostinelli:)
(:entrytitle:MSc Program in Computer Science:)
(:entrystatus:publish:)
(:entrycomments:none:)
(:entrytags:Teaching:)
[[#blogit_entrybody]](:if userlang EN:)

!!`MSc Program in Computer Science 

....
(:if userlang IT:)
....
(:if:)[[#blogit_entrybodyend]]

• 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

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:

• chg: Use $FarmPubDirUrl instead of $PubDirUrl.

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 (http://www.songplugging.com/pmwiki.php/Main/Blog).

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.

'''$[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="nobody@acme.com" id="comment-email" tabindex=1:)\\

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:

count={$bi_EntryStart}..{$bi_EntryEnd}

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

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!

!!! #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:)
(:div1end:)
(:include {$SiteGroup}.EditQuickReference:)
[[#blog-form-controlend]]

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.
include_once("$FarmD/cookbook/blogit/blogit.php");

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

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)

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?

include_once("$FarmD/cookbook/galleria/galleria.php");
# Remove galleria Header javascript/css statements:
unset($HTMLHeaderFmt['jquery']);
unset($HTMLHeaderFmt['galleria']);

# Other config statements...

include_once("$FarmD/cookbook/blogit/blogit.php");

# 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.

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?

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...

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.

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.

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...

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...)

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]);

with

    $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.

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

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.

   $CategoryGroup='Category';

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

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?

@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.

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?

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

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

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 http://church.qdk.org/pmwiki/index.php?n=Blog.Main. 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.

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.

(: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:)
(:else:)
non blog sidebar stuff
(:if:)

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

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

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...

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?

!!! #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:)
(:div1end:)
(:include {$SiteGroup}.EditQuickReference:)
[[#blog-form-controlend]]

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.

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
 ...
 Comments

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.

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.

$EnableUndefinedTemplateVars=1;

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.

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

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.

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.

$EnableUndefinedTemplateVars=1;

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

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.
include_once("$FarmD/cookbook/blogit/blogit.php");

$EnableUndefinedTemplateVars=1;

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.

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..

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.

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?

$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 http://users.isy.liu.se/johanl/newyalmip/pmwiki.php?n=Blog.Huh (lastest versions of everything, installed from scratch). Any idea?

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.

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: http://peterkay.name/test/Blog/Blog-Entry-Number-1 Not sure why removing the line in the SaveTags function makes the problem go away.

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:

Site/BlogIt-Admin?action=blogitadmin&s=blog-grid&blogid=blogid=&status=draft

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.

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. http://peterkay.name/test/ ; passwords are the same as the admin password for your example site; will keep it up for a little bit?

{(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.

(: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']);
}

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?

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?

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?

Thanks!

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).

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 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.

(: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.

Update:

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

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;
include_once("$FarmD/cookbook/captcha.php");

## add the blog feature
include_once("$FarmD/cookbook/blogit/blogit.php");     

# Script to obfuscate e-mail address
include_once("$FarmD/cookbook/deobmail.php"); 

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 but...no luck. cheers fabrizio

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;
include_once("$FarmD/cookbook/captcha.php");

# add a blog feature
include_once("$FarmD/cookbook/blogit/blogit.php");     

# Script to obfuscate e-mail address
include_once("$FarmD/cookbook/deobmail.php");

the blog is on line here: http://soenglish.freehostia.com/

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 http://control.ee.ethz.ch/~joloef/wiki/pmwiki.php?n=Main.HomePage

$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: kabren@gmail.com. Thanks!

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;
include_once("$FarmD/cookbook/captcha.php");

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.

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?

Correct.

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:)
becomes
  !!! [[{(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=...:) 

to

(: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

BlogIt-Admin?action=blogitadmin&s=unapproved-comments&blogid=blog1

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.

SEO

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:

  $EnableFixedUrlRedirect=0;
  $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.

Internationalization

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...]]'); 

write

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:

<<SNIPPED>>

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

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)

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 (zapgun.pt), 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 pmwiki.org 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: http://zapgun.pt/wiki/index.php/Blog/Blog. 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 pmwik.org, 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)]] »
(:div9991end:)
[[#common-blog-headend]]

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 .'/';
$EnablePageIndex=1;
$MaxIncludes=500;

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? http://heksebua.com/pmwiki/pmwiki.php?n=Blog.Blog 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:

$bi_BlogGroups='News,Linda,Blog1';

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; distrowatch.com. 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 blogit.zip" or "7z e blogit.zip" 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.