ryan

Yeah, I think you are right. I'm going to change this.

Sent, let me know if you don't get it. Any more? PM me if you don't feel like pasting your email address here.

Wow, not cheap. Where did you find that? I'm guessing a child's car seat won't fit so well in their either.

I haven't yet really figured out Google+ yet, but I have figured out how to do invites so if anyone isn't already on it just let me know if I can send you an invite.

Lots of good ideas here and lots to consider. I'm trying to figure out if some of these things should be built-in, or if we should make the image capabilities as pluggable as possible, or if we should have a couple of different types of image fields (or more likely, a little of each). It's true that the in-CMS image scaling may not make much sense if you are already scaling the images in the API. But we also can't assume that's the way everyone is using it. I tend to think that interactive scaling will be applicable in some instances. Perhaps it's something a checkbox can enable/disable in the image's field settings. No doubt, cropping is definitely more useful to the way that most use PW. Antti's got a point in that there may be a need to have the smaller version visually cropped but not the larger version. For instance, this site: http://directory.pewscholars.org/years/2011/ On that site', we've got these little square thumbnails of people that all have to be the same dimensions vertically and horizontally. But if you click to their bio, the photo is only constrained horizontally. When I initially uploaded the photos, some people's heads were getting chopped, so I had to do some manual cropping and Photoshop and re-upload for a few of them. But of course, that meant that I had to take something away from their full-size photo for the needs of the thumbnail. It wasn't a problem in this case, but certainly it would have been preferable to be able to manipulate my thumbnail separately and not have to crop my full-size photos. Thinking of another instance, I was working on a site where we had the thumbnail, which led to a portfolio page of "medium" size photos, which in turn led to the full size photos. So if there is an $image->thumbnail, why not an $image->medium too? Once starting down this path of image variations, it's a little hard to predict what the exact need will be. So one option would be to take $image->thumbnail even a little further and provide for definable image variations in the image field's settings. Perhaps you call one of them "thumbnail" and another "toenail", but it's left up to the user what they want to define with a given image field. It would be a little tricky to implement, but it would be useful and only add the additional functionality for those that specifically wanted it. Another option related to the $image->thumbnail idea is to instead have an $image->original. This is Antti's idea, but maintains an original rather than a thumbnail. By default $image->original would just point to itself. But if you cropped or resized your image at any time, then $image->original would be populated with the original unmodified version. There's no assumption about what it would be used for. Though PW would use it internally so you could interactively scale up or re-crop an image from the original (rather than going through a new JPG compression for every modification). Basically it would just "be there" in the background if you wanted it. The $image you see in your field would be the one you cropped (so the person's head doesn't get cut off). Most folks might not even know PW is keeping a copy of the original (minus a little 'view original' link)... so there's no perception of additional complexity. From the API perspective, if I wanted to produce a list of 100x100 thumbnails and link to the original unmodified version you'd do it like this: <?php foreach($page->images as $image) { $thumb = $image->size(100, 100); echo "<a href='{$image->original->url}'><img src='{$thumb->url}' /></a>"; } If an image had never been cropped, then of course $image->original would be the same thing as $image... no need for performing additional checks in your API code. Both $image->thumbnail or $image->original could have solved the examples I mentioned above. The main difference is that $image->original would be used by PW internally (so it can scale/crop from the source rather than copies), and there would only be one image to interact with from the admin side (like currently).

PW updates the last modified date if you call $page->save() or $pages->save($page) -- those two commands functionally identical. But if you save just one field from a page, like $page->save('body'), it doesn't update the last modified date or anything in the pages table. It only updates the 'field_body' table. Perhaps it makes sense for it to update the pages table too (something to talk about more), but the thought behind the current behavior is this: if you are just saving an individual field, you are likely doing so to limit overhead as much as possible. As a result, PW doesn't considers that a field save, not a page save. I don't think that there would be much overhead in updating the modified date, so it's something to consider. I'm not sure how you are seeing it modify the modified_user because the query that updates that is the same one that updates the modified date, and it doesn't get executed when you just save a field (2.1). For a page save, the last modified user has to correspond go a user in the system. So if you want to show the user as "api" as the last modified user, then you'd have to add a user called "api" and set it to be the current user before you save your pages (full page saves), like this: Wire::setFuel('user', $users->get('api'));

If your dev environment is running in a different path than your web site, then you are right this will be a problem. It's the case for me, as I have everything running off of paths on my dev server, but the web sites ultimately run off the web root. This module solves that problem for everything from asset links to page links and even moved pages: http://processwire.com/talk/index.php/topic,280.0.html 90% of the time, this is probably going to be a TinyMCE specific issue, so I should probably just build some basic root URL abstraction right in the TinyMCE module...

It's not a car or a motorcycle... it's a monotracer. Did a little more research about these "monotracers", and sounds like they are made in Switzerland and built around some BMW motorcycle parts. http://monotracer.com/ http://monotracer.peraves.ch/ http://peraves.wordpress.com/ So far I can't figure out how much they cost or where/if you can even buy one. They also have the eTracer, which is an all-electric version.

