Support/Comments for PubKitBlog (pkBlog) 1.4.2-beta

928 Posts

kp52 Reply #11, 16 years, 10 months ago

The } else { part of it was for the config file, not the inc file - sorry if that was unclear.

So in line the relevant line of the inc file (for a non-friendly URLs site) we want:

$landing .= '&template=preview&docid=' . $doc->Get('id');

and in the config file (in the Ditto set) we replace

  $documents = $_REQUEST['id'];

with

  $documents = $_REQUEST['docid'];

to match the parameters new name.
I’ll be working on a site using code derived from pkBlog today, so I’ll be testing this out and will update if necessary. It needs refining anyway to test whether the MODx config is set for freindly URLs or not and set the query string accordingly.

KP

57 Posts

annii Reply #12, 16 years, 10 months ago

Hi thanks, I knew this was my error....
But, for some reason I’m still not getting the preview
my ditto/blog.config now looks like this:

<?php
if ($_REQUEST['template'] !== 'preview') {
    if (empty($_REQUEST['tags'])) {
        $display = '3' ;
    }
  $tpl = 'blog.first.tpl' ;
  $extenders = array('summary') ;
  $tagData = 'pwTags' ;
  $tagDelimiter = ',' ;
  $tagDisplayDelimiter = ', ' ;
  $orderBy = array('parsed'=>array(), 'custom'=>array(), 'unparsed'=>'pkDate DESC, menuindex DESC');
} else {
//  $documents = $_REQUEST['id'];
 $documents = $_REQUEST['docid'];
  $showPublishedOnly = 0;
  $display = '1' ;
  $tpl = 'blog.preview.tpl' ;
  $extenders = array('summary') ;
  $tagData = 'pwTags' ;
  $tagDelimiter = ',' ;
  $tagDisplayDelimiter = ', ' ;
}
?>

The relevant lines in pubKitBlog.inc look like this

  	if (isset($fields['preview'])) {
//  		$landing .= '?template=preview&id=' . $doc->Get('id');
$landing .= '&template=preview&docid=' . $doc->Get('id');
	} else {

   		$landing .= (!empty($docId)) ? '#' . $prefix . $docId: '';
	}

    $modx->sendRedirect($landing);
}

The url looks like this
index.php?id=2&template=preview&docid=53
and I just get taken to the main blog in both firefox and ie7...
I know I know nothing about php code, but I keep thinking back to the info I read on the Pogwatch site which said

The blog.first.tpl template chunk is used for the listing unless the query string "?template=preview" is appended to the URL. If the query string does include "?template=preview" (set up by clicking the Preview button in the main Create Post form), only the document specified by the ID which is also in the query string is displayed, and the blog.preview.tpl template chunk is used

and which referred to blog.config.php
Is the ? important in pulling blog.preview.tpl?
Anyway, I’ll let you get on with your own test, as I may well be adding to the confusion by coming up with my unsubstantiated theories.... rolleyes

Thanks

Anni

928 Posts

kp52 Reply #13, 16 years, 10 months ago

It looks as if my enthusiasm for xhtml URLs was over the top. I’ve experimented with switching friendly URLs off (this also meant I had to put an ID rather than a page alias into the action attribute of my preview form), and found the following works in the inc file:

  	if (isset($fields['preview'])) {
		$landing .= ($modx->config['friendly_urls'] == 1) ? '?' : '&';
  		$landing .= 'template=preview&docid=' . $doc->Get('id');
	} else {
   		$landing .= (!empty($docId)) ? '#' . $prefix . $docId : '';
	}

As before, the relevant part of the config file looks like this:

if ($_REQUEST['template'] !== 'preview') {
  $tpl = 'newsItem.tpl';
} else {
  $documents = $_REQUEST['docid'];
  $showPublishedOnly = 0;
  $tpl = 'news.preview.tpl';
}

I’m not sure what’s going on with the ampersands. When I have friendly URLs on, they seem to come out like /news.html?template=preview&docid=35 regardless of whether I use ’&’ or ’&’, and, more curious, regardless of the setting in Tools > Configuration for "XHTML URLs".

If friendly URLs are off, the URL always comes out with & if that’s what is in $landing, again regardless of the configuration setting. So let’s leave it to MODx to keep XHTML happy on this point, and put a plain old ampersand in $landing.

