Skip to content
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

Merged
merged 7 commits into from
Apr 20, 2018

Conversation

danielbachhuber
Copy link
Member

@danielbachhuber danielbachhuber commented Apr 17, 2018

Description

Adds a editorMediaUpload wrapper, which injects post context for media uploads.

Fixes #1586
Previously #6155

How has this been tested?

I tested by uploading a new image into Gutenberg:

image

Once the image was uploaded, it was correctly assigned to its parent post:

image

I also tested with an audio file.

@danielbachhuber danielbachhuber requested a review from a team April 18, 2018 00:02
@danielbachhuber danielbachhuber added this to the 2.7 milestone Apr 18, 2018
Copy link
Member

@noisysocks noisysocks left a 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!

import { select } from '@wordpress/data';
import { mediaUpload } from '@wordpress/utils';

export default function editorMediaUpload( filesList, onFileChange, allowedType ) {
Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// Create upload payload
const data = new window.FormData();
data.append( 'file', file, file.name || file.type.replace( '/', '.' ) );
data.append( 'post', postId );
Copy link
Member

@noisysocks noisysocks Apr 18, 2018

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.

Copy link
Member Author

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.

Copy link
Member

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?

@@ -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.
Copy link
Member

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.

*/
export function mediaUpload( filesList, onFileChange, allowedType ) {
export function mediaUpload( filesList, onFileChange, allowedType, postId = null ) {
Copy link
Member

@gziolo gziolo Apr 18, 2018

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(),
} );

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Handled in 21f40c7

* @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() );
Copy link
Contributor

@youknowriad youknowriad Apr 18, 2018

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Handled in 21f40c7 and 25bf867

Copy link
Member

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.

@youknowriad youknowriad modified the milestones: 2.7, 2.8 Apr 18, 2018
@gziolo
Copy link
Member

gziolo commented Apr 18, 2018

Code looks good with the assumption that we will move this newly introduced function to editor module in the near future 👍 I haven't tested yet.

@danielbachhuber
Copy link
Member Author

@WordPress/gutenberg-core Any other changes needed on this, or is it good to merge?

Copy link
Member

@gziolo gziolo left a 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 :)

@danielbachhuber danielbachhuber dismissed noisysocks’s stale review April 20, 2018 15:50

I handled these initial requests.

@danielbachhuber
Copy link
Member Author

I wasn't aware I need to verify that in Media tab outside of Gutenberg. It took me a while to find out :)

@gziolo Sorry about that!

@danielbachhuber danielbachhuber merged commit f53590a into master Apr 20, 2018
@danielbachhuber danielbachhuber deleted the 6155-editor-media-upload branch April 20, 2018 15:50
@youknowriad
Copy link
Contributor

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 :)

@danielbachhuber
Copy link
Member Author

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 [gallery] shortcode within a post, the default behavior is to display all images attached to the post. Similarly, an attachment has a post status of inherit, which means it inherits the visibility permissions of its parent post (when attached to the parent post).

@joemcgill
Copy link
Member

joemcgill commented Apr 20, 2018

Interestingly, this comment from Boren seems to give the best historical context for why attachments originally existed:

Looking forward to the day when users don't ever see the terms attach or detach. This whole thing is a hack around the lack of API for getting images from content.

nuzzio pushed a commit to nuzzio/gutenberg that referenced this pull request Apr 25, 2018
…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
@mtias
Copy link
Member

mtias commented May 3, 2018

This whole thing is a hack around the lack of API for getting images from content.

Good thing blocks provide a path for this :)

@karmatosed karmatosed added the [Feature] Media Anything that impacts the experience of managing media label May 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Media Anything that impacts the experience of managing media
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants