One of the workarounds I've just tried is using default filename=<page name>. I can hide the form input and choose a name automatically, so all the user sees is an "upload here" button.

Then, they see a place to upload their file, which already has the the new (random) name filled out for them. The random name is also the name of the page the form is supposed to edit, but with File: tacked on the front of it. I haven't gotten this to work yet, but even if it does, I've already noticed a problem that will make it fail:

default filename=<page name> does not include the file's extension!

I'm going to fiddle around with it some more to see if it would work if an extension were included. If it does, then maybe that will be a quick and dirty way to get this working, by modifying the code that deals with <page name> to also grab the file's filename.

I'm not sure if it can get the file name, but this seems like an easy solution if it can.

It appears the workaround does not quite work (I have to manually edit stuff to get it to work). It still could be the basis for fixing this problem, but I don't think it'll provide a very good solution since the user would not be able to name their own file.

I'm going to abandon that technique and try something else.

There is a workaround described here that I have tested:

http://old.nabble.com/Semantic-Forms-cannot-create-file-pages-tt32127155.html

Although it works well, I have to use a dedicated form for it since Semantic Forms can't work with more than one page at a time, even though it can handle more than one file upload at a time. It would be simpler if SF could add and populate template pages for unlimeted numbers of uploaded files mixed with normal pages, also.

Since uploads are already a feature of SF, a logical further step is to make SF able to create and/or edit multiple pages simultaneously, including file uploads.

For example, this would allow creation of a form to be used as an image property editor. If I've got a variety of images on a page (or pointing to/from the page with properties and queries), I could edit the properties for all image pages simultaneously. That would be handy if only one of the images is supposed to have a certain property, like a designation as the main image for the article.

Multiple page editing will probably be a nice consequence of adding the feature requested initially in this report.

Marking bug as "invalid" - from what I can tell, what is being requested is already doable in SF. Feel free to re-open the bug if not.

I've mostly finished going through the file uploading functionality of Semantic Forms during the past week, and I've found several bugs and corresponding workarounds. I could post a whole bunch of bug reports, or I could reopen this one and just lay it all out. I did a good job of documenting them within the comments of the test code I used, to explain what is happening, where, and how to workaround it, so if you're OK with it, I can just plop it here and let you have a look before reopening this.

In general, I think SF could use an overhaul of how it handles file uploading, and the bugs I've found are a good place to start. The worst part by far of all of this is MediaWiki's upload system in the lightbox. I'm completely stumped on how to even begin to work around problems I've found with that. I haven't written them down, but I could if it will help. I think it's mostly MediaWiki's problem, but the problems snowball into a disaster once they're combined with Semantic Forms, since the two products aren't capable of being glued together very well.

I'm not sure if the right solution to the uploading problems is to produce a custom uploader just for SF, or to redo the MediaWiki uploader to #1 make it more reliable in general, and to #2 make it more compatible with external calls from things like SF.

Now that I think about it, I better start writing down all the failures I encountered with the uploader before I forget, so I don't have to retest them all.

Below is a copy and paste of an image form.

You can see the form in action here for a fresh file upload (login: Demo/test):

http://www.coincompendium.com/wiki/index.php/Special:FormEdit/Image?&Image[uploadoredit]=upload

And here for an edit of an existing file (login: Demo/test):

http://www.coincompendium.com/wiki/index.php?title=File:Vulture.jpg&action=formedit

In the comments are descriptions of bugs, problems, and workarounds. I'm not sure how to break these up into individual bug reports since most of it seems to be closely related, so here it is in it's entirety:

<noinclude>
This is the "Image" form.
To create a page with this form, enter the page name below;
if a page with that name already exists, you will be sent to a form to edit that page.

Note that if you want to use this form to create file pages with the proper file page name, ignore everything above. You need to use special links to access the form. More info at: [http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Manual/Using_Semantic_Forms_for_file_pages_and_uploads Using Semantic Forms for file pages and uploads]

