Ticket

+commit
 
+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:

 

 

 

 

+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