ryan

Thanks for the kind words and recommendation Joshua! We appreciate it. I likewise have very positive thoughts regarding HTML KickStart. I hadn't known about it until recently and am really impressed what what I see. Something that comes to mind is a possible future ProcessWire site profile that's built around HTML KickStart (if you aren't opposed to it), some really cool possibilities. I look forward to experimenting more. Thanks for making this great framework.

Currently you can't have a textformatter configurable with a field's settings, though a textformatter can be made configurable in the module settings (where you could workaround that). But perhaps I should find a way to enable textformatter config options with the field.

I think this looks pretty nice. Could be a good replacement for the debug mode we've already got. I have no idea yet if it'll work with PW, but I'm going to give it a try. Thanks for letting me know about it!

Soma, sounds like you've got it right. If you want the default language to be German, then just throw in the German files into the default language. There's nothing English about the default language except for the name "default" (which you uncovered the reasons for). But if you want to connect the language to a code like "de", then I suggest creating a new field called language_code and adding it to the language template. When you want to select a language, just use "language_code=de" in your selector. When you create your English language as an alternate, you won't need to upload any JSON files for the admin side of PW unless you want to change the English that is already there. I don't think there's any reason to gravitate towards keeping 'default' as English, unless it really is your site's default language. But if you want to do that for some reason, then you would just edit the 'guest' user account and change guest's language to to be 'de' or whatever you want your site's default language to be.

I saw that too--good to see. It looks like he's also using ProcessWire to power that 99lime.com site.

It is possible, but you'd have to modify the Comments fieldtype and inputfield to do it. As a result, it may be something you'd want to wait for the updates, unless you need it right away.

You've found a bug. Try putting a space before your '_n' ( and that'll fix it. I should have a proper fix committed here in a couple minutes. Thanks for finding this. Ryan

Adam you want to use the Selectors class. Try running this example, which should answer a lot of questions: $str = "a=1|2|3, b<=1, c*=xyz|some, d>10, e|f=something, g!=nothing"; $selectors = new Selectors($str); $tests = array('0', '1', '3', '9', '15', 'Adam', 'abcdefghijklmnoprstuvwxyz', 'something', 'nothing'); echo "<ul>"; foreach($selectors as $s) { echo "<li>" . $s; echo " (" . $s->field . $s->operator . $s->value . ")"; echo "<ul>"; foreach($tests as $test) { $matches = $s->matches($test) ? "<strong>Matches</strong>" : "Does not match"; echo "<li>$matches: $test</li>"; } echo "</ul></li>"; } echo "</ul>";

Clinton, I've updated the module to support this. You'll find it in the latest commit in the PW 2.2 source. To enable, specify '0' as the max length for the description field in the module settings. Can you confirm that this solves the issue and enables use of the full article? Thanks, Ryan

main.php just refers to a main markup template. It would be the same thing as a head.inc and foot.inc combined. But many use a main.php rather than separate header/footer includes.

ProcessWire 2.2 is already released, so the term "hard launch" would refer to the date when we send out press releases to various sites to announce it. Before that happens, I want to get an official language pack section setup on the site and wrap up a bit more documentation. I would say we'll do a hard launch in two weeks, roughly. But don't wait to upgrade to PW 2.2, as it is now considered the stable version.

That's great to hear Google can execute JS and index stuff from it. That's quite a technical feat, I'm impressed. I did some testing a couple days ago with Disqus and found Google wasn't indexing them. But it may just depend on the site, widget version, etc. But the fact that they CAN definitely changes my opinion about javascript-based comments. However, I still have to believe there are major advantages to staying in control of the markup and accessibility of your comments… but just not as many as before. Things are always changing for the better.

Sorry, I misunderstood. If those files are only going in the places that need it, then the concern I had is not applicable. Not necessarily. When a file is on a protected page, ProcessWire could spit out a link to the passthrough script as the $file->url(), like domain.com/files/123/somefile.pdf, rather than to its protected location in /site/assets/files/.123/. The $file->filename() property would still refer to the actual disk path since htaccess limits aren't applicable there.

Thanks Dave, you are right, that's a typo on my part -- it should be explode().

No matter where you use a selector like "parent=/path/" in the API, it's always going to refer just to direct children of that parent. The selector used in this field setting exhibits the same behavior as the rest of the API. I think what you might be looking for instead is the "has_parent" selector option, which is a way to refer to a page having a parent anywhere in it's ancestor tree. You won't see "has_parent" used in the API very much (or ever?) because you'd typically do this instead: $pages->get('/products/')->find('template=product'); But behind the scenes, that actually translates to this: $pages->find('has_parent=123, template=product'); 123 is the ID of /products/. The "has_parent" has to be used with an ID rather than a path, though I'll probably change that, now that there's an external use for it.

It does work for me. Are you sure you don't have one of the other fields populated, like parent or template? Let me know if you can think of anything else I might try to duplicate here. Also, regarding Antti's question -- are you using an asmSelect with a 1-page reference? asmSelect is only meant for multi-page references.

Nevermind about this, I was wrong as that limitation never made it into the code at GitHub (was already fixed before I pushed it to GitHub). I tried this as my selector with a multi-page field using asmSelect: parent=/building-types/, template=airports|aquariums It worked for me, showing the selectable pages I wanted it to. Is there anything else I need to do to duplicate?

I couldn't duplicate this until I tried with changing it to a single-page field rather than multi-page field. That did it, I could duplicate it. I looked closer and see we have an optimization that enforces the parent at load time, but only for single-page mode. Usually this optimization would be good, as it gives a slight performance edge. But obviously it's not good with PageListSelect, so I removed it. Thanks for finding this. I've committed the update to the 2.2 source. Is this paired with one of the PageListSelect inputfields? You mentioned asmSelect, but since PageListSelectMultiple also uses an asmSelect style sort list, I'm not sure. You probably saw the note with 'selector' and 'template' where it says "This is not compatible with PageListSelect inputfields". However, it should be compatible with a regular asmSelect Inputfield. But you might need to use parent=123 (page ID) rather than parent=/produckte/, though not for long (already a fix for that but still tweaking it).

Oliver, I'm not certain without seeing some code. If you'd like, PM or email (ryan at this domain) and I'll be glad to take a look. Is the page you've added your Process module to using the default 'admin' template, or something else? If not the 'admin' template, then note that you'll probably want to have URL segments turned 'off' in your template settings I think you already understand this part, but I'll describe how Process modules work with regard to URLs. If you have a Process module you've assigned to page /languages/ and you access that page, then the execute() method of that process will be called, and whatever it returns will be displayed. But if you access the URL /languages/add then it's going to call executeAdd() instead, and likewise if you access /languages/edit then it's going to call executeEdit() instead. There are no predefined segments, so it doesn't have to be "add" or "edit", but it can be whatever you want it to be, so long as maps to an execute[segment] function in your Process module.

check_access just refers to view access, and this is assumed if you omit check_access. So the only reason to ever use check_access is if you want to include pages the user doesn't have access to view, due to access control settings. To list the pages you mentioned, you'd just use "status=unpublished". If $user->isSuperuser() then don't bother performing any checks, because they will have access. You could cycle through the templates, see which ones are defining access, and of those, which ones have editRoles that are consistent with the users roles. Then include those templates in your $pages->find() selector. But this leaves out those pages that inherit their access. That's because that access is inherited through the hierarchy at runtime, so not possible to determine without actually loading the page and following it's inheritance path. As a result, this is a complex question to which there isn't a simple answer... at least not one I can think of yet.

I don't think it will. Once that "include=all" appears in there, that pretty much overrides anything else you might set in there. I think it would probably be unusual to ask PW to check access and include unpublished pages, but a potential need might involve including 'hidden' (but not unpublished) pages and disabling access checks. So in that case, you'd do: include=hidden, check_access=0

Antti's right about what that example is doing, but let me do another. Lets say we've hooked in before $session->redirect(). If I go look at the function definition in /wire/core/Session.php, I can see it has two arguments: $url and $http301. So lets say I want to hook into that and automatically add a GET variable to every redirected URL, like "url.com/path/?is_redirected=1", I'd do this: public function hookSessionRedirect(HookEvent $event) { $url = $event->arguments('url'); // get the existing value $url .= (strpos($url, '?') === false ? "?" : "&") . "is_redirected=1"; $event->arguments('url', $url); // set the new value that gets sent to $session->redirect } Btw, there is some overhead in using the argument names as opposed to the position (it involves using Reflection), so in most cases I think it's still better to use the argument position rather than the name. But have wanted to make both options available because I think some people will find it more straightforward to to use the argument names... and it no doubt makes code examples more readable.

Evan, make sure you sanitize $_POST['email'] before putting it into the selector. Since you are dealing with a page name, I recommend this: $name = $sanitizer->pageName($input->post->email); $my_page = $pages->get("template=template-photo, name=$name, include=all"); "check_access=0" will cause it to include pages that the user doesn't have permission to view as a result of access control. It's what you'd want to use if you wanted to (for example) generate public listings for pages, but only full members could view the whole page. In that fashion, you could have the page appear in lists to everyone, even if only the members could view it. The non-members could get a login page when they click on it. "check_access=0" won't cause unpublished or hidden pages to be included. Whereas "include=all" will include everything regardless of access, publish or hidden state. Any function that returns a PageArray (like $pages->find or $page->children) will have this access checking enabled by default, unless you turn it off with include=all. But functions that return a single page (like $pages->get) don't check for access/status since they are returning a pre-determined (by you) item and quantity, and aren't likely to be used for making navigation.

Nico, this has been added in the latest commit of 2.2. To make use of it, have your hooked function (getPage in your case) do this: $event->replace = true; // now original function won't be called $event->return = 'you are now providing the return value'; Also your hook obviously must be a 'before' hook in order to replace the original. So you'd init the hook like this: $this->addHookBefore('ProcessPageView::execute', $this, 'getPage'); Unrelated to the above, but another cool addition: I upgraded the hook system so that it will let you set or get hooked function arguments by name rather than just by position. So if you'd hooked into Pages::save, and you wanted to refer to the 'page' argument, you can now do this: $page = $event->arguments('page'); Before you could only do this, having to know what position the argument was in: $page = $event->arguments[0]; You can also set arguments back to the event by name if you want to, i.e. $event->arguments('page', $mypage);

This is the case with template, but not parent. If you set a parent, then PageListSelect assumes that to be the starting point in the tree. The pages don't have to have that parent directly. They just have to have that parent as an ancestor. This is the way it's supposed to work, and the way it worked here just testing it. Are you getting a different behavior? But you are right with regard to template. PageList doesn't take template into account because PageList is designed to list hierarchy not type. It's feasible in the future that template could be combined with parent as a constraint within the hierarchy defined by parent, but that ability isn't there right now. As a result, template constraints shouldn't be used with PageListSelect inputs. It's not just a matter of an Inputfield here. The paths for pages don't actually exist anywhere that can be searched. Paths are constructed and determined at runtime, and only for pages that are loaded. There's nothing to strpos() or find(). So we'd need to find a place for them to be cached before such a solution could search them (using that 'mypath' field, for example). I'll keep thinking if there's other ways.