Module: Blog

[Peter Knight]

Cool. Missed that one.

I notice it's still in BETA but I'll give it a shot.

P

[atano]

I did so .. tell me where the mistake?

see screenshot

[kongondo]

Atano,

I can't see your image clearly nor able to download it. I can't read the error messages on the Tags, Categories and Comments visibility. However, the error 'maximum function nesting level of 100 reached' is a well known xdebug issue. Here's how to solve it. That will probably sort out your other issues as well.

Some module developers haven't yet updated their modules' PW version compatibility list. SchedulePages will work just fine in 2.5. Did you try it?

[atano]

• Select one or more categories below and drag to sort them in order of relevance. If you want a category that doesn't already exist, create a new one.

   

  Not fully configured / currently nonfunctional

  Not fully configured / currently nonfunctional

  blog_categories

• Tags

• Not fully configured / currently nonfunctionalNot fully configured / currently nonfunctional

  blog_tags
• Comments visibility

  Comments are visible by default. This setting overrides the global setting.

  Not fully configured / currently nonfunctionalNot fully configured / currently nonfunctional

  blog_comments_view

SchedulePages I installed)) thanks

[kongondo]

OK. Try and solve your error in 5.1 as I showed you above and see if that sorts out the other issues...

[atano]

5.1 error I decided .. now all is well

but error "Not fully configured / currently nonfunctionalo" error persists

[kongondo]

Hmmm...that is strange...Hard to tell what it is since I have just tested the install and it works just fine. I  think these resulted from the first error (5.1) and the installer didn't finish. Can you please use Blog 'Cleanup' to uninstall all the Blog components (leaving only the module) and start again from your step #3? If that doesn't resolve the issue, completely uninstall the module and start afresh. 

Edited November 11, 2014 by kongondo

[atano]

Thank you very much, Kondongo. Everything reinstalled again and it works))) 

[kongondo]

Cool

[kongondo]

Update: Blog is now in version 2.2.2 (merged changes in dev version to master).

See changelog here:

In the coming days, I will update the docs with the changes introduced in this version

[Russell]

Yes, if using PW 2.5

