Fix max upload size error message #4203

jorgefilipecosta · 2017-12-29T15:05:26Z

Description

This PR aims to fix #3984. It improves media upload error handling, by showing a generic message when the upload fails, and by validating the max file size before starting the upload so we are not wasting resources try to send an invalid file to the server.

How Has This Been Tested?

Add an image block. Try to upload an image bigger than max file size upload limit. the value can be changed by adding this lines "php_value upload_max_filesize 3M / php_value post_max_size 3M" in .htaccess.
See that the correct error notice appears.

Screenshots (jpeg or gifs if applicable):

Types of changes

Added an onError handler to media handler. Used the handler to validate max file size and generic upload problems.
Passed max upload size from in client assets to allow max file size validation.
Added the ability for blocks to display error notices.

ellatrix · 2017-12-31T00:30:54Z

Nice pre checking! Would it perhaps be nice to display the error on the block itself (locally), instead of at the top (globally)?

karmatosed · 2018-01-03T14:30:54Z

Right now all our error/success messages go in one place, the top. I think having this also go there is for now right. We absolutely could consider what messages work for contextual, but that feels a different issue and shouldn't block this going in as is.

ellatrix · 2018-01-03T20:18:22Z

@karmatosed We currently have some error messages that are block-specific that go in the block, such as JS errors and externally modified messages.

karmatosed · 2018-01-04T11:56:28Z

Hmm, isn't it only JS errors though or external? I'm thinking from a UX perspective the 'message place' works at top for user information.

So we can track this, do we have a record/list of all error messages and where they output? Would be a good exercise in seeing we're being consistent.

ellatrix · 2018-01-04T17:17:59Z

E.g. create a list block, click the ellipsis, edit in HTML, remove the list HTML and add something else, then try to go back to visual. There will be a message with three action buttons.

ellatrix · 2018-01-10T15:12:33Z

Would be good to have this. Ran into it with paste too.

ellatrix · 2018-01-10T15:44:09Z

editor/components/block-list/block.js

@@ -421,6 +422,7 @@ export class BlockListBlock extends Component {
 								id={ block.uid }
 								isSelectionEnabled={ this.props.isSelectionEnabled }
 								toggleSelection={ this.props.toggleSelection }
+								createErrorNotice={ this.props.createErrorNotice }


Code-wise it also seems cleaner to display the error within the block? This error does not apply to the whole page.

Thank you for the feedback @iseulde, I will propose a version with a block-specific error 👍

Awesome, thanks! :)

jorgefilipecosta · 2018-01-11T19:18:10Z

Hi @karmatosed, @iseulde, I added a new mechanism so we can test a different approach using block level error notices. The errors are different from the existing block parsing error. In this case, the block should continue to work normally e.g in the gallery even if one image failed the upload I should be able to see and manage the other images or upload a different one. I will update screenshots so we can see the new approach.

ellatrix · 2018-01-15T12:19:47Z

Just wondering out loud... What if the error notice is part of the block edit component, and we just have a standard class for the error notice (kind of like it is done in WP core now). Or it is a component similar to Editable etc. Would that not make the code simpler? Or does the error notice need to appear outside the block edit boundary? I think the error makes sense to display as close to where the state lives, if that makes sense, not only code wise, but also visually. The error was triggered inside the upload part of the image block. Now it kind of feels like its a block on its own.

ellatrix · 2018-01-15T12:28:04Z

Just ideas

jorgefilipecosta · 2018-01-15T13:18:19Z

Just wondering out loud... What if the error notice is part of the block edit component, and we just have a standard class for the error notice (kind of like it is done in WP core now). Or it is a component similar to Editable etc. Would that not make the code simpler?

The problem with this approach is that each block would need to implement the management of the notices. E.g: keep the state of which notices are being shown, and provide functions to dismiss them and then pass this functions down to the generic component as props. This notices management logic would be repeated across the blocks needing notices. Right now it is not repeated e.g blocks just have a function to throw notices and then they don't have to handle them.

The error was triggered inside the upload part of the image block. Now it kind of feels like its a block on its own.

