Add Block: Playlist

[jasmussen]

Splitting this out from #283. See also #804.

Attributes

• None, Left, Right, Center, Full Width.
• Caption

States

Placeholder:

Neutral:

Selected:

[karmatosed]

Is the idea this is both video and audio? To make sure we have the same as existing editor we would need to have both video and audio playlists.

[StaggerLeee]

I never liked how it force itself to use 100% article content width. And it is most used case an User will put it in the Post.

Playlist is perfect for sidebars, widgets. And maybe some list of podcasts in Posts. Not even then it looks nice enlarged to 100% width.

Playlist could use a bit of new philosophy and rewrite of code. I mean not necessary prevent 100% width, nothing wrong with it. But rearange things, elements, to make it more modern and fitting.

I dont know, bigger thumbnail at the left of song, not at top. Some new elements, etc... Not necessary any element anyone so desperately needs. But just to make it appear better when say it is 700px width in the Post. (Or worst, today modern websites without sidebars, and imagine Playlist 1000px - 1200px wide)

[StaggerLeee]

Here is how it looks compared to SoundCloud widgets. They use nothing extraordinary and revolutionary. Just different appearance and clever arrangements.

[youknowriad]

Some technical issues here:

• How to get the duration of an audio file (without some heavy JavaSript)
• we also need to load JavaScript to the frontend to be able to switch the played track (something we didn't do yet IIRC)

[jasmussen]

How to get the duration of an audio file (without some heavy JavaSript) we also need to load JavaScript to the frontend to be able to switch the played track (something we didn't do yet IIRC)

The initial mockups show the playlist as it works in WordPress today. Can we reuse parts of that?

[youknowriad]

@jasmussen yes, we discussed this a bit in a chat. It's probably possible using WP's mediaElement.js. Some help from the media folks would be awesome.

[karmatosed]

Let's try and get this into 2.1 as it needs to be in for feature parity with media.

[anthonyburchell]

Howdy! I'm new to playing with Gutenberg so I thought this would be a fun first block to try and build. :) I got a lot of work done for the different views for audio playlist. Working on giving video playlist an option and then I can move on to render side to match the current Core playlist functionality. I started my branch here if anyone wants to take a look: https://github.com/anthonyburchell/gutenberg/tree/add/805-playlist-block

My playlist block is just a copy of the audio block that I was using for reference so you'll notice it needs a lot of cleanup.

I'll be farther along and have something to discuss at the Media meeting next week @karmatosed

[karmatosed]

@anthonyburchell this is exciting! Look forward to your update during the media meeting. Thanks for taking on this!

[anthonyburchell]

I have a few things added to my branch for the playlist block. :) I wanted to get some questions documented here before the Media meeting tomorrow. Audio as well as Videos are now respected in the block and this is dependent on the type of playlist created. This should match the current Core playlists functionality.

There a few things that I need to figure out still.

1. I’ve added an attribute for playlistType and set a conditional statement for the two playlist types (audio, video.) I’ve set the conditional returns based on that defined type. Is this the right place to do this and are there any problems with the attribute? Here’s where I’m doing this: https://github.com/anthonyburchell/gutenberg/blob/add/805-playlist-block/blocks/library/playlist/index.js#L133-L171

2. Currently I’m setting the first result in the media object to be loaded. I think this is fair to assume (maybe I’m wrong.) https://github.com/anthonyburchell/gutenberg/blob/add/805-playlist-block/blocks/library/playlist/index.js#L133-L171

3. I’m not sure the right structure for swapping out the src. It doesn’t look like we’re using mediaElement.js on the current Audio block so I’m wondering, for the sake of consistency, if we should follow the HTML5 direction? If we do this are we losing anything from the current playlist feature? Does this give us the opportunity to customize it further going forward on the project?

Things to consider if we don’t go the mediaElement.js route:

• Events for moving on to the next track/video and end of playlist what do? Maybe a loop argument that can be added in the upload modals?
• Mixed content types now possible? I could see someone with a video/audio podcast using that. Being able to include both in a list would be interesting

Here's a screengrab of where it's at currently:

I'm very open to anyone's help to solve the problems above. As I mentioned in my first comment, this is my first stab at Gutenberg. Any and all feedback is welcomed :)

