apeisa

Ok guys, just watched latest episode of True Blood with my wife and after that coding of this was peace of cake This turned to be pretty cool... actually supercool Lots of work to do (settings etc), but all the core functionality that I needed for my current project is there already. Screencast is worth thousands images, so here we go: http://screencast.com/t/qOmxvS8enGsD (Some of the images that it saves are pretty large so it takes a while... I use "Large" setting from flickr, which is usually 1024 width.)

Haha - I actually have no notifications, I just live here

Pete: welcome to the forums! As far as I know the other things you suggested aren't there yet, but this last one is (at least on upcoming 2.1 version: https://github.com/ryancramerdesign/P21). Go to setup -> Fields -> choose image field and there "Max Image Dimensions".

Thanks. I will start to look extending fieldtypeFile. Flickr API is pretty nice, it allows to search based on license. So currently it searches only for CC images that have "available for commercial use" - of course you would need (probably, depends on their license) to contribute authors (my intention is to pre-populate the description field with that information). I probably will add settings so that you can search: commercial or also non-commercial CC licensed images from all public photos or then like you described from users own flickr account.

I cannot say what is causing your first issue, since if those files really are 0444, then you shouldn't see those warnings. The second one: check your parent page template settings: children -> Required Template for Children. You should have "Any" set there, now you might have some template (other than "page") set there, which only allows that template. PS: I'm not sure but it might be good to have another setting for default template for children? I know that pw is pretty good guessing what template you want (based on the other children pages), but it's not always right.

I quote myself: I started to thinking: as we can add images with url on templates - is it possible to have same functionality on admin site? So if you know the url you could just add that, no need for download & upload. (I don't know if this is supported on code level already...?) I added little screencast that probably helps to understand what I am talking about http://screencast.com/t/AsQ7cwBd5Y So what I would do is add hidden form fields for images that user choose (those fields value would be url to fullsize image). Then fieldtype would process those without expecting file upload, and pull images from flickr url.

Well, it seems I probably need a new Fieldtype for this after all.. since this plugin will not upload local files, it will just add images to pages from public urls. So the way this handles form input is very much different to file and image inputfields. That doesn't mean a lot of work, but I would liked very much if it could have been same fieldtype, since the data they contain are identical, only the way that data (image file & description) is different. On the bright side - those fieldtypes can be changed (just converted image field to file field => all works fine) so if I for some reason want to stop using flickr import and start uploading.. all would work fine after field type change. PS: Ryan, after last update it is now possible to select Image as inpufield type for file field (you probably knew this). It actually works, but gives broken image on non-image files. I don't think that is something that needs to be fixed, since it a) works b) is something that side builder needs to intentionally change.

Works very well, thank you sir! I hope to get my inputfield ready and shared soon!

Thanks Ryan. I will try this soon.

Just a wild guess, but probably image field accepts url also (of course url needs to be public), so you don't have to do that transfer / temporary location / delete temp image stuff at all. And to my understanding if you add image and save page, then that image is copied to /site/assets/files/page-id/ folder. So you would have to remove temp file if you don't want to keep duplicates. If image field doesn't accept urls then you have to go harder way. But I probably wouldn't add that downloading / removing to script (at least if original png files are in single folder) - it would be easy to just remove the folder where all temp images are saved after import is successful.

If I edit line 47 in FieldtypeImage.module and change it from $inputfield = $this->modules->get("InputfieldImage"); to $inputfield = $this->modules->get("InputfieldFlickrimage"); Then it uses this new inputfield. This helps me to develop this module, but of course this should be somehow extendable. Of course I could create another Fieldtype by extending fieldtypeImage and set that use this new inputfield, but that would be as clean as I would like it to be. It would be nice to have different inputfields for images and files also.

