apeisa

I think you have it already: $page->pagefield_radios->title; or $cat = $page->pagefield_radios; $cat->title;

Played more with Aloha: Since Aloha makes only one instance for multiple editables (which is great for performance), it makes this harder to implement. We need to strip functionality based on what kind of field is edited (textarea or just text). We don't want to allow adding headers inside of header etc. There probably are methods on Aloha API that let us do that. If not, then we have to live with it or just use very bare bones version of Aloha (inline elements only). Editing feels very fast and natural. Now I want to also drop images to the website I already implemented this to play nicely with AdminBar - it adds new button to Adminbar, if you have it installed (Quick Edit). And after you start editing content, there appears second new button: "Save Aloha" which gives you a nice little alert with all the editable content.

Ryan, I took your code and started taking it further. It is very good start and not much to do really. I have Aloha editor floating around my content already and I am starting to implement the saving. Is there any easy way to get that id='fieldname' to textformatter? So does the textformatter know what is the field name that uses it? Fieldname is something that I wanna know, when I save the edited content, isn't it? PS: testing this made me think that there probably will be some issues using Aloha on front and TinyMCE on the back. Not sure though? If they both provide clean enough output, then it will work. Need to test this well after this is ready. PPS: http://drupal.org/node/1018352 (it seems to be much harder to implement on drupal - not a surprise though, but interesting read)

I didn't realize that there are json responses already, that is great. What you suggested looks great! For some reason this ajax fileupload is not recognized as ajax request (I always get normal response). That is probably this is XMLHttpRequest Level 2 (http://www.w3.org/TR/XMLHttpRequest2/) or then I am just missing headers. I will study this after I get back to code. Sending additional headers with jQuery: http://api.jquery.com/jQuery.ajax/ Ajax() supports it, not sure about Post() (probably not). But that probably isn't necessary other than in file uploads (which cannot be send with regular js post). I don't see any benefits using headers instead of post in normal use. Deprecated fileName - I will look into it and change to more modern way to do it to keep it working in future also.

There is modified date already.

Looking at the issues list it seems that next week might be the week that official 2.1 is released? I think that we need to solve the few issues left with file uploads and on issues list there is no "showstopper" issues left imo (many are "minor usability improvements").

