kongondo

Thanks! I think there are a few remaining strings that need to be made translatable as well like the 'No' and 'Yes' for published posts. I'll get to them later.

Yes; this is now (or soon will be) resolved in the core https://github.com/ryancramerdesign/ProcessWire/issues/432 Not sure if it has been committed yet...

Update: Blog version 1.2 Read below before updating. For new installs, proceed as normal ------------------------------------- Changelog TL:DR: Comments visibility settings + Posts' Bulk Actions + Update Script Comments Comments visibility can be controlled 'globally' as well as on a 'per post' basis Default is that comments and comment form are visible. You do not need to specify this setting; it just applies A post's comments SPECIFIED visibility overrides the global setting except for one case (see below). Post Comments Settings are set via a page select on a Post's page (also in 'Settings' tab in Blog Dashboard - see below) No selection: Default [comments and comments form will be shown] Always Show Comments: This will enforce overriding of global setting (e.g. Disable Comments) Disable New Comments: Will show old comments but not the comments form; visitors will not be able to submit new comments & message 'Comments closed for this post' will be shown. Disable Comments: Will neither show old comments nor the comments form; visitors will not be able to submit new comments & will see message 'Comments not allowed for this post'. Old comments WILL NOT be deleted . Global Comments Settings are set via a page select on the Comments page (in Dashboard as well). Settings here DO NOT override a Post's Comments settings WHERE A SELECTION has been made (i.e. if NOT empty). No selection: Default [comments and comments form will be shown] Disable New Comments: Similar to above Post setting except will affect all Posts' comments where no comments visibility selection has been made. Disable Comments: Similar to above Post setting except will affect all Posts' comments where no comments visibility selection has been made. Global Maximum comments allowed per post. If any number > 0 is specified in this new setting, IRRESPECTIVE of a Post's comments settings, if a post's comments is greater than the maximum set here, then 'Disable New Comments' will kick in. So, this takes precedence. Note: If you are logged in as superuser, even PENDING and SPAM comments are counted; so, the Global Maximum may be 'temporarily reached', if that makes sense Recap of comments visibility, in order of descending priority: 1. Global Maximum comments allowed for posts (/blog/comments/) 2. Any comment visibility SPECIFIED on a post (i.e. not empty) (/blog/posts/your-post/) 3. Any Global comment visibility SPECIFIED on comments page (/blog/comments/) 4. Default. 'Settings' Tab You can also set both the Global comments visibility and the Global Maximum comments allowed per post on this tab. The current setting will always be selected in the input field. Note: A blank Global comments visibility means no setting specified . So, if you want to change to 'no global setting specified', just select a blank and save [equivalent to deselecting a page select] (hope this makes sense). Note: Where no Global Maximum comments is set (i.e. blank), saving in the 'Settings' Tab's General Settings will subsequently show a '0' [zero]. This is equivalent to a blank, so not to worry Bulk Actions Introducing Bulk Actions for the Posts Tab! Make bulk changes to posts: Unpublish/Publish Comments visibility (as specified above for Posts' Comments visibility). In this case, also a 'Default Comments View' selection available. This is the equivalent of the 'no selection' specified in page selection field above. Trash Delete (note: no warning given before delete; careful with this one!) New column in Posts' Table also shows currently specified Comments visibility for each post. 'Default' means no selection made. Other - Some code clean-up. - See blog-side-bar.inc issue below. UPDATING I have written an update script (attached) that will add the new features in Blog 1.2 (2 fields, 1 template, 3 pages, 2 page updates, etc.). I have thoroughly tested the script. However, try this first on a test/non-essential install! If everything works, you can use it on your live environment Note: This assumes you haven't changed the native Blog paths and page names. Otherwise, it won't work properly. It won't corrupt any data but may just not install some stuff Note: You will still need to update the module as normal in your PW admin! Above is just to save you manually creating the extra fields, etc. To update: # Copy and paste the contents of blog-upgrade-version1-2.txt at the very top of one of your template files. Save the template file. # The script will only run if you are logged in as a superuser so other users won't know what's happening. # View a page using the template file you've just amended. The new fields, template and pages will be created. # Reverse the changes to your template file and save. # Update Blog via PW Admin as usual (to version 1.2) # Copy blog.css to /site/templates/css/. blog-upgrade-version1-2.txt If you are using the blog-side-bar.inc you might want to make/note the following changes. This only affects existing Blog installs! (not new ones) There was a missing <br> tag + $item->date instead of $item->blog_date. This will ensure Recent Comments widget also show the Post's date. If you are using the code from this file, you can make the following changes: OLD: $date = $blogOut->formatDate($item->date); $out .= "<li><span class='date'>$date</span> <a href='{$item->url}'>{$item->title}</a></li>"; NEW: $date = $blogOut->formatDate($item->blog_date); $out .= "<li><span class='date'>" . $date. "</span><br> <a href='{$item->url}'>{$item->title}</a></li>"; In addition, the code has now been changed not to show 'recent posts widget' on the blog home page. @Adrian idea, thanks! Screens Happy blogging!