I started to create quick module where It would offer possibility to search and select images from Flickr in addition to local hard drive. I cannot get it to display selection of Inputfield Type like it offers when creating Inputfields for FieldtypeText, FieldtypeTextarea or FieldtypePage. When I look the source code of FieldtypeImage and FieldtypeFile it seems that they are hardcoded to always use InputfieldFile or InputfieldImage. So after I create Image field I could choose this new inputfield as I can choose between textarea and TinyMCE when creating Textarea inputfield. This is the little I got so far... I cannot do much to proceed before I get my field to use this. <?php class InputfieldFlickrimage extends InputfieldImage { public static function getModuleInfo() { return array( 'title' => 'Flickr images', 'version' => 100, 'summary' => 'Upload local files or get those straight from flickr', 'permanent' => false, ); } public function init() { parent::init(); } public function ___render() { $this->config->scripts->add($this->config->urls->InputfieldFile . "InputfieldFile.js"); $this->config->styles->add($this->config->urls->InputfieldFile . "InputfieldFile.css"); return parent::___render()."FlickrMagicIsHere"; } }

Great post Ryan and interesting discussion, thanks for bringing it up Neotoxic. I agree (I haven't seen problems author of the article is writing), but there are some problems. If CMS is not flexible enough for site builders then it means that you start looking for plugins for every need you have. You know, things like "product listing plugin" or "phonebook plugin" etc. Take that approach and soon you have 35 plugins installed. Now add one very poorly coded plugin which broke something that few another plugins needs. After that you have few non-working plugins because of one badly working - and you do not have a clue why that is happening (you start uninstalling those plugins, one by one and looking if all starts working again). This is the scenario where many non-developers-but-active-site-builders end up when they build and maintain sites. That is one of the reason I think where "custom content" cms like pw, ee, symphony, drupal (and if I remember also wordpress 3.0+ in some way) is requirement for bigger sites (and by big I mean that they have lot's of very different kind of content). If you respect your content, then you have all doors open. Of course there is many many differences between those systems in other areas.

Thanks Ryan! I like your method very much. Straightforward and easy to understand. In my experience most sites we build usually go with one or two main templates. One template for frontpage and another for content pages. After that if there is some campaign sites or special subsections then those get their own template if needed (usually css targeting is enough). Actually it is also your version, I copied it from another topic where templates are discussed

You did try with template name that contains only numbers? I tried again with name "123" and same error. Here is the markup that table contains: <tr> <td>edit?id=51</td> <td>0</td> <td>1</td> <td></td> </tr> <tr> <td><a href='edit?id=40'>home</a></td> <td>1</td> <td>1</td> <td></td> </tr> Similar error is also when you create a user with name that is only numbers.

I usually put my issues on github, but I didn't figure how to post screens there, so I put this one here. I think similar problem is on user listing, so probably little problem on code that generates the table markup. But the screenshot probably tells everything that is needed. Running on latest version of P21.

I have coded my sites using simple included header & footer technique (similar to how demo site is coded). It has it's merits (simple and straightforward), but on bigger sites it may add lot's of controller logic to header files or a lot of little bit different template files, where logic and markup is mixed. I know there is TemplateFile class which I assume is something that Ryan uses on most of his projects. Usage looks simple: <?php $out = new TemplateFile("./includes/my_markup.html"); $out->set('headline', $page->get("headline|title")); $out->set('body', $page->body); $out->set('sidebar', $page->sidebar); $out->set('navigation', $pages->find("parent=/")); echo $out->render(); But how I would code those headline, body etc. variables to my_markup.html file? I assume that my_markup.html can contain php... So are those just $headline, $body, $sidebar etc? Or probably like $this->headline etc?

Martin: thanks and glad that I could help. slkrwrm: I splitted your question to new topic: http://processwire.com/talk/index.php/topic,335.0.html

I don't think so (if you remember to use === instead of ==). But not sure about this, Ryan probably knows more. Here is some information, but not much about performance: http://php.net/manual/en/language.oop5.object-comparison.php

I forget to check if it is current page. Just add || $p === $page to your if clause and it should work as expected: <?php foreach($pages->find("parent=/illustration, sort=sort") as $p) { if ($page->parents->has($p) || $p === $page) { $class = 'current'; } else { $class = ''; } echo "<li class='$class'><a href='{$p->url}'>{$p->title}</a></li>"; } I know that coding navigation is not the easiest job in the world if you are not experienced coder. I think we should have some more code snippets shipped with demo site or some kind of code snippets area on website. Or FAQ or Wiki...

