Google shutting Picnik down!
Permalink 2 users found helpful
Just spotted that Picnik will be shutting its virtual doors on April 19 of this year:
http://www.picnik.com/
Might be time to look at replacing Picnik integration in the file manager with a new, similar service (something like Pixlr, maybe? Think they have a decent API) or perhaps something lighter weight within the core itself (I think Jordanlev has done some work on an C5 cropping image editor in the past...haven't seen any development of it for a while though).
Just a heads up all!
http://www.picnik.com/
Might be time to look at replacing Picnik integration in the file manager with a new, similar service (something like Pixlr, maybe? Think they have a decent API) or perhaps something lighter weight within the core itself (I think Jordanlev has done some work on an C5 cropping image editor in the past...haven't seen any development of it for a while though).
Just a heads up all!
I enjoy using Sumo Paint (http://www.sumopaint.com) but it may be too advanced as a replacement for Picnik
I haven't evaluated or checked if there is an API / callback agent etc. to be able to integrate with but here is a list of what I found as alternatives to picnik...
http://pixlr.com/editor/
http://www.splashup.com/
http://fotoflexer.com/
http://www.aviary.com/
http://www.flauntr.com/
http://www.sumopaint.com/home/
http://www.picmagick.com/ (has since been open-sourced MIT, so might be able to be fully integrated)
http://www.drpic.com/ - wow, ads ads ads...
http://pixenate.com/ - not so pretty....
http://snipshot.com/ - nice callback agent
- Phil
http://pixlr.com/editor/
http://www.splashup.com/
http://fotoflexer.com/
http://www.aviary.com/
http://www.flauntr.com/
http://www.sumopaint.com/home/
http://www.picmagick.com/ (has since been open-sourced MIT, so might be able to be fully integrated)
http://www.drpic.com/ - wow, ads ads ads...
http://pixenate.com/ - not so pretty....
http://snipshot.com/ - nice callback agent
- Phil
Some list here, though I have not used any (look for the "online" ones)...
http://alternativeto.net/software/picnik/...
http://alternativeto.net/software/picnik/...
Maybe http://ipiccy.com/
Simple to use and they seem to be interested in the Picnic folks. They ask on facebook what Picnic users would like them to change to practically give them a second home. Resizing and co. is as simple as in picnic.
Quote from FB:
Guys, thank you for all kind words! We will try to add maximum features from Picnik and even more. Follow us on Facebook, Google+ and Twitter (find links on our FB page) to get our updates. We'll do our best to make iPiccy the second home for your photos.
Simple to use and they seem to be interested in the Picnic folks. They ask on facebook what Picnic users would like them to change to practically give them a second home. Resizing and co. is as simple as in picnic.
Quote from FB:
Guys, thank you for all kind words! We will try to add maximum features from Picnik and even more. Follow us on Facebook, Google+ and Twitter (find links on our FB page) to get our updates. We'll do our best to make iPiccy the second home for your photos.
I've tried heaps of 'em and think that
http://www.aviary.com/web
- all html, no flash, easy to use - would be great!
http://www.aviary.com/web
- all html, no flash, easy to use - would be great!
Does anyone know, when are these changes suppose to take place and when will C5 core team know which product will be used?
Per the last totally random show, it sounds like the solution will be homebrew. It will probably not include more advanced image editing tools and will focus more on scaling/cropping images.
What I'm really excited about is that block builder's should be able to hook in this, allowing users to crop an image to a block's specifications.
What I'm really excited about is that block builder's should be able to hook in this, allowing users to crop an image to a block's specifications.
I have another opinon.
It could be a simple resizer or option system like WordPress; small, medium, large oprion.
Most of the time, people only want to use it to resize the image.
Or we could add the option "Small" "Medium" "Large" like WordPress.
So the site admin can upload and save the original size image, and config the image size of your site, and when pasting onto the page, it could resize onto the right size.
Just an idea.
It could be a simple resizer or option system like WordPress; small, medium, large oprion.
Most of the time, people only want to use it to resize the image.
Or we could add the option "Small" "Medium" "Large" like WordPress.
So the site admin can upload and save the original size image, and config the image size of your site, and when pasting onto the page, it could resize onto the right size.
Just an idea.
I agree that some basic editing tools can be added within the dashboard so we're not relying on another 3rd party that could close down.
But perhaps offer several integration options that can be switched from the dashboard. That way it will be more future proof. I have some installations of c5 that were customised somewhat so I'm not looking forward to having to update those. Spewin!
But perhaps offer several integration options that can be switched from the dashboard. That way it will be more future proof. I have some installations of c5 that were customised somewhat so I'm not looking forward to having to update those. Spewin!
I agree that something simple to just do cropping and resizing will meet 90% of people's needs. As the OP mentioned, I started building this out a while ago but never got it finished. (It was pretty cool actually -- you could drag a crop frame around, all javascript-based).
I had a vague plan to finish it up some day and sell it in the marketplace, but I'm not sure if that will ever happen. I'll talk to Franz about it, maybe they'd be interested in putting it into the core system now that Picnik is going away.
I had a vague plan to finish it up some day and sell it in the marketplace, but I'm not sure if that will ever happen. I'll talk to Franz about it, maybe they'd be interested in putting it into the core system now that Picnik is going away.
Mnkras and I were recently looking into this cool little open source project known as svg-edit. It uses the power of SVG and html5 to it's fullest to make a great open JavaScript image editing platform. I think if we are able to play our cards right, this might be the kind of thing that could be used everywhere, IE a new block with which to edit images on the fly! Check out the demo:http://svg-edit.googlecode.com/svn/branches/2.5.1/editor/svg-editor... or the main project pagehttp://code.google.com/p/svg-edit/...
I sound fanatic because I am, this is the sort of project that I get excited about! =D
I sound fanatic because I am, this is the sort of project that I get excited about! =D
That does look really cool, but it looks to me like it's serving a different purpose -- the demo is like MS Paint, not something that you edit (or resize/crop) photos with.
I dunno... maybe people were using Picnik to drastically alter their photos? I've never once myself done that or ever had a client ask to do that though -- really it's only resizing and cropping that I think are needed in the web interface. I guess I could see some touch-up stuff like brightness and contrast, maybe red-eye reduction -- but certainly not pencils and paintbrushes and color swatches.
I dunno... maybe people were using Picnik to drastically alter their photos? I've never once myself done that or ever had a client ask to do that though -- really it's only resizing and cropping that I think are needed in the web interface. I guess I could see some touch-up stuff like brightness and contrast, maybe red-eye reduction -- but certainly not pencils and paintbrushes and color swatches.
You have a tremendous point here, I didn't think about that at all. There is always the option of showing the png as a different object within the vector graphic. IMHO, resizing images on the web is not effective. The files aren't ever compressed well enough to be on par with compressing in an editor and reuploading. Might as well just size them in css =P
I very strongly (but respectfully) disagree with you about resizing. It is incredibly effective (Concrete5 does this for you in many situations you probably aren't even aware of), and in fact necessary for a lot of non-technical people who don't really understand anything and upload huge files directly from their camera and then wonder why it takes 20 minutes and then expands to fill out 3x the browser window. And the quality setting is variable so it can be adjusted to suit your tastes (or needs if your viewers have low bandwidth).
Stepping back a bit, it is obvious that there probably isn't one best solution for everyone's needs. Some users are professional photographers (or advanced amateurs or whatever), whereas others are completely non-savvy. Some people don't even have offline photo editors (or if they do they certainly don't know they exist nor how to use them)...
What I think would be really great is if the "edit" item in the popup menu when you click a file in the file manager fired some kind of event, and you could install addons that responded to that. So people could choose various different image editor options (e.g. a stupid simple resizer/cropper like I suggested, a super full-featured editor like you suggested, or various API integrations to the services mentioned above). Ideally the core system would come pre-installed with one, and the rest could be in the marketplace. Kind of like how you can plug in different payment and shipping providers to the eCommerce system.
Stepping back a bit, it is obvious that there probably isn't one best solution for everyone's needs. Some users are professional photographers (or advanced amateurs or whatever), whereas others are completely non-savvy. Some people don't even have offline photo editors (or if they do they certainly don't know they exist nor how to use them)...
What I think would be really great is if the "edit" item in the popup menu when you click a file in the file manager fired some kind of event, and you could install addons that responded to that. So people could choose various different image editor options (e.g. a stupid simple resizer/cropper like I suggested, a super full-featured editor like you suggested, or various API integrations to the services mentioned above). Ideally the core system would come pre-installed with one, and the rest could be in the marketplace. Kind of like how you can plug in different payment and shipping providers to the eCommerce system.
I'm with you, Jordan. What was the JS you used with that one you started putting together before? jCrop (http://deepliquid.com/content/Jcrop.html)? Whether talking about my clients or personally, I would never want or expect C5 to do anything more than basic cropping, resizing, variable compression and, maybe, rotation. The nuts and bolts of sizing and image optimisation for web. Filters or anything fancier can and should be done offline in an image editor of choice prior to uploading to C5, as any online/server-side application is never really going to replace Photoshop, Fireworks, GIMP or something similar for artistically fiddling with images then correctly optimising.
Haha...in fact, I dread to think what my clients would produce if given access to a heavily featured image editor directly within the c5 interface! Filters all over the shop, ugly artifacts and, probably, a server meltdown; someone who can't get their head around not uploading a 15mb, 300 dpi, CMYK photo is only going to cause trouble when presented with too many options within a click or two! Know Picnik kindof allowed this, but then the overheads were Picnik's problem, not mine, and I never really introduced my clients to the 'edit' functionality because I didn't want to be stuck supporting them on the 3rd-party Picnik interface.
Any advanced editor add-ons could indeed be submitted to the marketplace in the usual fashion for addition is the need arises for a particular (well-behaved) client.
Haha...in fact, I dread to think what my clients would produce if given access to a heavily featured image editor directly within the c5 interface! Filters all over the shop, ugly artifacts and, probably, a server meltdown; someone who can't get their head around not uploading a 15mb, 300 dpi, CMYK photo is only going to cause trouble when presented with too many options within a click or two! Know Picnik kindof allowed this, but then the overheads were Picnik's problem, not mine, and I never really introduced my clients to the 'edit' functionality because I didn't want to be stuck supporting them on the 3rd-party Picnik interface.
Any advanced editor add-ons could indeed be submitted to the marketplace in the usual fashion for addition is the need arises for a particular (well-behaved) client.
@arcanepain, yes it was JCrop.
re: variable compression -- I just remembered that the compression is only variable globally in C5 via a config/site.php definition. I believe Kirk Roberts hacked the image helper at one point to allow the compression setting to be passed in, so this might be a good change to bring into the core along with all the other stuff we're talking about here.
Also, note that compression levels only apply to JPEGs, not PNG's (due to the nature of PNG's, not a C5 limitation).
re: variable compression -- I just remembered that the compression is only variable globally in C5 via a config/site.php definition. I believe Kirk Roberts hacked the image helper at one point to allow the compression setting to be passed in, so this might be a good change to bring into the core along with all the other stuff we're talking about here.
Also, note that compression levels only apply to JPEGs, not PNG's (due to the nature of PNG's, not a C5 limitation).
Haha...for sure. To be honest, most of my clients barely know what a .gif, let alone a .png! Just JPEG editing, resizing, cropping etc would do the job in 95% of cases I deal with via my clients.
I actually grabbed that modified cropping image helper when Kirk Roberts put it up...used it on a couple of sites, but then got lazy and have fallen back to the core version. Sitewide setting probably would do the trick, although the flexibility in the instant would be nice. As a compromise, perhaps an 'Image Settings' page in Dashboard > Settings would work -- at least this way the client can have some control over the quality setting in the editor and/or sitewide without having to edit config.php.
I actually grabbed that modified cropping image helper when Kirk Roberts put it up...used it on a couple of sites, but then got lazy and have fallen back to the core version. Sitewide setting probably would do the trick, although the flexibility in the instant would be nice. As a compromise, perhaps an 'Image Settings' page in Dashboard > Settings would work -- at least this way the client can have some control over the quality setting in the editor and/or sitewide without having to edit config.php.
Jordan's suggestion seems quite good but I don't think it would necessarily have to be an event after the upload. I think that add-ons could be given the possibility to change the event that is bind to the "edit" button in the file manager, that would probably be more than enough. Just some dashboard settings page where you could set "image editor" and there would be listed all the options that you could choose from.
When I found concrete5, I actually came from the WordPress world. For me and my clients, Picnik has been really "too much" and I've never had a situation where the WordPress edit options weren't enough (like many others have said here).
I actually found that while the editing options in Picnik are quite good, it really adds an overhead e.g. in a situation where I'm teaching my clients to crop or resize the image. That's the usual case and although it is quite easy with Picnik as well, it could be even easier (because there's a quite long time you have to wait before Picnik starts).
Just added my thoughts into the list...
Antti
When I found concrete5, I actually came from the WordPress world. For me and my clients, Picnik has been really "too much" and I've never had a situation where the WordPress edit options weren't enough (like many others have said here).
I actually found that while the editing options in Picnik are quite good, it really adds an overhead e.g. in a situation where I'm teaching my clients to crop or resize the image. That's the usual case and although it is quite easy with Picnik as well, it could be even easier (because there's a quite long time you have to wait before Picnik starts).
Just added my thoughts into the list...
Antti
Antti, you're right about keeping the plugin architecture simple -- I just mentioned the event thing as an example, not that I think it's the best technical solution.
I like the JCrop idea.
Something Very Simple and maybe even have them tied into helpers so you can provide those plugins option from the block/package.
I could see that as a great use for the thumbnail page list blocks where you would like a certain aspect ratio for each image, to prevent users from uploading images to tall/wide
Then Simple options like Resize, rotate, flip?.
Something Very Simple and maybe even have them tied into helpers so you can provide those plugins option from the block/package.
I could see that as a great use for the thumbnail page list blocks where you would like a certain aspect ratio for each image, to prevent users from uploading images to tall/wide
Then Simple options like Resize, rotate, flip?.
Same for me, include an absolutely minimal editor built in and whatever hooks are necessary to make it extendible/pluggable with add-ons.
Developing from this topic, there are a growing number of areas in C5 that have override/extension/plugin capabilities. At the moment there is a mix of re-invention and a sort of coding Chinese whispers on how such mechanisms are implemented.
I really would like to see a generic manager that can then be utilised as required by any area of C5 and addons that needs override/extension/plugin support (I accept that these are not all the same). It may also help clean up a lot of similar code in the core.
Developing from this topic, there are a growing number of areas in C5 that have override/extension/plugin capabilities. At the moment there is a mix of re-invention and a sort of coding Chinese whispers on how such mechanisms are implemented.
I really would like to see a generic manager that can then be utilised as required by any area of C5 and addons that needs override/extension/plugin support (I accept that these are not all the same). It may also help clean up a lot of similar code in the core.
Just found this:http://snipshot.com has a free api, can re-size, crop, rotate, etc (and no flash!)
While we are at it - iPad support for image editing would be nice.
Yeah, I am not an Apple guy, but I think finding one that is not dependent on Flash is a good idea. I was looking at Aviary (mentioned above) and Cloud Canvas which are HTML5 online image editors that have promise.
Probably some more out there as well.
Aviary:http://www.aviary.com/web
Cloud Canvas:http://www.cloud-canvas.com
Probably some more out there as well.
Aviary:http://www.aviary.com/web
Cloud Canvas:http://www.cloud-canvas.com
Whilst not an online editor we have tried and liked
http://www.imagemagick.org/script/index.php...
And more specifically the PHP wrapper phMagick
http://www.francodacosta.com (GNU Licenced)
the following from his website,
phMagick is wrapper for ImageMagick written in php 5, and it's designed with to ease the developer job by wraping ImageMagick complexity in easy to use functions.
It allows you dynamically generate thumbnails and catching effects like drop shadows, watermark images, write text as an image, create a mirror or reflex effect to images all without opening photoshop just with Php and ImageMagick. The main reason for making phMagick is to avoid the inefficiency of GD and php memory limits
http://www.imagemagick.org/script/index.php...
And more specifically the PHP wrapper phMagick
http://www.francodacosta.com (GNU Licenced)
the following from his website,
phMagick is wrapper for ImageMagick written in php 5, and it's designed with to ease the developer job by wraping ImageMagick complexity in easy to use functions.
It allows you dynamically generate thumbnails and catching effects like drop shadows, watermark images, write text as an image, create a mirror or reflex effect to images all without opening photoshop just with Php and ImageMagick. The main reason for making phMagick is to avoid the inefficiency of GD and php memory limits
Imagemagick is a very useful tool, however it is server-side, and not available on most vanilla lamp setups.
Good.
EDIT: Sorry that wasn't very productive.
I'm so excited that concrete5 is now looking to find an awesome new html5/js editor. I'll start looking.
EDIT: Sorry that wasn't very productive.
I'm so excited that concrete5 is now looking to find an awesome new html5/js editor. I'll start looking.
It is nowhere to be seen.... (atleast by me)
Ya, I'll start looking. One of the reasons is that you have to image versions, which is probably too big to do client side, so there will probably have to be some ajax-ing going on. Which means it would probably have to be a little middle-ware specific.
I know the devil is in the details, but if it's a basic editor, it's not rocket science. I mean look at how little code this is.
http://www.script-tutorials.com/demos/138/index.html...
http://www.script-tutorials.com/demos/138/index.html...
What about the basic plugin architecture?
In the core there would be:
a) resize
b) crop
Nothing else. Then people could do their own add-ons for more extended editors.
I actually made just a POC/testing HTML canvas project of my own interest with one person I know few years back and I can tell you will be facing quite a lot issues in it if you actually want to make something "production ready" of your own although it might not seem like that much of code:
http://code.google.com/p/html-5-canvas-whiteboard/...
That was just of our own interest to test the abilities of HTML canvas element and was just a "playing around" project.
Also, cross browser issues should be considered in something like this when maybe some SVG drawing library might be a better choice...
-Antti
In the core there would be:
a) resize
b) crop
Nothing else. Then people could do their own add-ons for more extended editors.
I actually made just a POC/testing HTML canvas project of my own interest with one person I know few years back and I can tell you will be facing quite a lot issues in it if you actually want to make something "production ready" of your own although it might not seem like that much of code:
http://code.google.com/p/html-5-canvas-whiteboard/...
That was just of our own interest to test the abilities of HTML canvas element and was just a "playing around" project.
Also, cross browser issues should be considered in something like this when maybe some SVG drawing library might be a better choice...
-Antti
Just found this not the best UI but I think offers a very simple Editing interface
Rotate, Resize, Crop
http://www.cropzoom.com.ar
Rotate, Resize, Crop
http://www.cropzoom.com.ar
I've used JCrop and GD on a Concrete5 website to crop, layer images (with transparency) and resize. I coded it pretty quickly so the C5 developers should be able to do it in minutes.
I would like to see a basic image editor that allows you to crop, rotate and resize images. It should detect and use the best image processor available and use GD if no other is available.
Picnik was neat but Flash sucks and it was slow. I don't think very many people used any of the cool features. Probably why they closed.
I would like to see a basic image editor that allows you to crop, rotate and resize images. It should detect and use the best image processor available and use GD if no other is available.
Picnik was neat but Flash sucks and it was slow. I don't think very many people used any of the cool features. Probably why they closed.
What I would like to see.....
....would be a javascript based version of what we have built in flash in the composer template for blog posts in 5.5
The key features are:
1) A developer can define the footprint you're working towards. That makes it really easy for Mom to upload an image from her camera and get it sized to the header space without remember scary numbers.
2) Scale controls
3) Rotate controls
4) Movement controls
Generally you're scaling/rotating/moving to fit it INTO a certain footprint, which is why our flash image guy has the treatment it does of showing the light box with the dimmed outter area.
The ideal solution for the core would not require any additional 3rd party image libraries.
Not work with flash (And be mobile/ipad friendly at possible)
And be built in a way that it could be swapped out with something more powerful than it if desired.
I'm a big fan of not reinventing the wheel, although the obvious experience on this one has been its not awesome when the wheel is removed from your car mid-trip. I agree we're not talking rocket science here so I can imagine just writing something. If there was a nice MIT/LGPL library that made that a lot easier, I'd feel comfortable with that approach. It's unlikely we'll do a direct hook into a commercial 3rd party service like that in the core again.
....would be a javascript based version of what we have built in flash in the composer template for blog posts in 5.5
The key features are:
1) A developer can define the footprint you're working towards. That makes it really easy for Mom to upload an image from her camera and get it sized to the header space without remember scary numbers.
2) Scale controls
3) Rotate controls
4) Movement controls
Generally you're scaling/rotating/moving to fit it INTO a certain footprint, which is why our flash image guy has the treatment it does of showing the light box with the dimmed outter area.
The ideal solution for the core would not require any additional 3rd party image libraries.
Not work with flash (And be mobile/ipad friendly at possible)
And be built in a way that it could be swapped out with something more powerful than it if desired.
I'm a big fan of not reinventing the wheel, although the obvious experience on this one has been its not awesome when the wheel is removed from your car mid-trip. I agree we're not talking rocket science here so I can imagine just writing something. If there was a nice MIT/LGPL library that made that a lot easier, I'd feel comfortable with that approach. It's unlikely we'll do a direct hook into a commercial 3rd party service like that in the core again.
The thing I just posted (https://github.com/jordanlev/c5_image_cropper... ) is probably 75% there towards your stated goals.
It doesn't have rotation, but that's the easiest feature to add.
As for "be built in a way that can be swapped out"... this is something that needs to be changed in the core code... just make that "edit" link in the file manager popup menu call some kind of hook or event or something instead of being hard-coded to the picnick stuff. Andrew should bestow us with some guidance on this one.
It doesn't have rotation, but that's the easiest feature to add.
As for "be built in a way that can be swapped out"... this is something that needs to be changed in the core code... just make that "edit" link in the file manager popup menu call some kind of hook or event or something instead of being hard-coded to the picnick stuff. Andrew should bestow us with some guidance on this one.
And I didn't explicitly state this anywhere, but consider it public domain / MIT license / whatever you want to do with it.
This gets my vote.
I'm also way to busy the next two weeks, but will try to sneek an 30-60 a day on it until it clears up.
I'm also way to busy the next two weeks, but will try to sneek an 30-60 a day on it until it clears up.
Does this work? I installed but it doesn't do anything.
I would love to see #1 implemented. I hate having to put in "240px" into the notes and hoping that the customer will resize properly.
I second this option.
Anything to make it easier for the client. All they want to do is upload an image and see it on their site without having to edit images.
If we were able to set the image size to individual blocks, which then scales/crops any image to the width of that block, now this would be great!
Or even better, set the size in the dashboard area and assign blocks to use this setting. You could have a checkbox at the bottom of the content block to tell it to use it or not.
Would this be an option?
Cheers
Chris
Anything to make it easier for the client. All they want to do is upload an image and see it on their site without having to edit images.
If we were able to set the image size to individual blocks, which then scales/crops any image to the width of that block, now this would be great!
Or even better, set the size in the dashboard area and assign blocks to use this setting. You could have a checkbox at the bottom of the content block to tell it to use it or not.
Would this be an option?
Cheers
Chris
I just put the image cropper/resizer I was working on a while ago back onto github:
https://github.com/jordanlev/c5_image_cropper...
I unfortunately can't provide any help with this for a couple of weeks due to life happenings, but if someone was going to spend time on it this will save you a TON as I've worked out a lot of UI math.
It's a pretty elegant UI in my opinion -- basically the user only has to put in 1 or 2 numbers (in theory those are defaulted by the designer/developer so laypeople can ignore them), then they can set the frame of the image to be whatever they want and it will automatically figure out the best possible dimensions and crops to make that work.
The README is very extensive, and contains a thorough todo list as well. This should give a big head start if someone wants to take it and run with it. Wish I could be more involved, but will be out of commission for the next few weeks...
-Jordan
https://github.com/jordanlev/c5_image_cropper...
I unfortunately can't provide any help with this for a couple of weeks due to life happenings, but if someone was going to spend time on it this will save you a TON as I've worked out a lot of UI math.
It's a pretty elegant UI in my opinion -- basically the user only has to put in 1 or 2 numbers (in theory those are defaulted by the designer/developer so laypeople can ignore them), then they can set the frame of the image to be whatever they want and it will automatically figure out the best possible dimensions and crops to make that work.
The README is very extensive, and contains a thorough todo list as well. This should give a big head start if someone wants to take it and run with it. Wish I could be more involved, but will be out of commission for the next few weeks...
-Jordan
alright!, let me see jordan :)
The ability to script this in to a block's edit page would be a serious boon to c5 imho. The thing most people I work with are uncomfortable with c5 about is giving the user the ability to screw up the look of a carefully designed site. Currently, you can get pretty far turning off access to the content block and using a series of pre-chosen/made blocks.
Images are still dangerous though. You can force the size an image is displayed at, but I've seen people take photos from their 10 megapixel camera and stick them right in to a 200x200 image space.
I actually need this for something I'm working on, I'll investigate how this might be done with jordanlev's solution and get back to ya.
Images are still dangerous though. You can force the size an image is displayed at, but I've seen people take photos from their 10 megapixel camera and stick them right in to a 200x200 image space.
I actually need this for something I'm working on, I'll investigate how this might be done with jordanlev's solution and get back to ya.
Just discovered the Picnik news and came straight to these forums to see if Concrete5 had a plan… good to see something is underway.
I definitely endorse the simple function approach, however what Franz says about not reinventing the wheel seems important too…
I was just setting up a new account on mailchimp for a client and noticed that mailchimp had replaced Picnik with Aviary … it's not on my personal mailchimp account so looks like something they are rolling out slowly, but in my opinion this is a significant endorsement of Aviary.
Secondly, I was extremely impressed with the simplicity of the Aviary set-up. You seem to just be able to embed the widget – you are not wrenched away to another site in the way that picnic used to. There is a demo here:http://www.aviary.com/web
So, basically whilst I'd certainly be keen for an bespoke concrete5 simple editor time it won't be long before picnik is gone and Aviary looks like a very good (/better) replacement.
I definitely endorse the simple function approach, however what Franz says about not reinventing the wheel seems important too…
I was just setting up a new account on mailchimp for a client and noticed that mailchimp had replaced Picnik with Aviary … it's not on my personal mailchimp account so looks like something they are rolling out slowly, but in my opinion this is a significant endorsement of Aviary.
Secondly, I was extremely impressed with the simplicity of the Aviary set-up. You seem to just be able to embed the widget – you are not wrenched away to another site in the way that picnic used to. There is a demo here:http://www.aviary.com/web
So, basically whilst I'd certainly be keen for an bespoke concrete5 simple editor time it won't be long before picnik is gone and Aviary looks like a very good (/better) replacement.
Aviary looks awesome!
agreed
Just want to chime in to say cropping is really the only absolutely necessary tool for my (my clients') use. Everything else is gravy (and too much gravy can be bad for you). Avoiding Flash would be a win.
ps - aviary does look pretty cool, but I can see how avoiding another third-party service might be preferred.
pps- wonder what's going to happen with non-updated c5 installs and the Edit button. Big fat error?
ps - aviary does look pretty cool, but I can see how avoiding another third-party service might be preferred.
pps- wonder what's going to happen with non-updated c5 installs and the Edit button. Big fat error?
.
@mbone99, I saw what you initially put and now your post has nothing. Why did you edit your post to say nothing?
@codingpenguins - the snippet I originally posted was a hack so I've reworked as a proper add-on that seamlessly replaces Picnik with Aviary. The add-on is awaiting approval - should be available soon.
I had to build a custom image cropper recently for a client in real-estate, specifically so that they could customize the look of the same image, but that appeared in multiple dimensions throughout the site.
As others have already alluded to up above, it ended up using the jCrop plugin, with a jQueryUI range slider to adjust the size. I had to build custom dashboard components for the real-estate package, so the screenshots that are attached aren't in the context of the file manager, but the same code could easily be dropped into the file manager.
The details of how it works:
1) First step is you, as the site manager/developer, define the thumbnail dimensions as "thumbnail templates". There is a link in the dashboard that pops up a modal, which allows you to predefine image width and height. Super simple; you just define a width, height, and give it an "image template" name.
2) From the property manager menu (which would translate to the File Search page), you click on the property (which has a file assigned to it), and hit "Setup Site Thumbnail." (In the file manager, it might say "Manage thumbnails".
3) A modal pops up, where you have 1) a drag handle to adjust the size of the image, and 2) a drop-down menu to choose which thumbnail size this should be cropped to. As you select a different thumbnail size, the crop dimensions will change.
4) When you hit save, the system resizes/crops the image, and stores it in the cache.
5) The ImageHelper class was extended, so that there is now a method for getTemplatedThumbnail(); where you pass in the same arguments as the getThumbnail() method. If the user has done the previous steps and setup a custom thumbnail for the template matching the dimensions passed in to getTemplatedThumbnail, then it'll return that thumbnail. In all likelihood, the user isn't going to go in and setup ALL the thumbnails for ALL the images - so if the thumbnail matching the dimesions passed in doesn't exist, it'll fall back to the getThumbnail method with $crop = true, then return the image with a best-guess crop.
6) Same thing above has been ported to the image block. If the image that is supposed to be output has a cropped template matching the dimensions passed into the Width and Height fields of the block, it'll return that image. Otherwise, it'll fall back and crop it. Also, the ImageBlock setup form now has dropdown list of all the template names, and if one is selected, it'll use the dimensions in that template.
Screenshots are attached. Hope that all makes sense!
The UI certainly isn't the most polished/sexy thing in the world, but its super intuitive and works a treat.
If anyone is interested and thinks this might be a good approach to the problem, I'll do some forking to the core file manager and put in a pull request on github and you guys can check it out.
As others have already alluded to up above, it ended up using the jCrop plugin, with a jQueryUI range slider to adjust the size. I had to build custom dashboard components for the real-estate package, so the screenshots that are attached aren't in the context of the file manager, but the same code could easily be dropped into the file manager.
The details of how it works:
1) First step is you, as the site manager/developer, define the thumbnail dimensions as "thumbnail templates". There is a link in the dashboard that pops up a modal, which allows you to predefine image width and height. Super simple; you just define a width, height, and give it an "image template" name.
2) From the property manager menu (which would translate to the File Search page), you click on the property (which has a file assigned to it), and hit "Setup Site Thumbnail." (In the file manager, it might say "Manage thumbnails".
3) A modal pops up, where you have 1) a drag handle to adjust the size of the image, and 2) a drop-down menu to choose which thumbnail size this should be cropped to. As you select a different thumbnail size, the crop dimensions will change.
4) When you hit save, the system resizes/crops the image, and stores it in the cache.
5) The ImageHelper class was extended, so that there is now a method for getTemplatedThumbnail(); where you pass in the same arguments as the getThumbnail() method. If the user has done the previous steps and setup a custom thumbnail for the template matching the dimensions passed in to getTemplatedThumbnail, then it'll return that thumbnail. In all likelihood, the user isn't going to go in and setup ALL the thumbnails for ALL the images - so if the thumbnail matching the dimesions passed in doesn't exist, it'll fall back to the getThumbnail method with $crop = true, then return the image with a best-guess crop.
6) Same thing above has been ported to the image block. If the image that is supposed to be output has a cropped template matching the dimensions passed into the Width and Height fields of the block, it'll return that image. Otherwise, it'll fall back and crop it. Also, the ImageBlock setup form now has dropdown list of all the template names, and if one is selected, it'll use the dimensions in that template.
Screenshots are attached. Hope that all makes sense!
The UI certainly isn't the most polished/sexy thing in the world, but its super intuitive and works a treat.
If anyone is interested and thinks this might be a good approach to the problem, I'll do some forking to the core file manager and put in a pull request on github and you guys can check it out.
This definitely looks like a good start. Any chance we could get a version of this that works by replacing the edit template for images in the file manager? This is the edit.php file found in concrete/elements/files/edit/image.php which is loaded up in the dialog when "Edit" is chosen for any image. That'd be great – it'd be a complete replacement for picnik without having to understand site thumbnails, etc...
For sure, when I find some time in the next few days I'll bundle it up and send it over. Do you want a pull request via github?
This looks like a good solution - did you ever get anywhere with this?
Text editing is not an option for some people I know who enjoy concrete5... At least a big centered text on picture to write something like "Sold" or "Done"!
A pity Google is closing Picnik :/
A pity Google is closing Picnik :/
Looks like Flickr today-ish announced that they have signed to use Aviary, moving away from Picnik:
http://www.engadget.com/2012/04/05/flickr-adopting-aviary-photo-edi...
Not sure if that is still an option, but something to consider....the Aviary site really does not say anything about "free", though...but I did not sign up for a key so I don't know if they do a "requests per month" type of thing or not.
http://www.engadget.com/2012/04/05/flickr-adopting-aviary-photo-edi...
Not sure if that is still an option, but something to consider....the Aviary site really does not say anything about "free", though...but I did not sign up for a key so I don't know if they do a "requests per month" type of thing or not.
Hi guys,
We've just released this addon to seamlessly replace Picnik with Aviary:
http://www.concrete5.org/marketplace/addons/aviary-image-editor/...
Best regards,
mb
We've just released this addon to seamlessly replace Picnik with Aviary:
http://www.concrete5.org/marketplace/addons/aviary-image-editor/...
Best regards,
mb
Just thought I'd throw my 2 cents in here. I was very surprised yesterday when I went to show a client how they could edit a photo in, bragging about it, then was shocked to see it was no longer available. Bummer. Told my client it used to be great, obviously, b/c google bought it. Anyways, I brushed it off for the time being telling them we'll have to wait on a system update at some point for them to edit images.
So, here's my solution, which is totally born out in the wild working w/ clients and emerging html5/css3 standards.
I think the answer is already here. I've built 2 adaptive websites now, and had to do some js to remove the image width & height from images placed via TinyMCE. So that would be the first step—a check box or something to tell TinyMCE wether or not to insert image width & height values.
Once that's taken care of, then the script that generates thumbnails could be used, along w/ the techniques used here:http://adaptive-images.com/
This would be incredibly useful, as it would allow site developers alot more ease in making a site adaptive—images being the big problem currently—using CSS Media Queries. This will equal out to 1 site fits all, a developers dream.
As an added bonus, I don't have to explain the ins & outs to clients about image sizing anymore. They could upload "Large" images from their cameras and smart phone—a good idea considering Retina Displays on the horizon—then you have some settings that the developer defines for thumbnail sizes of that image—ones that will fit the layout from smart phone to tablet to web to TV. Using that large image, c5 could make an image all those sizes and cache it. Then the proper image could be delivered based on screen size.
This would solve several problems in one. However, it wouldn't solve photo editing per say, just sizing and prepping for an adaptive web.
Hope this makes sense. I'd love to know others thoughts on this. While it may not be the photo editing solution—it's definately something that needs to be addressed in c5, b/c like it or not, the web is going mobile.
Hope this helps generate some ideas.! Holler if you have any questions.
So, here's my solution, which is totally born out in the wild working w/ clients and emerging html5/css3 standards.
I think the answer is already here. I've built 2 adaptive websites now, and had to do some js to remove the image width & height from images placed via TinyMCE. So that would be the first step—a check box or something to tell TinyMCE wether or not to insert image width & height values.
Once that's taken care of, then the script that generates thumbnails could be used, along w/ the techniques used here:http://adaptive-images.com/
This would be incredibly useful, as it would allow site developers alot more ease in making a site adaptive—images being the big problem currently—using CSS Media Queries. This will equal out to 1 site fits all, a developers dream.
As an added bonus, I don't have to explain the ins & outs to clients about image sizing anymore. They could upload "Large" images from their cameras and smart phone—a good idea considering Retina Displays on the horizon—then you have some settings that the developer defines for thumbnail sizes of that image—ones that will fit the layout from smart phone to tablet to web to TV. Using that large image, c5 could make an image all those sizes and cache it. Then the proper image could be delivered based on screen size.
This would solve several problems in one. However, it wouldn't solve photo editing per say, just sizing and prepping for an adaptive web.
Hope this makes sense. I'd love to know others thoughts on this. While it may not be the photo editing solution—it's definately something that needs to be addressed in c5, b/c like it or not, the web is going mobile.
Hope this helps generate some ideas.! Holler if you have any questions.
http://www.concrete5.org/marketplace/addons/aviary-image-editor/
I agree w/ Concrete5Dutch on this one. Aviary may be fine for a temporary fix, but no 3rd party would be best.
True, and better as picnic and also - yet - better as the editor in 5.5.2.
interesting thoughts. we were looking at the resolutions required for
new ipads and chuckling the other day
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
new ipads and chuckling the other day
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
Yeah, Retina Displays are going to drive web images into print resolution sizes. Some day, there may be a program that allows you do do a layout, then pick what media you want to export it to: Print, Web, Video, etc. Retina Displays make that even more feasible I think. However, bandwidth will be an issue unless some sort of compression is developed to allow the larger images to be compressed to a more digestible size. I guess my solution revolves around this more. From my experience, clients that might actually use PicNick's more advanced tools, like sharpening, etc, already have Photoshop and know how to use it, so Picnic is not so valuable to them. For the clients that do use it, cropping and image size is really the only thing they use. Things like Sharpening just seem confusing and are not used.
I believe Danny Baggs(http://www.concrete5.org/profile/-/12046/) is already onto my solution—or was there first. He's got some info here that's going along w/ what I've suggested:
•http://www.concrete5.org/documentation/how-tos/developers/responsiv...
•http://dannybaggs.wordpress.com/2012/03/02/responsive-images-web-de...
•http://www.concrete5.org/documentation/how-tos/developers/responsiv...
•http://dannybaggs.wordpress.com/2012/03/02/responsive-images-web-de...
Hi All,
Thanks Abs0lute for the intro to the discussion and reaching out as you did.
For what it is worth, here is my (long-winded) opinion:
I tend to agree with a majority here in that, in my experience, image cropping and resizing is the most in-demand requirement and the other needs are to be considered separate. I also agree that clients should be insulated away from this challenge as much as possible.
Given this, the approach I decided to take to crack this particular nut was to include the knowledge of image dimension constraints (i.e. site design) and perform a "best fit" automated crop. This empowers the site developer/designer to build this constraint into the c5 template logic.
A number of assumptions are made in this approach however. For instance, an uploaded image that has square dimensions, which needs to fit into a rectangular element within the design is centralised on the axis that needs cropping. Common sense you may think but remember this is taking that control away from the client, which depending on the scenario could be a good or bad thing. In my case, it was a good thing and the users have been grateful. Not once has there been the scenario where a non-central crop was needed but to be fair, this could be down to transparent communication with the clients about what the system would do for them so that they had the knowledge to hand to "feed" the system the right images.
The only other option I built into this solution (an extended ImageHelper that uses PHP's GD library) was whether an image should be pseudo zoomed. That is to say that if an image would be cropped to such a degree that the image doesn't fill the containing area in the other axis, the level of crop would be eased out so that the containing element would be guaranteed to be filled. In my opinion, this again is a decision that the designer/developer should make and not the end user, which is why it is a function parameter, which could of course be driven by a block's attribute - i.e. checkbox in block edit form.
Finally, and slightly separate, in my uses of this logic, the code that utilises this extended ImageHelper is context aware in that it knows of the consuming device constraints. I've utilised the DeviceAtlas service to identify the device and utilise knowledge of the device's screen resolution to provide the constraints for the ImageHelper logic.
This has worked pretty well for me and has taken care of those scenarios where clients upload that 10Gazillion pixel picture, which won't excessively negatively affect the page load time for visitors (image cached after crop).
The only part I'm not comfortable with is a general challenge around Responsive Web Design and images. The link between knowing the design constraints within the CSS and implementing that constraint within the c5 page type or block templates sits uncomfortably with me but it is an easy compromise when the alternative is to "educate" clients on their additional responsibilities when using a fuller editing solution.
The above approach allows you to generically target certain devices using the responsive web design concept. Knowing that a given logo or profile pic is to be say 25% of its parent (the parent being the body for example) and detecting the iPhone's retina display through Device Atlas allows you to constrain the width of that image served to 0.25x<X>, where <X> (640 in the iPhone 4 case) is the physical width in pixels of the detected device.
So in conclusion, I'm all for keeping it simple for users to the point where they shouldn't have to do anything!
Therefore, my request, would be to have such a 'best practice' approach evolve around an improved ImageHelper (from my strawman above - feel free to pick at - Jordanlev has already given great constructive critique) and give site developers the option to enable 'extended' image editing features through an API, which could be implemented by 3rd party in my opinion.
Happy to share further if it would be any use.
Regards,
Dan
Thanks Abs0lute for the intro to the discussion and reaching out as you did.
For what it is worth, here is my (long-winded) opinion:
I tend to agree with a majority here in that, in my experience, image cropping and resizing is the most in-demand requirement and the other needs are to be considered separate. I also agree that clients should be insulated away from this challenge as much as possible.
Given this, the approach I decided to take to crack this particular nut was to include the knowledge of image dimension constraints (i.e. site design) and perform a "best fit" automated crop. This empowers the site developer/designer to build this constraint into the c5 template logic.
A number of assumptions are made in this approach however. For instance, an uploaded image that has square dimensions, which needs to fit into a rectangular element within the design is centralised on the axis that needs cropping. Common sense you may think but remember this is taking that control away from the client, which depending on the scenario could be a good or bad thing. In my case, it was a good thing and the users have been grateful. Not once has there been the scenario where a non-central crop was needed but to be fair, this could be down to transparent communication with the clients about what the system would do for them so that they had the knowledge to hand to "feed" the system the right images.
The only other option I built into this solution (an extended ImageHelper that uses PHP's GD library) was whether an image should be pseudo zoomed. That is to say that if an image would be cropped to such a degree that the image doesn't fill the containing area in the other axis, the level of crop would be eased out so that the containing element would be guaranteed to be filled. In my opinion, this again is a decision that the designer/developer should make and not the end user, which is why it is a function parameter, which could of course be driven by a block's attribute - i.e. checkbox in block edit form.
Finally, and slightly separate, in my uses of this logic, the code that utilises this extended ImageHelper is context aware in that it knows of the consuming device constraints. I've utilised the DeviceAtlas service to identify the device and utilise knowledge of the device's screen resolution to provide the constraints for the ImageHelper logic.
This has worked pretty well for me and has taken care of those scenarios where clients upload that 10Gazillion pixel picture, which won't excessively negatively affect the page load time for visitors (image cached after crop).
The only part I'm not comfortable with is a general challenge around Responsive Web Design and images. The link between knowing the design constraints within the CSS and implementing that constraint within the c5 page type or block templates sits uncomfortably with me but it is an easy compromise when the alternative is to "educate" clients on their additional responsibilities when using a fuller editing solution.
The above approach allows you to generically target certain devices using the responsive web design concept. Knowing that a given logo or profile pic is to be say 25% of its parent (the parent being the body for example) and detecting the iPhone's retina display through Device Atlas allows you to constrain the width of that image served to 0.25x<X>, where <X> (640 in the iPhone 4 case) is the physical width in pixels of the detected device.
So in conclusion, I'm all for keeping it simple for users to the point where they shouldn't have to do anything!
Therefore, my request, would be to have such a 'best practice' approach evolve around an improved ImageHelper (from my strawman above - feel free to pick at - Jordanlev has already given great constructive critique) and give site developers the option to enable 'extended' image editing features through an API, which could be implemented by 3rd party in my opinion.
Happy to share further if it would be any use.
Regards,
Dan
I agree that it would be nice if tinymce could be told to not insert image widths/heights (I could have sworn I saw a forum post about how to do this, but can't find it anymore... here's something from the tinymce forum that might be helpful:http://www.tinymce.com/develop/bugtracker_view.php?id=4770... ).
However, please note that adaptive images is not a complete solution to everyone's image editing needs -- even if mobile is becoming dominant, adaptive design is just one approach to building mobile sites, not the only approach. Yes, it's a popular one and one I think is great and concrete5 should support it, but it will not be the solution for everyone out there.
Kind of off-topic, but what I think would be great is if you could set max width and/or height dimensions on the AREA in your theme templates -- then that would somehow filter up to image controls in blocks so they'd know which dimensions to use as the "frame" in the new built-in image resizer thing.
However, please note that adaptive images is not a complete solution to everyone's image editing needs -- even if mobile is becoming dominant, adaptive design is just one approach to building mobile sites, not the only approach. Yes, it's a popular one and one I think is great and concrete5 should support it, but it will not be the solution for everyone out there.
Kind of off-topic, but what I think would be great is if you could set max width and/or height dimensions on the AREA in your theme templates -- then that would somehow filter up to image controls in blocks so they'd know which dimensions to use as the "frame" in the new built-in image resizer thing.
Excellent idea Jordan! I like the w/h AREA idea, and would make things even more flexible.
Currently, the W3C is also considering adding bandwidth as an option to be used in media queries also. If it goes through, I think Responsive Design will be the rock solid choice for moving forward into a mobile web.
I agree that Responsive web design may not be what everyone needs—but it is certainly the holy grail for developers I know in that it offers the promise of 1 site for all screen sizes.
I'm sure some more robust image editing would be needed for those that rely on it though, but I think having responsive image capabilities will go a long long way in addressing what most clients need and actually use—without them even needing to know how to use it b/c it'll do it's job automatically!
Also, I had already ran across the TinyMCE edit and tried it. Didn't seem to change anything at all. Not sure if I did something wrong, or c5 has additional areas you have to address. My temporary solution is to just use javascript to strip them out:
Currently, the W3C is also considering adding bandwidth as an option to be used in media queries also. If it goes through, I think Responsive Design will be the rock solid choice for moving forward into a mobile web.
I agree that Responsive web design may not be what everyone needs—but it is certainly the holy grail for developers I know in that it offers the promise of 1 site for all screen sizes.
I'm sure some more robust image editing would be needed for those that rely on it though, but I think having responsive image capabilities will go a long long way in addressing what most clients need and actually use—without them even needing to know how to use it b/c it'll do it's job automatically!
Also, I had already ran across the TinyMCE edit and tried it. Didn't seem to change anything at all. Not sure if I did something wrong, or c5 has additional areas you have to address. My temporary solution is to just use javascript to strip them out:
<!--Strip width and height attributes from img, video, and object so we can have fluid images. Change 'body' to '#id-name' or '.class-name' to target just those areas instead of everything. --> <script type="text/javascript"> var $fluid_items = $('body').find('img,video,object'); $fluid_items.removeAttr('width'); $fluid_items.removeAttr('height'); </script>
+1 for the non entry of dimensions from the editor (or at least have it configurable).
Definitely agreed that we're talking about what is actually a broad set of Use Cases here.
Definitely agreed that we're talking about what is actually a broad set of Use Cases here.
Just wanted to reiterate in this thread: as of 5.5.2, concrete5 is no longer dependent on picnik. There is a built-in editor, written in JavaScript, that can make basic image transformations. If you check out the new image block in 5.5.2 you can also see how to pass a footprint to this editor, which locks the aspect ratio of the edit tool. This can be used by other blocks, or anything that calls the file manager.
For those who want more tools, or don't want to upgrade their site, you can use the aviary image editor which is in the marketplace. This is only something you'd have to do if you didn't want to upgrade, or if you want more functionality than what the built-in editor provides.
Finally, we'd love help in testing and improving the built-in editor, and would be happy to review pull requests in github related to it. Sounds like there's some great developer energy in this thread.
One last thing: we had a nice page that should have shown up for users of concrete5 before 5.5, should they try and edit images. We were with picnik to show this page post-closure. It looks like there are some kinks in that page, leading to a less than instructive experience post-closure. We're trying to rectify this. Thanks everybody!
For those who want more tools, or don't want to upgrade their site, you can use the aviary image editor which is in the marketplace. This is only something you'd have to do if you didn't want to upgrade, or if you want more functionality than what the built-in editor provides.
Finally, we'd love help in testing and improving the built-in editor, and would be happy to review pull requests in github related to it. Sounds like there's some great developer energy in this thread.
One last thing: we had a nice page that should have shown up for users of concrete5 before 5.5, should they try and edit images. We were with picnik to show this page post-closure. It looks like there are some kinks in that page, leading to a less than instructive experience post-closure. We're trying to rectify this. Thanks everybody!
Hey Andrew,
Can you give me a yes/no on if you'd accept a pull request that modifies the Area class to accept image dimensions, which are then passed to the image editor (in the case that the block itself hasn't explicitly set width/height?).
My reasoning here is that when I'm building a site for a client, I know that the sidebar is 200px wide, with 10px of padding, so I know that any image added to that area (whether it's an image block or any other kind of block) should have a max width of 180px -- and if this could be passed to the new image editor instead of requiring the user to enter width/height into some boxes, that would make things that much easier.
Can you give me a yes/no on if you'd accept a pull request that modifies the Area class to accept image dimensions, which are then passed to the image editor (in the case that the block itself hasn't explicitly set width/height?).
My reasoning here is that when I'm building a site for a client, I know that the sidebar is 200px wide, with 10px of padding, so I know that any image added to that area (whether it's an image block or any other kind of block) should have a max width of 180px -- and if this could be passed to the new image editor instead of requiring the user to enter width/height into some boxes, that would make things that much easier.
Block/Area attributes :)
Haha... I wrote 90% of that. Everything but the final touches of interface. Then @jordanlev talked me out of it. It's actually pretty easy if you user the User AtCat as pseudo boilerplate.
EDIT: Final touches wasn't really accurate. I had a fair amount of interface stuff to do. This was right around 5.5.1 if I remember correctly.
SECOND EDIT: I can't remember if versioning was supported.
EDIT: Final touches wasn't really accurate. I had a fair amount of interface stuff to do. This was right around 5.5.1 if I remember correctly.
SECOND EDIT: I can't remember if versioning was supported.
>Hey Andrew,
>Can you give me a yes/no on if you'd accept a pull request that modifies the Area class to accept image dimensions, which are then passed to the image editor (in the case that the block itself hasn't explicitly set width/height?).
>My reasoning here is that when I'm building a site for a client, I know that the sidebar is 200px wide, with 10px of padding, so I know that any image added to that area (whether it's an image block or any other kind of block) should have a max width of 180px -- and if this could be passed to the new image editor instead of requiring the user to enter width/height into some boxes, that would make things that much easier.
Would love this. This is a much better match for real world use.
>Can you give me a yes/no on if you'd accept a pull request that modifies the Area class to accept image dimensions, which are then passed to the image editor (in the case that the block itself hasn't explicitly set width/height?).
>My reasoning here is that when I'm building a site for a client, I know that the sidebar is 200px wide, with 10px of padding, so I know that any image added to that area (whether it's an image block or any other kind of block) should have a max width of 180px -- and if this could be passed to the new image editor instead of requiring the user to enter width/height into some boxes, that would make things that much easier.
Would love this. This is a much better match for real world use.
Hi Jordanlev,
Is the Area the right place for this? It feels too high up the chain if you ask me and a little too specific.
In my opinion, it feels like it should be something that we can set into a Block via the Area in much the same way as we can set custom templates for specific Blocks within a given Area.
More specifically, an abstract method to set some properties of a Block and therefore these properties are Area specific and influence the Block's rendering within that Area only. How a block interprets these properties is up to the implementation of that Block and even as simple as utilising these properties in a custom View template.
EDIT: example - $a->setBlockProperties($block,$propertiesArray);
For example, if I am able to set a couple of properties into any Image Block within a given Area (say a maxWidth and maxHeight value for example), I would then be content to write a custom View template for that block that utilises these properties. Equally, you could imagine further settings that may influence the nature of any automated modification such as the "zoom" feature I mentioned earlier or any other designer desired feature like grey-scale only images etc.
Therefore, could part of the solution be the passing of a generic properties map into Blocks via the Area?
Disclaimer: I'm no c5 expert so apologies if I've bypassed something that already exists or been oblivious to.
Regards,
Dan
Is the Area the right place for this? It feels too high up the chain if you ask me and a little too specific.
In my opinion, it feels like it should be something that we can set into a Block via the Area in much the same way as we can set custom templates for specific Blocks within a given Area.
More specifically, an abstract method to set some properties of a Block and therefore these properties are Area specific and influence the Block's rendering within that Area only. How a block interprets these properties is up to the implementation of that Block and even as simple as utilising these properties in a custom View template.
EDIT: example - $a->setBlockProperties($block,$propertiesArray);
For example, if I am able to set a couple of properties into any Image Block within a given Area (say a maxWidth and maxHeight value for example), I would then be content to write a custom View template for that block that utilises these properties. Equally, you could imagine further settings that may influence the nature of any automated modification such as the "zoom" feature I mentioned earlier or any other designer desired feature like grey-scale only images etc.
Therefore, could part of the solution be the passing of a generic properties map into Blocks via the Area?
Disclaimer: I'm no c5 expert so apologies if I've bypassed something that already exists or been oblivious to.
Regards,
Dan
My two, pence
Would love to be able to pass the dimensions in and really like the Area option,
Setting at the block level would be good, but the problem then require the client to change the settings if they move the block? ie move the block from the sidebar at 200px to the header where the image is the full width of the page. I know its not difficult to do if it where a custom template but it would be nice to do it automatically. (Though maybe this could involve a similar $a->setCustomTemplate($block, "template");
ie $a->setRatioDimensions($block,$w,$h);
)
For me an ideal solution would be nice to have the option cascade, so I could set the dimensions at the area level and then if defined at the block level it would override the areas setting.
- Sean
Would love to be able to pass the dimensions in and really like the Area option,
Setting at the block level would be good, but the problem then require the client to change the settings if they move the block? ie move the block from the sidebar at 200px to the header where the image is the full width of the page. I know its not difficult to do if it where a custom template but it would be nice to do it automatically. (Though maybe this could involve a similar $a->setCustomTemplate($block, "template");
ie $a->setRatioDimensions($block,$w,$h);
)
For me an ideal solution would be nice to have the option cascade, so I could set the dimensions at the area level and then if defined at the block level it would override the areas setting.
- Sean
I like Jordan's idea for an area option, giving control to a theme developer.
I like Sean's inheritance and override extension to the idea even more.
I like Sean's inheritance and override extension to the idea even more.
@dbaggs - can't tell from your post if you're aware that the block-specific functionality you're talking about is in 5.5.2 -- I think it's only implemented in the Image block, but it could be implemented in other blocks if the developers are inclined to do so.
My idea is basically what @TheRealSean mentioned -- that the theme designer could provide "fallback dimensions" in the area, but they could be overridden on a per-block basis.
My idea is basically what @TheRealSean mentioned -- that the theme designer could provide "fallback dimensions" in the area, but they could be overridden on a per-block basis.
Hi Jordanlev,
As you can tell, I wasn't aware of that so thanks for the tip. I'm only a "weekend" c5'er so to speak, so my exposure to the broader code base is not too in-depth.
I still feel that a dimension related named method on the Area object feels too specific, regardless of its role as a fall-back. I'm in agreement with you over the need to get fall-back dimensions to the blocks that need it though.
Given that you say you can set Area specific property values and a Block can access them, I think the solution is mostly in place. A 'setDimensions' method on the Area feels too much like 'it fixes my problem today' and by name, it has a very finite scope. By contrast, the setting of properties via the Area is abstract enough to be applied across different Blocks for different Use Cases. i.e. Setting the fallback max dimensions for an Image Block through the Area properties but also perhaps setting a property that is read by a Video Block that auto-plays when it is in the main central content Area when by default it would not or passing a property that plays a video without the playback controls etc.
These things should typically be under a developer/site designer's control - creating a custom Block template achieves this and negates the need to build these options into a customised Block with such properties persisted to the database.
Regards,
Dan
As you can tell, I wasn't aware of that so thanks for the tip. I'm only a "weekend" c5'er so to speak, so my exposure to the broader code base is not too in-depth.
I still feel that a dimension related named method on the Area object feels too specific, regardless of its role as a fall-back. I'm in agreement with you over the need to get fall-back dimensions to the blocks that need it though.
Given that you say you can set Area specific property values and a Block can access them, I think the solution is mostly in place. A 'setDimensions' method on the Area feels too much like 'it fixes my problem today' and by name, it has a very finite scope. By contrast, the setting of properties via the Area is abstract enough to be applied across different Blocks for different Use Cases. i.e. Setting the fallback max dimensions for an Image Block through the Area properties but also perhaps setting a property that is read by a Video Block that auto-plays when it is in the main central content Area when by default it would not or passing a property that plays a video without the playback controls etc.
These things should typically be under a developer/site designer's control - creating a custom Block template achieves this and negates the need to build these options into a customised Block with such properties persisted to the database.
Regards,
Dan
If someone have time to consider this :
http://www.ajax-image-editor.com/...
http://code.google.com/p/paintweb/...
http://code.google.com/p/svg-edit/...
Or adapt this :http://drupal.org/project/imageeditor...
http://www.ajax-image-editor.com/...
http://code.google.com/p/paintweb/...
http://code.google.com/p/svg-edit/...
Or adapt this :http://drupal.org/project/imageeditor...
To use Picmonkey now instead of Picnik, put the attached file (image.php) in /elements/files/edit/ (not in /concrete/elements/files/edit/)
Nice work, thank you for this. I have been finding Jcrop a bit clunky for editing larger images or needing to crop images wider then the default image.
This scratches that itch and really nice to use.
Please award yourself 100 internet points. :)
This scratches that itch and really nice to use.
Please award yourself 100 internet points. :)
Thanks!
How does the header image on the yogurt theme have a predefined crop area for the header image in the composer?
I realize that I didn't post about my little PicMonkey package here. So here's the link :https://www.concrete5.org/marketplace/addons/picmonkey-image-editor/...
Hi I have used Picmonkey - it is seems good but after discovering that it had no transparency when scaling images I ditched it. It also doesn't address the problem of predefining thumbnail sizes and having a crop window for thumbnails while keeping the original. And it is slow. But it is feature rich and a good free addon. Just not for me.
I think thumbnail creation should be built into the core as discussed. Why does Wordpress have this feature in the filemanager yet concrete5 doesn't?! Is there too many variables involved to have this much needed thumbnail option?
Why would concrete5 have to rely on third party image cropping for thumbnails?
For me the ideal scenario would be to define thumbnail sizes and then in the filemanager have an option next to edit as - create thumbnail which gives the option of the predefined sizes. Then when you edit the thumbnail there in a crop window (the right size) like in the cropzoom demos.
I have also noticed that the whole image core image editing is a bit buggy anyway. The crop window shows the wrong size dimensions. When you click undo the window size goes weird and when you save the timer goes on forever. I had to make excuses for all of this to my client yesterday, but I don't know the real reasons.
This is the first site I have built on Concrete5 and I think it is excellent, it is just the image editing core which I think needs more attention.
I think thumbnail creation should be built into the core as discussed. Why does Wordpress have this feature in the filemanager yet concrete5 doesn't?! Is there too many variables involved to have this much needed thumbnail option?
Why would concrete5 have to rely on third party image cropping for thumbnails?
For me the ideal scenario would be to define thumbnail sizes and then in the filemanager have an option next to edit as - create thumbnail which gives the option of the predefined sizes. Then when you edit the thumbnail there in a crop window (the right size) like in the cropzoom demos.
I have also noticed that the whole image core image editing is a bit buggy anyway. The crop window shows the wrong size dimensions. When you click undo the window size goes weird and when you save the timer goes on forever. I had to make excuses for all of this to my client yesterday, but I don't know the real reasons.
This is the first site I have built on Concrete5 and I think it is excellent, it is just the image editing core which I think needs more attention.
Can this thread turn into a list of options? That'd really help us..
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz