-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce editorMediaUpload
, which includes post
context for uploads
#6231
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 ran through your testing steps and it totally works!
blocks/editor-media-upload/index.js
Outdated
import { select } from '@wordpress/data'; | ||
import { mediaUpload } from '@wordpress/utils'; | ||
|
||
export default function editorMediaUpload( filesList, onFileChange, allowedType ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add a doc comment to this function since it's exported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utils/mediaupload.js
Outdated
// Create upload payload | ||
const data = new window.FormData(); | ||
data.append( 'file', file, file.name || file.type.replace( '/', '.' ) ); | ||
data.append( 'post', postId ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add a test case for this to utils/test/mediaupload.js
?
Edit:: ...oh, just realised that file doesn't really contain anything juicy. It would be nice if we mocked wp.apiRequest
and asserted that the POST request we build is what we expected. Up to you, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice if we mocked
wp.apiRequest
and asserted that the POST request we build is what we expected. Up to you, though.
I'm going to hold off for now. I think e2e tests will be more durable in the long term, but I'm still ramping up on where things currently stand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
postId
is optional, should it be omitted in the POST data when not set?
utils/mediaupload.js
Outdated
@@ -12,8 +12,9 @@ import { compact, get, startsWith } from 'lodash'; | |||
* @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 {number} postId Optional post id to associate with. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be {?number}
to inform about possible null
default value.
utils/mediaupload.js
Outdated
*/ | ||
export function mediaUpload( filesList, onFileChange, allowedType ) { | ||
export function mediaUpload( filesList, onFileChange, allowedType, postId = null ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started to think if this shouldn't be more general than postId
. wp.utils
was designed to contain general purpose utilities. An alternative approach would be to provide context
param or additionalData
param instead.
Then implementation inside createMediaFromFile
could look like:
import { forEach } from 'lodash';
forEach( additional.data, ( ( value, key ) => data.append( key, value ) );
and you could refactor the code in the wp.blocks
module as follows:
mediaUpload( filesList, onFileChange, allowedType, {
post: select( 'core/editor' ).getCurrentPostId(),
} );
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Handled in 21f40c7
blocks/editor-media-upload/index.js
Outdated
* @param {string} allowedType The type of media that can be uploaded. | ||
*/ | ||
export default function editorMediaUpload( filesList, onFileChange, allowedType ) { | ||
mediaUpload( filesList, onFileChange, allowedType, select( 'core/editor' ).getCurrentPostId() ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
select( 'core/editor' ).getCurrentPostId()
might be undefined here because the blocks
module doesn't depend on the editor
module. We thought for a long time that the blocks
module can be used independently form the editor
module but there are several places where this assumption has been proven wrong (autocompleter, shared blocks ...).
I think we're going to refactor these two modules to consolidate all components in editor
and leave blocks
for registration purpose only. The first step would be to extract the library of blocks to a separate module.
Not certain how to move forward for now though. Maybe we can check for the existence of the selector before calling it? and add a clarifying comment to move this to editor once the refactoring happens.
cc @gziolo @aduth @mtias another proof that this separation is not great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@youknowriad, I don't need more proofs. I'm already sold on the idea of having API based blocks
, core-blocks
and having all UI components moved from block
to editor
:)
I would start with moving block/library
to core-blocks
module and make it dependent on both blocks
and editor
. It might require exposing some files from blocks
but otherwise should be an easy task.
Code looks good with the assumption that we will move this newly introduced function to |
@WordPress/gutenberg-core Any other changes needed on this, or is it good to merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works as advertised. I wasn't aware I need to verify that in Media tab outside of Gutenberg. It took me a while to find out :)
I handled these initial requests.
@gziolo Sorry about that! |
Can I ask something related but not that important :) Why does WP keep a relationship between the post and the media? Doesn't seem so useful at first sight but I'm pretty sure I'm missing something :) |
I'm unsure of its historical genesis but it has a variety of practical applications. For instance, if you use the |
Interestingly, this comment from Boren seems to give the best historical context for why attachments originally existed:
|
…ads (WordPress#6231) * Introduce `editorMediaUpload`, which includes `post` context for uploads * Update media blocks to use `editorMediaUpload` and persist `post` * `mediaUpload()` doesn't return anything * Add JSDoc for function * Use an abstraction that permits passing additional data in request * Mention why this conditional is here
Good thing blocks provide a path for this :) |
Description
Adds a
editorMediaUpload
wrapper, which injectspost
context for media uploads.Fixes #1586
Previously #6155
How has this been tested?
I tested by uploading a new image into Gutenberg:
Once the image was uploaded, it was correctly assigned to its parent post:
I also tested with an audio file.