pkBlog - a simple MODx blog v.1.4.2 (12 Oct 09)

@annii: the date should be a long (a unix timestamp), as long as you are using the unixtime widget in your pkDate TV. It would be worth checking what the output from the date TV is, by putting it into a test document (or temporarily into your template), maybe as an HTML comment, and seeing what comes out in the source code: Together with your previous problem of seeing 1 Jan 70 (indicating an empty string or a zero), it looks as if the output from your date TV may not always be a timestamp.

@rx2: I aim to put it in the repository, I know the thirst is there for a better blogging tool, but first I’d like to be sure that at least one person has successfully installed it from the zip package in here! That may also mean I leave it aside for a few days then try to install it from cold myself, to make sure none of the little twiddly bits fall off when I follow my own instructions.
KP

The date TV uses the same date picker as the document editing form. The save_content processor converts it to a UNIX timestamp before saving it. The TV date picker does not; so it gets saved as the date string. If you need it to produce a UNIX timestamp, make sure to use the Unixtime output widget.

Quote from: kp52 at Sep 03, 2009, 12:12 PM

@annii: the date should be a long (a unix timestamp), as long as you are using the unixtime widget in your pkDate TV.

Yes I am definately, just double double checked.
Quote from: kp52 at Sep 03, 2009, 12:12 PM

It would be worth checking what the output from the date TV is, by putting it into a test document (or temporarily into your template), maybe as an HTML comment, and seeing what comes out in the source code:

<!-- [*pkDate*] -->

Together with your previous problem of seeing 1 Jan 70 (indicating an empty string or a zero), it looks as if the output from your date TV may not always be a timestamp.

Okay did this, with two different results:
My blogposts template shows the date fine (as it always did)
But,
When I it on my Main Blog Page template ( I use a different layout on this page )
I get an empty string ie instead of
I get


So it must be something different in my main blog template...

Here is a section from my Blog Posts Template

And here is a section from my main blog template


The only difference I see is my weird workaround of

Hey ho...I will try a clean install on a new server by Saturday and let you know..

Anni

Ummmm... but there shouldn’t be any PostTags snippet call in your main blog page (or its template)... The date and tags on each post listed on the blog page are produced by the blog.first.tpl chunk (below), which is specified in the ditto/configs/blog.config.php file As long as pkDate is delivered as a timestamp, the PHx files that are included in Ditto will do the necessary transformation.
KP

[SOLVED]
Sorry for confusing you... forget the names of the templates, I was just trying to show the difference between using dateifSet and not using it for the original dates issue.

Anyway one thing that may have skewed the results of my previous post was my weblogin status during the tests! It would now seem that your new v1.1.1b fix works as long as I am logged out.

So I’ve tested a few more things and through process of elimination, have found....

Using the old posttags snippet works fine whether a user is logged in or out. I have the weblogin homeid set as the edit post page.

When I update to the new post tags snippet it works fine until I login, then I get the parse error mentioned previously.
If I immediately swap back to the old post tags snippet, it works fine again..

Does this shed any light? Maybe I need to change something in my weblogin setup?

Anni

EDITED Sunday 6th Sept:
Okay, found the cause of this too and fixed it. KP52 kinda told me in his last post and I just didn’t see it...
When I had created my admin page templates I had duplicated and then edited the template I created for the blog posts and my editing was not thorough enough! I had left in
which was the cause of my parse error on login!!

Anni

Hi again
As promised I’ve just done a completely clean install of this on another server using the latest upload.
And, it works fine... The only problem I have (if it can be called a problem) is that any documents that were pre-existing in the blog container prior to installation show that date of Jan 1 1970.

Other than that, everything is GREAT.
So it would seem that my first attempts got a bit confused with changes, additions, errors etc making it a bit hard to see the wood for the trees !!

Anyway, this time I followed the documentation without assumption and it worked fine from the get go.

The only thing I noticed in the documentation is that you mention that pwTags is now pkTags, and yet all the example docs refer to pwTags etc...

Thanks so much for this long needed frontend manager!!

Anni,

I’m very glad things worked out with a clean install - something I have to try for myself as well (I’m quite capable of misunderstanding my own instructions given any ambiguity!).

Have you tried re-editing your old posts with misbehaving dates via the posts management screen?

I’ve just done a search for pwTags in the whole set apart from the PDF document, and as far as I can see the only place where there might be confusion is in the listing of the template variables. That document does say, though, that these are the TVs as used on my site. The installation document says

For tags (as of v1.1.1) you can use any checkbox or radio-button TV, and name it in the snippet call using the &tags parameter. Default TV is now pkTags (replacing pwTags)

Did you have somewhere specific in mind? I’d agree that the installation document could make it clear that you need to customize the tpl chunks and config files to use your own TV names.
KP

Hi
Re the dates on pre-existing documents: yes they can be changed successfully from the manage posts screen.
The references to pwtags in all the example docs isn’t a problem and is as you say explained. I just think that it’s a bit potentially confusing because it is just one character different from the default of pktags, if the documentation examples had for instance, mytags, I think it would be more immediately obvious that its your own choice..

Anni

Original post has now been updated with files for pkBlog 1.2. I’ve beefed up the instructions, and incorporated the key documents, parameters and TV definitions into the installation document. Some new parameters make the snippet more flexible, a few bugs have been fixed, and the code has been tidied here and there.

I’ve submitted this version to the Extras repository (my first submission - how nerve-wracking).

Updated parameters
&tagFormat - class for SPAN around set of tag options (was previously hard coded).
&cacheItem (default 1), set to zero for non-cacheable page. Mainly to cope with PHx - Ditto clash. Variable that used to determine this has been abolished.
$postid (where to go after publishing) can be single doc ID as before, or array of tag=>ID pairs. This allows for sites that use tags to categorize, e.g. news subsections, so tags can relate to different pages.

Bugs, corrections
- default &postid to newly created document (not &folder)
- Publish command from preview now clears preview flag (or sets published flag - whichever was wrong)
- Publish now sets published field conditional on pub_date, pkDateTo

Simplifications
- abolished config.bloglist.php - params are now set directly in Manage Posts document’s snippet call
- bloglist.manage.tpl and blog.preview.tpl chunks now use alias rather than doc id to set Add/Edit Post page as form action attributes, making it /admin/post-edit (on my site). Easier to maintain than keeping track of doc IDs.
- removed some redundant styles from forms.css, added ".clearer" class used in blog post template sample.

Outstanding issues
- need to review rich text / plain text options for the Intro and Content. I don’t think it’s possible at the moment to make the Intro a rich-text field, because it does HTML entities on saving.
- need to start thinking about how to internationalize the snippet.

pkEvents is coming along nicely, I must soon choose whether to put it out as a standalone snippet, or merge with pkBlog and make it the first version of PubKit. Decisions, decisions!
KP

Keith,

Congrats m8! Well done!

Can we vote on the pkEvents as a standalone or merged with pkBlog issue? My vote goes to standalone. I think that will make it more modular. I may want just the Events capabilities without the full blog capabilities.

cheers! k