ryan

Thanks Nik, this is a good find and fix. I am updating the code in the dev branch to include the line you added (no need for a pull request here). Using the same logic, I've also added a couple more things: 1. If wire('user')->isGuest(); then there's no need to exclude repeater pages because the user already doesn't have access to them. Meaning, they aren't going to show up in the results anyway, so no need to have the extra filter. 2. if 'has_parent' is specified with a value other than homepage, we don't need to have the filter either. Yes, they could still be included if you did a $pages->find('has_parent=/processwire/, title*=something'); but I think that's okay and maybe still an expected behavior. Though I think this is a rare query anyway. Another related idea is that I could bypass the "has_parent!=n" filter entirely and just have it exclude by template. For example, rather than adding "has_parent!=n", it could add "templates_id!=1|2|3" (where 1, 2, 3 are templates used internally by repeaters), which would probably be more efficient than the join that comes from has_parent. Last thing I want to mention is that the "%=" uses a MySQL "LIKE" which is non-indexed and inherently slow. You can get better performance by using "*=", which uses a fulltext index. Though the difference in speed isn't noticeable on smaller sites, but might make a difference in your case.

Perhaps having permissions at the template level should be a pre-requisite to making them definable at the page level? Meaning, if you didn't have this module installed, then the permissions would need to be setup such that the user would be able to create the pages. I thought this was the case before, but might not be remembering it correctly. This seems like a good way to go. It should also probably return false when the template defines access that doesn't include the user's role. So if you use the strategy above, this hook would be more about selectively denying access than allowing it. Maybe best to remove these fields entirely from the form at runtime using the ProcessPageEdit::buildForm hook: public function hookBuildForm(HookEvent $event) { if(wire('user')->hasRole('paakayttaja')) return; $form = $event->return; $field = $form->get('view_roles'); if($field) $field->parent->remove($field); $field = $form->get('edit_roles'); if($field) $field->parent->remove($field); $event->return = $form; }

