Honours the $overwriteWarning setting, rather than warning
about overwritten files, and when that warning is acknowledged by the user,
create a new file instead. We need to set this as close to
the Upload->load() call as possible, since it depends
on non-deterministic config state.
Also fixed UploadField operation with canUpload=false,
which broke the JS because no config could be found,
since the <input> field wasn't present. We can't put the data-config
attribute on the field holder, since fields can be rendered
without their field holder through FormField->SmalLFieldHolder().
Fixes https://github.com/silverstripe/silverstripe-cms/issues/874
See discussion at https://groups.google.com/forum/?fromgroups#!topic/silverstripe-dev/Dodomh9QZjk
Fixes an access issue where all public methods on FormField were allowed,
and not checked for $allowed_actions. Before this patch you could e.g.
call FormField->Value() on the first field by using action_Value.
Removes the following assertion because it only worked due to RequestHandlingTest_AllowedControllerExtension
*not* having $allowed_extensions declared: "Actions on magic methods are only accessible if explicitly allowed on the controller."
Very difficult to choose an image based on file name alone. Added thumbnail and reduced rows from 10 to 8 to compensate for increased height of rows with thumbnail included.
Caused the UploadField rows to show "[Object object]" because
it tried to pass through a PHP object to JS without string casting
(the return used to be a string).
Sometimes has-one UploadFields can get confused about whether or not there is an existing file that needs deleting. This setting lets you make a more robust has-one UploadField, where any existing file will be replaced. It more closely mimics simple single-file upload fields.
This is the companion setting to canUpload, letting you control whether existing files from the asset store can be referenced. It's particularly useful when using UploadField on the front-end.
Although editing meta-data or deleting permanently would require File editing/deleting permissions, merely linking to a record does not. This change is important for allowing front-end use of UploadField; or, more importantly, use of UploadFile by people without CMS rights.
The entire framework repo (with the exception of system-generated files) has been amended to respect the 120c line-length limit. This is in preparation for the enforcement of this rule with PHP_CodeSniffer.
1. Add arrows to edit dropdowns
2. Adjust lightened fields so they don't look like input boxes, and fix
rgba colours
3. Add ability to click file names to edit
4. Add feedback when edit button is hovered
5. Add feedback if a file has been opened for editing and shut again
(saved changes, unsaved changes, unchanged)
6. Add ability to open and close all files to edit them all at once
7. Add overall feedback for file uploads, and fix NaN error
8. Fix up area to match design
9. Fix error messages so they fit in the provided space
10. Fix case where a single uploaded file errors
http://open.silverstripe.org/ticket/7046
UploadField would default to one folder only, and wouldn't allow asset
tree traversal. HtmlEditorField MediaForm has this capability, so added
it here in a similar fashion via TreeDropdownField.
UploadField was relying entirely on the File::get_class_for_file_extension to
select a class, so it could only create File or Image objects. This
would break the relationships based on derived objects. Also make it
respect the FileField::relationAutoSetting.
