kongondo

Hey, your first module! Great stuff!

You are right, of course...I am having one of those days...I better go to bed

Check your image's fields Input Tab and tick checkbox at 'Overwrite existing files?' Since version 2.5.1

Your var_dump(empty($page->verein_datum)); worked for me as expected

Also...unless you actually changed the template name from 'blog-post' to 'blog_post'...then this line is also wrong... if($p->template->name === 'blog_post' && $p->blog_categories->title == 'Swatches'){ And, you could even shorten it to if($p->template == 'blog-post' && $p->blog_categories->title == 'Swatches'){

Aah, of course. My bad...

blog_categories is a Multiple Page field. This will not work $p->blog_categories == 'swatch'; This has been pointed out above with example code by LostKobrakai. Edit - see next post...

We are talking about two different things here then. You said templates (blog-post) but it seems you mean template files (blog-post.php)? What do you mean by layout? Do you mean the HTML markup or the layout of fields in the template? If HTML, Blog will not get in your way. You can use whatever template file you like but you need to associate your blog posts with the template blog-post. I don't know how much you've read up on the separation of these two concepts but you can have your posts use the template blog-post with a totally differently named template file or none at all. In a nutshell, Blog doesn't care about template files - just the templates. Btw, a couple of posts up I have provided a Gist of the method renderPosts() whose markup you can modify to suit your needs (if you are referring to the markup renderPosts() generates) and use that instead of Blog's renderPosts(). That will not stop you from using Blog's other methods, e.g. renderTags().

1366x768

Nice site Marc. However, I'm not liking the 'Go back' arrow in the top right corner when viewing the tractors. In Chrome,it's almost totally hidden

@Peter, In that case ProcessBlog wouldn't work. It has to find 'blog posts' by the template 'blog-post' rather than their parent because depending on the blog style you selected, the parent might not be a blog page. E.g. In blog style 4, the parent is the root page. The only way to differentiate blog posts in that scenario is by their template. What did you have in mind?

New additions arrived in April 2014 https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=58722 (grouping) https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=64049 (or-groups and sub-selectors) And are now documented here: http://processwire.com/api/selectors/ (but still missing grouping) OR-groups: matching one group of selectors or another Sub-selectors: selectors within selectors

Maybe you need to read this....http://processwire.com/api/arrays/page/. There is a sort function there if that is at all useful.

Something like this. Only 3 FieldSetTabOpen. For Category A we just rename 'Content' to something else in the template blog-post advanced settings. Category A Category B Category C Category D

Maybe it is this: http://processwire.com/api/arrays/page/

Actually, maybe you could group the categories' fields using fieldsets! Would that work? So, you would have 3 fieldsets for categories B - D. The normal landing edit page would be for category A. I'll see if I can test this.

So are you saying you will have four fixed categories? A - D? And each of your posts will belong to only one of those categories? If yes to all, then the easiest way (but maybe confusing) is to create your 4 categories, create your extra fields and add them all to the 'blog-post' template. Then, when rendering posts, pass a PageArray filtered according to your categories to renderPosts() to display. The problem with this approach is that you may end up with lots of fields some of which will be empty depending on the post category and this may confuse your editors. I am not sure if they could be hidden using PW show/if/dependency. I can't think of any other ideas atm. Otherwise, you might have to modify MarkupBlog to suit your needs.

Remember too that you have the API at your disposal. I hope you will not manually be checking and copying the page IDs of your select options!

It really is straightforward if you follow the the module 'Page Edit Field Permission' instructions Create all your extra fields for your Categories A - D Add those fields to the template 'blog-post' Create 3 roles . I say three since as per your description Category B and D seem to have the same fields? If not, create 4 roles and give them distinct names Install the module 'Page Edit Field Permission'. Make sure to read its instructions. In its configuration screen use the 'Handy Tool....' to create permissions for all your 'blog-post' fields that you want to limit access to. For instance, if you want all your users with the roles Categories A -D to be able to view the 'title' field, then there is no need to create a permission for it. The module will create permissions prefixed with 'page-edit-', e.g. if you ticked 'blog_body' as one of the fields in that screen, a permission 'page-edit-blog_body' will be created. Edit each of the roles you created in #3 and check the relevant permissions allowed for those roles. (i.e. give the roles access to edit selected blog fields). Edit and assign your users the different roles your created in #3. You can test with some dummy users, e.g. Jane, Samra, Onuko, Shah to represent your four Categories/Roles. Also give them the role 'blog-author' (needed by Blog). Edit the template 'blog-post'. In the Access tab, you should see the four roles created in #3. If they will all have 'view pages', 'edit pages', 'create-pages' and 'add children' privileges, then rather than granting these to each role, just assign the four privileges to the role 'blog-author' in that same screen. This is a template level access you are granting. Try logging in as each of your four dummy users. Edit a blog post. You will notice some fields are hidden depending on the role that user was assigned. Logging in as a superuser enables you to see all fields. That's it really...

Pretty much, but with a few additions as well. I have created a Gist of the renderPosts() function here: In the demo blog-post.php and blog-posts.php you could use it as shown below (assumes you've already included the function) //assumes function renderPosts() already included in page $content .= renderPosts("limit=5", true, $options);//using our function above//blog-posts $content = renderPosts($page, '', $options) . $blog->postAuthor() . $blog->renderComments($page->blog_comments) . $blog->renderNextPrevPosts($page);//blog-post For featured image, the default is off (0) . So, you need to add an $options array with values for featured image 1 or 2 for the type(s) of post where you want a featured image (i.e. small or large). Below are the defaults: //display post's featured image: 0=off,1=top(above post-headline),2=bottom(first item in post-body)') $options = array('post_small_image' => 0, 'post_large_image' => 0);//these are the defaults -> off (zero) Btw, note that for large posts you cannot use an embedded image as the featured image. You will need to designate a featured image. For small posts, both embedded and images tagged 'featured' will be picked up as featured images.

Hi Cerulean. Welcome to PW and the forums. Natively, the ImportPagesCSV module does not support importing Page Fields. However, with some minor changes to the code, you can make it do just that. See this post for instructions: https://processwire.com/talk/topic/383-module-import-pages-from-csv-file/?p=21476. Please note that any changes you make to modules will not survive an upgrade of that module. However, there are various ways of getting around that, normally duplicating the module code and renaming it. Recently, in the dev version of PW, there's a way to have two modules of the same kind co-exist.

No, you can't adjust that markup via options. There's other ways of doing it on the PHP side though, making it more foolproof than doing it client-side. See option #3 in this post (writing your own code to render posts): https://processwire.com/talk/topic/7403-module-blog/?p=83119 Maybe using str_replace: See this post by DaveP: https://processwire.com/talk/topic/7403-module-blog/?p=78348 Copy and modify the method renderPosts() into your own function which you can include in your template files Using #3 above, you can continue using the rest of MarkupBlog methods such as renderCategories() together with your own modified renderPosts(). If this doesn't make sense just ask

Not sure I get what you mean by Do you mean this <div class='post container'>My post</div> Or this? <div class='post'> <div class='container'>My post</div> </div> Both can be achieved by using jQuery if you don't mind manipulating the DOM using js. If the former (add a class using jQuery .addClass()) $("div.post").addClass("container"); If the latter (add an inner wrapper using jQuery .wrapInner()) $("div.post").wrapInner("<div class='container'></div>");

Well it's only been around for just over a year https://processwire.com/talk/topic/4203-sublime-text-2-snippets-for-processwire/

OK, in essence, a website builder...