ryan

I wasn't exactly sure how to do this, and if it'll work given that we're using a combo date+time picker, but I need to look into this further as soon as there is time.

This is correct. The admin UI doesn't let you select multiple fields to sort by yet. But your API calls can sort by as many fields a you want. It will use them in the order you specify them in the selector.

Are you sure you've got the latest commit? The Page::$issetHas = true; is what is designed to fix this exact issue. Make sure that you are setting Page::$issetHas = true; (exactly like that) before you initialize Twig. But I'm assuming you've done all this. As a result, the only reason I can think of why you'd get this error is if the page that was checked didn't actually have a 'summary' field in it's template. The error you are getting is from ProcessWire and it's throwing the error because Twig is trying to call a function called $page->summary(); and that function does not exist. So on the surface, it would look to me like Twig tries to call a $page->summary(); function if it finds that $page->summary; is blank. It seems like an unusual behavior... Twig doesn't accept something being blank and instead starts making arbitrary function calls using the property name. Maybe there is a way to turn off that behavior in Twig's config?

More updates to the blog profile at http://processwire.com/blogtest/ Still not done with it, but lots of new tweaks. The biggest one is the addition of Tags, as well as an update to the InputfieldPageAutocomplete (committed today) that makes it work really well for tagging. Now when you are entering something in the autocomplete, if it doesn't match anything you can just hit enter and it adds it as a new page. This is assuming that you've configured the field to support that feature. Anyway, the point of this is that it's a very natural way of adding new pages with autocomplete.

It's not possible at present to give other roles access to the trash. That is an area where access inheritance doesn't exist (since it's an anything-goes bucket 'o trash). It becomes a can of worms when considered in light of access control. Do you really want someone digging in your trash? A couple of alternatives: 1. Consider that /trash/ is just a page with children (albeit a smelly one). But you can just as easily make your own trash page. Rather than deleting pages, ask them to change the parent to your trash page (or drag their page into it). So long as they have access, they should be able to drag stuff in and out of it. If they pages they are dragging into it use templates that inherit access, and you make your trash page not viewable to guest, then any pages dragged into it are essentially removed from the site. 2. It sounds like you might be using trash as an unpublished area. If that's the case, I recommend just using PW's Unpublished status rather than the trash. 3. If you still want to use PW's system trash, you can create a template or module that lets them undelete stuff they've deleted. This isn't complete, but gives the basic idea: $deletedPages = $pages->get('/trash/')->find("modified_users_id=$user, include=all"); if(count($input->post->restore)) { $parent = $pages->get('/some/parent/'); foreach($deletedPages as $p) { if(in_array($p->id, $input->post->restore)) { $p->parent = $parent; $p->save(); echo "<li>Restored: {$p->url}</li>"; } } } // display list of their deleted pages and give them a 'restore' checkbox foreach($deletedPages as $p) { echo "<li><label><input type='checkbox' name='restore[]' value='{$p->id}' /> {$p->title}</label></li>"; }

Your example looks okay to me, and it should work. Try these to see if any fix the problem: 1. Try dragging your /blog/ to be a child of some other page, and then drag it back out to root. That should force a rebuild of the pages_parents index, used by the particular find() function you are calling. If there was a problem in the index, this would resolve it. 2. Try adding "include=all" to your selector, just in case the pages that aren't showing up are unpublished or hidden. Though for your production version, you probably don't want "include=all", but it's a good test for now. 3. Rather than $pages->get("/blog/")->find(...), try it without the get("/blog/'). That part is adding a little overhead, so if you aren't going to find pages using template blog-post outside of /blog/, then there's no reason to have that /blog/ filter there. So try changing it to this: $pages->find("template=blog-post, sort=-publish_date, limit=10"); 4. Are you certain that template blog-post has a field called publish_date and that it is a date field (not a text field)? And do all the pages in question have this field populated? Let me know if none of these fix it, or if #3 fixes it. If #3 works while the alternative doesn't, then I'd want to do a little testing here to make sure it's not a bug in PW's Page::find() function.

We also have an API function for this: $total = $pages->count("selector"); It basically works the same as @apeisa's example and is fast/low overhead.

Porl, yesterday I put in a commit that enables you to modify the behavior of the Page::__isset() function. For the PageTwig module, you are going to want to put this in your __construct() or init() method: Page::$issetHas = true; More info in the commit notes: https://github.com/ryancramerdesign/ProcessWire/commit/40ccfe2a05772f51a97c8a58e2c8721dfc0b51dd Thanks, Ryan

