apeisa

I started working on this and got pretty good start. Multiple selections and drag & drop already works (first thought that as "nice demo" feature, but it feels very nice in use). Next I want to add instant uploads. But that requires some url where js can post those files. What would be best solution here? Probably something like: /processwire/page/upload/?id=5839 (that would only manage ajax file uploads). Ryan, any tips on this? EDIT: I ProcessPageUpload looks like a good and simple solution here, will try that.

Not automatic translation, since that would ruin other than English urls. Can't you replace those before import or saving page? EDIT: Not sure what method you are using for import, but if you do it with API, you can set name different from title (you probably already knew this). <?php $p->title = "Cool & Nice"; $p->name = "cool-and-nice";

Yep. There isn't cropping in file api, but because you can read chosen files with javascript, you can display them, add cropping and do resizing etc before uploading the files.

Yep. Also possible to disallow uploading too big files right there and add cropping to images etc.

Probably, but can't remember. I have used datatables many times, and I have only good to say about that plugin. Rock solid stuff it is! Nice update!

I am working on few nice html5 features (see topic). I started these as a separate module, but soon realized that these are something that are probably always welcome. Or that is what I think at least, how about you guys? It would be easier and probably cleaner result if I just modify the core files in this (with keeping it 100% backwards compatible). I am going with html5 way here, so good support is in Firefox 6+. latest Chrome and upcoming IE10. HTML5 File API looks wonderful and this shouldn't require too much code. Actually there is one liner which makes file fields so much faster to use: $this->setAttribute('multiple', 'multiple'); If you add that to line 32 in your InputfieldFile.module then supported browsers will allow you to choose multiple files at once. It works without any other changes to anywhere. And shouldn't cause any problems for older browsers, since it is just a new attribute in file input field. I'm on very early steps on this, but if Ryan gives a green light and there is no good reason to keep these features out of the core, I will do these right into core InputfieldFile instead of extending that.

No worries, glad you got it working. That is nice little module and got me thinking. Modules page is not only place where lists get very long and would benefit from some more js love. I have used Datatables a lot and I think it would be perfect on many lists that pw has. It has nice filter search, pagination, sorting, it is fast and easy to use. As a little bonus it supports themeroller. Also possible to use with huge datasets with ajax. http://www.datatables.net/ - just that you guys can take a look - don't wanna capture Soma's module topic here

$this->addHookAfter('Process::execute', $this, 'loadJS');

That is something that Ryan showed me and is used in ProcessRedirects: <?php $field = $this->modules->get("InputfieldPageListSelect"); $field->label = 'Select Page to Redirect to'; $field->attr('id+name', 'select_page'); $field->startLabel = "Select Page"; $field->parent_id = 0; // tell it to start from homepage if(strpos($to, '/') === 0) { // if a value is already set, determine if it's a page // if it's a page, then populate the input with the page_id $page = $this->pages->get($to); if($page->id) $field->value = $page->id; } else $page = new NullPage(); $form->add($field); So $field->parent_id tells where to start (root of it) and $field->value holds the selected page id.

Usually they have. And since that works by uploading a file then anyone can add those titles to the file.

Yep, it requires header row: "The list of field names must be provided as the first row in the CSV file. "

Looks great and will definitely come in use! Will test and learn from the code later on.

Nice job Pete and congratulations! Will test this right away. Great to see two new community modules released at the same day! EDIT: Tested and works just like expected! Nice work. EDIT2: Don't know what I meant with "third party" in this context, community modules is what I meant

Ok guys, I consider this ready. Hope you will enjoy, this has been huge timesaver already on my personal project. What I did in last commit: It pulls image title and author from flickr, shows those when it lists images and saves those as image description Changed from tag search to text search (fixed also the bug with spaces) Cleaned the code a little bit on php side (js is and will probably stay messy ) https://github.com/apeisa/InputfieldFlickr I will probably add some kind of disclaimer to the module, as always when you use images that you have not taken yourselves or bought from reliable source, be careful with copyrights. This uses flickr search with licences 1,2,3,4,5,6,7 (when using on non-commercial site) and licences 4,5,6,7 when on commercial usage (what those numbers mean: http://www.flickr.com/services/api/explore/flickr.photos.licenses.getInfo).

