ryan

There are a number of ways to do this, but for the purposes of an example, lets look at your first one: Brand. Lets say you've got your brands as pages here: /brands/acura/ /brands/audi/ /brands/ford/ ...etc. Your search form might look like this: $checkedBrands = $input->whitelist('brands'); if(!is_array($checkedBrands)) $checkedBrands = array(); foreach($pages->get('/brands/')->children as $brand) { if(in_array($brand->id, $checkedBrands)) $checked = " checked='checked'"; echo "<label><input type='checkbox' name='brands[]' value='{$brand->id}' $checked> {$brand->title}</label>"; } And your search processor might look like this: $selector = ''; if(is_array($input->get->brands)) { $brands = array(); foreach($input->get->brands as $brand) $brands[] = (int) $brand; $input->whitelist('brands', $brands); if(count($brands)) $selector .= "brands=" . implode('|', $brands) . ", "; } $vehicles = $pages->find("template=vehicle, $selector"); Now when it comes to showing something like models, you'd either want the models to have a page reference selecting a brand they relate to, or you'd want to make the models children of the brand. That should make it fairly easy to determine your models once you know the brands: $models = new PageArray(); foreach($brands as $brand) { $models->import($pages->get((int) $brand)->children); }

I'm not sure I understand the question 100%, but I think we need to take a look at the code that actually generates the selector (rather than just the code that generates the form). Also, while developing search engines, I always find it helpful to output the selector that is being used. Once the site is finished with the development then I remove it. But to do this, you may want to add something like this at the top of your search results: <?php echo "<h2>" . htmlentities($selector, ENT_QUOTES, "UTF-8") . "</h2>"; ?>

I don't understand what you mean about "denounced by phishing hotmail", so might need more explanation there, but understand the rest. Whether it's a security hole depends on your hosting environment. If you are in a shared hosting environment and accounts are not fully jailed or virtualized from one another, then a directory set to 777 will be writable by other users that also have accounts on the same server. But in this environment, just changing to a different permission doesn't totally solve the problem either, because the other users can still write to your directory so long as Apache is running as a shared user. Still, the user would have to be on the same server and have an account just like yours, so the culprit will be easy to spot for your web host. Given that they haven't identified a "who", I think it's more likely that you have another software installed on your account (WordPress compromised?) and that any writable directories are being taken advantage of from your own account. Either that, or someone guessed the password for your PW admin account. So check into these possibilities. Either way, inquire with your host what permissions they recommend to make files writable to your CMS. Then update the relevant settings in your /site/config.php. You'll also want to adjust the permissions for files already on the system. I'll be happy to tell you what to do, but we need to know what permissions your host says to use, as what applies to one system may not to another. Best case scenario is that Apache is running as your own user account and that we can remove all write permissions except to you. But even that won't solve a hacked WordPress or compromised password.

The term "block" implies generated output or some understanding of what the final output is. PW is meant to be totally markup and output independent so there is no concept of anything relating to generated output. It may be web-based, but the content it's managing might not be. It's the opposite of something like Drupal. I'm not saying the other systems have the wrong approach, because there are benefits and drawbacks to different approaches. But I've been working on this blog profile for ProcessWire the last couple of days and my mind is entrenched in blocks at the moment. I'm not sure if this is exactly what you are trying to achieve, but what you guys are describing sounds kind of similar to the "widgets" sidebar in the blog profile. There is a multi-page reference field called 'widgets' on the homepage. You select (asmSelect) from different widgets (pages) that you want to appear in the sidebar (i.e. Recent Comments, Recent Posts, Twitter Updates, etc.), and then drag them in the order you want them to appear. All the pages in the site inherent these widgets. When other pages in the site have their own 'widgets' field, it gets prepended to the list of widgets inherited from parent pages. Though I'm thinking about making it override rather than inherit, as I'm just trying to find the easiest to understand solution for new users. But regardless of where it ends up, it was pretty easy to setup: // inherit and append widgets $widgets = $page->widgets; foreach($page->parents as $parent) { if($parent->widgets) $widgets->add($parent->widgets); } // output widgets foreach($widgets as $widget) { echo $widget->render(); } I'm guessing this is still different than what you guys are talking about, but figured it might at least add to the conversation since it sounded somewhat similar to what's already been mentioned.