Rationale for strange curly brace templates used here:

		| :
		| 0

		| {{!}} restricted <!-- prevent editing of file name in upload field while CSS to hide it completely loads -->
		| {{!}} uploadable

		| {{PAGENAME}}
		|

		| [[{{FULLPAGENAME}} | 100x100px | middle | This is the image you are editing.]]
		|

		| ! style="vertical-align:middle;" {{!}} Image:
			{{!}} [[{{FULLPAGENAME}} {{!}} 100x100px {{!}} middle {{!}} This is the image you are editing.]]
			{{!}}-
		|

}}
}}<nowiki>

</nowiki>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div><nowiki />
<!-- Semantic Forms can't make file pages. Workaround is to manually specify the page to create using the page name parameter in the info tag with "File:" prepended to "<Image[File]>" https://bugzilla.wikimedia.org/show_bug.cgi?id=30034 --><nowiki />
{{{info | create title=Upload image | edit title=Edit image | page name=File:<Image[File]>}}}<nowiki />
{{{for template | Image | label=Basic facts about this image}}}<nowiki />
<!-- "Edit" radiobutton grayed out in Google Chrome on edit pages. --><nowiki />
<!-- uploadoredit radio button field parameters "mandatory" with "default=edit" fails to prevent "None" radiobutton from appearing on edit pages. No workaround available other than hiding the entire field. --><nowiki />
<!-- uploadoredit radio button field show on select fails to function when field is hidden, so must use MediaWiki:Common.css to hide uploadoredit CSS class. --><nowiki />
<!-- File upload field containing file name still shows sometimes, even with show on select correctly set to hide it, but "None" does not appear. Making two copies of uploadoredit radio button field with show on select causes it to hide correctly. Must use template-constructed field and conditional "uploadable" parameter to ensure upload link is still not available if field fails to hide. http://www.coincompendium.com/wiki/index.php?title=File:IMG_0943_crop_text.jpg&action=formedit --><nowiki />
<!-- File upload field containing file name still shows briefly before div id CSS is loaded to hide it on edit pages, which allows users to edit the file name field while believing incorrectly that they are able to change the file name. --><nowiki />
<!-- File upload field containing file name is editable after file is uploaded, which allows users to edit the file name field while believing incorrectly that they are able to change the file name. --><nowiki />
<!-- File upload field id input_5 used in MediaWiki:Common.js to prevent user editing of file name field after uploading completed. --><nowiki />
<!-- File uploading light box that contains MediaWiki's standard uploader causes problems on small screens because it can't be closed or scrolled while it's in a fixed-size & position lightbox. https://bugzilla.wikimedia.org/show_bug.cgi?id=30020 --><nowiki />
<!-- After a file is uploaded, it remains possible to click the "Upload file" link again, to repeat the process. Doing so will cause the previous file to be "lost" due to no semantic properties being applied without also clicking "Save page" at the bottom of the form. Unfamiliar users may do this if they do not realize they need to click yet another button at the bottom of the form, after they've already clicked "Upload file" on the MediaWiki file upload lightbox, and perhaps already filled out the form. --><nowiki />
<!-- Reuploading a file that produces warnings will cause Semantic Forms to fail if the user does not check "Ignore any warnings". The file might be uploaded, but "lost" due to the file name not being passed to the form, and the identical error repeating when the user gets warnings again if they try to reupload the file. This can also happen, for example, when the file has been previously deleted, possibly because it was previously "lost" in an identical circumstance, or a similar circumstance such as the one above where users continue to upload files without realizing they need to click a second button to "Save page". I'm sure there are other ways this particular bug can be triggered. --><nowiki />
<div class="hidden"> <!-- makes it so hidden uploadoredit fields below don't take up any space. Not necessary anymore to hide them with the uploadoredit CSS class, but whatever. --><nowiki />
{{{field | uploadoredit | class=uploadoredit | input type=radiobutton | values=upload, edit | default=edit | show on select=upload=>uploadfield;}}} <!-- Must duplicate this line to make buggy show on select hiding work. Workaround discovered by accident when accidentally pasting form code twice in form edit page. I don't know why it works. --><nowiki />
{{{field | uploadoredit | class=uploadoredit | input type=radiobutton | values=upload, edit | default=edit | show on select=upload=>uploadfield;}}} <!-- Must duplicate this line to make buggy show on select hiding work. Workaround discovered by accident when accidentally pasting form code twice in form edit page. I don't know why it works. --><nowiki />
</div>