Great suggestions from everyone. I've also played around with jCrop in the past and thought we would eventually implement cropping in PW using this or another tool. But will implement it at the API level first (since we need it at that level before we can build a front-end). PW already supports center cropping (by resizing just one dimension) in addition to regular resizing, but doesn't yet support coordinate cropping. I suppose coordinate cropping at the API level isn't that useful since it requires making a visual judgement… but we'll have it anyway. Forget about TinyMCE for the moment. The existing plan was that image fields (FieldtypeImage) would get an "edit" link for each image. That "edit" link would open ProcessPageImageEdit in a modal window. This is the same image edit screen that you see after selecting an image in TinyMCE. We would add the cropping functionality here (with jCrop or otherwise). You would be making edits to the original image. So any resizes and crops you made would be committed to the image once you hit "save". Though perhaps you'd also have the option to "save a copy" if your field supported more than 1 image. Now back to TinyMCE. It would work the same way, only it's going to work off copies of the original image, given that it's only "borrowing" images from another field. That's how it already works (with resizes), but just restating it to say that it'll continue to work this way with crops. Btw, great examples Antti! Finally, just for fun… here's a screenshot from Dictator CMS (what came before ProcessWire). It had a little bit more advanced image manipulation functions that PW2 does, so far. And please disregard the name and branding for Dictator (made in 2003). That dude in the logo is apparently Kim Il-sung (North Korean Dictator, statue)... I was young and didn't know any better (it was supposed to be a concert conductor). Needless to say, after a friend informed me of this, Dictator was re-branded as ProcessWire. Though Dictator's code is long gone (none of it is in PW2).

Thanks for the report, I will try to duplicate and fix here. Regarding the duplicate pages: PW doesn't support multiple copies of the same page in the same list, primarily because the underlying <select> that these widgets are progressively enhancing doesn't support that. Though perhaps we'll find a way around that at some point.

I didn't use a password field on the installer just because I wanted them to be sure they had typed it in correctly. After all, if you type it in wrong here you won't ever be able to login to your PW admin. So I wanted to make sure they could see what they were typing (at least, I like to). But perhaps a better solution would be to just make them type it twice (2 password fields).

Translating data from one source to another can always be tedious and complicated. But at least the PW side of it is relatively easy. More advanced importers have to create and populate page references or handle mirroring of existing data in addition to importing of new data. I've built more of these than I can count, so glad to post examples or pass along any info I can anytime somebody needs to do something similar.

It's okay, I don't like jQuery UI CSS framework that much either, but it gets the job done. But I do like jQuery UI, so it's a necessary evil. I figured it would be better to embrace it rather than compete with it by introducing multiple frameworks.

Thanks, that's good to know. Currently, since user names are page names, they are bound by the same rules, so that means that user names can contain these characters: a-z 0-9 dash "-" period "." underscore "_" If it's a straightforward matter to add uppercase letters to that in the future too, we'll certainly do it. Also wanted to mention that the characters above are just for the login name itself. You can add other fields to the 'user' template to support any other data you want to store… In your case, I'm thinking you might want to add a 'display_name' field or something like that. If you wanted to, you could even construct your site's front-end login to disregard PW's login name completely (though you'd still have to set it to something behind the scenes, perhaps to the user's ID number).

Actually I've been meaning to set this up for awhile, but finally got a few minutes to do it yesterday and didn't want to start it out blank.

It's called the jQuery UI CSS framework. http://jqueryui.com/docs/Theming/API This is what PW uses, though it also introduces a few of it's own things on top of that (though not much).

Looks good, thanks for posting!

This is something I just don't have much knowledge on. I've never maintained a user account on any site that was anything but lowercase, so the thought just never came up. What do other systems do in this regard? Are U&LC usernames common, or is lowercase fairly standard?

While the data import may be the hardest part of this, it's probably also going to be a lot simpler than you think. If you can get the data you need to import into some standard format (like CSV, JSON, XML, etc.) then you'll have no problem getting it into PW. Here's a really simple example of importing a CSV that has has fields for 'title' and 'body': <?php $fp = fopen("data.csv", "r"); $parent = $pages->get("/path/to/parent/"); $template = $templates->get("some-template"); while(($data = fgetcsv($fp)) !== false) { $page = new Page(); $page->parent = $parent; $page->template = $template; $page->title = $data[0]; $page->name = $data[0]; $page->body = $data[1]; $page->save(); } When the time comes, just post some details about what you are doing and we can get you started.

Looks like a good upload solution, I like where you are going with this. I'm usually not 100% up-to-date with jQuery just because it's never seemed that beneficial. So I typically upgrade it when some time has passed or when an need comes up for a new version (like this). I'm certainly happy to upgrade PW 2.1 to use the newer versions if you need it, just let me know.

Spotted this on my evening walk up to the town square so snapped a few photos. Later I saw it drive off, and those middle wheels folded up into the body of the vehicle kind of like airplane landing gear. Anyone else ever seen one of these?

Pete, that sounds like a cool site to develop in PW. I've always heard good things about MODx, though have never developed a site in it. It would be good to hear about the differences if you pursue this project sometime in the future.

Thanks Pete, that's very kind of you. This is still a pretty new project so there's plenty we haven't thought of yet too. We are all full time web designers and developers here, and I think we get a lot of good collaboration and thinking going on in these forums.

I've thought that we should eventually provide 2 views for the images. A thumbnail grid view (with just the photos), and the current view. The thumbnail grid view would horizontally stack as many per row as the interface width would allow, and you wouldn't see the description field. Since this isn't yet an option, I recommend putting a FieldsetTab field around your images field, and give it the label "Images". That way, in your page editor, our images will be on their own tab and you won't have to do all the scrolling when making other edits. Another option is to set your images field to be "always collapsed" when configuring it. Many of the sites that I work on have 50+ images on a given page, and have found that utilizing the tab makes it pretty manageable. Edit: I also meant to add that you would be able to switch between the two views (in JS) just by clicking one of two icons at the top: # or = (if you can imagine those are icons and the first looks like a grid and the second looks like rows).

This looks awesome! Well done. This looks very fun to use. I really like what you are doing with this module.