Now that I looked your example I am pretty sure this is what you want (I also edited my previous example a little): <?php foreach($pages->find("parent=/illustration, sort=sort") as $p) { if ($page->parents->has($p)) { $class = 'current'; } else { $class = ''; } echo "<li class='$class'><a href='{$p->url}'>{$p->title}</a></li>"; }

stillmovingdesign: If you want to check if any page is one of the pages in path, you can use this code: <?php if ($page->parents->has($p)) { // This means that page $p is one of the parents of current page ($page) } In your example something like this: <?php foreach($pages->find("parent=/illustration, sort=sort") as $p) { if ($page->parents->has($p)) { $class = 'current'; } else { $class = ''; } echo "<li class='$class'><a href='{$p->url}'>{$p->title}</a></li>"; }

Great discussion. This is really interesting question. One article I remember reading from this topic is here: http://allinthehead.com/retro/357/the-lure-of-on-page-editing (great comments also). This is true. But it is also true on current AdminBar implementation and it is also true on real admin site: you cannot edit blog posts when you are editing blog listing page. Non-tech people would probably find the actual blog post easier by clicking blog post, than by looking for children pages (or somewhere else - you just have to know) in admin site. Yes, special cases like these are where true admin view is much better or even only option. I'm not so sure about this. Ryan showed example code which means you don't have to do anything special in your templates. Also no need to use 5px border (special background icon on that wrapper div that TextformatterAloha creates should be enough). So you do not need anything special in your CSS neither. This is exactly the same reason why I have been thinking for this. It looks damn good on sales meeting, might even give one or more "wow, that is nice" comments from audience. And depending on the site your "content editing" might be mostly small edits, typo corrections, linking and stuff like that. Then you would love tool like aloha editor. So there is also real life situations where it would be good. I was earlier thinking this in realm of adminbar, and somehow didn't even think that option. I think that it would make great sense to build this separately, but in a way that they work well together. It keeps adminbar codebase clean and simple - and gives it path to grow in more "admin" direction if needed. I might put some effort to this on my summer holiday (first week going, three left). It seems simple and rewarding project. Or maybe I do something after we finish the movie tonight.... (edit: decided to close computer and go to bed) Of course, that would be an honor actually

Did some comparison between adminbar and locomotive's inline editing. Not so impressed with locomotive's current implementation anymore. Clicking edit button creates full page refresh and again saving (or clicking "done editing") creates another. It doesn't feel fast and it's not fast. I think editing with current way adminbar is done is much quicker (it loads editing page in background and shows it in iframe), and creates page refresh after you hit save. Also things like saving or canceling editing are much clearer in adminbar. Of course inline editing could be done without any page refreshes at all, and that should be quicker than adminbar's current implementation. I need to think about this a little, but it seems that I won't be getting into that inline editing thing after all. It is nice demo and great for small and simple sites, but it just don't seem to bend very well for flexibility that pw offers. I think it really is more confusing than beneficial for many reasons. Situations where someone should really consider implementing inline editing are when they are building something like drupal gardens is for drupal.

Ryan's solution looks nice and clean. I was first thinking implementation without that textformatter, so person who creates html template can add that on wherever he thinks quick editing is reasonable. But using textformatter here is much cleaner solution! I am still worried if this is good in overall, compared to modal-type of editing. Quick edit only supports text fields, where processwire sites (at least those that I have build) have lot's of other fields too, mainly page-fields. Of course we can add two different edit modes, but is that really convenient? Other option is to ditch modal editing all together and simply only offer aloha inline editing + real admin. Anyway, I got working version of the new ui ready yesterday. It will get some more polish, but I find it already more pleasing to use than old one. "Sliding" is nicer than modal in this situation. You can grab this version from: https://github.com/apeisa/AdminBar/tree/AdminBarNew