[karmatosed]

From a design view this seems pretty solid and as expected. I would like to get the coding issues resolved to then see if we can add in.

[StaggerLeee]

Sincerely, I get nothing from this animated GIF. Too chaotic. Like World Olympics in fast clicking.

[anthonyburchell]

sorry about that @StaggerLeee! I'm working within my gif upload limits. I think github has a time/size constraint so I try to make them as fast as possible.

I wanted to post an update here as it has been a little while. After digging through this and reverse engineering the Core playlist creation I've found a few big things that needed to change in my code. We don't take into account the model needed for the playlist block (also audio block).

I've added the below model to the media-uploads-button file. That file handles creating models for images/galleries, but not for any other type of media. The default passed values are not enough to render things like artwork titles or descriptions. I know that the audio block is already merged but it does not take into account things like image, url, artist, album, etc as well. I also noticed that the audio block does not utilize the Core implementation of audio using mediaElement. We may want a separate issue on that but here's how the model looks now for playlist media.

 const playlistItemObject = ( playlistMedia ) => {
    const attrSet = [ 'sizes', 'mime', 'type', 'subtype', 'id', 'url', 'link', 'caption', 'album', 'artist', 'image', 'title'];
    return pick( playlistMedia, attrSet );
};

Here is how the media-upload-button is setting the model for galleries. I'm using this section to apply the defined model above:

const selectedImages = selections || state.get( 'selection' );

        if ( ! selectedImages || ! selectedImages.models.length ) {
            return;
        }
        if ( multiple ) {
            if ( playlist ) {
                onSelect( selectedImages.models.map( ( model ) => playlistItemObject( model.toJSON() ) ) );
            } else {
                onSelect( selectedImages.models.map( ( model ) => slimImageObject( model.toJSON() ) ) );
            }
        } else {
            onSelect( slimImageObject( selectedImages.models[ 0 ].toJSON() ) );
        }
    }

We may want to change selectedImages to selectedMedia because we probably want to use this for other forms of media (videos, audio, etc.) For now I'm using selectedImages to work through building the models. We need to follow something similar for the audio issue mentioned above to build audio models.

Now that I've got my objects properly holding the required attributes we can start work on the render side of things finally.

Ive been reversing Core's playlist shortcode and have found that we use a template in media.php. I think the remaining work on my for playlist is porting that over.

Here's the section of media.php that has the structure of the playlist that renders currently in Core: https://github.com/WordPress/WordPress/blob/13e40181eb4cee1ebdd624f70fc376d444d55bcc/wp-includes/media.php#L1856-L2177

FYI for anyone that wants to help out, the above repo I mentioned is current: add/805-playlist-block feel free to ping me on WordPress Slack at any time (antpb)

[anthonyburchell]

Howdy! Another update here. There were a few roadblocks that were not realized in my last update so here's a new update with those roadblocks now fixed!

1) We lack a mediaelement component to be used by video and audio. The current implementations in the Video and Audio block are using standard html5. For the sake of backwards compatibility we should probably be using mediaelement library to render those things. 2) We lack a global for mediaelement altogether. (this has been added in my 805 repo) 3) We need templates to match wp-playlist.js and the other templates. (Still need to figure out the best approach for this)

I've updated my repo to now include the mediaelement global and you can reference my repo's playlist block to see how it is being called and used. Currently, as this block works, it would technically fit the needs of fixing the Audio and Video blocks. I'll get to those soon and make a PR separate from this one. I think we may want to pull out the mediaelement component portion of my updates and make a PR so this component is usable to others as I make progress on the playlist templates.

Here's a screenshot showing how the player is loading right now. Looking mediaelement-y :D

[antpb]

