494096 - Uploading an image should automatically add the thumbnail

Status: VERIFIED FIXED

(support.mozilla.org :: Knowledge Base Software, task)

Description

[Chris Ilias [:cilias]]

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.

Comment 1

[David Tenser [:djst]]

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?

Comment 2

[Chris Ilias [:cilias]]

The screencast implementation has an Upload button right next to the Browse button. Image uploading should behave the same way as screencast uploading.

Comment 3

[Paul Craciunoiu [:paulc]]

Eric, have some input on how to make this behave like screencast uploading, since you implemented those?

Comment 4

[Paul Craciunoiu [:paulc]]

FTR, I've started on this and it looks alright. Should be done by Friday, maybe sooner.

Comment 5

[Paul Craciunoiu [:paulc]]

Attachment: v1

* 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.

Comment 6

[James Socol [:jsocol, :james]]

Comment on attachment 407954 [details] [diff] [review]
v1

Works great, very nice.

Comment 7

[Paul Craciunoiu [:paulc]]

r54488 (trunk).

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

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.

Comment 9

[Chris Ilias [:cilias]]

Tested on https://support-stage.mozilla.org/en-US/kb/*Cannot+connect+after+upgrading+Firefox

I selected the image in the file chooser, then clicked [Upload] but no thumbnail was displayed.
Screencast: <http://ilias.ca/sumo/imageupload.ogg> [4.4M]

Comment 10

[James Socol [:jsocol, :james]]

https://support-stage.mozilla.org/tiki-upload_picture_ajax.php - 404 Not Found

Paul, looks like you just forgot a file.

Comment 11

[Paul Craciunoiu [:paulc]]

r54553 and r54556 (double patched...)
Good catch James. Sorry about that. Now it's good, I tested it on the testupload article: https://support-stage.mozilla.org/tiki-editpage.php?page=testupload

Comment 12

[Chris Ilias [:cilias]]

Tested on https://support-stage.mozilla.org/en-US/kb/*Cannot+connect+after+upgrading+Firefox and it worked!

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED on https://support-stage.mozilla.org/tiki-editpage.php?page=testupload.

Comment 14

[Paul Craciunoiu [:paulc]]

r54610 (prod), r54611 (fennec)

Comment 15

[Louis-Philippe Huberdeau]

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?

Comment 16

[Paul Craciunoiu [:paulc]]

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.

Comment 17

[David Tenser [:djst]]

LPH: let us know if you need more clarification. Removing tiki_discuss to indicate Paul's answer. :)

Comment 18

[Louis-Philippe Huberdeau]

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.

Comment 19

[Paul Craciunoiu [:paulc]]

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

Comment 20

[David Tenser [:djst]]

(1) is definitely the "hottest" and most modern approach. (3) would be acceptable but not preferable, as it's simply a clunkier experience.

Comment 21

[James Socol [:jsocol, :james]]

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.

Comment 22

[James Socol [:jsocol, :james]]

Louis-Philippe: Any response to comments 19-21? It sounds like we have a pretty unanimous preference on the SUMO side.

Comment 23

[Louis-Philippe Huberdeau]

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.

Comment 24

[James Socol [:jsocol, :james]]

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.