ryan

The default precision value is 0. I can update this to assume no precision value until it is specifically set ... I think this makes sense--thanks. The precision field is for rounding, not formatting. I think what you want is number_format(). You could do this in your output: $value = number_format($page->float_value, 2); I could add this formatting in as a configuration option with FieldtypeFloat too, but once formatted, the value is a string, not a float. And I'm not sure it's wise for us to have this Fieldtype returning strings rather than floats. There are also localization considerations with number formatting (decimal type and thousands separator), which are also the job of number_format.

We're probably only a few days from bringing in the new jQuery into the master branch. So far I've only come across the one issue I mentioned before and nothing else has turned up yet. If that's the only issue, I'd consider that fairly minor (easy to fix). So no reason to delay further on bringing in newer versions of jQuery and jQuery UI.

Only if the template is one that defines access. Templates that already inherit access would still inherit. I guess that the most common use case would be that you'd set all your templates to not define access except for 'home' and 'admin'. You'd give all those editor roles edit access on the home template, which would then be inherited by all your others. Then your page-level access control would come in to place limits on that. But I think this would solve the issue with the "you aren't allowed" error you were getting. But I also think it would be a good way to go in general, as its building upon the access control already there (which saves some work) rather than just replacing it. In your viewable() or editable() hooks, if they are coming back 'false' then you don't even need to perform page-level access checking. Ah, I know what you mean. This is one thing I don't like about checkboxes... no way to tell the difference between unchecked and not-present. I was thinking removing them would still work, since they would not be present in the form for the render or the process, but maybe I'm overlooking something. You might try this (below) instead, which doesn't remove them but designates them as hidden and thus not rendered or processed: public function hookBuildForm(HookEvent $event) { if(wire('user')->hasRole('paakayttaja')) return; $form = $event->return; $field = $form->get('view_roles'); if($field) $field->collapsed = Inputfield::collapsedHidden; $field = $form->get('edit_roles'); if($field) $field->collapsed = Inputfield::collapsedHidden; $event->return = $form; } If that doesn't do it, we might try and just get away from checkboxes and use either radio buttons, select multiple or asmSelect instead (something that have a distinction between not present and not checked).

Namespacing not supported by PHP 5.2.x which currently represents a large base of ProcessWire users. Probably by ProcessWire 2.4 we'll require PHP 5.3 at which time we can namespace.

Soma's example is the way the InputfieldForm is meant to be used in this instance. Forms in HTML don't have a 'value' attribute, so we repurposed it in InputfieldForm to function as a way to put in whatever you want. However, if you wanted to do it the more traditional Inputfield way (using InputfieldMarkup), you could also do this, though it's not necessary: ... $form = $this->modules->get("InputfieldForm"); $form->attr('action', $url); $form->attr('method', 'post'); $form->attr('id', 'myform'); $field = $this->modules->get("InputfieldMarkup"); $field->value = $table->render(); $form->add($field); ...

Nik, this has been pushed to the dev branch: https://github.com/ryancramerdesign/ProcessWire/commit/eecd862a6ecf90f2c6b1c173c4d129c5152a31e7 In addition adding in the isGuest() check and the has_parent check, I changed the line you added to be this: // optimization: if parent, parent_id, template, or templates_id is given, and an equals '=' operator is used, // there's no need to explicitly exclude repeaters since the parent and/or template is specific if(in_array($name, array('parent', 'parent_id', 'template', 'templates_id')) && $selector->operator == '=') $includeAll = true; Basically added in 'template' and 'templates_id' since those are also specific enough so as to warrant exclusion of the filter. And added an extra check that the operator was "=", since if they used something like not equals (!=), or greater than/less than (>< <= >=), that would still warrant inclusion of the filter. But just in case I got any of this wrong, I've kept it in the dev branch for further testing.

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