Just an update around this issue. I have continued work on this and am in a place where the playlist block is starting to utilize a mediaElement component and pass the appropriate attributes. I hit a bit of a road block recently in getting my code to respect the new changes in 2.3 so I'm finally in a place where everything is caught up. I am now in the process of matching the logic of our current implementation of playlists in core. I apologize on the lack of updates here they will be more frequent over the next week as I work to bring this across the line. Been a bit of a holdup due to my priorities shifting to 4.9.6 readiness :)

[anthonyburchell]

Another update here: I've chatted with @joemcgill on a different approach for this block and it was decided that we should focus on ID as the main attribute. From there we can get the data we need in an callback render function. I'm experimenting with storing the ID in an element in the the containing div...possibly class names.

~I think I'll also follow the approach in the latest-posts block using REST calls to pull the ID's to be handed back to the shortcode render function.~ (We don't need REST calls since the shortcode is only expecting IDs...) Does this all sound good to you @mtias ? Any missing attributes or bottlenecks I may be hitting here?

[mtias]

You could store the ID in the comment attr for easiest access. You'll then get in the render callback as a proper attribute.

[antpb]

Thanks @mtias . Did a bit of cleaning up on my repo and started fresh here: https://github.com/antpb/gutenberg/tree/add/playlist-block-805

hitting publish now saves the ids as we would expect them.

example:

<!-- wp:playlist {"ids":[50,6]} /-->

I'm working on the callback function and I assume this would require core modification to media.php to use the register_block_type function?

register_block_type( 'core/playlist', array(
                'render_callback' => 'wp_playlist_shortcode',
) );

I did that and got undefined function error for register_block_type. Not entirely sure the best way to do this. Going to pick it back up tomorrow. figured I'd leave an update. :)

[antpb]

Solved the above issues with including the dependencies

I'm currently using the following in media.php and we now have front end loading playlists!

function playlist_block_callback_dependencies() {
    wp_register_script(
        'gutenberg-playlist-block',
        plugins_url( 'gutenberg/core-blocks/playlist/index.js', __FILE__ ),
        array( 'wp-blocks', 'wp-element' )
    );
        register_block_type( 'core/playlist', array(
                        'editor_script' => 'playlist_block_callback_dependencies',
                        'render_callback' => 'wp_playlist_shortcode',
        ) );

}
        add_action( 'init', 'playlist_block_callback_dependencies' );

My question now is, because my implementation is modifying core, is this the right way to go about it? Is there a way to add these dependencies and render callback within Gutenberg instead of media.php?

^ added it to index.php in playlist blocks root directory. Progress!

This is getting very close! Here's a screenshot of the front end:

[themightymo]

+1

[aaronjorbin]

@anthonyburchell I put the future label on this, but if you are going to have this be a part of the merge can you add it to a milestone and remove the label, please.

[antpb]

@aaronjorbin yep yep! Agreed we can move to Future.

Just to document here the current status:

The only big blocker in this being included in the merge is setting a condition to include the js templates/playlist dependencies. My PR was including the playlist/video playlist scripts on every page load (in client-assets.php). The new approach takes a similar one to the Code Editor block: https://github.com/WordPress/gutenberg/blob/80ac62507567a7e8c2f02693bbb05edc1532407b/components/code-editor/index.js#L28-L70

I currently have a mirror of that approach for enqueuing playlist dependencies. I went ahead and updated the PR today to include these new changes: https://github.com/antpb/gutenberg/tree/add/8050-playlist-refactor-2

There still seems to be an issue where it is not finding wp_underscore_playlist_templates .

After creating a playlist block, console errors: Cannot read property 'replace' of undefined. saving draft/publishing and refreshing the page has no issues. Also publishing and viewing on the front end renders the playlist as expected.

If anyone has any ideas on how to fix this, I'm open to suggestions. Until then, lets leave this on Future. :)

[kiwipaulrob]

Eager for this feature. I don't have the coding skills to help. Can it be brought forward? 5.1 looks a long way off....

[keramch]

migrating existing playlists into a gutenberg-built page is proving problematic... at best overly time consuming to update... i beg you to push this further up the ladder :)