Currently ProcessWire only attempts translation on page names. There is some overhead with doing it, so we avoid it where possible (like with filenames). If there's more demand for doing this, or if we find ways to make it happen without extra overhead, it would certainly be a consideration down the road.

Not currently, but will keep this in mind for a future version.

I'm not sure I understand: a module that removes rooms for tourists? I don't get it. I have a feeling the link would answer it, but it doesn't seem to work (got a 404).

This is on the list for 2.3, so should be coming soon!

I've been working on a blog profile that we can have as an installation option for ProcessWire. The goal is to have a profile that someone could download and setup a pretty nice website/blog without having to touch any code (i.e. it's ready-to-run and populate). I'm hoping that this is something that may help us to grow our audience beyond the web development community. The requirement is that it must be as easy (or easier) than WordPress, both to install and use. This profile is also for web developers, as it's a blog profile ready to be styled and enhanced -- a good starting point. It uses the Zurb Foundation CSS framework, so it is fully responsive and mobile-ready. It's not much to look at now, but should be fully functional. I'm making progress and wanted to post a preview. The content you see here is from one of my client's blogs and the content is just here to test things out. http://processwire.com/blogtest/ I'm hoping to get this up on GitHub next week. I've never really done much blogging, so am seeking feedback on what others would suggest to make the blog profile as good, powerful and simple as it can be. Right now it's pretty much a generic Zurb Foundation "look and feel", so it probably needs at least some color tweaks and integration of some masthead photo(s) or something.

Great module Diogo! Tested here and seems to work well. I did have to change the selector to "$field.status<1, include=all". I did "<1" rather than "=0" so that it would catch comments marked as spam as pending too. In your getModuleConfigInputfields I recommend removing the "size=200" attribute, as that's causing an overflow issue in Chrome/Mac at least. I would just leave off the size attribute there (unless you need it small), as it'll automatically size to the screen width if you leave it out.

Once PHP 5.4 is pretty mainstream (later this year?) we'll drop support for PHP 5.2 and then use PHP 5.3 namespaces. But lots of folks are still running on PHP 5.2 (including me on a few servers) and I don't see any way to be backwards compatible with PHP 5.2 once we start using namespaces. Still, I'm anxious to get them in the PW core and just trying to find the right time when it'll help more people than it will hurt.

Something that is storing images exclusively on another server probably needs to be a different animal from the existing image/file fieldtypes. Rather than trying to hook into functionality there, I would go and create a new fieldtype so you can start fresh. On the other hand, if the goal is to just keep a copy of any files used at the other server, and then replace references to them at runtime (like when output formatting is on or something) then I think that would be more of a scenario where hooks would be useful.

JS is certainly an easy way to accomplish it for helping the editors. It's more the developers I'm worried about, coding in a manner that expects a field to always be populated, when it may not be technically possible for that to always be the case. But if it's just helping the editors that we need, then that's no problem: there are no technical challenges there.

Not sure about this one. Another user had requested that we add that str_replace(' ', '%20', $filename) in the past because it apparently wasn't working without it on filenames that have spaces (and that's why it's there). Sounds like this behavior may depend on the environment. I would never think to use spaces in filenames for anything like this, so can't say as though I know exactly how to tailor this to everyone. But I've added another check in there and pushed it to the source. Though not sure if this will help in this particular situation or not. Either way I recommend avoiding filenames with spaces as that's not very portable. But give the update a try and let me know if it makes any difference here.

Not sure that I understand exactly, but if $_POST is empty, then ProcessWire also won't be able to get at any of the posted data. So I would look to find why $_POST is empty (from a redirect or incorrect <form method> attribute?) before getting into the ProcessWire specific stuff.