Yep, that it was. Now that I rethink it, I actually copied the new .htaccess from the new site I created on subdir to test if it works - and not from the local site that where I should have copied it. And funny thing is that the test site in subdir was most probably build from same version of P21 than the "ghost site" that I removed in first place. So when I overwrote the .htaccess, it was exactly same contents... Thanks for your help Ryan!

Now it works. Not sure about the exact reason, but I think I add notice to myself: make sure the folder where you are transfer your files really is clean...

I think we are getting closer. I did run older version of pw on the same dir some weeks ago. I removed that with winscp and that have most probably left some hidden files like .htaccess. Stupid me didn't check if there was older .htaccess (I just overwrote it with the correct). No change here. Now I jumped to shell and removed with rm -rf the whole dir and started re-transferring now.

1. Only missing favicon.ico 2. Installed just fine and login was successful. Strange. Something must be wrong with my db import/export. I will try that again.

Soma: thanks! Ryan: thanks for your help again, I will implement descriptions and hope to "officially" release this soon.

On my local 5.3.3 and on server it is 5.3.2-1ubuntu4.9

Damn you Ryan. You write code faster than I write English? Seriously, can't thank you enough. Additional module for page based permissions feels like best solution possible. Will test this soon and will give feedback on this.

This sounds excellent, really looking forward to get my hands on and testing.

That is not bad idea. Need for it depends a lot about sales - our customers are trade unions, political parties, charity organisations, student organisations, sports clubs etc... so some of those can have 200 000 members and others just 500. As I said it won't probably get that big in our future projects (or at least that is what we hope ), but if it gets, then that kind of solution is something that we will definitely consider. I think pretty usual request is this: "Can I add new page and select who can view it?". In page based ua I could say: "Yes, you can do it by yourselves". Now the answer for that would be: "you just call us, and we set up new role for you" (under the hood we create new template and role). Sometimes that is better, sometimes worse. For some it is requirement and very much needed feature, for others it is something that they don't need or don't wanna use and ask from us anyway.

Ryan, thank you for your answer. Good questions. In example above (it was a simplified - but BIG - imaginary scenario. Usually they are smaller but much more complex) each association (or sub-association) site is not real website. It might be just one news section. Or small file sharing area. Or private discussion. Also same data (ie. news, events, files etc) are reused on different sections (main editor adds news, checks which associations can see what etc). Also same user can belong to more than one association - so he/she needs to go to different parts of the site. When scenario has been "big, but clear" we have build those as separate sites that our client manages (can add/edit/remove new sites), just like you proposed. But they are usually smaller, but more complex scenarios, with many many more user roles and deep levels of content. If you read my above paragraph again, you see that if those all are in separate sites, you need a secure way to share data between sites, you also need single identity provider with single sign-on solution between sites (ok, our clients has member registry where user data is kept) etc. So many times it is actually more simpler to have one bigger and more complex site than to build many smaller one. But whenever we can take logical part away from the "big site" - we do that. We also courage our client to avoid complex ua scenarios and just be open and share data whenever it is possible. But organisational culture is something that we cannot force overnight - our solutions need to bend to our clients needs. Yes we would. Difference is that our client does that by themselves, not us. Also currently you need to a) create template and configure access b) edit page and change template. So in a way that is currently also managed in page level, because you need to change the template. I agree that our needs are pretty complex and custom. Also - we are not sure how complex stuff we want/need to build anymore. I do not want to build (or buy to be build) anything for this before it starts to slow down our sales. So I am pretty confident that current level is mostly enough for us (cannot predict too much tough, we'll see ). Currently I see that the way pw manages access is very clean, efficient and great way for site builders - and it allows all the possible "who can edit what" scenarios that there is easily. But if you are building extranets or intranets your needs are very different. It is more like "who can see what" and "I need to share some data with these roles now". Page-spesicific permissions are clear winner there. Something that client can quickly do by themselves (add new page => select which roles can access it => save). As doolak wrote in first post: I don't want to allow my clients anywhere near template settings. And when this is only place where access can be managed, then it is very limited what client can do here (manage users and their roles). Most of the time that is exactly how we also want it, but I think we are not only ones who will have situations where more ad hoc solution would do much better.

Very nice little site! Elegant and just beautiful.