[qantumthemes]

It's already about 6 months that people are complaining for missing basic features as playlists. They shouldn't have forced Gutenberg while still missing basic functionalities that people were already adopting since ages. It seems a guy with a gun went to Automattic and said YOU PUBLISH GUTENBERG NOW!!!!!!!!! Like the bad guys from the movies, and then the Automattic developers said "But Sir is still missing..." And the bad guy said "NOWWW or heads will start blowing!!!"

So we are now forced with an editor that is missing everything.

Only possible reason.

Technically speaking, as keramch says, bringing this to Gutenberg is problematic, as it can be with tons of other frontend custom elements.

This because the Gutenberg principle of taking pieces of the frontend into the editor is wrong per-itself. Page builders add to the frontend editor controls, do not bring the shortcode output IN the backend.

Wrong paradigm, true issues.

Then all goes with placeholders to fix.

[Soean]

There is a discussion about deprecating this feature as usage does not seem to be high. See https://make.wordpress.org/core/2018/12/27/media-meeting-recap-december-21/

[qantumthemes]

Thank you Soean for your kind link. The decision is anyway being taken without considering huge niches of the market which are instead relying heavily on this feature in their websites. But anyway, thanks for the precisation. Assuming then that this was too hard to bring to gutenberg and being trashed.

Good, less work for us.

[qantumthemes]

Also I'd like to ask, what with the thousands of websites already containing playlists in their existing contents? Are they going to disappear or display the raw shortcode?

[keramch]

@qantumthemes playlists don't seem to disappear, which is good - they can be managed via classic editor module, but that kind of defeats the purpose, doesn't it? Why wouldn't we all just go BACK to classic editor... which wasn't broken... if we have to use that module to achieve our content requirements inside Gutenberg? the amazing folks (and I mean that) at Automattic (and frankly, the whole "internet") seem to forget that the VAST MAJORITY of people who are creating websites are individuals and small businesses who just need stuff to work... they don't need (nor care in far too many cases) it to be fancy. They don't want nor have the time/brainspace, to relearn how to do the updates they need to do to their content to share their product, service or information with the world. If we HAVE to adopt Gutenberg, why not just duplicate a classic editor module and name it "playlist" :) everyone will be happy and you don't have to spend a huge amount of resources redesigning it.

[kiwipaulrob]

Is the playlist feature going to make it into 5.1 as previously discussed, or at least into a plug in sometime soon?

[Soean]

The WordPress 5.1 beta is out, so we don't add new features to this version.

There were no changes in the PR in the last months: https://github.com/WordPress/gutenberg/pull/9169 so I don't think there is something soon.

[karmatosed]

To me this seems like the type of block could be a custom one in special plugin, over supported in core. I deeply appreciate the work that went into this and would love to see it become a plugin available still.

[gziolo]

What should we do about #9169 and all the work done by @antpb. Is it okay to close this PR and have it as a reference for the future plugin?

[afercia]

Just noting that, whether a Playlist block will ever be implemented or not, the current experience is not great. Similarly to https://github.com/WordPress/gutenberg/issues/13852, playlist shortcodes work in the Classic Block but then, when transformed to blocks, all users can see is the following 😞

Audio playlist:

Video playlist:

[qantumthemes]

Completely agree, the issue for customers induced us to force the classic editor, after 6 months still they weren't able to bring this old shortcode to gutenberg, while after so many months of use I can totally agree the new editor has more downsides than advantages.

[ralphonz]

So are we getting a playlist or not? Really hate this gutenberg stuff. I don't see why it had to change so soon before it was ready to have the same features as the classic editor.

[X-Raym]

+1 for audio playlist !

[1000camels]

