ryan

Diogo, I can't seem to duplicate here. Tried both master and dev 2.2.9. How recently did you update? I'm assuming master branch, but let me know if dev. The error indicates that a call to $modules->get('InputfieldRadios'); didn't succeed for some reason. First thing I would do is clear your modules cache. You can do this by going to Modules > Check for new modules. Does that resolve the error?

I'm happy to make any changes/improvements that you need to this module. As you can see, this module was designed for a narrower context without too many features, but now is a good time to broaden it, and I think it'll adapt easily. For starters, why don't we move renderList() to be renderList($selector) and the "limit=25, status<statusMax" can be moved to executeList, like this: public function ___executeList() { return $this->renderList("limit=25, status<" . Page::statusMax); } That way you can just override executeList. Does this solve what you need for that? Also, I've run out of time today so didn't have a chance to take a closer look at the other issue you mentioned, but if you can let me know of any specific changes I can make the same ones here.

Soma I don't have a 5.2.4 to test on, but if you try modifying that debug_backtrace does it also fix the issue? The issue with 2.2.9 showing the value rather than the label for a checkbox is unrelated -- I think I know what's causing it, it's related to some new features I recently added to the checkbox inputfield. Should be an easy fix.

Doesn't sound like you are on the dev branch. I think the problem here is just that CodeMagic only has translations for cs, en and sk. This is the only reason why I don't have codemagic installed by default. If you use codemagic with some language other than these, you'll get a javascript error. Try removing codemagic from your TinyMCE field settings and I'm guessing the error will clear up, but please let me know.

I'm having difficulty following the code due to IP.Board removing all indentation. If you can post the .module file or add it to the modules directory, I can get a better look. No need to make them translatable in the module itself. They should already be translatable from the fields editor. It looks to me like you've got this setup correctly.

This was actually fixed in the current version's source code about 10 days ago, so it's better just to grab the latest version of ProcessWire rather than replacing Pagefile.php.

Well I sort of understand, I mean I'm still using VIM and a 1986 IBM Model-M keyboard. Those maybe those aren't good comparisons. I see us requiring 5.3 within the next 6-months or so, not 2-3 years. But at the moment, my main interest is just in growing our user base, so anything that contracts (rather than expands) the user base is undesirable. But I think 6-months from now will probably be the right time to do it.

Good ideas nik! I've added a new $config->dbCache variable. When set to boolean false (in your /site/config.php file) it adds the SQL_NO_CACHE in exactly the same way you posted. This will appear on the dev branch this week.

I haven't actually moved any tutorials, at least not that I'm aware of. I see your comment on this page: http://processwire.com/tutorials/ As far as I know, that Quick-start one is the only Tutorial that's ever been in there. Although there are several subpages below it. However, those were all written by one of our users for ProcessWire 2.0, and they've not been updated since. So I worry a little about how applicable they still are. The only other places I know of that we have tutorials are the Tutorials forum here and here: http://wiki.processwire.com/index.php/Small_Project_Walktrough Let me know if I'm missing something?

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.