Recent Changes - Search:

Cookbook

PmWiki

pmwiki.org

« Return to BlogIt

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

Table of Contents

Comments

The user comments, and sample sites below are included on the BlogIt Users page, which you can edit to leave your own comments or sites. If you have larger questions or suggestions, edit this page and leave them in the Open Questions section below.

Example Sites

Edit the BlogIt Users page to add your site. Please add your publicly visible galleries in this section.

User Comments

Edit the BlogIt Users page to add your support. You can edit this page and add your name.

  • (+) June 01, 2009 SteP: I like your blog recipe, thank you.
  • (+) Anon?: Thanks for a nice package! I am starting to use BlogIt for an "interactive" News section on my website.
  • (+) Luigi: I'm still testing it. The most interesting feature is (to me) comments handling. Impressive :-)

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
  • Please enter new questions at the top of the list. If you have many questions separate each one under a different heading.
  • If you feel that your question has been answered, please move it to the closed questions section below.

Restrict comment to authenticated users?

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

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

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

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

And in config.php, something like this: 

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

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

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

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

How to approve links in comments?

16-July-2009: Logged as an enhancement

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

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

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

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

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

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

local/group.php support

1-Jun-2009: Logged as a bug

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

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.

Date gets changed on New Entries

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

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

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

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

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

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

Delete a post

Status: Added to 1.4.0

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

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

Entries don't display

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

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

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

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

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

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

Issue with posting: author name required whereas field populated

Status: Bug fixed 1.3.2

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

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

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

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

Delete a Comment after it has been approved

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

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

$AuthUser['htpasswd'] = 'wiki.d/htpasswd'; $AuthUser['htgroup'] = 'wiki.d/htgroup'; //defines the editors group $DefaultPasswords['edit'] = array('id:*');

//some stuff here...

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

	'blogs'=>array('comment-edit','blog-edit', 'blog-new', 'sidebar','blogit-admin'),
	'comments'=>array('comment-approve', 'sidebar','blogit-admin')

);

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

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

Body displayed twice

Status: Issue resolved

johan? February 13, 2010: The body of blog items are displayed twice on my setup http://users.isy.liu.se/johanl/newyalmip/pmwiki.php?n=Blog.Huh(approve links) (lastest versions of everything, installed from scratch). Any idea?

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

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

Unstyling entries in the sidebar

Status: Closed

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

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

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

Status: Resolved in 1.2.2

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

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

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

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

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

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

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

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

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

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

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

blogid in sidebar problem in default installation.

Status: Resolved

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

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

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.

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

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

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

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

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

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

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

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

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

UPDATE2: Some notes from a quick poke around.

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

How to stop comments from showing up in AllRecentChanges?

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

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

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

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

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

That makes a lot of sense. Thanks again!

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

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

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

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

CleanUrls problem

Status: Resolved in 1.2.0

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

  ?invalid page name

  We are sorry for any inconvenience.

  Return to http://mysite

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

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

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

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

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.

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' etc., splatted

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

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

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

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

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

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

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

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

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

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

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

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

Also, try this.

  1. Include blogit as normal.
  2. On a non-blogit entry page -- so just a normal pmwiki page -- use the markup that seems to be causing problems, for example:

(:blogit-skin date fmt='long':)4324244(:blogit-skinend:)

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

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

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

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

Comments don't work with PerGroupSubDirectories

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

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

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

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.

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.

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

Issue resolved.

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

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

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

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

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

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

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

Issue fixed (1.0.0)

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

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

thanks a lot for your help

DaveG, 6-Sep-2009:

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

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

This is what my config.php file right now: 

# include the Captcha feature                      
if (!CondAuth($pagename,'edit')) $EnablePostCaptchaRequired = 1;
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

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

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

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

# include the Captcha feature                      
$EnablePostCaptchaRequired = 1;
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

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

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

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

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

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

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

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

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

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

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

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

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

Issue closed

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

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

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

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

Issue fixed (1.0.0)

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

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

Captcha troubles

17-Jul-2009: Issue resolved.

SteP July 13, 2009: How is the captcha feature supposed to work overall? I mean I was able to enable a captcha for the the #comments-form, but now that captcha is enabled pmWiki wants me to enter a valid code in #blog-form too. Is this how it works for you? As a workaround I changed the #blog-form template to add captcha input
(:div style="overflow:auto;width:75%;margin:10px 20px 10px 40px; padding:4px; background-color:#f8f8f8":) 

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

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

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

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

Correct.

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

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

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

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

Fixed title in #unapproved-comments page

16-Jul-2009: Problem addressed

SteP July 14, 2009: Here the title of each unapproved comments in Site.BlogIt-Admin always was "#unapproved-comments" instead of the blog entry title. I changed Site.BlogIt-CoreTemplate slightly to fix this issue:
(:div style="overflow:auto;width:75%;margin:10px 20px 10px 40px; padding:4px; background-color:#f8f8f8":) 

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.

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.

Multilanguage support

Issue fixed (1.0.0)

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

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

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

Date field does not validate correctly

Issue fixed (1.0.0)

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

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

Blog title with spaces do not display correctly

Issue fixed (1.0.0)

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

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

Repeat site title on blog pages

21-May-2009: Problem addressed

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

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

Spaces in blog title

14-Jul-2009: Further info requested

Hello! I'm runnig a website for my architecture firm (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.

Talk page for the BlogIt recipe (users).

Edit - History - Print - Recent Changes - Search
Page last modified on March 14, 2010, at 10:14 PM