ryan

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.

It's easy enough for me to search/replace, but I'm reluctant to remove it entirely (at least for awhile) as I don't like to risk breaking anyone else's code. But indicating that its deprecated is a good idea. Very nice, I like it. And actually think it is still useful even outside of an IDE. But I'm confused by the last line: "class Post extends Page" -- is this what you mean by fake-out the IDE, or does the Post class have a purpose beyond it?

Do you mean like put it in a /* comment */ or something?

WillyC's example just modifies the output of the $page->path() function (which is also used by $page->url). His intention there is to change what URL gets sent out when you call $page->url. It's really no different than making your own function and using it instead, except by using a hook like this, you can continue to use ProcessWire's API and get the result out of it that you want. Ultimately it's just a syntax convenience. While his hook example handles the URLs that get output in your markup, you still have to have something to look for and capture those URLs. Perhaps you could use mod rewrite, but typically you would use the "URL segments" feature that you see on the "URLs" tab when editing any template in PW admin. Lets use a simple example of your homepage template (home) with filename home.php. And lets say you want to make it so that when someone access domain.com/contact/ (a URL that doesn't currently exist) you want it to display the page that lives at domain.com/about/contact/. So you are setting up your site to respond to the shorter URL of /contact/ (rather than /about/contact/, where the page actually lives). Go to Setup > Templates > home > URLs. Click the checkbox to "allow URL segments", and save. Now edit your /site/templates/home.php file, and do something like this at the top: if($input->urlSegment1 == 'contact') { // render the /about/contact/ page echo $pages->get('/about/contact/')->render(); return; } else if($input->urlSegment1) { // throw a 404 throw new Wire404Exception(); } // otherwise continue normally and display your homepage.

Very cool Pete (and Netcarver)! Thanks for posting this.

If the page name were different, it would technically be a different page. We will find a way to do some kind of aliasing down the road, but it would involve some changes to the way that ProcessWire addresses and differentiates between pages. But it's doable. I'm just waiting for the simple solution to pop into my head and it hasn't yet.

Andrew, I'll be glad to answer any questions you have. I see you already posted some in another thread, so will respond later tonight or tomorrow AM.

Of course! I'm always glad anytime to get updates like this. In this case, I wonder if it really should get down to the database level. For instance, supporting the option of a 'unique' index down to the table schema in text fields, which could then be inherited by the email field. For something beyond an individual site, uniqueness probably needs to be enforced down to the database level for any field used as a login identity. That's one reason why 'name' is good for this, because that uniqueness is already enforced. But the same could be done with email. I'm going to look at what changes might be needed at the lower level of text fieldtypes.