I think this is correct, that it really just depends the way you are used to working with images. For the sites I build, if I ask for an image of a specific size, it's because that's the size I need. I don't care what it has to do to get there, because the needs of my layout are more important than the image itself. An image of any size other than what I asked for would be inconsistent at best or a layout breaker at worst. I'm usually dealing with lots of images that I depend on being consistent with each other in size. I hate upscaling, but I hate inconsistency even more. If something has to be upscaled then I'm going to notice that and try to find a better image, but at least the damage is limited to the image rather than the layout or consistency. Here's another way to accomplish it. Put this somewhere in one of your first template includes: function sizeDown(HookEvent $event) { $width = (int) $event->arguments[0]; $height = (int) $event->arguments[1]; $image = $event->object; if($image->width < $width) $width = $image->width; if($image->height < $height) $height = $image->height; $event->return = $image->size($width, $height); } $wire->addHook('Pageimage::sizeDown', null, 'sizeDown'); Now you can substitute any $image->size() call with $image->sizeDown(): $image = $page->image->sizeDown(300, 200);

This makes sense, thanks for the great explanation. I will pull this in to the ImageSizer class to have it check both extension and type.

I was questioning this too, but couldn't decide what the headline should be? "Main" or "Top" or "Navigate!", it all just seems a little cheezy and unnecessary. But it would look good to have something there, just not sure what.

Is it only the repeater fields that don't save, or all the fields? I'm assuming all fields, but let me know if I'm wrong. Because you are doing this outside of ProcessPageEdit, you need to connect the values from your inputfields to the values in your page. Something like this: function formToPage(InputfieldWrapper $form, Page $page) { foreach($form as $inputfield) { $name = $inputfield->attr('name'); if($name && $inputfield->isChanged()) { $page->set($name, $inputfield->attr('value')); } if($inputfield instanceof InputfieldWrapper && count($inputfield->getChildren())) { formToPage($inputfield, $page); // go recursive } } } formToPage($form, $page); $page->save();

That's why it's going to come with defaults already populated and identified. So to be more clear, there will be a title, CSS selector and color picker. The title says what it's for (i.e. "Vertical borders") and the CSS selector targets them. The only thing the typical user will change is the color picker value. If someone wants to take it further and add their own extra repeater items to customize further, that's up to them. But I don't see or expect the non-developers to do that. Also, I fully expect people to make a horrible explosion of colors. Put even a single color picker into the hands of a non-designer and the results won't be pretty. But I'm not responsible for other people's color choices. Honestly, if there aren't a few explosions, then we're not making things configurable enough.

Nobody likes upscaling. But if I call a function asking for it to create something at a certain size, it's because that's the size required. If there are other conditions surrounding that, shouldn't it be left to the caller to decide? i.e. if($image->width > 300) $image = $image->width(300); If not wild about extra arguments (especially booleans) in API functions because they aren't self explanatory in the resulting code. So I'll only use them when absolutely necessary. Whereas, a bit of code like above is self explanatory to us now, and years from now when things like "what does the 3rd argument mean" are no longer fresh on our minds. On the other hand, I've got no problem with self explanatory function names, like widthNoUpscale(), but sometimes adding more makes the API less simple.

You can edit the profile page directly and change the template that it uses. But it would need to be one that's doing the same thing as PW's admin template. A much simpler thing you could do would be to edit the existing /site/templates/admin.php and set it to add some stylesheet or JS to change the look. For instance: /site/templates/admin.php <?php if($page->name == 'profile') $config->styles->add($config->urls->templates . 'styles/profile.css'); require($config->paths->adminTemplates . 'controller.php'); You'd want to have a role called 'employee' that has page-view and profile-edit permissions, and nothing more. They will be able to edit their profile.

Thanks for posting this! The SVN diff looks exactly like the Git ones. This seems like a good method, perhaps even in addition to extension filtering. But one thing I'm wondering is, does it change anything about the result? ImageSizer fails at it's own check rather than at GD's check, but seems like it would still fail. I'm just wondering how this solved the issue of BMP images renamed to JPGs?

At the 960px to 1199px width, we're at our ideal line lengths (12 words per line on center column). Right sidebar is about the same as the one on this site. Do you mean the one that appears in the 768px and 959px (i.e. tablet/iPad view)? I'm thinking about throwing down the right column on this view, but not yet sure. I can make the border color there configurable (vertical vs. horiz) so someone could make it the same as the background color, making it invisible. I'm going to use a repeater for the color configuration. Two fields in there: CSS selector and color picker. Kind of a fun use of a repeater. The admin will remain configurable by it's own themes as it is now.

Thanks for the feedback. All 3 fields are required on comments, as they've always been, so didn't think there was a need to designate required vs. non-required, since they are well, well… required. But I think you may have a sixth sense because I'm adding an optional 'website' field, which brings the required vs. non-required designation into play. So expect to see it before this blog profile is considered final.

I agree, I don't know how you get some much done! I wish that I had your level of productivity.

Repeater fields aren't designed to be used outside of the trusted user context of the admin (at least, not yet). That's not to say it isn't possible, just that it would probably take some time to figure out how, so I don't know how to answer the question yet. Even if you can get it working on the front-end, you have to be concerned about scale. Someone could create some real problems in your site by adding a million repeater items. So you would at least want a max_items option before considering something like this outside of a trusted user environment (and that's something we'll add soon). On the other hand, if you are building your own forms and creating and using repeaters purely from the API, then I think that should be fine. In that context, you can tailor it to the fields you are working with (perhaps not having to worry about things like AJAX saves) and account for the maximum items you will allow, etc. So I think my suggestion would be that if you use repeaters outside of a trusted user context, then create and populate them via the API so that you can lock it down with some hard limits specific to your case.