I have been following this discussion for a while. A few months ago, I decided to try to build an alternative approach to the playlist. To begin with, I do not think the playlist is very attractive. As well, it requires too much manual maintenance of the media in the playlist and doesn't address external media. So I developed a plugin, which has a Gutenberg block for it. It is called Audio Envelope (https://aporia.info/wp/audio-envelope/), and it is in the plugin directory. Aside from looking for feedback on this, I am curious whether you all think my approach to building separate audio blocks and then pulling them together under one player/playlist works for you. For me, it matches better with the WordPress approach to reusing Posts in Archives model. It also works with HTML5 Audio, which the MediaElement playlist does not.

[kathrynwp]

Another request for an audio playlist from a WordPress.com user.

[kiwipaulrob]

Any update on audio playlists in Gutenberg?

[b-shchuko]

I haven't tried this code but I want to raise an existing problem with the existing native WP playlist. The problem is that it doesn't work with W3 Total Cache CDN. The URLs are not rewritten in the native playlist, although they are rewritten if you use a single-track native WP player. I hope you'll fix this issue in this new block (and, implicitly, hope you release it someday).

[qantumthemes]

I haven't tried this code but I want to raise an existing problem with the existing native WP playlist. The problem is that it doesn't work with W3 Total Cache CDN. The URLs are not rewritten in the native playlist, although they are rewritten if you use a single-track native WP player. I hope you'll fix this issue in this new block (and, implicitly, hope you release it someday).

It looks like they don't really give a damn about the whole playlist support. I'll be rising the question personally to Automattic at the next WordPress conference.

[bricedupuy]

Still waiting

[noisysocks]

This was requested here: https://core.trac.wordpress.org/ticket/45560

[celloexpressions]

It's disappointing for feature parity to still be missing here. The best option currently is to add a playlist via a classic block (and its embedded media library). Or, to use only the classic editor for sites and post types that rely heavily on audio.

As with the numerous other features that blocks now enable, it isn't appropriate to deprecate this feature in core at this point. It still works via the classic editor and has been used used in years worth of published content. Removing it breaks workflows and it can't be completely removed from core because it's used in existing content. That approach would require a much larger conversation. In the meantime it would be great to enable this workflow in the block editor so that these sites have a viable option of switching editors.

[paaljoachim]

I brought up this issue during the Core Editor chat. (Link to the slack thread.) https://wordpress.slack.com/archives/C02QB2JS7/p1608128880090100

@youknowriad mentioned: "I believe we decided to not include blocks relying on media element in Gutenberg Core. so may want to just close this one."

I mentioned: "I believe the issue mentions feature parity with the older classic editor."

[maddisondesigns]

A Playlist function is definitely needed. Gutenberg was supposed to provide, at the bare minimum, the same functionality that the Classic Editor provided. Two plus years down the track and it's still falling short of this.

[paaljoachim]

I am wondering if we need to first off improve the current Audio block with among other focuses being able to use inner/child blocks as part of a Play list. Similar to Image blocks that are a part of the Image Gallery block being worked on. https://github.com/WordPress/gutenberg/pull/25940

[gwwar]

This was discussed in the Feb 3, 2021 core-editor chat (https://wordpress.slack.com/archives/C02QB2JS7/p1612363563122800):

This issue is still a low priority for being implemented by the team, but the project welcomes contributions if someone has a passion for driving this issue forward. For next steps: one way to experiment, might be to start with a plugin. Note that the mock ups and approach in the summary need rethinking and updating. It may also help to close this issue and create a fresh one for clarity.

[maddisondesigns]

@gwwar Closing this issue and creating a new one will simply put it back even further in the queue. At least by keeping it open you can see how long people have been waiting for this functionality. It's disappointing that feature parity with the Classic Editor isn't being made a priority before new features are implemented. People are using this functionality today, so it's sad to see that there's little priority in making their transition to Gutenberg a lot easier. Users shouldn't have to find a plugin to replace functionality that has been in the Classic Editor for years, and for functionality that users were promised that would exist in the new editor. Not only is that a really bad suggestion, but you'd be forcing people to re-edit all their past content so as to make it work with any plugin they decided to use.