Yes, always sanitize anything that gets sent to any API call. If you don't, then anyone can inject anything into that selector just by specifying it in your signup_name field. While I can't think of a major problem that could occur with that in your example, it's best to prevent any injection situation. The stakes may be higher in another situation. That's because selectors are designed for your use, not the users. API calls run as superuser, so it's feasible that in some scenario a hacker could exploit an unsanitized selector. You can't modify data with a selector, so it's not at the same level of concern as something like SQL injection, but still a good idea to sanitize anything getting sent to any API call. Except for $sanitizer API calls of course.

I just updated the Input class so that you can now unset URL segments. Use the existing $input->setUrlSegment($n, $value); function, but specify null as the $value for the segment you want to unset. When you do that, it'll unset the segment and reindex. For instance, lets say you had page /about/products/a/b/c/ where /a/b/c/ are the URL segments 1, 2, 3. If you call $input->setUrlSegment(1, null); then /b/c/ would be segments 1, 2 (and no more 3).

Soma that's not the correct behavior. The segment of a page that actually exists should never be included as a urlSegment. urlSegments are just the extra segments in the URL that didn't resolve to a page. I'll add this unset function to the $input.

Make sure you do this before putting $username in your selector: $name = $sanitizer->pageName($input->post->signup_name); $u = $users->find("name=$name"); While you don't want to have that directly in your selector either way (since it would be unsanitized), I just wanted to add that when you are dereferencing object properties in a string, it's best to surround the statement with {}, like: "{$input->post->signup_name}"; and that should solve the problem.

Thanks for the post Alan. Unless I'm misunderstanding, you shouldn't need to use the 'hidden' at all, as an unpublished page isn't going to be showing up on the front-end site or navigation either way.

Proper required fields aren't quite as easy as they sound in ProcessWire. There are some problematic scenarios. For instance, what if you edit a published page, make a bunch of edits and leave a required field blank. When you save, if there is a missing required field, then logically the save should be aborted. But any other changes you made that were valid would also have to be aborted, otherwise we'd have a page in a partially saved state (which is not possible). A page can't be in two states at once. And if we're saying we support real required fields, we can't have a published page in the system in a state where one of the required fields is blank. So the required field support you see in PW right now is not much more than symbolic, because the page can still exist without a required field populated. PW will complain and give you errors telling you about it, but it can still exist. Real required field support means letting a copy of a given page exist in some unpublished/draft state, until the requirements are met. Once the requirements are met, it can replace the published page. Until versioning is built in, making this happen is overly complex. So until that happens, any required field support will likely just be symbolic required field support via javascript or PW error messages. People will still want to code their templates to account for empty value situations, even on required fields. That's the primary reason why the 'required' option is hidden in advanced mode, because I don't want to imply that you can always expect some field to always be populated. Another scenario that not even versioning can fix: lets say you have a site with a bunch of active pages in it. You add a new field to a heavily used template and make it 'required'. All the existing pages will have an empty required field. It's a tricky situation. The expectation of required fields seems to open more potential for site-breaking situations. Better to code things as if required fields didn't exist.

I've been offline for the weekend since Friday, sorry to be stepping into the conversation late. I'll be happy to implement an unset function for url segments, but wondered if it should just unset, or should it also reindex the url segments that are remaining? For instance, if you have both urlSegment1 and urlSegment2 set, and you unset urlSegment1 should urlSegment2 take the place of urlSegment1?

$_SERVER['REQUEST_URI'] isn't filtered, at least I don't think it is. Just trying to protect against any possible request injection into the logs.

Also you can always change the parent from the settings tab of any page.

We use PHP built in JSON functions for speed and efficiency. PHP 5.4 adds two new options to json_encode for unescaped UTF8 and "pretty in print", so I think PHP 5.4 will solve this and I will implement a version check so PW takes advantage of it.