Yes I think that's quite important.
I am still thinking about the possibility to implement some general multipurpose "custom fields" - that would be great ;)

Those fields also should be displayed not at the bottom of the page, but at the top along with other information..

This one looks great and is already using bootstrap so can be fastly integrated:

http://blueimp.github.com/jQuery-File-Upload/

The only question is the license. Are we allowed to use MIT license components?

We should be OK with MIT licensed items. Same question came up about the use of lessphp in the core, and as long as we used it as MIT and not GPLv3, we'd be good to go.

+1 for the blueimp script(s).

I added some more notes to the issue just to give whomever works on this an idea what we should expect based on what's already in place on jcode.

Discussing this with David and Chad here at CoderFaire, we're in agreement that we don't feel the need for a file upload system anymore. GitHub allows you to attach images now and we're trying to encourage folks to use PRs for patches instead of uploading diff files, and there's plenty of free services to hang other files.

Thoughts?

I think we should provide an option to upload images if an issue is submitted via the tracker application.
For that matter, I like the way the Jetbrains tracker displays uploaded images as thumbnails and the full size on hover. As opposed to the GitHub "way" of displaying them embedded in the text. I believe that might become quite annoying when people starting to upload their "full screen" screen shots.

Of course we can also use one of the freely available picture upload services - I would only vote for this option if we run out of space on our own servers... Otherwise it would be very time consuming for testers and coders.

As for the patch upload... I remember that every time we touched that topic, somebody stepped up telling that he/she would really prefer to upload a patch instead of fiddling with GitHub..
So - I believe if we are able to implement this, we should do it instead of losing contributors.

As an (unrelated) side note, in case you haven't read it already: Are we taking care of our own?

That blog post and @pmjones keynote here at CoderFaire yesterday (see http://paul-m-jones.com/archives/4691 for slides) are really thought provoking.

So back on topic

At the least, we should at least tie in with the upload API (if it's available) to keep with the motion of having the content in the issue and comments the same. Perhaps the one thing we do differently in rendering is that we use Joomla\Image to go down to a thumbnail sized image inline (if there's not an endpoint for that already in GitHub) instead of the full-sized image.

@davidhurley 's argument against the direct attachments at this point is that we really want to move towards a more GitHub oriented workflow, and keeping that option readily available doesn't go with that. We already require GitHub accounts to work with the app, so folks will have access to Gist. Even if they don't want to figure out how to do a PR, they can at least paste into Gist. @dongilbert also brings up that there's the Gist API so we could do something with pasting the content there and the Gist piece is handled for the user.

I haven't seen an upload API yet but that would be interesting. But you now, a picture says more than 1000 words so I think additional media is somewhat important..

The idea of using Gists instead of just "attaching" patch files is pretty good, we should work on that.
Of course I am all in favor of using GitHub pull requests as the first choice -- provided they are "GitHub merged" including all their commits, otherwise they are somewhat pointless and a simple patch file would have the same result with sometimes less effort.

Well we could try with GitHub and then see how it goes.

If we dont have the ability to upload things such as screenshots then we are not solving the big problem. Having a single point of truth for the issue tracker. It is one thing to expect people to create pull requests over at github but if we have to have testers/reporters doing that as well just so that they can upload a screenshot we are no better off than now with two separate trackers. my 2c

Well @brianteeman is right. I could start to implement it after fixing the current issues we have :)

So the first step was made ;) See here a workable UI. I decided to go with the Blueimp scripts. Currently UI supports only image uploads (JS validated). As you can see it has full features like upload/download preview. You will also notice that it generates markdown inline code for the images. Of course drag&drop is also available.

There is no Upload API currently - all the simple logic is inside the controllers: Put/Delete. So no validation, image resizing and etc.

Questions to discuss:

• do we need the full UI (like on my demo), some minimal version like here or the simplest one (drag&drop + upload button)?
• will we stick with the inline code or will support full "Media App": storing all uploads in the DB, manage them, showing them in some way and etc?

Looks great to me as it is

Maybe add a text string "Upload image files only"

On 19 November 2013 08:08, Dmitry Rekun notifications@github.com wrote:

