The amount of code in this module is actually quite small, and much of it can be loaded only when needed. If you don't want to use the field formatters or input filters, don't use them!

I don't propose merging oEmbed Provider or oEmbed Embed.ly.

Comments

voxpelli’s picture

voxpelli commented

I kind of agree - but wouldn't this be hard to do in a fully backwards compatible way?

Anonymous’s picture

Anonymous (not verified) commented

I don't think it's an impossible thing to do. The risk is that someone's field formatters and input formats have to be re-configured, but I don't know if this is a big deal. If someone is upgrading from D6 to D7, this may be one more trouble point but it would hardly be the only one. I'll look deeper into how CCK handled this.

bburg’s picture

bburg
he/him
Location Washington, DC
commented
Issue summary: View changes

Hi, I ran into this as a problem, oembedfield and oembedcore were deprecated, but I had been using the oembedfield, which was defined as a dependency of one of my core Features modules. This cascaded through several Features modules that defined that module as a dependency.

Since the updates to oembed run as an update hook, and upgrading will require running this hook, it seems like what I need to do is after the update hook runs to uninstall the modules. I should re-install them, configure my fields to use the new oembed, then re-export my features, with the dependency removed?

astonvictor’s picture

astonvictor commented
Status: Active » Closed (outdated)

D7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.