kongondo

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!

fenton, Good question. It's something I've been discussing with some people. Currently, the only way to achieve this is to clone the module and modify it (typically paths and selectors) to read your news section pages (i.e. the fields). Obviously, that is not ideal or for everyone. However, Blog is meant for, er blogging. So, another solution is needed. The current idea is to create a separate (but similar) skeleton module that is highly configurable and adaptable to different needs such a news site, etc. At the moment, this is still an idea. There is no ETA yet Cheers.

Thanks for filing this in GitHub. I currently have this working on my local install. Added a 'blog_excerpt' integer field to the 'blog' template. Will also enable editing via the 'Settings' tab in ProcessBlog. Due to the nature of this module, for existing installs (i.e. if you've already installed ProcessBlog) you will have to manually create the field; The module will not attempt to modify existing fields; the risk of corrupting/loosing your data means it's not worth it . I'll post a notice here once I have updated the module, thanks.

blog_date field You are right. It should be about the post publish date. I don't think this will be difficult to implement - I'll just steal and modify the code here by SiNNuT and Soma . I'd still like to leave a manual override (i.e. not disable user editing of it); I envisage cases where a post is published 'by mistake' and has to be recalled for later publication. Scheduled Pages I'll have a think about this one. I can see the potential. Thanks for your ideas!

@looeee, Thanks for further testing this. One thing I have tried to clarify in my posts further up is that the included Template Files are just demos. Some of the code in there is not even related to MarkupBlog. The code in the Template Files is also deliberately verbose. For instance, there is a lot of repetitive code that could be best split up into includes. I decided to leave it like that so that users could select whatever templating approach they wanted (yes, refactoring needed; I might revisit this decision in future). In order to do this effectively, they need to be familiar with the methods/functions available in MarkupBlog . So, I will be writing up a guide covering those methods (e.g. your examples above). Configurable Excerpt Length: Good suggestion. Please file an issue on GitHub if you can so that I don't forget this. Cheers.

In the case of Blog, if any Template File with an identical name is found, it is NOT overwritten (it will be skipped over instead). For all other items (Fields, Templates, Pages, Role) if even one identically named item is found on a site where you are trying to install Blog, then ALL these items will not be installed in order to avoid potential data loss. ProcessBlog 'Dashboard' would still be installed (although it wont be of much use; you would probably need to uninstall it )... See the README. This info is included there (have subsequently made it clearer)... Thanks!

Update: And we are off...'Blog' is now available in the modules directory. Updated first post...

@looeee, Welcome to the forums! I'm glad the module is of benefit... Currently, there is no comment moderation within Blog itself. This is deliberate. You have two choices: 1. You can install the module 'Comments Manager' to manage all your comments in one place. It would have been nice to integrate Blog and CM better but currently there are no plans to do so. 2. You can moderate comments on a per post basis. Just edit a post and you will find all comments awaiting your approval