We can try to improve the visual, instead of rendering directly we can pass a prop that contains the rendered notices. The blocks can then choose to place them inside some specific part, for example, render inside the placeholders like in your first example ( I will try to provide a sample). But in the non-empty states ( e.g: a gallery with images where the upload of a new image failed.) the notices would still look similar to the example we have now.

ellatrix · 2018-01-15T14:01:47Z

But in the non-empty states ( e.g: a gallery with images where the upload of a new image failed.) the notices would still look similar to the example we have now.

That makes sense.

jorgefilipecosta · 2018-01-15T22:50:06Z

Hi @iseulde, this PR got updated so the notices feel more part of the block. Thank you for the feedback 👍 I added screenshots to the new design. The mechanism is still easy to use for block creators e.g: notices can be added with online to show them and another line to create a new message.

ellatrix · 2018-01-18T14:11:48Z

blocks/library/gallery/index.js

@@ -62,6 +62,10 @@ registerBlockType( 'core/gallery', {
 		},
 	},

+	supports: {
+		notices: true,


Why is this needed? I'm not sure I understand this.

ellatrix · 2018-01-18T14:14:49Z

blocks/hooks/notices/index.js

+
+		/** @inheritdoc */
+		render() {
+			if ( ! hasBlockSupport( this.props.name, 'notices' ) ) {


From the previous comment, can't we always add the notices props?

Yes, it would be an option, the supports notices is just for the property to be opt-in, e.g: blocks just receive if they ask for it.

ellatrix · 2018-01-18T14:17:18Z

blocks/hooks/notices/index.js

+		*
+		* @param {string} id  Id of the notice to remove.
+		*/
+		removeNotice( id ) {


What happens when a block with a notice disappears? Does it just stay around here in the state? This is why I think it would be beneficial for the state to be local, not global.

In other words, why do we need to keep a global list?

Notices is a HoC around blocks, it would be the same as doing something like withNotices( GalleryBlock ); that adds notices property to gallery block. I can easily switch to this version. The only disadvantage is that blocks would need to be React components to use it and the current approach also allows blocks to take advantage even if their edit method is a function. When a block with notices is removed, the HoC around it will also be removed and its state is deleted.
Similar to happens when we use withAPIData the HoC also has its own state when a block it wraps is removed its own state is also deleted.

jorgefilipecosta · 2018-05-01T09:48:30Z

Hi @iseulde, from the technical point of view this code was also updated we now make use of a HOC, I would appreciate if you could have a new look :)

ellatrix · 2018-05-01T11:27:43Z

blocks/editor-media-upload/index.js

- * @param {Array}    filesList    List of files.
- * @param {Function} onFileChange Function to be called each time a file or a temporary representation of the file is available.
- * @param {string}   allowedType  The type of media that can be uploaded.
+ * @param   {Object}   $0                   Parameters object passed to the function.


Interesting notation! :)

ellatrix · 2018-05-01T11:31:20Z

blocks/editor-media-upload/index.js

+	maxUploadFileSize,
+	onError = noop,
+	onFileChange,
+} ) {


Nice to have an options object here!

ellatrix · 2018-05-01T11:44:15Z

components/higher-order/with-notices/index.js

+			this.removeNotice = this.removeNotice.bind( this );
+
+			this.state = {
+				notices: [],


Wouldn't it be simpler to store notices by ID here?

this.state = { 1: {}, 2: {}, }

That also makes it easier to add and delete.

I used an array to follow the same logic we use on the global notices. I wanted to use the same that is being used globally.

ellatrix · 2018-05-01T11:55:15Z

components/higher-order/with-notices/index.js

+ * @return {Component}                    Wrapped component.
+ */
+export default createHigherOrderComponent( ( BlockEdit ) => {
+	return class WrappedBlockEdit extends Component {


Curious: why enhance the BlockEdit component and not let block authors enhance their own edit component or a child component of that? The whole BlockEdit does not need to rerender on a state change, right? Notices are only shown within the edit component of the block, or am I mistaken?

Sorry, I missed the update to the component name during the changes, it should have been called OriginalComponent instead of BlockEdit.
withNotices is a generic HOC that can be passed to any react component and it is not being used against BlockEdit we use it inside the blocks edit because as you said notices are only shown within the edit component of the block.

ellatrix · 2018-05-01T11:58:30Z

core-blocks/gallery/block.js

@@ -236,6 +247,7 @@ class GalleryBlock extends Component {
 					</PanelBody>
 				</InspectorControls>
 				<ul className={ `${ className } align${ align } columns-${ columns } ${ imageCrop ? 'is-cropped' : '' }` }>
+					{ noticesUI }


Can this be a child of ul?

It should be outside of the ul during the rebase I made a mistake it was corrected. Thank you!

ellatrix · 2018-05-01T12:02:54Z

The main question for me is #4203 (comment). I don't understand why the component need to be so high up the tree with passing a notices object etc.

jorgefilipecosta · 2018-05-01T16:19:57Z

Hi, @iseulde thank you a lot for the review. The component was not high up in the tree, but as I used BlockEdit as the name of the component passed to the HOC, it looked like it was being used high up in the tree. The name was corrected.

gziolo · 2018-05-10T08:09:54Z

@jorgefilipecosta - can you update this PR and make it mergeable? What are remaining blockers in here?

jorgefilipecosta · 2018-05-10T10:10:13Z

Hi @gziolo, thank you for checking this PR, I rebased it. I think we don't have blocking points, from the design perspective it was approved. I would like to have final approval from the code perspective because we are implementing and exposing a local notices mechanism for block creators (which may not be trivial to change later).

ellatrix

Just a few questions... looks great otherwise. I wish there wasn't so much stuff passed and that the API were a bit simpler.

There's also a failing test.

ellatrix · 2018-05-14T15:59:53Z

components/placeholder/index.js

 	const classes = classnames( 'components-placeholder', className );

 	return (
 		<div { ...additionalProps } className={ classes }>
+			{ !! notices && notices }


Why is !! notices needed? Can't it be null?

ellatrix · 2018-05-14T16:02:49Z

core-blocks/gallery/edit.js

@@ -195,6 +198,13 @@ export default class GalleryEdit extends Component {
 			</BlockControls>
 		);

+		const noticesUI = notices.noticeList.length > 0 &&
+			<BlockNotices


I'm just wondering here... Could the BlockNotices be a prop of this component that is added by withNotices. Or would there be any other way to avoid passing all this stuff (less for the block author to worry about).

jorgefilipecosta · 2018-05-16T17:45:56Z

Hi, @iseulde thank you for your review! I followed your suggestion, and now withNotices adds a UI prop so we make the usage easier and we don't have to pass many props around. If the user wants a custom UI it is still possible to have one.

ellatrix · 2018-05-16T18:03:28Z

components/higher-order/with-notices/index.js

+				<OriginalComponent
+					noticeList={ this.state.noticeList }
+					noticeOperations={ this.noticeOperations }
+					noticeUI={


This seems nicer! Wondering if it could make it clear things up even more if noticeOperations are properties on noticeUI? Do you think that would be strange?

Related with #4203 (comment) although we pass a noticeUI I wanted it to be a totally optional prop and allow components to ignore it if they just want the notices without relying on the default UI we provide.

ellatrix · 2018-05-16T18:03:42Z

components/higher-order/with-notices/index.js

+		render() {
+			return (
+				<OriginalComponent
+					noticeList={ this.state.noticeList }


Does that still need to be passed?

It is not being used, but passing it allows a user of the HOC to create a different UI and not rely on the provided noticeUI.

ellatrix

Looks good to me!

Squashed commits: [5cceb909a] Added maximum file size validation to media upload; Passed maxUploadSize client-assets. This change makes client size validation of the file size, avoiding spending time uploading invalid files to server. It also shows a friendly error message if the file size validation fails.

jorgefilipecosta added [Feature] Blocks Overall functionality of blocks [Type] Bug An existing feature does not function as intended labels Dec 29, 2017

jorgefilipecosta self-assigned this Dec 29, 2017

jorgefilipecosta force-pushed the fix/max-upload-size-error-message branch 2 times, most recently from 247e67e to 34534a1 Compare December 29, 2017 16:39

mtias added the Needs Design Feedback Needs general design feedback. label Jan 3, 2018

karmatosed removed the Needs Design Feedback Needs general design feedback. label Jan 3, 2018

jorgefilipecosta requested review from youknowriad, mcsf, aduth and ellatrix January 3, 2018 16:50

ellatrix reviewed Jan 10, 2018

View reviewed changes

jorgefilipecosta force-pushed the fix/max-upload-size-error-message branch from 34534a1 to 64c67b3 Compare January 11, 2018 18:59

jorgefilipecosta added the Needs Design Feedback Needs general design feedback. label Jan 11, 2018

jorgefilipecosta force-pushed the fix/max-upload-size-error-message branch from 64c67b3 to 8a98a71 Compare January 15, 2018 22:43

ellatrix reviewed Jan 18, 2018

View reviewed changes

karmatosed removed the Needs Design Feedback Needs general design feedback. label Apr 28, 2018

jorgefilipecosta force-pushed the fix/max-upload-size-error-message branch 2 times, most recently from cf08e69 to 6c1c06f Compare May 1, 2018 09:47

ellatrix reviewed May 1, 2018

View reviewed changes

jorgefilipecosta force-pushed the fix/max-upload-size-error-message branch 2 times, most recently from 2c7ff1f to b704760 Compare May 1, 2018 15:55

gziolo added the [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed. label May 10, 2018

jorgefilipecosta force-pushed the fix/max-upload-size-error-message branch 2 times, most recently from f17dffb to 9ba0213 Compare May 10, 2018 10:00

jorgefilipecosta removed the [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed. label May 10, 2018

mirka mentioned this pull request May 10, 2018

Allow file uploads using drag and drop & add placeholder #5462

Closed

ellatrix approved these changes May 14, 2018

View reviewed changes

jorgefilipecosta force-pushed the fix/max-upload-size-error-message branch from 9ba0213 to caa931c Compare May 16, 2018 17:42

ellatrix reviewed May 16, 2018

View reviewed changes

jorgefilipecosta force-pushed the fix/max-upload-size-error-message branch from caa931c to 9092d69 Compare May 16, 2018 20:11

ellatrix approved these changes May 17, 2018

View reviewed changes

mirka mentioned this pull request May 17, 2018

Implement File block #6805

Closed

11 tasks

jorgefilipecosta force-pushed the fix/max-upload-size-error-message branch from 9092d69 to ce37495 Compare May 22, 2018 14:29

jorgefilipecosta merged commit deabbc3 into master May 22, 2018

jorgefilipecosta deleted the fix/max-upload-size-error-message branch May 22, 2018 14:40

danielbachhuber added this to the 3.0 milestone May 22, 2018

mirka mentioned this pull request May 27, 2018

Check allowed mime types before uploading media #6968

Merged

4 tasks

Fix max upload size error message #4203

Fix max upload size error message #4203

Conversation

jorgefilipecosta commented Dec 29, 2017 • edited Loading

Description

How Has This Been Tested?

Screenshots (jpeg or gifs if applicable):

Types of changes

ellatrix commented Dec 31, 2017

karmatosed commented Jan 3, 2018

ellatrix commented Jan 3, 2018

karmatosed commented Jan 4, 2018 • edited Loading

ellatrix commented Jan 4, 2018

ellatrix commented Jan 10, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jorgefilipecosta commented Jan 11, 2018

ellatrix commented Jan 15, 2018

ellatrix commented Jan 15, 2018

jorgefilipecosta commented Jan 15, 2018

ellatrix commented Jan 15, 2018

jorgefilipecosta commented Jan 15, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jorgefilipecosta Jan 18, 2018 • edited Loading

Choose a reason for hiding this comment

jorgefilipecosta commented May 1, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ellatrix commented May 1, 2018

jorgefilipecosta commented May 1, 2018 • edited Loading

gziolo commented May 10, 2018

jorgefilipecosta commented May 10, 2018

ellatrix left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jorgefilipecosta commented May 16, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ellatrix left a comment

Choose a reason for hiding this comment

jorgefilipecosta commented Dec 29, 2017 •

edited

Loading

karmatosed commented Jan 4, 2018 •

edited

Loading

jorgefilipecosta Jan 18, 2018 •

edited

Loading

jorgefilipecosta commented May 1, 2018 •

edited

Loading

ellatrix left a comment •

edited

Loading