I know that I pushed this update yesterday right when I wrote my message. But look what was waiting for me in my shell window when I just now checked: I typed in the push and just assumed it went through yesterday, as it always does. Then moved onto the next thing. For some reason GitHub is prompting me for a username (didn't expect that). Anyway, I just typed it in now so hopefully it should be online finally.

You've already got my two common patterns: the basic profile and the blog profile. processwire.com and modules.processwire.com are both built in a manner very similar to the basic profile (seeing as they essentially are the basic profile). Though I did modify them a bit: rather than using separate head/foot includes, they include a "main.inc" which has the entire markup template in it. main.inc also includes sidebar.inc to cover the navigation and widgets that get displayed in the sidebar on any page.

Not yet an ETA on this. I'm not sure how well this translates to an installable module on top of an existing site. It's something I'd like to do, but it might have to be something entirely different than this. Instead, I think this profile is better as a starting point for a site that needs a blog. If I had an existing site that needed a blog, I'd be more inclined to build it the regular way so that you can remain consistent with the way you are building your templates, etc. Blogs are very easy to build in ProcessWire, so the blog profile is good as a ready-to-go site, a starting point, or an example. But not as useful for something to bolt onto an existing site. However, you may find it still worthwhile to look at the way that it's setup and see if any of the ideas in there might be worth carrying over into your own.

This is where the session comes in. So if you are going to go this route, you'd want to add another condition to check that you haven't already stored a language in the session too: if(!$input->get->language && !$session->languageName) $session->redirect($page->url . '?language=it');

Antti, I was able to reproduce that and have fixed it. Thanks for finding it. The last pull request broke the preg_match index association and I didn't catch it.

Thanks for the updates! I think you've got a good name there, but wanted to mention another possible alternative: PageListDecorator ? I only mention it because what it's doing is decorating the items in the Page List, so when you mentioned the name change it popped into my head. Though I think either name works. When ready, you might like to add this one to the directory at http://modules.processwire.com/add/

I think you've got a good method there, but just be mindful of security. Any time you let paths and files be specified from the admin, you've really got to trust whoever will be populating those paths/files. When it comes to template files, it's best if you keep all the shared stuff out of them and include that separately. For instance, the basic profile includes head.inc and foot.inc, which represent the markup common to all pages. But you can take that much further, delegating to separate includes for other elements when it makes sense (sidebar, navigation, etc.) I also like an approach where you setup some common features in your template that you can turn on or off with checkboxes on the page. For instance, you might have a checkbox that turns on/off the sidebar or comments, etc. And the detection and display of those things would likely be in your shared include files like head.inc or foot.inc. So when it gets down to the actual template file, it doesn't have to focus on anything other than what's completely unique to that template. Even on very large sites, its rare that you should need a lot of templates if you are using them as types and controllers rather than using them to represent minor markup changes. But there are a whole lot of approaches that you can take, and what is best for one may not be for another.

I like Caribbean beaches This is good to think about for the future if we find we have many users near that area.

You could certainly set your homepage template to redirect to that URL when the homepage is accessed without a language GET variable. But I think it would be much better to just assume that your 'default' language is 'it'. There is no rule that the default language has to be English or anything else. The only rule is that it just has to be named 'default' (in the admin), but it is there to represent whatever you want your default language to be. In your case, it sounds like you want your default language to be 'it' since you are wanting an access to /index.php to instead go to /index.php?language=it. So the proper way to do this is to use the default language as its intended. But if you are still wanting to do exactly what you asked, you would do this in your homepage template: if(!$input->get->language) $session->redirect($page->url . '?language=it');

You would create a new field using type 'Repeater', not a template. Though technically you are correct in that a repeater field does create a template to group them, behind-the-scenes. But this is not something you usually need to think about when dealing with repeater fields.

It sounds like you've got the URL generation part down correctly, but your homepage template isn't detecting the URL segments correctly. Can you post the code you are using on your homepage template? If I understand your site structure correctly, you are going to want something like this: if($input->urlSegment1) { $category = $pages->get('/categories/' . $input->urlSegment1); if(!$category->id) throw new Wire404Exception(); if($input->urlSegment2) { $subcategory = $category->child('name=' . $input->urlSegment2); if(!$subcategory->id) throw new Wire404Exception(); if($input->urlSegment3) { $article = $pages->get("parent=/articles/, category=$category, subcategory=$subcategory, name=$input->urlSegment3"); if(!$article->id) throw new Wire404Exception(); echo $article->render(); } else { echo $subcategory->render(); } } else { echo $category->render(); } } else { // render your homepage } Also double check that you are allowing URL segments on your homepage template (Setup > Templates > home > URLs > URL Segments.

Great module nik! Already using and enjoying it here, will be very handy for sure. Thanks for making it.

Teppo, the dev branch now now has switched from extension detection to type detection per your suggestion and code. https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/core/ImageSizer.php Thanks, Ryan

Looks like I broke this a couple weeks ago, but it was an easy fix. Thanks for finding it.

Thanks Nikola, I have approved it: http://modules.processwire.com/modules/ergo-admin-template/ If you want to add any photos to it, just do it like this: (img)http://domain.com/photo.jpg(/img) Replace the paranthesis above with [bracketed] parenthesis. I had to use the round ones because IPBoard interprets bbcode too.

Sounds good Andrew, Thanks-- I'd enjoy getting a look sometime.

Gazley, try the attached. I got your message with the attachment and looks good, but since I already had unimplemented classes in there meant for this purpose (just hadn't gotten around to it), figured I should use them instead. So I used some of what you sent me and also added a couple of new ones to differentiate page numbers from next/prev buttons. All these should now work: // previously present, but not implemented. Now implemented. 'firstItemClass' => 'MarkupPagerNavFirst', // newly added: applied to the first LI with a number in it 'firstNumberItemClass' => 'MarkupPagerNavFirstNum', // previously present, but not implemented. Now implemented. 'lastItemClass' => 'MarkupPagerNavLast', // newly added: applied to the last LI with a number in it 'lastNumberItemClass' => 'MarkupPagerNavLastNum', Let me know if this covers what you were needing? This is now posted in the dev branch. But you can also just replace your MarkupPagerNav.module with the attached if you prefer. MarkupPagerNav.module

Nik this is now merged into the dev branch. All seems to work well in my testing so far. Thanks for your work in upgrading this functionality. https://github.com/ryancramerdesign/ProcessWire/commit/ed28b1b3b2a8e69e3200072bd8293f4a0c591617

Great admin theme Nikola! Love it. Nice work! Would you mind adding it to the modules directory? http://modules.processwire.com/add/ -- we have a section in the modules directory just for site profiles. I want to send out a tweet about the new theme tomorrow if that's good with you.

Thanks Andrew, we are happy to have you here. Sounds like you have a lot of background in designing and building CMSs, so we are glad to have your expertise here too.

I don't think that your code above will work because you are setting session values in the middle of output. Everything that you do with regard to getting/setting language needs to happen before you start outputting stuff. You'd do it like this: <?php if($input->get->language) { $name = $sanitizer->pageName($input->get->language); $language = $languages->get($name); if($language->id) { $session->languageName = $language->name; $user->language = $language; } } else if($session->languageName) { $user->language = $languages->get($session->languageName); } ?> <html> <head> ... I'm putting that <html> tag there just to show that you need to take care of the language getting/setting stuff before you start sending markup. More likely you would include('./head.inc'); or something like that.

You can put restrictions on this too. When you edit a template, there is a tab called 'Family'. From there you can choose what page templates are allowed for family (parents and/or children). A screenshot probably explains is better than me though. Regarding MVC and what SiNNuT was saying, a good site profile to look at is the Blog Profile which is takes something much more resembling an MVC approach than the basic profile. Though I'm not suggesting that it's a better approach, but rather an alternative one that some way prefer and some may not. -- Edit: netcarver beat me to it

Can you try renaming your Page reference field to something other than 'users'? Since that is the name of an API variable, I'm just wondering if it's causing a conflict somewhere. I checked and 'users' is not a reserved word in the system, but maybe it should be.