ryan

Great module Soma! Thanks for making this and posting. The only thing I wonder is why make it an autoload module? This is one that is meant for on-demand use, so it doesn't technically need to be an autoload module. Though I agree it does make for a nicer API call: echo treeMenu->render(...); // vs. echo $modules->get('MarkupSimpleNavigation')->render(...); But I'm just thinking that if every module took this approach, PW wouldn't run as efficiently, or could even run out of memory. But I love this module either way.

Pete that error message you posted is very likely the issue. If you've got an error consistently being displayed, that will interfere with the ability of any ajax request to complete... the resulting JSON would be unparseable. I looked at line 78 of InputfieldPageAutocomplete.module and I'm not quite sure how it could generate that error. Can you double check that line 78 of that file is the same as this in your installation? foreach($this->value as $page_id) { $page = $this->pages->get((int) $page_id); if(!$page || !$page->id) continue; // THIS IS LINE 78 $out .= $this->renderListItem($page->get($this->labelFieldName), $page->id); } I am thinking that somehow your installation must be different, because it should be impossible (from what I can tell) for the statement at line 78 to produce that particular error. Please let me know what you find?

Thanks Oliver. I think the issue here is this: // offer user roles to choose $roles_field = Wire::getFuel('fields')->get('roles'); $field = $roles_field->getInputfield(Wire::getFuel('page'), $roles_field); // HERE $field->label = __("User roles", __FILE__); $field->description = __("Roles given to users created for this type of login by default", __FILE__); $field->value = $value; $field->name = 'user_roles'; return $field; Note the line I labeled 'HERE'. You are asking it to get an inputfield for the 'roles' field in the context of $page. At that time, $page is /processwire/modules/ (template admin) and that page has no 'roles' field. So I think this is unpredictable. Instead, I would suggest doing this: // offer user roles to choose $field = wire('modules')->get('InputfieldCheckboxes'); $field->attr('name', 'user_roles'); $field->label = __('User Roles')); $field->description = __("Roles given to users created for this type of login by default"); foreach(wire('roles') as $role) $field->addOption($role->id, $role->name); $field->attr('value', $user_roles); Just tested here and it works. Also, unrelated, but had a couple other things I wanted to mention: Wire::getFuel('something') is the same as wire('something'). The wire('something') is newer syntax, and you'll usually see the older syntax in the core. But I find wire('something') easier to read, so just wanted to mention that you don't have to use Wire::getFuel() unless you want to. For language translation, __('something'); and __('something', __FILE__); are equivalent. Specifying the __FILE__ saves a little overhead, as PW doesn't need to figure it out on it's own. But for something like a module config, or even your own site templates, it probably doesn't matter much. I've mainly been including the __FILE__ part in getModuleInfo() functions because those do have potential to be called on each request, so every little optimization helps there. Note that none of this is applicable to the $this->_('something'); syntax, but if course that syntax can't be used in a static function. For the top of your getModuleConfigInputfields($data) function, I recommend including something like this: $defaultData = array( 'user_roles' => array(), 'consumer_key' => '', 'consumer_secret' => '', ); $data = array_merge($defaultData, $data); That initializes defaults and makes any corresponding values in $data overwrite them (if present). But if values aren't present, then you don't have to worry about PHP complaining about uninitialized indexes when you are in PW debug mode.

Adam, sorry I linked to the wrong message in that thread before. Here's the instructions for the 'replace' hook: http://processwire.c...ndpost__p__7435 You don't want to call $pages->___save() unless you are using a 'replace' hook. For all other hooks, the original method that you hooked is still called (either before or after your hook). So a 'replace' hook is different in that it tells PW you are completely taking over the implementation. These have not been used a lot, and there is potential for conflicts with other modules hooking the same function. So that's why I say it's probably better to throw an exception where possible. In that case, your hook would look like this: function savePageValidation($event) { $page = $event->arguments[0]; $everythingIsOkay = true; if($page->other != $page->that) { // pseudocode $everthingIsOkay = false; } if(!$everythingIsOkay) throw new WireException("Aborted save because other != that"); } A replace hook would look like this: function savePageValidation($event) { $event->replace = true; $page = $event->arguments[0]; $options = $event->arguments[1]; $everythingIsOkay = true; if($page->other != $page->that) { // pseudocode $everythingIsOkay = false; } if($everythingIsOkay) { $event->return = wire('pages')->___save($page, $options); } else { $event->return = false; $this->error('Page was not saved because other != that'); } }

Thanks Sevarf2, I'll take a look at this and find a fix. Just to confirm, you only experience this effect when using a date field that's set to populate today's date?

Thanks guys, keep me up to date. I think this sounds like a great idea, and looking forwarding to adding it.

Soma, you are right it shouldn't be autoloading that JS, given that the module is not an autoload one. Turns out that the $modules->isUninstallable($class) was inadvertently init'ing the class when it did its check, so it was causing the modules init() function to be called when viewing its config screen. Just fixed this in latest commit. Thanks, Ryan

Thanks Antti, just fixed in latest commit. This applies to situations where you are adding a page somewhere and only 1 template is allowed (per the parent page's template family settings).

Great work Soma, it looks and works great! A great alternate way to navigate pages in the admin. Just tested here and it works great. Javascript error, ProcessDataTable.js line 26.

I totally agree with all that's been said. No need for PW to be creating directories unless they are going to be used. I would get this updated today if I could. Just dealing with a real time crunch here, so expecting to get this in place in April.

If I can get anyone to commit on writing a success story, I'll go ahead and add the forum. So whoever writes the first success story gets to lead the forum. Here's the catch, you have to write it and post it first. Then I'll create the forum and move the topic to it.

Welcome Charliez! When it comes to using jQuery on the front end, pretend that ProcessWire isn't there. Link to jQuery the way you usually would, whether through Google's CDN or by storing a copy locally in /site/templates/scripts/ (or wherever you prefer to). I think it's better that you don't utilize the same jQuery as ProcessWire's back-end because the needs of your site and the needs of PW's backend may be very different. You should also be able to upgrade one without the other. No need to have a front-end to back-end dependency like that. Using PHP in fields is generally not recommended because 1) it's not terribly efficient; and 2) It means that anyone with admin access (that knows their PHP) can bypass any and all security. The same goes for any CMS system that lets you enter PHP in fields. Likewise, the security of your server is then only as good as your client's worst password. PHP is just plain powerful, so I think it's good to limit its access to developers. Even if your client knows no PHP, a resourceful hacker may someday discover your client's crafty password ("b00b13s") and find their way in. If you give them PHP access, your web server will find most of its resources going towards running an IRC w4r3z server and DDOSing the CIA … Or maybe not, but that was my experience with WordPress last month. After all that, if you must enable PHP from your fields, you'll want to eval() it from your template. This is essentially what any other system that lets you use PHP in fields does. So if you have a field called 'php_code' assigned to your template, you'd execute it like this from your template: eval($page->php_code); I think that once you get deeper into PW, you'll find that PHP in fields is oldschool CMS methodology and not something that's really necessary in ProcessWire. With regards to blogging, I've always felt that WordPress answers just about every need in this area, so I've not tried to venture very far into that, and instead focus on the things that ProcessWire can do better than any other platform out there. Though it turns out that PW can be quite a great blogging platform (perhaps even better than WP in many respects). So I think you'll be seeing more and more pre-made options for this in ProcessWire as the platform matures. Also thanks to Sinnut, formmailer and slkwrm for the great replies.

Thanks for the report Sevarf2. Just to make sure I understand, what do you mean by: they increase? Maybe that question will answer itself when I try tomorrow. Taking a look in the code, the getBlankRepeaterPage returns a page that is in unpublished/hidden status. It uses that combination for what it calls 'ready' pages. In order to make it one that's published for use as a live repeater, those statuses have to be removed. Try adding this before your $c->save() and let me know if that fixes it? $item->removeStatus(Page::statusUnpublished); $item->removeStatus(Page::statusHidden); I didn't think people were already using it at this API level yet. I need to get to work on simplifying the API for this fieldtype.

I love that PHP 5.4 makes short tags always on. But it's going to be a long time before the rest of the world is using PHP 5.4, so for anything "distributable" we probably still have to use traditional <?php tags for a couple more years. If I have control over the environment, I usually use the <?= short tag, but not the <? one. I have no idea why, perhaps I should.

You'd have to hook into Pages::save ($pages->save), not Page::save. If you use a 'before' hook, you could throw an exception if you want to abort the save. This is what I recommend doing. But if throwing an exception doesn't meet your needs, you can also use a 'replace' hook: If you use a 'replace' hook, $pages->save will never be called on it's own, so you'll have to take over the call. In order to avoid a recursive loop when you call it from your hook, you'll want to call $pages->___save() instead (which bypasses any hooks).

That's a great overview of PHP 5.4. I'm pretty thrilled with the additions they've made--a nice upgrade. I've not had a chance to try it yet, but I can't see any reason why PW wouldn't run great on PHP 5.4.

Lpa, I'm assuming you are running the latest PW (2.2.0.1), but let me know if not. I'm running Safari 5.1.2 as well, on 10.6.8. But I can't duplicate this. I'm always suspicious of cache issues with Safari. Is anyone else able to duplicate?

Good idea! Perhaps this could be part of our Showcase forum, or a subset of it.

It seems like both HTML Kickstart and Twitter Bootstrap are both very full featured, just in different ways. Zurb/Foundation is not as full featured as either of those two, though there is a lot of nice stuff in it. I got a chance to experiment with it and liked how simple it makes putting together a responsive site--it seems to be built around responsiveness to the bone. Whereas Twitter Bootstrap has it's responsive abilities disabled by default. The only thing I wasn't sure about with Foundation is the speed of it... it does seem noticeably slower in my browsers than the other two, though that may be isolated to my environment.

Oliver, could I get a copy of the getModuleConfigInputfields function you are using so that I can test with it locally? Feel free to just extract the relevant part and post here or email to me at ryan at this domain name. I just wanted to make sure I'm getting the context of this right.

I think that your best bet for this is your apache log: grep ' 404 ' /path/to/access_log Though that's assuming you are logging referrers in your access log. I also like Google Webmaster tools for finding 404s. You could always create a http404.php template file for ProcessWire, and then have it log the info somewhere: $log = new FileLog($config->paths->logs . '404.txt'); $log->save($sanitizer->text($_SERVER['HTTP_REFERER']) . ' => ' . $sanitizer->text($_SERVER['REQUEST_URI'])); But the above may be overkill since info about 404s is already be tracked in apache logs and web analytics.

Antti, this looks fantastic. I'm pointing another domain to processwire.com so that I can test this out. One suggestion that I have is to change this: // If subdomain is visible on url, we might wanna redirect if(strpos($_GET['it'],$subdomain) !== false) { // We don't redirect if one has editing access (because user would need to login on new domain also) $page = $this->pages->get("/". $_GET['it']); if(!$page->editable()) { $_GET['it'] = str_replace("{$subdomain}/", "", $_GET['it']); $this->session->redirect('http://' . $subdomain . '/' . $_GET['it']); } } …to this (or something like it, as I've not actually tested, but hopefully the intention is there): // saved $_GET['it'], since PW unsets it after using it // note this is an unsanitized variable, so only look at it, don't use it protected $it; public function init() { $this->subdomainsArray = explode("\n", strtolower($this->subdomains)); $this->it = ltrim($_GET['it'], '/'); // ...then your existing code… } public function ready() { // if $this->subdomain was valid in init(), then no need to do more here. if($this->subdomain) return; $subdomain = $this->page->rootParent->name; // if rootParent->name isn't a subdomain, then no need to continue if(!in_array($subdomain, $this->subdomainsArray)) return; // if subdomain is visible on url, we might wanna redirect if(strpos($this->it, $subdomain) === 0 && !$this->page->editable()) { $url = str_replace("/{$subdomain}/", '/', $this->page->httpUrl); $this->session->redirect(url); } } The point of this is to avoid sending an unfiltered $_GET['it'] into $pages->get(), which may contain anything in it at that point. There's always a security concern with sending unfiltered input to any function that isn't expecting it. You can avoid the issue completely by moving the check into the ready() function, which gets called after PW has already validated the URL and determined the page. If you wanted to get more fancy with it, you could also foreach($input->urlSegments) and append $input->pageNum (if > 1), but I really don't think that's necessary.

what? Maybe so, I'll try to split it. I tried creating a new field using the Repeater type, but the label wasn't lost. But I had experienced the issue you describe once before (and fixed it), though not specific to a repeater field. Let me know if you can think of any other details on how to reproduce it. Yep

Thanks Soma, fixed in latest commit.

I was a little worried about making path() or url() hookable since they can feasibly be called hundreds or thousands of times in a request. I found a way to make functions hookable without adding any real overhead, except it requires defining two functions rather than one. But it'll be perfect for high-traffic function calls like this. So I've made Page::path hookable in this manner, and it's ready to go in the latest commit. Note that you'll want to hook the method, not the property. In the Page class, calling $page->path or $page->url resolves automatically to $page->path() or $page->url(), so if you are adding a hook, you want to hook the method. I'm thinking we really only need $page->path() hookable (?), since it is what is used by $page->url(). The only difference between $page->url() and $page->path() is that $page->url() calls $page->path() and then prepends $config->urls->root to it. So $page->path is relative to the PW installation root, and $page->url is relative to the server's web root. Though in most installations, the two are the same, as most don't run PW from a subdirectory. The only other difference is that $page->url() trims off the trailing slash if its template says it should (I don't ever use that feature myself).