Problem/Motivation
I've been attempting to add a local 'fallback' oembed provider, along the lines of embedly or iframely.
Basically to scrape metadata or opengraph summaries of *any* random page.
So I would want to place at at the end of the list of providers, and if it's not youtube or vimeo or twitter etc, then use my provider.
I added it manually via the UI at /admin/config/media/media-oembed/list/
I gave it the scheme to match of "*"
... and now it wins over top of all the more specific scheme patterns - which was not desired.
I traced the behaviour eventually to
/**
* Helper function that compares the length of match expressions.
*/
function _media_oembed_specificity_compare($a, $b) {
return strlen($a) - strlen($b);
}
.. and it turns out that this means that the *shortest* pattern string always wins. Which would be not what is desired!
You want the longest (most specific) pattern first, then falling back to grosser wildcards.
HOWEVER, there are also other issues with this _media_oembed_specificity_compare() - mostly that the individual scheme patterns are concatenated already, making the rough comparison by length fruitless.
_media_oembed_specificity_compare() probably can't be repaired as-is.
The list of oembed providers seen at /admin/config/media/media-oembed appears to be alphabetical, so that provides additional confusion.
Proposed resolution
I would have expected to be able to weight these resolvers, and was surprised this wasn't happening in that UI already.
This may be only an issue for cases where the scheme patterns are ambiguous (which doesn't happen in the limited sample set yet). Maybe even just flagging one provider as 'fallback' would be sufficient for the remaining use-cases.
Options:
- Attempt to repair _media_oembed_specificity_compare() to really work (and apply that fix to the table at /admin/config/media/media-oembed also). A genuine specificity sort is possible, but there is more to it than strlen.
- Inject a 'weighting' field to provider definitions - probably hard, due to where settings live
- Maybe just being able to nominate 'fallback' ? Feels hacky but sufficient in most cases I can imagine
Current interim work-around for me was to add dummy additional scheme patterns to my provider in order to make it a longer string than the others so it would lose the sort! ;-p
* XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Comments