Hi FuturShoc. Glad you like the module. I thought about this a lot, even with the /site/blog/.... URL, where others would prefer /site/my-awesome-post/...but decided to leave it to the user (for now at least...), if they so wish, to manipulate the URL segments... UPDATE: Feature now available in Blog version 2

Yep, what Martijn said or read here from the Reiska himself https://processwire.com/talk/topic/163-images-and-thumbnails/?p=1160

Good catch Antti!

Try $image->of(true); just before resizing...

Had an oops moment in my post #47 above; edited it (sort of a note to self; feel free to ignore )

Exactly. so, the logic, in order of ascending precedence (i.e. 3 > 1, etc.) could probably go like this: 1. Comments are ON by default. 2. On each 'post' page (/blog/posts/my-post/), will include a checkbox: 'check to disable comments for this post'. This will ignore #1 3. On some settings page or on the 'posts' page (/blog/posts/) have a checkbox or similar that says: 'disable comments on all posts'. Ignore #1 & #2 So, #3 is 'greatest' and will ignore #1 and #2 but will NOT change their settings; checked boxes (#2) will remain checked and unchecked ones (#1) will remain unchecked but their 'directions' will be superseded by #3 . ################################# EDIT ################################# Oops warped thinking on precedence above!!! It should be the other way round! See edits below.. So, the logic, in order of ascending precedence (i.e. 3 > 1, etc.) could probably go like this: 1. Comments are enabled by default everywhere. 2. On the 'comments' page (/blog/comments/) have a select that says: 'disable comments on all posts/disable new comments on all posts'. Ignore #1 but respect individual post's settings (#3) 3. On each 'post' page (/blog/posts/my-post/), will include a select: 'disable comments on this post/disable new comments on this post/always enable comments on this post'. This will ignore #1 & 2. This is like a get() in ProcessWire: it is explicit and ignores 'hidden' status. So, #3 (individual post setting) is 'greatest' and will ignore #1 and #2. ################################# END EDIT ################################# Btw, you will notice very soon that there's very little 'do this the PW way' - in many cases, there is no PW way The system is so versatile yet powerful you will be amazed...

Comments on/off? Been thinking about a new feature. Ability to turn on/off comments both on a per post basis and on a Blog-wide basis. So, if a post has comments turned off, the user gets the usual 'Comments not allowed for this post' or something similar. Additionally, maybe also a feature to turn-off submitting of new comments on a post when approved comments hit a certain number, say '100'. What do you guys think? Need to think a bit more about how best to implement this...

OK, I'll wait for a pull request from you ..... I'll have a think...but I'll work on the auto-publish-date feature first... Edit: Show me an example post please, thanks.

