Ticket
use attachment fu for uploads+issues
addresses many image/file issues:
undesirable file names
handling large images
Sometimes when people upload a new image to an existing image card, it doesn't take
possibly more:
Ticket
ability to rename files and images+issues
The file name on the server (which will be the file name when users download the file), not the name of the card.
Should this be pending use attachment fu for uploads? --John Abbe
yes, name is based on your original filename now, if you don't like it change locally and re-upload :)
--Lewis Hoffman.....Fri Apr 24 10:46:38 -0700 2009
ability to rename files and images+discussed in support tickets
Ticket
Uploaded a file http://processarts.wagn.org/wagn/Process_PL_Nancy and the file name had an s trimmed from it - what's up with that?
Irrelevant if we leave uploaded file names as given.
--John Abbe.....Thu Oct 16 12:35:16 -0700 2008
Subsumed in use attachment fu for uploads. (Right?)
--John Abbe.....Sun Mar 08 21:02:04 -0700 2009
stop over-regularizing file names+discussed in support tickets
Development Tickets (by status)
Ideas
Documentation Tickets
Support Tickets
Development Tickets (by status)
Ideas
Documentation Tickets
Support Tickets
use attachment fu for uploads+solution
Image Urls in relation to file or database storage
generically, the url of images will be /$path/$name$size.$ext
$name could be taken either from the original filename, or the name of the card. my inclination is cardname. $ext would be taken from original file. In neither case is the url necessarily stable: the filename or extension could change on subsequent uploads. however if we use cardname then the uniqueness of the name is already preserved. $size is the optional extension for resized versions of the image, ie. "_thumb"
$path depends on implementation. If we want to be able to serve files directly from apache, then the web path must match the filesystem path, and the filesystem path needs disambiguation between multihosted wagns and probably should have a couple of levels of subdirectories to avoid overloading one directory, ie. /card_images/$wagn_id/0003/0204/$name$size.$ext
If we're willing to give up that optimization and go through the database then we can use the same path as regular cards, /$name$size.$ext or /wagn/$name$size.$ext
Files and images
Allow file/image name on server to be different from the card's name.
(We were changing the file's name to match the card name if that was predetermined.)
If the card name is not already specified when the file is uploaded, fill in the card name with the name of the uploaded file. Allow 'illegal' characters - they'll be checked on card creation.
Question: Does the cardname keep or delete the extension?
Keep content view as the name of the file, linked to the file. (We considered "Download" or "Download " linked to the file.)
Images
in inclusions, people can add:
|size:full (size as uploaded)
|size:icon (16 pixels max height/width)
|size:small (75)
|size:medium (200) - default if no size is specified
|size:large (500)
images are scaled up/down to all those sizes when uploaded
if any included card is in content view, pass CSS (e.g. |height: and |width:) in rather than apply it to the card
(if that becomes hairy, push to post-1.0)
When editing an image card that already has an image, something like this:
Current image:
|show current image, size:small|
|text box| Browse...
|checkbox| Delete picture (but keep card)
Save Cancel Delete |cardname|
Question: did we come up with where/how in there to let people remove the current image without uploading a new one?
No. Suggest "Reset to Blank" link below the current image.
view (line) not supported for use attachment fu for uploads+solution+more thoughts
I'd like to be able to resize an image in a Wagn card simply by dragging its corner (when I click edit). When I drag the corners it also shows the current size of the image. Deki Wiki has a very good example of this. This won't resize the original image, just that instance of the image. --Scott Keeler
(Scott, i combined what you wrote into one comment here...)
Just for clarity's sake, if you're editing the image card, that seems like it should affect it in all contexts. If you want to resize it only in a given context, i can see adding inclusion syntax (i suggested some above in +solution), but don't have any brilliant ideas about how to do it in-GUI. In View mode? Hm...
--John Abbe.....Tue May 06 09:06:57 PDT 2008
we wanted to be sure you were aware of this issue (will ticket it after this email) so that it could be addressed in a future update. if you create an image card with an image that is .jpg (for example) and then want to edit the image and upload a .gif, the image won't update. it seems to embed/internalize the extension so you don't actually see it when you are viewing or editing the card (you could view the source, but we are after easy user experience) and then when you try to upload, it doesn't give you any message of why it isn't working. so, you have to create a new card and upload the other file there. ideally, you would be able to upload a new image by editing that card regardless of file extension.
--Amy Sample Ward.....Wed Sep 03 15:07:57 -0700 2008
New ticket?:
Rename card name when file with new name has been uploaded ?
--John Abbe.....Wed Feb 25 13:33:11 -0800 2009
Not sure what this note in the EtherPad meant:
No change to key; no change to card's name
--John Abbe.....Wed Feb 25 13:33:31 -0800 2009
Lewis researching:
Whether there will be a problem with uploading files/images with the same name as an already-uploaded one.
Also researching (if we do want to offer a stable URL to the current image in a card):
Web browser handling of image versions - is there something we can do so that the browser knows to reload the image when it's been changed?
--John Abbe.....Wed Feb 25 13:44:43 -0800 2009
When testing, check: change underscores to spaces in image names
--John Abbe.....Sun Mar 08 21:03:57 -0700 2009
code is up and running on sandwagn
--John Abbe.....Tue Apr 07 09:11:14 -0700 2009
Uploading with no card name isn't yet filling in a card name
Currently defaulting to small, rather than designed medium - on purpose? Related thought: Do we want default in inclusion and when looking at card on it's own page to be the same? (inclined to default to full on it's own page)
Tried to upload a non-image file to an image card and in the place the image would appear, got the working header bar of a Wagn page (even did a search :-).
Had a .png in an image card - ((removed reference to sandwagn)) - edited the image on my computer and saved it as .jpg. Tried to upload new image to same card, and got the same behavior as with non-images (just above here), and continued spinning and "Uploading..." (didn't notice if that was happening with non-image files)
not implemented yet in edit interface:
Delete picture (but keep card)
any reason not to merge http://wagn.org/wagn/use_attachment_fu_for_uploads+solution+more_thoughts into http://wagn.org/wagn/use_attachment_fu_for_uploads+discussion ?
—John Abbe, April 7, 2009
Looks like *logo is resizing to small? That i'm pretty sure we want to be full.
--John Abbe.....Tue Apr 07 17:35:40 -0700 2009
Uploading to ((removed reference to sandwagn)) (new card) or ((removed reference to sandwagn)) gets eternal spin
--John Abbe.....Sat Apr 18 08:33:50 -0700 2009
http://johnabbe.wagn.org/wagn/logo_all_sizes - full broken still
--John Abbe.....Wed Apr 22 08:31:20 -0700 2009
10-40 seconds to upload a 240K image seems long.
--John Abbe.....Wed Apr 22 16:45:00 -0700 2009
working backwards:
- 10-40 seconds; 40 seconds is slow for sure.. since the upload goes to Amazon my inclination is to blame Amazon. let's keep an eye on it if it stays bad can will dig in further.
- sandwagn: broken bucket, fixed now
- *logo: using default, which is now medium
- discovered buckets broken for new wagns in cluster: Fixed!
- 1st ticket above: renaming file: name is based on your original filename now, if you don't like it change locally and re-upload.
- todo (thinking after 0.13 for all these)
- keep eye on upload times (have seemed ok to me lately)
- auto-fill card name from image name
- fix full view for gifs fix full view for images
- option to delete
- handle mismatched/invalid mime types (at least decent err msg)
--Lewis Hoffman.....Fri Apr 24 10:13:31 -0700 2009
by far most common problem to date seems to be missing/misconfigured buckets. first thing to check if there are problems. we have easy cap task to create bucket. Also, hoptoad does indeed rock.
--Lewis Hoffman.....Fri Apr 24 10:49:01 -0700 2009
That file is still taking forever to upload, will just add it to the new ticket unless someone says otherwise.
(want to fix that now or add to new ticket?)
--John Abbe.....Fri Apr 24 13:43:13 -0700 2009
New ticket to polish up new file and image uploading
--John Abbe.....Fri Apr 24 18:06:52 -0700 2009
I'm looking for an existing ticket on image sizes, and this is the most related I've found.
The requested "resize" feature might be nice too, but the set of allowed images sizes in really limiting, and they are absolute so there is no way to get a similar display size for all resolutions at the client.
The "large" is too small for many cases, leaving "full" as the only viable option with the image file rescaled externally.
Suggestions:
Add a bigger size option: xlarge or something
Have a user preference so that images a user can make all images bigger just for them
Have a numerical view size option (% of large maybe? 200 would give you 2*500=1000)
--Gerry Gleason.....Fri Dec 04 06:08:13 -0800 2009