Modules -> New -> Add module from URL-> point to the zip file in Blog dev branch (if you can't wait till this coming week when I merge to Master). PW will upgrade Blog. Nothing will be reinstalled. The code will be updated. As usual, good to test first before deploying to a production environment. Yes, alternatively, you can manually overwrite the old module files with the new ones...You might then want to refresh your modules list for latest module version numbers to show...

Hmm, not necessarily a blog issue, but I did the update last week and it all said it worked fine, but I've only just got around to trying the comments change, and when it didn't work, I looked at the MarkupBlog module and there are no changes in it. Not a drama I can change it manually, but I wonder why it didn't work?

[Russell]

Something else I've just come across. Since I'll be probably posting articles and don't particularly want to swap between an admin login and an author login all the time, I was hoping for some way to change the Author links to use the display name, instead of the username. I'm guessing this would require module changing and not just something I could code myself while still using the MarkupBlog author functions?

[kongondo]

Hmm, not necessarily a blog issue, but I did the update last week and it all said it worked fine, but I've only just got around to trying the comments change, and when it didn't work, I looked at the MarkupBlog module and there are no changes in it. Not a drama I can change it manually, but I wonder why it didn't work?

I don't get this bit. There are changes to renderPosts() right here on line #663 . I added the option 'post_comments'

'post_comments' => 1,//show comments info? 0=off,1=comments count top,2=comments count bottom,3=comments count top & bottom

Are you certain you passed the option to renderPosts()? By default, the comments count is displayed at the top. To not display it, you would need to do something similar to below in your blog-post.php template file and something similar in your blog-posts.php

$options = array('post_comments' => 0);//don't display post comments count
$blog = $modules->get("MarkupBlog");
echo $blog->renderPosts($page,'',$options);

Something else I've just come across. Since I'll be probably posting articles and don't particularly want to swap between an admin login and an author login all the time, I was hoping for some way to change the Author links to use the display name, instead of the username. I'm guessing this would require module changing and not just something I could code myself while still using the MarkupBlog author functions?

By default Blog will try to display the author's full names. If none are found, it will display their user name. To set up the 'display names', you will need to add these to the field labelled 'Display name (first and last name)' [a title field] when editing the user's profile, i.e. Admin > Access > Users

[Russell]

Oh sorry I think I've confused you. The module was not updated by the update process. I ran the "update from url" step, but then when I looked today, the module was still the old one. No drana I just downloaded the .zip again and overwrote with the new module.

As for aurhor name, I have it displaying my name fine, but the problem is the link url still shows the username, not the display name, thereby giving someone withp malicious intent a foot into the backend door.

[kongondo]

As for aurhor name, I have it displaying my name fine, but the problem is the link url still shows the username, not the display name, thereby giving someone withp malicious intent a foot into the backend door.

Hmm, that's an interesting observation Russell. Let me have a think...I see two solutions...

1. Use the $sanitized->pageName() of the author 'display name', e.g. if John Doe, the link will be /authors/john-doe/. The potential problem with this is that in blog-authors.php, we need to get the name (i.e. user name) of the author in order to return their posts. OK, it is still possible to get the user by working it out from their pageName sanitized display name but that is not foolproof. There could be two John Doe's? 

2. Use the user's ID in the link, e.g. /authors/1234/. In a link that's fine but in the URL that's not nice. I'll see if I can use this option but with a 'prettier' URL.

Glad to hear other thoughts! I aim to resolve this quickly.

Edited November 12, 2014 by kongondo

[cstevensjr]

I remember there was a similar issue with the Blog Profile.

https://processwire.com/talk/topic/1394-blog-profile/page-6

I believe that issue dealt with displaying the admin account name when listing the Authors.

I don't know the details of how your Blog module is setup, however the solution presented for the Blog Profile was pretty nice. 

Edited November 12, 2014 by cstevensjr

[kongondo]

Thanks Charles. It is a similar issue but extends a bit further. In the case you linked to, the poster was only concerned about the admin account. In the case here, it is that as well as any other account really.

[kongondo]

Upcoming update: Blog version 2.3.0. (dev)

In relation to the issue about displaying Blog Authors' usernames in their pages URLs/Links, I have updated Blog (dev branch for testing first). If an author's 'display names' (title field in user template) are set, Blog [renderPosts(), postAuthor() and renderAuthors()] will now use and display a $sanitizer->pageName() version of that as URL/Link to that author's posts. E.g., if a Blog author has the display names 'Grace Jones' and a username 'gjones', if using Blog Style 1 or 2, their author URL will be, e.g.:
 
/blog/authors/grace-jones/ rather than the current /blog/authors/gjones/. I have updated the demo files blog-post.php and blog-authors.php to reflect this change (see screenshots below). Inevitably, if you are using these files (or their code), unless you update them to reflect the changes your links will lead to 404s. Apologies for this. However, the benefits of the changes outweigh this inconvenience IMHO. Similarly, if you are using custom code, note that, as stated above, renderPosts(), etc will no longer use an author's username in creating author URL/links. Hence, you will also need to adjust your code (see examples in the above template files if unsure).
 
if a 'display name' is not yet set, there will be no author URL link and a generic 'Author Name' will be displayed as the author's name rather than their username. This should serve as a reminder for the client/developer to make sure a 'display names' is set for each Blog Author.
 
I will soon merge this to Master branch as it is an important update. Please test and let me know if there are any issues, thanks.
 
Screens.
Blog Author without 'display names' set

 
Blog Author with 'display names' set

Edited November 14, 2014 by kongondo

[Russell]

It looks like something went screwy when I tried the update from URL, or somewhere along the line, as I have a second copy of the module installed in a sub-tree of the modules directory, which mirrors my local drive path to the original modules directory. As a result, I think I have some old and some new files in my install location.

So, I just want to manually refresh all the core files without doing a reinstall. Should it be OK to simply delete everything under the blog tree, except the templates directory, which I've customised, and put in a fresh copy of the current dev files/folders?

[kongondo]

@Russell - I don't completely follow. Running the module in a sub-directory doesn't seem like a good idea. Delete the sub-directory one. Then update the one in your /site/modules/ directory. If you can wait a few minutes I will be merging the dev and master branches. This way, you can update as normal. If you can't wait, you can also just copy and paste all the latest module files (minus the template files, of course) and paste this in your /site/modules/ProcessBlog/ directory overwriting the older ones.

Btw, note that PW now saves an older copy of your module directory when you update a module (don't know if this only happens when you update from URL or uploading a file in contrast to updating via PW's modules' directory. So, you might see a folder .ProcessBlog - that is a backup of older files when you update.

Edit

Realised I didn't answer you question about deleting Blog Pages. As I had mentioned in a previous post and now updated README to include this (thanks...)

You should NOT delete the main Blog pages post-install(i.e. anything other than Example Tag, Example Category and Example Post) OR (however remote the chance of this is) CHANGE the IDs of these pages (in the database). In order to allow for flexibility, Blog stores and tracks its main pages using their IDs.

Edited November 19, 2014 by kongondo

[kongondo]

Updated Blog (master/modules directory) to version 2.3.0.

See post #244 above for explanation of changes.

[Peter Knight]

@Kongondo - I had a question about the directory structure and upgrade compatibility.

Can I add my own custom fields to the default blog-post template and will it survive future upgrades?

I need to create a second set of tags called Client Location. These tags will have their own folder into which I'll store those tags (pages). If I add this folder to your blog folder structure, will this survive future upgrades?

[kongondo]

@Peter,

Since an upgrade doesn't reinstall the module, any custom fields or pages you add post-install should survive.

[Russell]

@Russell - I don't completely follow. Running the module in a sub-directory doesn't seem like a good idea.

I agree, and I didn't put it there. I have no idea how it got created. The older version was in the proper location at this local path :-

/Applications/MAMP/htdocs/maryvalecommunity.com/site/modules/Blog

The newer version was in this local path :-

/Applications/MAMP/htdocs/maryvalecommunity.com/site/modules/Blog/Applications/MAMP/htdocs/maryvalecommunity.com/site/modules/Blog

It's fixed now I think - my live site is still bugged so not 100% sure if something else screwy has happened, but I don't know how it happened in the first place.

[kongondo]

That's still a strange path. Blog files should be in /site/modules/ProcessBlog/. E.g. /site/modules/ProcessBlog/ProcessBlog.module. Did you create the 'Blog' folder yourself?

Edited November 19, 2014 by kongondo