Updated 2026-04-30: removal target moved from 3.2.0 to 4.0.0 to comply with SemVer (removal of public API requires a major bump). Thanks to kmonty for the pushback.
Summary
The renderEmbedCode($width, $height, $autoplay, $title_format, $use_title_fallback) method should be deprecated in favor of renderEmbed(array $options).
The new renderEmbed() method provides a cleaner API that accepts an options array instead of positional parameters. The base implementation in ProviderPluginBase::renderEmbed() already delegates to renderEmbedCode() for backward compatibility, and all core providers (YouTube, Vimeo, YouTubePlaylist) already override renderEmbed() directly.
Steps
3.1.0
- Add
@deprecated in video_embed_field:3.1.0 and is removed from video_embed_field:4.0.0. Use \Drupal\video_embed_field\ProviderPluginInterface::renderEmbed() instead.to:ProviderPluginInterface::renderEmbedCode()ProviderPluginBase::renderEmbedCode()
- Add a
@trigger_error()call inProviderPluginBase::renderEmbedCode()to emit a deprecation notice at runtime. - Update any remaining callers in the module to use
renderEmbed()instead.
4.0.0
- Remove
renderEmbedCode()fromProviderPluginInterface. - Remove
renderEmbedCode()fromProviderPluginBase. - Remove
renderEmbedCode()overrides from provider plugins (YouTube, Vimeo, YouTubePlaylist). - Remove the delegation in
ProviderPluginBase::renderEmbed()that callsrenderEmbedCode().
Motivation
The options array pattern is more flexible and easier to extend without breaking the method signature. Third-party provider plugins (e.g. video_embed_dailymotion) need to support both methods during the transition period.
Issue fork video_embed_field-3580405
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mably commentedComment #4
mably commentedComment #6
mably commentedComment #9
kmontyMight I suggest removing this in the next major, (e.g.
4.0.0) rather than the next minor release? According to semver, removals should be done in majors. This prevents someone who does acomposer updatewith unpinned dependencies from having their application potentially break.See https://github.com/semver/semver/issues/712#issuecomment-913201179
Comment #10
mably commentedI have no problem with that. Could you provide an MR please?
We will probably release a 4.0.0 version for Drupal 12.
Comment #11
mably commentedComment #13
mably commentedI have updated the issue: removal target moved from
3.2.0to4.0.0. The@deprecated+@trigger_error()already on the 3.x branch can stay; only the timeline shifts. A new MR has been created to amend the deprecation strings to point to the new target.Comment #14
mably commented