Last modified: 2014-02-12 23:38:30 UTC
Created attachment 9454 [details] Full form for context context My workaround for this problem is some javascript and/or CSS to prevent the user from manually changing any text in the upload field. The JS prevents the cursor from gaining focus in the text of the upload field, and the CSS completely hides the field. Some ParserFunctions logic is used to conditionally display either the upload field for uploading a new file, or a thumbnail of the image file that is being edited. Many bugs and workarounds are at play. Here's the CSS: /* hides uploadeoredit radiobutton field that causes the upload field to appear when uploading, and disappear when editing */ .uploadoredit { visibility:hidden; !important;} Here's the JS: $(function (){ var input = document.getElementById("input_10"); if (input) { input.readOnly = true; } }); Note that the JS must be tailored for each form, and adjusted if the form is changed, since it accesses the specific field ID's, instead of classes. Field ID's found using source code view or something like Firebug. Here's the relevant comments from the form text: <!-- 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_10 used in MediaWiki:Common.js to prevent user editing of file name field after uploading completed. --><nowiki /> Basically, since CSS and JS load at different times, I'm using both methods to hide the upload field so it can't be edited, and I'm using the show on select method with a radio button. Many methods are used to hide the field because Semantic Forms does not handle file pages very well yet, so all possibilities of editing the field must be eliminated using all the methods here. I think one of them turned out to not be necessary in the end after I found another workaround that worked, but I left it in the code with its comments for completeness as a reference for when the bug is finally being reported.
I just discovered another related problem. Users that like to upload files from an URL are trying to enter in the URL into the upload field without clicking the upload link first to upload the file. It's resulting in pages like this, containing useless data: http://www.coincompendium.com/wiki/index.php/File:Http://honestsilver.com/CoinPhotos/3552444-004f.JPG In addition, the user is confused, and unsure what went wrong, so they end up either not uploading anything, or they use the link that says "No file by this name exists, but you can upload it." - which results in a file being uploaded, but not connected to its semantic data, so it is essentially "lost" forever, with no way to match it to its data. If I can't figure out which file goes with what semantic data, I have to delete it all, and hope the user is willing to try again.
It appears this problem can no longer be worked around without the JS above (which affects ALL form fields) after I updated from SF 2.2.1 to 2.3.1 because the magic word {{FULLPAGENAME}} no longer works. My code for working around this problem fails under 2.3.1 without the magic word. The code checks to see if the form is being used to edit or create a page. When creating, the "File:" portion does not exist (under 2.2.1), but it does when editing (but not under 2.3.1). See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=32883