The issue of using question mark or ampersand has nothing to do with PHP, the URL has to conform to the standard way of providing data to any kind of program that resides at the relevant address. See Wikipedia for more information. (I’m pretty sure every mental asylum has at least one person huh

sitting in a corner muttering to themself about ampersands.)

KP

57 Posts

annii Reply #14, 16 years, 10 months ago

Thanks, yes that fixed it

I won’t pretend to understand why the snippet needed changing, just very grateful that it’s now working

Anni

☆ A M B ☆
24,524 Posts

sottwell Reply #15, 16 years, 6 months ago

I just spent three hours beating my head against the wall, trying to figure out why why why every time I edited a document, it was adding another set of p tags before and after the content!

Turns out that because the input type of the pkRichContent TV was ’Rich Text’, and because its default content is just the [+newsBody+] placeholder tags, TinyMCE was adding p tags (forced_root_block). When the actual newsBody content was loaded into the Rich Text ouptut widget, since the content had p tags, it was getting doubled opening and closing p tags. TinyMCE was cleaning that up by turning the first and last tags into complete sets.

Now, this could be avoided by reconfiguring TinyMCE to not do the forced_root_block thing, but a better solution is to change the input type of the pkRichContent TV to just Text. It doesn’t need a rich text input type, just the rich text output widget. Problem solved.

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

5 Posts

flipmoe Reply #16, 16 years, 5 months ago

Hopefully this is an easy resolution for something stupid I’ve done on my side. I’m running ModX version 1.0.3 and plBlog v1.4.2. I’ve installed everything correctly and it’s working properly, except of course for restricting access.

The blog entry page works correctly when it’s publicly available, however whenever I restrict access to a group of users I receive the error "Too many forwarding attempts". I’ve made sure that my admin user is part of the security group for the web editor group I created.

Is there a simple setting that I’ve missed somewhere?

Thanks in advance

928 Posts

kp52 Reply #17, 16 years, 5 months ago

Do you have error pages set up for 404 Not Found and 403 Access Denied? This problem can be connected with failed attempts to find them, and it may be down to having set access restrictions. See thread at http://modxcms.com/forums/index.php/topic,15330.0.html.

You can create a simple page for each error and link to them by ID in Tools > Configuration > Site tab (Error page and Unauthorized page).

KP

5 Posts

flipmoe Reply #18, 16 years, 5 months ago

Thanks for the help! I solved the problem I hadn’t setup the weblogin structure correctly.

Hoping you can help with one last challenge. Is there a way to have the web-publishing section also support the other tv fields that are available in the standard modx manager page. Specifically, I’m looking to post to the [+description+] and [+link_attributes+] fields (and call data from these fields).

Do these tv’s have to be hard-coded into the pkBlog snippet?

Thanks!

928 Posts

kp52 Reply #19, 16 years, 5 months ago

Yes, it would involve adding to the code in the main included file. I’ll try it out in pkBlog if I can find the time, meanwhile the untested idea is set out below. It’s only suitable for plain text fields, and could do with some enhanced data checking on the way in:

1) add a list of the other document fields as an array variable around line 75 (where the TVs are listed in similar fashion)

$extraFields = array('description','link_attributes');

2) Add a loop to the create/update document code around line 178 (add DB escaping and HTML safety features to taste)

foreach ($extraFields as $extra) {
	$doc->Set($extra, $fields[$extra]);
}

3) Add a loop to pick up the values when the item is recalled for editing around line 260

foreach ($extraFields as $extra) {
	$modx->setPlaceholder($extra, $doc->Get($extra));
}

4) Add the relevant fields to your form, using the standard identifiers as the name attribute for each input tag, and as the name of the placeholders in the value attributes. Then they should be available in the $fields array after the form is submitted.

It would be nice to build this sort of choice in, and make a document field list into a parameter for the snippet call. I’ll not be doing this in pkBlog, as I’ve been working on the more general-purpose PubKit, which I really do hope to publish this week, but I’ll see what might be achieved in PubKit.
laugh

KP

5 Posts

flipmoe Reply #20, 16 years, 5 months ago

Hey, that worked beautifully!! Thank you very much, pkBlog is now doing everything that I needed!

Thank you again!