apeisa

I think Adam is right here. I would try this: change addHookAfter -> addHookBefore and remove $page->save (shouldn't be needed since you modify values before actual save. Not sure though.

Glad you like it! That is the way how everyone feels about first. First it just feels stupid and wrong to use pages like that. Of course because we are so used to what "page" means in cms. But processwire's power and simplicity comes from simple fact that almost everything are pages. Now that I have developed little more with processwire, I am amazed how quickly I can do things... and the reason for this is that.. well, everything are pages I loop and find everything using same API. Even users, permissions and roles are pages (in 2.1) so you can extend (well, you probably want to extend only users) and use those just the same way than everything else. Another thing that I suggest learning (or probably that you will learn pretty quickly just by developing with pw) are WireArrays. You will be glad to realize how great tools you have in hands every time you need those.

"Type" is not reserved word, I tested before I posted (I thought that it is myself too) Thanks for this. I noticed that this is probably possible when I was checking API, but never used it that way - so I didn't dare to post it. Damn you have coded brilliant software Ryan!

Oh, I forget to write how you can use these selections in your templates. Let's assume that you gave your page field name "type". So this is how you get all pages that have checked "Developer" from them: <?php // We need to get "developer" page first $developer = $pages->find("parent=/type/, name=developer"); // Next we find all pages that have type field with developer checked (we use $developer page from last line here): $dev_pages = $pages->find("type=$developer"); // Let's loop pages and echo title and all types they have: foreach($dev_pages as $p) { echo "<h2>$p->title</h2>"; foreach ($p->type as $type) { echo "<p>$type->title</p>"; } } or if you just want to check if current page has Publisher checked: <?php $publisher = $pages->find("parent=/type/, name=publisher"); if($page->type->has($publisher)) { echo "Publisher"; }

Pete, this is possible and will show you one of the most powerful features of processwire. Doing this first time feels little strange, but soon you will see how convenient and flexible this is. You can achieve this with "Page" field. First you create page called "Type". This is just a container page and might be something you do not want to be accessible for public (maybe only for superadmins?). Sometimes you want to keep these under some other page, so url would be /tools/type/ or /settings/type/ etc. Under that page you create all your selections as pages. Developer, Publisher and Current Rights Holder would all be pages under "Type" page. It works with any template, but I usually have one "referencepage" template for pages that contain only title field. You might also create template called "type" (you might wanna add more details for type, like small description or icon.. anything). Now that you have your pages somewhere, it is time to create page field. Page field allows you to create one-to-many or many-to-many relationship between your pages. Add new field, and choose "Page" as a type. Then you just choose that "Parent of selectable page(s)" is your /type/ page (or /tools/type/ or wherever you put it). Alternatively you could choose "Template of selectable page(s)" if you have dedicated template for wanted selections. And finally you can select "Input field type" where you find "Checkboxes" or "SelectMultiple". There is also asmSelect which is custom field that pw uses a lot internally. It also allows multiple selections. This might seem like a lot of work or complicated, but once you do this and realize all the superpowers that it brings, you'll never look back PS: If you already knew this all and you were just looking for quicker alternative, then I'll keep my answer as a future reference.

Nothing from Switzerland is cheap Found this article (in Finnish): http://www.hilavitkutin.com/2008/04/14/monotracer-on-futuristinen-katettu-moottoripyora/ Article is written in 2008 and says that you can order one for yourself for Christmas 2008. It's not a concept design, real product manufactured in factory lines. Price 52 500 euros is without taxes. So in Finland that would be much more expensive. From some other article (or youtube comment...) I found that there are only 400 of those around.

Image resizing is done only on first page load, so it affects very little for overall user experience. PW always first checks if there is already required image on right size and resizes only if image is missing. You can actually do very nice resizing already: http://villarental.com/villas/presidio-del-mar/ (new site developed by Ryan). I have nothing against defining various image sizes. It is pretty much same than one of the ideas that Ryan mentioned in his long reply. Presetting different images, like thumbnail, medium etc... That would require much more work in UI (cropping for each variation? preview?) and also require more coding on field setting (although using JSON would be possible shortcut here). That would be very powerful solution, no doubt. Although I believe that over 90% of sites doesn't require more than one cropping variation of each image (sizes and center cropping are well supported already). If multiple sizes are possible with clear and well working solution, I am all for it.

Soma: good idea, but that is pretty much supported already. You can do those resizes on the fly in your templates. What we are trying to achieve now is to have visual cropping tool without messing with UI and api too much.

Sounds good. Overall pw image manipulation is in good shape. This is something that is sometimes a real timesaver, but never a showstopper. English only admin is a showstopper for many.

Hmm... I am running fresh 2.1. on my localhost and I couldn't produce this error. I have only adminbar installed, no other modules.

Ryan: I like your $image->original idea much better. It's also much clearer on UI side: you edit the image, but you can always "undo" back to the original. I also like your idea about adding multiple variations of single image ($image->thumbnail, $image->medium etc)... but after thinking that a while it is probably something that very few sites would need and would require lots of code and documentation. I think core solution here should be simpler (like the $image->original is).

True. That would be useful all around. If I remember correctly there is no way to say which fields are required at all. This could be great option on many fields, not just this one. I remember Ryan mentioned something about this, but not sure what was it?

Hmm...? please re-read my previous post. For UI wise that wouldn't require anything but "crop thumbnail" link or icon (which could open cropping view in modal or inline - whichever works best). For your 300+ galleries that wouldn't require anything at all. All would work just like before. There is no additional fields, just a new "feature" for current image field. And that feature is $image->thumbnail. If you would like using cropped images in some of your templates, you would just replace your $image->size(xxx,yyy) to $image->thumbnail->size(xxx,yyy). In API - I don't think that it cannot be much cleaner. Not even a single new method. If you did read my last reply with thought, could you describe more which makes that such a horribly complicated? PS: It might be, that I did explain my idea in horribly complicated manner, but I really cannot think easier way to do this. At least for now, let's see about tomorrow

I agree. But what I see beneficial would be to have cropping tool for thumbnails in admin. In templates you really don't know how to crop, since you cannot see the images. So center crop works there nicely for 90% of images (and it would be really really rare situation that you would use some other cropping there - unless it is some "wise" cropping which tries to analyze images). Portrait pictures of people are problematic for center cropping, lots of head dropping there To have cropping tool for thumbnails would require that each image could contain another image also ($image->thumbnail). So there would be original (full size image that was uploaded) and then thumbnail image. In templates you could use your images like this: <?php echo "<a href='$image->url'><img src='$image->thumbnail->url' alt='$image->description' /></a>"; If there isn't any cropping done, then it $image->thumbnail would be just a regular center cropped image (size would be how it is defined on field settings). Since thumbnails are also just regular images, you could resize those too in your templates. So you could set your thumbnail size to be "fullsize" and you could just crop those however you want on admin. That would allow you to easily fix poorly cropped images. See this snippet compared to above one: <?php $thumb = $image->thumbnail->size(100,100); // If resizing gives bad result, you can crop in admin and wow, it looks good! echo "<a href='$image->url'><img src='$thumb->url' alt='$image->description' /></a>"; What do you guys think? I'm not sure if I follow you here, but isn't this same issue that Pete asked in first message and I answered in first reply? There is already Max dimensions image field setting (in 2.1 at least) which resizes images right after upload. Our current cms has this, and from our 200+ clients I know only one who uses this and end results they have is horrible I think that could be cool in some projects, but should be separate module.

About 50k euros.

While there is no way to mirror images from another image field to other (and not sure if that would be good feature), there is nothing to stop you from creating centralized image area or using any image on any page of your website (without using wysiwyg editor). You can easily do this on template level (pull images from another pages). Let's say you have page /images/ which is your centralized image area. Below that you have galleries, like /images/summer-2011/ and /images/record-covers/ etc... Template type "gallery" have few fields, like "title", "author" (page reference), "tags" (page reference) and "images" (image field). Now in your templates you can pull those images in various ways: 5 galleries, with thumbnail links to real gallery pages: <?php $galleries = $pages->find("template=gallery, limit=5"); //Default sort, so newest is how it's sorted on backend foreach($galleries as $gallery) { $thumb = $gallery->images->eq(0)->size(100,100); //This creates 100x100 thumbnail, crops to center - no better way for cropping yet echo "<a href='$gallery->url'><img src='$thumb->url' alt='$thumb->description' /></a>"; } All galleries with tag "summer": <?php // First we need tag page "summer" $summer = $pages->find("template=tag, name=summer"); $galleries = $pages->find("template=gallery, tags=$summer"); foreach($galleries as $gallery) { ... } All galleries from user "martin" <?php $martin = $pages->find("template=user, name=martin"); $galleries = $pages->find("template=gallery, user=$martin"); foreach($galleries as $gallery) { ... } I'm not sure if these examples are anything what you were looking for? But through API you have very popular tools for managing and displaying your images in different templates. What I would love also would be nice little cropping tool. Not so simple issue though, probably needs some "default thumbnail" for image fields. EDIT: As I was writing this post, Almonk wrote his about these cropped images.

Same here. I get same kind of feeling now while developing websites than I got when building my team on JA, building transportation network in Transport Tycoon or developing new technologies in X-COM. But big difference is in what comes after I have played: websites are something real, that is there for other people to use and enjoy. Computer games just sucked my time But most bizarre feeling is that I sometimes feel bad that I don't play games anymore... like not keeping touch with an old friend PS: I do not play a lot of games, but I tried Terraria about a week ago. I played 14 hours straight with my friend. I will not touch that game anymore though

Ah, ok. That is nice. Although I always have images in other tab so that would be very hard to do in practice.

Shhhh. Don't let Adam know that he is the only one who said that one is a car.

I think that double password fields would be little better, minor issue though (although password value stored to firefox autocomplete is a bit stressing..). If not, at least mention that it will be displayed (you might want to use some common password if you creating test installation and there might be coworkers or some other people watching over shoulder). Although same issue would be on db password and I think it is easier (and of course faster since only one input required) when you really see what you have typed. About usernames: I agree with Adam here. I don't think that there is need for having more complicated usernames, since extending user profiles is super easy. So I would accept "aPeisa" and just convert it to "apeisa" everytime user logs in or creates new users.

I didn't. And I tried dragging and dropping like a madman and couldn't get anything done I used chrome, maybe this is something that works on firefox only? Or then I just dragged from wrong place (I tried to drag images from modal)?

Nice site! I used to be huge x-com and Jagged Alliance fan (I'm not much of a gamer anymore..).

Looks like a nice file uploader and uses jQuery UI so would be great match from that point of view. File uploads are definitely one of the areas where processwire needs some loving, so nice to see more interest here! Please ask all the help you need Pete if you start building this one.

I have never looked jQuery UI CSS framework from software side: I have used editor and customized css, but never built any markup that works with jQuery UI CSS. But I agree with you guys: probably no need to re-invent the wheel here. btw: my mockups and early versions are always ugly. Sometimes the leave that way though

Ryan has mentioned that he will develop autocomplete inputfield at some point, though no deadlines for this. Of course if someone has need for it before, all free to build But your another question: getting values from another database. Yes, there is interesting question on how to save those values in pw database. If you are ok to save just the value as text, then you are good to go with text field and create new inputfield for it (which queries your database and offers those in select field or autocomplete). There isn't key + value fieldtype (yet, I have been thinking of building one), so if you need that functionality then you need to create a custom fieldtype also. You can also use multiple fields and pages to store values. If you choose this route, then you have to build little script that imports data from your external database to pw fields. I would probably do this route myself, since it is pretty easy to do and then it's all "native" on processwire side. Quick example: let's say you want to pull tags from another database and then use those exactly same tags in your processwire posts. You create template called tag. It has only one field, title. Then you create page that has those tags as children (ie. /tags/). Now your import script would do the following: Query external database Loop all the values Save all the values as tags, under the /tags/ page If there is already tag with same name, then skip If you want to also remove tags (in case the tag is removed from external db), then it is little bit more complicated (you have to add some flag to all tags, and remove flag if tag is still there => after loop remove tag pages that still have flag on them) If you do remove tags, then you need to remove all relations that is already made to it (probably before you remove tag) After import is working, you just set the page field like you do with any other relation on processwire. There is many different ways to allow this selection (radios, checkbox, select, asmSelect etc), so just choose your favourite. Then you add to that field to templates where you want to use it (since we are talking about tags here, you would probably add your tags-field to your "post" template). Tags was probably bad example for this latter method, since it requires only one field. But if importing something more complicated, like users with multiple attributes (name, phone, email, password etc), then this is actually pretty good method imo. Last point: you probably want to cron your import script. There is LazyCron if you don't want or can't setup real cron: http://processwire.com/talk/index.php/topic,284.0.html