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

If you did a search and replace, you probably also renamed the reference to PageEditFieldPermissionConfig.php in the module file? i.e. line #115 where the file is required_once and line #116 where a function from that .php file is returned. However, if you didn't rename the .php file itself, PHP should just have thrown an error that a file was not found. Hmm..wondering if this is what caused the problem.... require_once(wire('config')->paths->PageEditFieldPermission . 'PageEditFieldPermissionConfig.php'); return PageEditFieldPermissionConfig($data);

Here's a simple autoload module example that is part of the Blog module suite. And here's some resources. Have fun!

I have answered the question on that thread in case you missed it

I think in template files would be too late? The stripping already happens in the page edit.

@Mary, Yes, you need to create an autoload module...You would need the other bits required in a module, e.g. the install and uninstall methods...Shout if you need any help..

@ Mary, Some freaky coincidence with the segmentation error? Just to clarify, there's only two instances inside PageEditFieldPermissionCustom.module where you need to rename 'PageEditFieldPermission'. These are on lines Line 24: The module class name - class PageEditFieldPermission extends WireData implements Line 115: wire('config')->paths->PageEditFieldPermission PageEditFieldPermissionConfig does not need renaming. Please test on a development server first

Welcome to PW and the forums Misan.. Have a read here for all $page properties and methods: http://processwire.com/api/variables/page/ What you want is $page->created: Unix timestamp of when the page was created or 'created' if in a selector Related - $page->modified: Unix timestamp of when the page was last modified Also useful to read about $pages: http://processwire.com/api/variables/pages/

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.

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.

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); 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

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

Cool

Horst has some suggestions here: https://processwire.com/talk/topic/4668-protect-original-images-in-siteassetsfiles/

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.

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

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?

Regarding selectors, don't know if OR-groups, Group, sub-selectors would be relevant in your case? https://processwire.com/talk/topic/3768-processwire-dev-branch/page-10#entry64049 https://processwire.com/talk/topic/7370-search-for-one-field-or-another-but-with-different-values/ https://processwire.com/talk/topic/3768-processwire-dev-branch/page-9#entry58722 Edit...hmmm, maybe not...not sure these would be helpful...

@Peter, we already have comments manager module that should cover this need - albeit without integration into the Blog module...

@Atano, Welcome to PW and the forums. Thanks to trying out Blog.. 1. I am not sure what is happening in your case. How are you creating a new post, using the Quick Post or as a normal PW page (i.e. via the pages tree)? 2. SchedulePages works fine in PW 2.5.2 3. No; there is no support for sub-categories 4. Have a read here for PW caching options to assess what suits your needs best: http://www.flamingruby.com/blog/processwire-caching-explained/

@Mary...With the current module you can't...but...with the following simple change, you can . Of course, you can always just request Ryan to make this configurable (i.e. whether to completely hide the field or just lock it down, etc)...Meanwhile.... 1. Create a custom copy of the module 2. Rename the module file from PageEditFieldPermission.module to say PageEditFieldPermissionCustom.module 3. Rename the module class similar to #2 plus change all instances of PageEditFieldPermission (whole word) in the module code to PageEditFieldPermissionCustom 4. Change line #91 in your PageEditFieldPermissionCustom as shown below (see inputfield collapsed setting constants here) //if($field) $field->parent->remove($field);//comment this out if($field) $field->collapsed = Inputfield::collapsedNoLocked;//add this line Haven't thoroughly tested...

This behaviour is documented here: http://processwire.com/api/arrays/page/

Norbert, have a look here: https://processwire.com/talk/topic/6096-imagick-resizer-need-to-be-tested-2/. A couple of people have been working on this...

Templates need corresponding fieldgroups...Something like below should do it (not tested, written quickly!) //new fieldgroup $fg = new Fieldgroup(); $fg->name = 'template-category'; $fg->add(wire('fields')->get('title')); $fg->save();//save the fieldgroup //create a new template to use with this fieldgroup $template_category = new Template(); $template_category->name = 'template-category'; $template_category->fieldgroup = $fg; //add the fieldgroup we created above $template_category->label = 'Category Template'; //template label $template_category->save();

@Macrura,....ah, yes, thanks. That's the support forum. I was checking via the modules directory and it isn't listed there... Merging this topic there...