So the first step was made ;) See herehttp://tracker.j-esports.com/tracker/jtracker-bugs/215a workable UI. I decided to go with the Blueimp scripts. Currently UI
supports only image uploads (JS validated). As you can see it has full
features like upload/download preview. You will also notice that it
generates markdown inline code for the images. Of course drag&drop is also
available.

There is no Upload API currently - all the simple logic is inside the
controllers: Put/Delete. So no validation, image resizing and etc.

Questions to discuss:

• do we need the full UI, some minimal version like herehttp://tutorialzine.com/2013/05/mini-ajax-file-upload-form/or the simplest one (drag&drop + upload button)?
• will we stick with the inline code or will support full "Media App": storing all uploads in the DB, manage them, showing them in some way and etc?

—
Reply to this email directly or view it on GitHub#18 (comment)
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Maybe add a text string "Upload image files only"

Easy, but this text depends on my questions in the previous comment.

As I said I would keep it exactly as you have made it right now. Images only and nice and simple. For an example of the test strings see the blueimp demo notes http://blueimp.github.io/jQuery-File-Upload/index.html

Ok I got it :) So @brianteeman votes for the "images only" with the full UI ;)

"Images only" basic UI - great job @b2z

@elkuku thanks. Basic UI = full UI?

BTW @elkuku @mbabker I found a simple Upload API that we could use. The only problem is that messages will not be translated. Dunno how to bypass it...

Maybe being stupid, but why have an upload ability at all if you can simply place the images in the textarea?
Or better yet? Why not implement the same editor abilities as the editor here on github (simply drag image into editor).

I think I am even more stupid... how do you "simply place the images in the textarea" ?

Uploading them by dragging them to the textarea - that would be also my favorite option - just like GitHub does

You can, of course, upload them to any of those pic dumps and use the markdown syntax to include them - or is it this what you meant by "simply placing them" ? :)

By dragging and dropping but you cant do that on all browsers

@elkuku There is an insert image option in that editor:

So, yes, I mean with the markdown.

Why not implement the same editor abilities as the editor here on github (simply drag image into editor).

@nonumber that is one of the options. See my comment. We should stick with the one or leave it as is - full UI + drag&drop ;)

There is an insert image option in that editor:

We can remove it or leave for an external images uploads.

So yeah - drag & drop for supported browsers, and a button for those unsupported ;)
If we can explore the PHP core upload progress - that would be also very cool ...

@elkuku what do you mean by core upload progress?

Well I mean this, but since it's PHP>=5.4 we may shoot an e-mail to Rochen begging them to update their PHP to a current version.

On the blueimp demo upload progress is working fine. As I understand it is styled with JS+CSS only. But I do not know why it is not working on my demo, because all CSS files are in place. Strange... I need to investigate.

Ok I found the problem. There is a diff between BS 3.0 (as on blueimp demo) and BS 2.3 classes' names. Fixed and now progressbar is working

So where did we stop? I need to know the next steps :) We will stay with the full UI or?

@elkuku @mbabker I tried this Upload API. It is good, but does not support array of files I corrected constructor with the few lines of code like this:

if (!is_array($_FILES[$key]))
{
    $this->originalName = $_FILES[$key]['name'];
    $this->errorCode = $_FILES[$key]['error'];
    parent::__construct($_FILES[$key]['tmp_name']);
} else {
    $this->originalName = $_FILES[$key]['name'][0];
    $this->errorCode = $_FILES[$key]['error'][0];
    parent::__construct($_FILES[$key]['tmp_name'][0]);
}

But this does mean that we have two options:
1. Do not update it (bad).
2. Fork it and make own one based on this (?).

What do you think?

I would support only single file upload - as on GitHub ;)

I would support only single file upload - as on GitHub ;)

But GitHub supports multiple...

ups, you're right, never tried that...
What if you make a PR to the repo ? sounds like a useful addition ;)

What if you make a PR to the repo ? sounds like a useful addition ;)

I can, but the author seems to be inactive :( And my solution is not the ideal...

So I've cheated a little bit I've created class File which extends class File from the Upload API and in the constructor modified $_FILES

BTW I pushed the branch uploads and you can checkout how currently it is implemented ;) I squashed everything into the one commit 62fb465.

If you want to test it you will need to run bower install and composer install/update to get vendor files.

I am on the final stage and have a question to discuss - do we want all our uploads to be in the same uploads dir?

⇒ #251