Closed Bug 494096 Opened 13 years ago Closed 12 years ago

Uploading an image should automatically add the thumbnail


( :: Knowledge Base Software, task)

Not set


(Not tracked)



(Reporter: cilias, Assigned: paulc)




(Whiteboard: sumo_only)


(1 file)

When editing an article, if you want to add an image, you need to upload it, then either save or preview the edit, before the thumbnail is available to add the uploaded image to the article. That is very confusing. The image should automatically be available to add to the article, upon upload.
The UX needs to be more specific in order to fix this though. How should the process of uploading an image be? How do you initiate the upload to get that automatic thumbnail?
The screencast implementation has an Upload button right next to the Browse button. Image uploading should behave the same way as screencast uploading.
Target Milestone: --- → 1.4.1
Target Milestone: 1.4.1 → 1.4.2
Eric, have some input on how to make this behave like screencast uploading, since you implemented those?
Assignee: nobody → paulc
FTR, I've started on this and it looks alright. Should be done by Friday, maybe sooner.
Attached patch v1Splinter Review
* Updates tiki-editpage.tpl templates to add new markup
* Adds a JS file webroot/js/upload_picture.js which handles the uploading
* Uses similar code from screencasts
* Updates some JS in the footer which was giving errors (noticed while debugging)

I thought of removing the insertImgFile() JS function to reduce our script size for all pages, but this is being used in attachments (e.g. line 452 of mozkb/tiki-editpage.tpl). I decided against it for upstreaming&p12n.
Attachment #407954 - Flags: review?(james)
Attachment #407954 - Flags: review?(james) → review+
Comment on attachment 407954 [details] [diff] [review]

Works great, very nice.
r54488 (trunk).
Closed: 12 years ago
Resolution: --- → FIXED
Do I need to cover the JavaScript-disabled case here?  What range of browsers should we be supporting?

I've taken a cursory look already, and it's looking pretty good; Chris, if you get a chance to take a look too, that would be great.
Tested on*Cannot+connect+after+upgrading+Firefox

I selected the image in the file chooser, then clicked [Upload] but no thumbnail was displayed.
Screencast: <> [4.4M]
Resolution: FIXED → --- - 404 Not Found

Paul, looks like you just forgot a file.
r54553 and r54556 (double patched...)
Good catch James. Sorry about that. Now it's good, I tested it on the testupload article:
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
r54610 (prod), r54611 (fennec)
Whiteboard: update contributor docs
Whiteboard: update contributor docs
Whiteboard: tiki_bug
There were several changes regarding this. The upload picture feature morphed and is now merged with file galleries as a default behavior. At this time, it's still possible to revert, but those days are probably numbered.

The upload picture shortcut is now accessible from the toolbar and opens an other window. Thumbnails seem to work as expected.

This may be sumo_only now.

There is something about ajax uploads in there. It might be worth looking into. What does the feature do exactly?
Whiteboard: tiki_bug → tiki_bug, tiki_discuss
This bug was mainly about not having to save the page to upload an image, on tiki-editpage.php

See comment 0 and comment 2 for the functionality desired. In short: yes, the ajax uploads are the most important part and basically what this bug is about.
LPH: let us know if you need more clarification. Removing tiki_discuss to indicate Paul's answer. :)
Whiteboard: tiki_bug, tiki_discuss → tiki_bug
The file upload now opens a separate window, so the entire edit page reloading is no longer an issue.

Is this a suitable solution to you?

Otherwise, I need to look at the ajax upload in details and see how it can be implemented as 100% of the code changed.
LPH: It sounds suitable to me, but if it's not too much trouble I'd still rather use this bug's approach (1), rather than (3). Of course, with JS disabled, (3) is better, since our approach reverts to (2), but, from our experience, I think <1% of users don't use JS, and contributors are almost certainly not part of those. See below.

Just to be sure, I'm cc'ing Chris too. Chris, David, James, feel free to add your thoughts. As I understand it from LPH, the behaviors sum up to:

(1) Current SUMO:
* use iframe to upload on the same page
+ no need for separate window
+ no need to reload page

(2) Previous SUMO:
- need to reload page (unnecessary)

(3) Current Tiki:
- use separate window
+ no need to reload page
Whiteboard: tiki_bug → tiki_bug, tiki_discuss
(1) is definitely the "hottest" and most modern approach. (3) would be acceptable but not preferable, as it's simply a clunkier experience.
For what it's worth, I'd throw my weight behind a non-popup/non-modal solution. It doesn't need to be exactly our solution, but I prefer to avoid popups and modal dialogs wherever possible from a UI standpoint.
Louis-Philippe: Any response to comments 19-21? It sounds like we have a pretty unanimous preference on the SUMO side.
As far as I am concerned, the current solution works. I agree it's not ideal, but bringing it there is additional work and is likely not as simple as it looks. Perhaps it can be marked for future improvement.
I don't like devolving the functionality that our users have already had. It's not high priority, but it looks like this is something we'll have to re-apply locally sometime after upgrade.
Whiteboard: tiki_bug, tiki_discuss → sumo_only
You need to log in before you can comment on or make changes to this bug.