{| class="formtable"
{{#var: show image being edited}}
! style="border-bottom:1px solid black;" | File:

<div id="uploadfield">{{(((}}field {{!}} File {{!}} mandatory {{#var: restricted uploadable}} {{!}} default filename=image {{#time: U | now}}.jpg{{)))}}
If your upload is not a '''.jpg''' file, be sure to change the '''Destination filename''' to have the correct file extension (.jpg .png .gif .pdf, etc).
Please click the checkbox that says "'''Ignore any warnings'''" at the bottom of the upload screen.<br />
{{hidden begin

		| toggle     = left
		| title      = Help info and examples.
		| titlestyle = background:lightgrey;

}}
Please upload an unaltered version of your image '''''for archival purposes'''''. If you need to make minor adjustments to your image before uploading (like [http://en.wikipedia.org/wiki/Cropping_(image) cropping]), try using [http://pixlr.com/ Pixlr].

If you need to make notes on an image, instead of drawing diagrams on it (the old way), use the ImageAnnotator (the new way):

{| class="wikitable"
! style="text-align:center;" | The old way
! style="text-align:center;" | The new way

{{hidden end}}
</div>

! style="border-bottom:1px solid black;" | Belongs to:

What CC number is this image for? It could be for a type, sighting, specimen, or some other page. Separate multiple entries with a comma.<br />
Example: '''CCT1, CCS2, CC3'''

! style="border-bottom:1px solid black;" | Image of:

{{{field | Image of | input type=checkboxes | values=

		Obverse,
		Reverse,
		Slab front,
		Slab back,
		Detail,
		Altered,
		Set,
		Box,
		Certificate,
		Accessory,
		Documentation,
		Screenshot,
		Other

}}}
{{-}}
{{hidden begin

		| toggle     = left
		| title      = Help info and examples.
		| titlestyle = background:lightgrey;

}}
<gallery> <!-- galleries break if there's whitespace formatting around the file name, because file names can have validly have white space --><nowiki />
File:1989GWWcto.jpg| '''Obverse''': "Front" side only. [http://en.wikipedia.org/wiki/Obverse_and_reverse]
File:1989GWWctr.jpg| '''Reverse''': "Back" side only. [http://en.wikipedia.org/wiki/Obverse_and_reverse]
File:1989GWWo.jpg| '''Slab front''': Usually displays the obverse of a coin, and has the label.
File:1989GWWr.jpg| '''Slab back''': Usually displays the reverse of a coin.
File:1995 1 oz silver proof panda with white spots of death 2.jpg| '''Detail''': Highlights a detail with a [http://en.wikipedia.org/wiki/Close-up close up] camera shot.
File:1995 1 oz silver proof panda with white spots of death 3.jpg| '''Detail''': Highlights a detail with a final image [http://en.wikipedia.org/wiki/Cropping_(image) crop].
File:1995 1 oz silver proof panda with white spots of death.jpg| '''Altered''': Has permanent annotation markings on the subject of the image (coin).
File:1995 1 oz silver proof panda with white spots of death 4.jpg| '''Altered''': Significantly "doctored" (Contrast adjusted high in this case).
File:1984 22 g silver ancient temple pagoda 4 coin set.jpg| '''Set''': An easily recognizable set of some sort.
File:1984 pagoda goldfish box and outer box.jpg| '''Box''': Some coins were originally sold with a presentation box or other container.
File:1984 pagoda COA.jpg| '''Certificate''': Certificate of Authenticity (COA), or other certificate.
File:1992 invention & discovery set compass toy.jpg| '''Accessory''': Booklets, toys, stamps, paraphernalia, or other accessories.
File:EMS China sample form.jpg| '''Documentation''': Receipts, forms, invoices, conservation reports, brochures, catalogs, etc.
File:2011-11-02 165547.jpg| '''Screenshot''': Image of the screen, usually of a website [http://en.wikipedia.org/wiki/Screenshot]
File:2010 Hong Kong Convention display case.jpg| '''Other''': Anything else. Please describe below.
</gallery>
{{hidden end}}

! style="border-bottom:1px solid black;" | Caption:

A short description of the image.<br />
Example: '''Close up of scratch near the date'''

! style="border-bottom:1px solid black;" | Main:

Images marked as "Main" are displayed on pages preferentially. If you're not sure, don't change this.

! style="border-bottom:1px solid black;" | Page creation date:

Now: {{#time: Y F d l H:i:s | now}} [http://en.wikipedia.org/wiki/Coordinated_Universal_Time UTC] ({{#time: U | now}})

{{{end template}}}

'''Free text''':<br />
'''Warning''': Do not delete "ImageNote" lines, if they are shown below. They are the code that displays annotations on an image without altering the actual image.<br />
Hint: if you want to reset this field to the default, delete everything above the "ImageNote" lines, if present, and then enter in only '''<code>{{subst::Template:Image form preload}}</code>'''

{{{standard input|free text|rows=25|preload=Template:Image form preload}}}

{{{standard input|summary}}}

{{{standard input|minor edit}}} {{{standard input|watch}}}

{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}
</includeonly>

In case I change something, here's the version pasted above:

http://www.coincompendium.com/wiki/index.php?title=Form:Image&oldid=7157

Created attachment 9452
I think the form will be easier to read if attached as a file.

I think the form comments will be easier to read if attached as a file.

Attached:

I decided to reopen this, since it requires a workaround to get it to function on a file page. I think that's because of the "File" namespace, which isn't dealt with automatically in SF, and has to be manually specified with the pagename parameter, like this:

page name=File:<SomeFileTemplate[FileFormField]>

Of course, that's just the beginning of difficulties in handling file pages. Other issues are in the comments of the form file I pasted and attached as a text file.

Let me know if there's anything that needs explanation, if there's anything else I can do for this.

I didn't really understand any of this. If there's more than one bug, you should create a separate bug report for each one, explaining the problem.

OK, I'll close this one and start over.

Changing back to "invalid" - as far as I can tell, this is still not an actual bug.

I think I originally marked it as an enhancement. Yes, it looks like it still is marked as an enhancement. Is it an invalid enhancement too? I don't see why it would be invalid.

It's invalid because it can already be done - you can create file pages with Semantic Forms.

leo_wallentin wrote:

Unless I am missing something, this workaround does not work when I'm allowing multiple files to be uploaded from the same field, right?

It has been a while since I looked at this, but if I remember correctly, the workaround does not work in that case. Most of my users have given up trying to use Semantic Forms for files. They get confused about the upload and page creation that happens without Semantic Forms, so they end up not saving the form and the file is "lost" due to missing semantic data needed to make it useful. If SF could handle the upload and create the file page, this issue would be resolved.

At some point I will need to consider whether getting into Semantic Forms code is going to be fruitful, versus putting together something independent that can handle file uploads in a way that doesn't confuse people. This isn't just a problem with Semantic Forms, MediaWiki has always been kind of clunky for files, although I haven't upgraded from MW 1.18.x yet, so maybe 1.19.x or 1.20.x will have something more practical.

If not, I've been curious about Lazarus + Free Pascal, and maybe a client side software bit is going to be more fruitful for such a problem. Hopefully before I get that far, a better solution will be ready.