ryan

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.

$u = wire('pages')->get($user->id); //get the user page $transacties = wire('pages')->find("template=transaction, users=$u"); vs. $transacties = $pages->find("template=transaction, users=$user"); Those two above are actually identical, so I would just use the shorter one. There's no need to retrieve $u, because it would be the same thing as $user, an API variable already present. What I'm wondering is if these "transaction" pages are access protected in some way? I'm guessing they are, based on the name. So what you want is probably this: $transacties = $pages->find("template=transaction, users=$user, check_access=0"); or this $transacties = $pages->find("template=transaction, users=$user, include=all"); The "check_access=0" does nothing other than cancel access checking. Whereas "include=all" does even more, as it cancels access checking and enables hidden and unpublished pages to be included as well.

To the outside world (those accessing your website) everything is a page, accessed by a URL. ProcessWire is just trying to maintain consistency between the outside and the inside. All pages have a consistent set of properties and methods, but a Page derives its actual "type" from its template. So a Wine, a Review and an Event are all different types, while still sharing the common heritage of being a Page. A Page is basically a URL addressable container for data that has a parent and optionally children. But beyond that, everything about the Page's type comes from the template. Pages in ProcessWire are very similar in concept to nodes in Drupal (from what I understand). But nodes in Drupal are abstracted away from URLs whereas pages in ProcessWire are always connected to a URL. Even if that URL is tied to something you never intend to use as a renderable page on your site (and might not even have a template file), the URL is still a consistent, known way for you to refer to a page from the API, or wherever. A Page's URL is always reflective of its parents, meaning you know where a page physically lives in the tree based on it's URL. ProcessWire embraces the addressing system of the web, both on the front-end and back-end.

I was missing a few of the reserved words in the field creation process, honeypot being one of them. But hopefully got them all covered now. If you use a reserved word, it'll still let you, but it'll just append an underscore to the end of it so that there's no confusion.