I have actually had similar need in almost every site. If you use date field to manage "when it is published", then you have to be very careful with each of your selectors (so that ie: you don't show unpublished stuff on your "latest edited pages on whole site" list or something). It feels like pretty generic need to be able to say something like "hidden from all search and lists when current date < publish_date", It would be great to be shown as hidden also on pagelists. Of course it would be pretty simple cron module to check that and publish pages when publish date has passed, but not the most elegant way of handling this?

Very nice looking site, congratulations! I liked your previous showcase also (this: http://smd.net.au/work/walkerabercrombie/). UPDATE: Very nice touch with your logo on project case pages. Love how it fades to background and gives all attention to the project.

Sevarf: current situation is little bit messy. This should work in 2.1: https://github.com/apeisa/AdminBar/tree/AdminBarNew and the master branch in 2.0. If you are using the "AdminBarNew" and 2.1 then there are some new issues.

Heh, that was just me being stupid. That is something I send on FieldtypeFile.js, adn you were trying to get that working on all places (not just inputfield file), so sorry about that. We can forget it Great news that you got it working! I agree that we need some kind of error handling. Probably best would be if you get it easily to return small json snippet, something like this. { "status": "ok", "filename": "filename.jpg" } or { "status": "error", "errormsg": "file was corrupted" }

Good catch! Probably should update to latest commit when developing for the core

Current dev version of AdminBar gives a nasty js alert on IE9 (not sure about earlier ones): "Load jQuery first!". It happens occasionally when clicking "Edit page" link. Not everytime, but about 50% of times. It comes from tiny_mce.js file. I changed that part from: return alert("Load jQuery first!"); to return false; and everything seems to be running smoothly. I assume that jQuery is needed for those link & image modals? If so, then silent fail here should be ok, since it won't take long that jQuery gets loaded (those works in my tests even when I get the alert). IE9 seems to have many bugs related to how it loads javascript files, and this is probably just one of those. Whatever the reason is, it seems that occasionally in IE9 and using Adminbar, tinymce gets loaded before jQuery. In the other news: for some reason removing pages from AdminBar works now (I haven't done anything, and it didn't work in 2.0). It redirects to /processwire/ after deleting (I think that is good solution here).

Ok, now that files are flying like flies (heh heh), I think I will focus to next version of AdminBar, but will also try to implement Aloha Editor module. I will start from Ryan's code and concept above. Idea is that Aloha Editor would play nice with or without AdminBar. If you have AB installed, then it would use the same UI.

I think that latter might be better. I think that Themeroller and UI theme should be used as is - it should be vanilla and no reason to edit or add to those files ever. But to use more classes and styles that compliment jQuery UI sounds good to me. What comes to this drag & drop upload, UI was pretty much all that needed. Ok, the default hover state (pink) is little wild on big field area, but at least you notice it New "UI compatible" version available below: I tried this on my "clean admin" theme and it works nicely. Also this is 100% compatible with AdminBar (at least the latest version). InputfieldFile.zip

That is planned. See the adminbar topic (on mobile now, would link otherwise). EDIT: http://processwire.com/talk/index.php/topic,56.msg1988.html#msg1988

Ryan, thanks for your feedback and nice words. I haven't really thought about css clashes (and classes) here at all - although it might feel so since it uses jQuery UI progressbar, but that was the last thing that got added there So most of the classes and css are just quick ones I added to test things out. Will definitely try to make those use as much as jQuery UI as possible. I agree that it would be perfect to have zero colors coming from module & admin css - there are quite a bit currently around. It might be that some are needed because jQuery UI is not for everything (or is it? I don't know.), but I agree that we should keep that at minimum. Or at least use different shades of gray if some coloring is needed. "undefined" or undefined - I think there are few ways of checking undefined in if clause: (antti === undefined) or (typeof antti == "undefined") and I have read somewhere (can't even remember) that latter is the safest (works everywhere). Not on solid ground here, so please keep me corrected if I am wrong. It has never let me down though On posting to ./ insted of ./fields - You might wanna check if $_SERVER['HTTP_X_FIELDNAME'] returns something. Well, there are plenty of ways of course and you will know the best one. I will take a look at the jQuery Theming API and look for the best UI classes here. It worked without too much problem in progressbars, so shouldn't be a problem here. Also agree with having "ugly but unique" classes, will def. help people who are building own admin themes (like myself).

Pete, great idea and will def. implement that at some point. I also thought about cropping, but decided that it breaks the uploading flow badly. Might also use cropped images to show preview of the images (that might be the reason that preview slowed the site down because they were huge images just scaled down in css). I think that cropping would be best handled after uploading, in modal view that opens when you click the filename.

Great stuff Soma, I will update my code once I get home.

This has been causing issues on Soma's site and localhost. We did little debug session, and it seems that for some reason this: $this->page->filesManager->path returns nothing. So it tries to write the file to root and that gives (of course) permission issues: <b>Warning</b>: file_put_contents(/Koala.jpg) [<a href='function.file-put-contents'>function.file-put-contents</a>]: failed to open stream: Permission denied in <b>/path/to/pw/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module</b> on line <b>933</b> We continue testing and report if $this->page->$fieldname->path works there. But I am confused what might cause $this->page->filesManager->path to fail on Soma's server and localhost? He is using latest version of P21. EDIT: This code works: $this->page->$fieldname->path . "/" . $filename, One issue left: it saves files with the name it is saved (of course), like: Lighthouse.jpg, but on admin site it tries to get it with small first letter: getimagesize(/path/to/site/assets/files/1003/lighthouse.jpg) => this causes error. This seems to be something that will not be issue after ProcessPageEdit.module will use the wireupload class?

It might be a trap. I call my lawyer now.

Don't count on me on this one, I have very little knowledge on what comes to software licences. Ryan hasn't sued me yet, so I think that is pretty safe to remove the logo

Ok, few small improvements: No more "drop area", just throw your files to the field and that's it (I did leave small "or drop your files here" notification, so that people will know the possibility) Added 5-99% percentages to progressbar Cleaned and credited the code. Not sure where I should thank the guys (Robert Nyman and Craig Buckler) who provided initial code examples and tutorials, so I putted in to the comments with links. EDIT: Added ProcessPageEdit.module to attachment, since if someone tests this from zip only it won't save the files... InputfieldFile.zip ProcessPageEdit.module

Oh, and back to the topic! Site looks good scarota. I remember you gave us preview on this earlier? Pretty big site and lot's of different areas (and very little usual "content pages"), so I think that building that with pw must have been nice ride? EDIT: Oh and I somehow missed your client's AdminBar praise on first post. Glad to hear that. Will make sure that new version for 2.1 will be even better

I think that there are many very good concepts in html5 boilerplate and I use that as a reference, but would never use that as my default as is (that is not probably even a preferred way, though I am not sure). Feel like there is too much of everything, and rather than "building" my start, I would start it by cleaning all the stuff that I don't need. I have never had use for modernizr.js, I don't always use jQuery, I very rarely need IE hacks or styles, I don't always have google analytics, I don't always have javascript files included, no need to support chrome frame (IE6 < 1% in Finland) etc... So for me most of my projects would use just 5% or 10% what boilerplate provides. So I do keep my eye on that project and think that there are many very good tips and practices there, but would only use parts that I really need and understand what they are for.

It's a bug. That "parent template" setting is new stuff. Everyone should have right to have "trash" as a parent...