ryan

I committed a couple small additions this morning: 1. Fieldset indentation in the template editor. Hard to describe, but I needed some way to make the grouping of fieldsets a little easier to see in the asmSelect list in the template editor. Here's a screenshot which describes it better than I can: 2. The InputfieldCheckboxes field now supports columns. This would typically be used if you had a Page reference field using the Checkboxes input. When editing the field, you'll see a new option on the 'input' tab where you can specify a number of columns you want it to use. This is just a way to tighten things up for when you have lots of short-labeled checkboxes (see bottom of screenshot).

Not at present, but definitely interested in doing that for the future. It's just a matter of time/resources and putting it towards the stuff that matters most in the short term. Longer term it would be really nice to have something like this, especially as PW gets used more and more as a framework. I would version control your /site/templates/ and /site/modules/, but not your /site/assets/ as they are tied to DB entries. Though if you combine it with a DB export for each commit, then that would solve it. But this is something we'll have built-in version control for, further down the road.

Thanks Pete, sounds like we should definitely go ahead and add the octits-stream to keep the firefox happy. I will plan to add this. Thanks for your research and testing here.

I think this makes sense, but a little clarification to that message. It's taking about making it non-writable to the web server, not non-writable to you. I don't suggest removing your own write access from any file. But I think you are talking about the situation where Apache runs as the same user as your account, and it makes sense there. I will plan to combine these messages in a manner that fits that situation --good suggestion.

Wow how did you find that fix Pete? Good find! I will add this to the core, but just want to make sure the issue goes beyond one case, just to be on the safe side (?) Unless there's something out there that says this is a safe/expected header for this context. I'm not yet familiar with this octet-stream. Someone correct me if I'm wrong, but I don't think it matters if it's X-FILENAME or X-FILE-NAME. It's just a matter of what we're looking for on the PHP side, i.e. $_SERVER['HTTP_X_FILENAME'] vs $_SERVER['HTTP_X_FILE_NAME'].