Update: Blog version 1.1 Read below before updating. For new installs, proceed as normal ------------------------------------- Changelog 1. Added new widget 'Post Author' - @adrian idea, thanks. - This widget allows you to add a post's author's biography with each post. You can add it before or after a post (or wherever you wish). See example in updated 'blog-post.php' example: $blog = $modules->get('MarkupBlog'); echo $blog->postAuthor(); - The widget can be enabled/disabled in the 'Settings' Tab of ProcessBlog. It is enabled by default - Updated the CSS to style the widget Screen 2. Made 'posts truncate length' configurable - @looeee idea, thanks. - This is for when you want to render a 'post summary' - e.g. as seen on /blog/posts/. - Was previously hard-coded to 450. Default is now 450 where no value is specified - Can be configured either on the page /blog/posts/ or 'Settings' Tab of ProcessBlog UPGRADING As I have said previously and repeat here (just in case you missed it ) a module of this kind must not be altering your data if you've already installed it or where there are potential conflicts. Therefore, to upgrade, some manual input is required. Once we hit a lock-down on new features, then this requirement will fizzle out... A. Author Widget 1. This comes with a new template without a template file. - Create a template called 'blog-widget-basic' - Give it a tag 'blog' and a label 'Blog Widget: Basic' //just for consistency with other blog templates - Add the field 'blog_summary' save. Then within the template (i.e. click on the upward arrow of the field), change the description to 'Widget Description' in the modal that opens up. Save... - Still on the edit template view, under the 'Family' tab, specify 'No' under 'May pages using this template have children?' and 'Yes' to 'Can this template be used for new pages?' Save... - Copy over the updated blog.css to /site/templates/css/ (this assumes you haven't made any custom changes to this file!!!) 2. Post Author page - Under /blog/widgets/ create a new page called 'Post Author' and assign it the the above template ('blog-widget-basic') - In the 'Widget Description' field enter a description, e.g. 'Renders Post's author biography.' Save... The Author Widget should then automatically appear under 'Settings' in the Widgets section in ProcessBlog B. Post Excerpt Length 1. Add Field to Template - In the template 'blog-posts', add the field 'blog_quantity'. Save. Change the field's description to 'Posts truncate length'. Save C. Update Blog to version 1.1 In PW, now update the module to version 1.1. This will copy over the new module files (ProcessBlog.module and MarkupBlog.module) and their related files. Note: installer will not run again! So, don't worry All done; now go write a post about how cool ProcessWire is

Yeah, something to think about for the future...

Missing an =? ($page->use_wysiwyg==0)

Great. Thanks! Thinking about it more clearly now, I will still need an autoload module to use these with? This is for post pages that will be edited in the normal way using the Page Tree. I appreciate any pointers, thanks! Hooks are still a mystery to me

Hi Ryan, Will you be getting round to this any time soon? I currently would like this functionality for this issue in 'Blog'...otherwise I would have to possibly create an autoload module as shown here. Thanks.

Sorry @zlojkashtan, just seen I didn't reply to this. I didn't take this further; I only tested quickly using the code I show in my post above. Maybe what you need can be achieved in a different way? See the post before this one...or tell us exactly what your needs are.

$p = $this->modules->get('ProcessPageList'); $p->set('id',1234); // the parent page return $p->execute(); Is that what you meant? I have a feeling I am wrong!

Not sure I follow...you can already do this...you can call the page tree in your module and define what the root page of the tree is ...Page Tree is after all a module itself

Seriously? If yes, out of the box, no. But with some trickery, you can have MarkupBlog output posts from only a particular author, assuming each author has their own blog. I am just thinking out loud here. If this is a feature request, I'd like to have more details but also hear what others think Glad you like the module.

Apologies. version 1.0.0 of module was installed at /site/templates/Blog/ ...that should be /site/templates/ProcessBlog/ If updating the module within the PW Admin, this will write to this latter path... You will need to manually remove the former folder

Updated to version 1.0.1 Several strings made translatable as per mr-fan's pull request (thanks!)

Yes...the same holds true...On an update, none of your fields, templates, template files, pages or role will be overwritten. In fact, none of these will be installed whether they exist or not. An update does not re-rerun the installer.

Well, seems like you already got an answer at SO. I must admit though, your question here was rather vague in comparison to the details you offered across the pond

mr-fan First, welcome to PW and the forums! Happy to hear Blog is of some use to you. Thank you for your suggestions Translatable Strings Apologies for my oversight! Thanks for the pull request. I'll have a look and update. Publish from/until feature See my response to @Adrian above. I'll have to think a bit more about this although it is a good idea I think. I just have to think about how to best implement it. Archive - linked to row below with list of month's posts Not sure about this one. The Posts tab already shows the lists of posts sorted by date Meta tags, etc. Not sure I follow what you mean? Tags vs buzzwords I don't think buzzwords will work noindex, nofollow The best way to find stuff on these forums/PW site is to search using Google. E.g. noindex nofollow site:processwire.com See this example: https://processwire.com/talk/topic/3928-meta-robots-on-individual-pages/?p=38483 Thanks!