kongondo

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...

I am struggling to understand why this should be a module? You can pretty much run this as a function included in your template file. I am also not getting the question, what do you mean by grouping fields? Maybe give an example? And what does a FieldSetOpen have to do with a Markup module?

@Diogo...Mm...I always thought it was mr-fan ....I am referring to this one: https://processwire.com/talk/topic/7298-google-custom-search-for-your-browserbookmarks/ But of course you also have yours here which is the original

I've merged your 'PHP resources' topic with this one: https://processwire.com/talk/topic/2994-learning-php/?p=85246

Btw, in case you've not seen it, someone created a custom google search for the PW site. It's the one I always use

Posted these links in your other thread but reposting here... OK, here's some links in other threads: https://processwire.com/talk/topic/1555-learning-oop/ - more links in post #10 in that thread https://processwire.com/talk/topic/6030-learning-php-where-to-learn-just-enough-to-make-living-w-pw-easier/ https://processwire.com/talk/topic/4439-when-do-we-need-curly-brackets/ https://processwire.com/talk/topic/1931-recommended-php-style-guide/

My 2p....at the end of the day on such issues, really, it is horses for courses. There is nothing 'evil' about liberally using echo. Some people will include HTML in their PHP others will do it the other way round. Some people want complete separation of logic and 'views', others don't care. Some people use cameCase variables others don't. Some people swear by double quotes others prefer single quotes. Some people like OOP others prefer procedural style...Some people like direct output others prefer delayed. Others like template engines others don't...and on and on... Tell you what, the only thing you should never ever compromise on is security; for that, there are no ifs or buts. As for coding style, just pick what you are comfortable with and makes you most efficient. However if collaborating on a project where there are multiple coders, then obviously you would need to agree on the coding style . Edit: Glad the code worked for you. PHP resources: There's a number of threads on that already. Best if you searched first. I'll update this post if I can find the links as well. OK, here's some links: https://processwire.com/talk/topic/2994-learning-php/ https://processwire.com/talk/topic/1555-learning-oop/ - more links in post #10 in that thread https://processwire.com/talk/topic/6030-learning-php-where-to-learn-just-enough-to-make-living-w-pw-easier/ https://processwire.com/talk/topic/4439-when-do-we-need-curly-brackets/ https://processwire.com/talk/topic/1931-recommended-php-style-guide/ Happy coding!

Whereas that's a valid point, I am not sure that would happen. The primary purpose of the main docs found in http://processwire.com/api/variables/ and http://processwire.com/api/selectors/ is to quickly and efficiently teach (new) users how to use the ProcessWire API with as little verbosity and complexity as possible. The examples there are necessarily short so as not to lose focus or inundate the user. In addition, there are so many ways for outputting PHP content, different people preferring different styles, that it would be difficult to cover them all. The most basic/ubiquitous is 'echo' . For most people, whilst learning how to use the system also improves their PHP skills, I would suggest that you would get much more from the system if you additionally went through some very, very basic PHP tutorials . I could suggest a few if you haven't already identified any. On the other hand, in the template files tutorial such as this one http://processwire.com/docs/tutorials/how-to-structure-your-template-files/ you see some more advanced coding styles. Edit Beaten by @LostKobrakai - but you see we refer to the same thing...