Another option (though one I don't use often) is the 'global' checkbox available in the 'advanced' tab of the field editor. (Though I think this one may only be available if $config->advanced is set to true in your /site/config.php). Anyway, once you check that box and save the field, it then requires all your templates to have that field. And it will add it to any templates that don't.

Rob, how about this? # block everything except actual files/dirs that exist # for instance, JS/CSS files used by admin and modules, etc. RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule !^processwire - [F] # block access to root and /index.php file # if running site from subdir, replace '/' with '/subdir/' RewriteCond %{REQUEST_URI} ^(/?$|index.php) RewriteRule !^processwire - [F] Place right after your "RewriteEngine On" line.

Great to hear about the addition of fulltext indexes to InnoDB! Once MySQL 5.6 is more widespread in web hosting, I look forward to testing out and comparing to MyISAM in ProcessWire. Though my understanding is that InnoDB is technically superior in many ways. If that also translates to PW performance equal (or better than) MyISAM, then it would make sense to use that where appropriate and possible. Fulltext indexes really were our own MySQL/MyISAM dependency, so with PostgreSQL, MySQL/InnoDB and even SQLite now offering support, it will be possible to get PW going in more database platforms without too much effort.

That's correct, you should use has($child). The isValidItem() is meant for internal PW type checking. It only validates that the given object is a Page (any Page).

With the new field-template context, you can name it differently with labels and descriptions. But changing the actual 'name' of a field is something you can't do. Though even if we could, I think I might find that a bit confusing. Being able to change the other field settings (beyond label, description, columnWidth, visibility) is actually supported in the core, but I've got the system blocking it right now because I'm worried about side effects here. I figured we'd open this up in advanced mode soon, and then roll it out for everything once we're sure it's not creating major new issues or complexity. But it made my mind hurt just thinking about all the possibilities it could open up (good and bad). So decided to make field-template context contain only known variables to start, and then jump into the rest after marinating a bit.

This is the route that ProcessWire takes with the admin too (you can see it by view source in browser when in PW admin). PHP-powered JS files are definitely cool in the right places. But I worry a little about browser cache issues. You generally want your browser to cache those JS and CSS files. If you are outputting dynamic data with them, you may be preventing the browser from caching them, or battling it over caching them when you don't want it to. There are ways around it (managing cache headers and keeping track of when stuff changes) but it just seems like kind of a pain to me, though I've not done a lot of it.

Sorry for the typo, I've corrected my original post. Thanks for finding it Adam.

I don't know if there is a way to do that, but I also use MAMP here and it only prompts me for the password when I restart apache or reboot. I might do this once a month or so. The password isn't too bothersome if you don't reboot often.

We may have to add a button like that soon. Currently it restores defaults when you set it to the blank/original unset value. But of course that prevents you from overriding a default populated value with an unpopulated one. So currently it's best to leave the default (no context) value blank if you want it to be blank/unset in any alternate template contexts. Luckily, I don't think that's a common situation (at least not here). I'm not sure that I understand? There isn't a foundation for context outside of multiple template/fieldgroups, but maybe I'm not reading this right. Can you give me a more specific example or what you mean?

Actually this sounds familiar now, I think I remember that Safari for some reason does not support drag-drop file uploads. That was awhile ago that I remember talking about this before, and figured they would have fixed it by now. It seems like Apple is not giving much love to Safari lately.

Ray this is fantastic! Thanks so much for writing and sharing this with us. I am setting up a case studies forum as a subforum of showcase (unless you guys think it should go elsewhere?) and will move this there. Thanks again!

Sevarf2, I tried to duplicate this over the weekend, but so far not having luck. My repeater had an datetime field that auto-populated the current date and also had a datepicker on it. I tried saving them, deleting them, etc. I tried this with both setting the "ready pages" number and 0, 1 and 3. I'm wondering if there might be any other factors -- Are there any other fields in your repeater? Are you using the default admin theme or another? And any other modules installed? Thanks, Ryan

It sounds like it really is a Page object then, as it should be. The question then is why PHP is throwing a "not object" error. I'm wondering about the eAccelerator that your phpinfo said is installed. I have a feeling that line 78 isn't really line 78, and that it's line 78 of a cached file or something. I look forward to getting a closer look at the install (per your PM).

To assign the class to your article, like the one in your link (a full page article) you could add the category name to your <body> tag. <body class="<?php if($page->category) echo $page->category->name; ?>"> Then in your CSS file, you would do like what Diogo suggested: body.climate #article em { background-color: #07ABBA; }

You can do that, or you can download the ZIP and replace the /wire/ directory from your installation with the /wire/ directory from the ZIP. When not using git, I usually rename the existing /wire/ dir in my site to /wire.old/ temporarily, just in case I need to revert. Yes, everything should work in Safari. Though I would use Chrome over Safari to avoid the continuous beachballing on every site I visit with it (or maybe that's just my computer).

Pete, I'm still really confused about how that line 78 is throwing a "trying to get property of non-object" error. It really shouldn't matter if it says "single page or boolean false" or "single page or NullPage". Line 78 doesn't deal in that, and it's just a really unusual error. So I'm really curious to know what exactly $page is in that instance. It's apparently non-zero, non-object, which is something that $pages->get() technically shouldn't be able to return. Can you try adding this before line 78? var_dump($page); exit(); And see what it tells you that it is? Btw I don't see anything in your phpinfo that looks like a problem.

This is a good question, and one of the most advanced questions I've ever seen asked here. Here's how to do it. Unfortunately the $field context isn't available to the Pagefile/Pageimage, though the $page context is (accessible as $this->page from a Pagefile/Pageimage object). Given that, we can find the $field context like this: public function init() { $this->addHook('Pageimage::action', $this, 'pageimageAction'); } public function pageimageAction(HookEvent $event) { $field = null; // where we'll keep the field we're looking for $image = $event->object; $page = $image->page; $action = $event->arguments[0]; // find all fields of type FieldtypeImage that are part of the page we're using $imageFields = $page->fields->find('type=FieldtypeImage'); // loop through to find the one we're looking for foreach($imageFields as $imageField) { // good to get unformatted in case it's a single image field, // because it'll still be an array rather than 1 image $pagefiles = $page->getUnformatted($imageField->name); // if the image's pagefiles property matches the one with the // field we're looking at, we have a match. save in $field if($image->pagefiles === $pagefiles) { $field = $imageField; break; } } if($field) { $out = "<ul>" . "<li>Field: {$field->name}</li>" . "<li>Action: $action</li>" . "<li>Filename: {$image->filename}</li>" . "<li>advSetting: {$field->advSetting}</li>" . "</ul>"; $event->return = $out; } } To examine the result, do this: // single image field echo $page->image->action('test'); // multi image field foreach($page->images as $image) { echo $image->action('test'); } I will look closer at adding the $field context to the pageimages/pagefiles/pagefile/pageimage instances in the near future so that it's not necessary to find it yourself like this. But this is the best way to go for now.

Thanks Soma, this is a great module and a recurring need--I think it will be helpful to a lot of people, including myself. Nice work with the good documentation too.

I'm not sure there's enough to go on here to say for sure. Where are you setting the $input->whitelist values? That's probably the same place where you want to build your search selector. Something like this: $selector = 'parent=/products/, '; $name = $sanitizer->pageName($input->get->manufacturer); $man = $pages->get("parent=/manufacturer/, name=$name"); if($man->id) { $input->whitelist('manufacturer', $man->name); $selector .= "manufacturer=$man, "; } list($priceMin, $priceMax) = explode('-', $input->get->price); $priceMin = (int) $priceMin; $priceMax = (int) $priceMax; if(!$priceMax) $priceMax = 99999; // or some other max value $input->whitelist('price', "$priceMin-$priceMax"); $selector .= "price>=$priceMin, price<=$priceMax, "; $selector .= 'limit=25'; $products = $pages->find($selector); if(count($products)) echo $products->render(); else echo "<h2>Sorry no products found</h2>";

Thanks for fixing that Soma, and thanks for finding it Alan.