Thanks for taking the time to do this testing Neil. I look forward to seeing the results and learning any ways we can make it even more secure. I've put a lot of focus and effort into the security of ProcessWire and think (hope!) we will score well. I'm not aware of any others that have run a comprehensive security analysis like you, so am very interested. If you find any concerns you want to review with me before posting, PM me here or email ryan at this domain name. Security is one of my favorite topics when it comes to web apps, so very happy to hear about this.

Here's the new blog profile that's built up from the Skeleton CSS framework: http://processwire.com/blogtest/ As Skeleton doesn't come with any real design elements, it's much more of a blank slate than Foundation. So I put a little design time into this one and the profile is much more custom than the Foundation one. I think it looks a lot better than before. Of course, it could use some color and perhaps icons and imagery, but thought it might be a much better starting point than before. I'm thinking we'll make colors configurable via Soma's color picker Fieldtype/Inputfield. I've also added a 1200px view (something that Skeleton doesn't come with) so that this profile has a nice "wide" view, in addition to a normal desktop, tablet and mobile view. Beyond a change from Foundation to Skeleton, this one also includes a lot of improvements and tweaks to the profile itself. Since this is still a work in progress, I won't post an updated ZIP yet, but just wanted to post this preview to the latest version.

This is something that a lot of us do because it's fun, not because it's something that we have to do. We might make a module so that we can do something like this because it's fun, satisfying, and efficient (plus it looks good) … echo $pages->find('brand=/brands/audi/, mpg>25')->renderCars(); But the reality is that it's also not necessary. You could perhaps more easily just package it into your include file and do this: $cars = $pages->find('brand=/brands/audi/, mpg>25'); include("./render-cars.inc'); And in your render-cars.inc: <?php foreach($cars as $car) { echo "<p>{$car->title}: {$car->mpg} mpg</p>"; } What I'm trying to get across is that much of the things we all create and use modules for is optimization and fun. Perhaps others feel differently, but in my case, most of my sites don't even use any modules other than what comes with PW. I create modules when I want something I can re-use on multiple sites or share more easily with the PW community. Another point about modules is that they are a whole lot simpler than you would ever imagine, once you get going with it. But the lack of ability to create modules is not going to limit your ability to use ProcessWire in any way. You can make it do pretty much anything without having to even know about modules. But when the time comes that you become interested in it, it will only increase your enjoyment of development. So when you see what appears to be complex development conversations about modules and such, don't worry. What you don't know isn't going to hold you back in ProcessWire. It already seems like you have a really good understanding of development and using ProcessWire. Based on your past posts, I feel confident you can push ProcessWire to do what you need when you want to. And we're always here to help with questions and problem solving. If I were you, I would keep using ProcessWire for everything that you are comfortable using it for. When situations come up that you feel can't be as easily solved with ProcessWire, then investigate services like what Pete mentioned (Lemonstand, Shopify, Google, Facebook, Flickr). There are services out there for nearly everything and this is where a lot of functionality is trending. For instance, look at the quality of a comments service like Disqus... it makes you wonder if we aren't far off from the time when built-in comments are no longer considered a required core feature of CMSs. When we had to setup a forum for ProcessWire, I never considered trying to create it myself in PW. Instead, we went with SMF, and then IP.Board. Services like these and others are better than what you can reasonably expect to build on your own, or what you could expect to come with (or be added-on to) any other CMS. Honestly, if you use ProcessWire and then utilize services for the things you don't want to build, then you will be able to do everything you could ever want. And more quickly, more securely and easier to support, than if you were trying to leave it all to a CMS. For the rare cases where you need something that won't be easy to do in PW, and your service options are limited, then bring WordPress into the mix. Not that WordPress can do much on it's own, but it's following is so much bigger than anything else that literally every possible thing has been coded for it. I certainly wouldn't want to use WordPress as my CMS, but I have no qualms about pulling it in when something that I need is available as a WordPress plugin. You aren't going to find any other CMS that has as much 3rd party stuff built for it. WordPress is easy-enough to figure out in a day (from a development perspective) that you also won't find yourself as frustrated as in Drupal (at least, this was my experience). It's not much prettier than Drupal from an output generation perspective, but it will be much more respectful of your time.

You can do it like this to set it to today's date/time: $page->date = time(); Or like this to set a specific date/time, you can use any format that PHP's strtotime() function accepts, like this: $page->date = "2012-06-25 11:36:00";

This definitely sounds like mod_security. When posting a form with a field that has specific tags in it causes a 403, and posting it without them works, then you can be pretty sure that's mod_security coming into play. It sounds like your host has mod_security configured to block <iframe> tags appearing in POST submission values. This doesn't make a lot of sense given that all the embedding sites like YouTube use the iframe tag. I would check with your host and ask them how to disable these mod_security rules so that you can properly use the account.