-
-
Notifications
You must be signed in to change notification settings - Fork 813
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
(dev/core#2994) oEmbed - Basic protocol support (*incubation*) #29536
Conversation
🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷 Introduction for new contributors...
Quick links for reviewers...
|
e7f6bfc
to
fe4453a
Compare
@seamuslee001 This should be a bit more interesting to test:
|
fe4453a
to
c3bf2c9
Compare
f0ed78e
to
a7132c9
Compare
// Example usage: <crm oembed-sharing page="https://example.com/foo/bar?id=123"></div> | ||
angular.module('crmOembedSharing').directive('crmOembedSharing', function() { | ||
return { | ||
restrict: 'AE', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another newbie question: what does AE mean or do in this context?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A directive can be activated based on HTML (a)ttributes (<div crm-oembed-sharing>
or HTML (e)lements (<crm-oembed-sharing />
) or HTML (c)lasses (<div class="crm-oembed-sharing">
).
The exports
and restrict
both speak to this. It's the same "A". Slightly different angles:
- The
exports
is more of a build-instruction/dependency-info. If somebody else wants to usecrm-oembed-sharing
, then we should autoload the module. - The
restrict
is a runtime thing -- it tells the browser how to target things at run time (eg how to use DOM selectors).
This mismatch between them (exports=A
, restrict:AE
) is a latent bug.
$data = [ | ||
'page' => Civi::url('frontend://' . $pathStr, 'a')->addQuery($query), | ||
'iframe' => Civi::url('iframe://' . $pathStr, 'a')->addQuery($query), | ||
'share' => Civi::url('frontend://civicrm/share', 'a')->addQuery(['url' => Civi::url('frontend://' . $pathStr, 'a')->addQuery($query)]), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just confirming that frontend://civicrm/share is something that gets maps to a different URL depending on the User Framework/CMS of the producer site, and also allows different entry points for each, specifically WordPress which cannot have a url/route be mapped to file system location at top level within docroot if we are to comply with WP software policies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JoeMurray, yeah frontend://civicrm/share
is an ordinary frontend route -- going through the normal CRM_Core_Invoke
, CRM_Core_Menu
, civicrm_invoke()
, etc. It's just a stub.
- It can convey extra params like
?maxwidth
and?maxheight
. - If you paste into an oEmbed client, then it's replaced by the
<iframe>
. - If you open it manually, then it redirects to the real page.
Overview
oEmbed is a protocol for sharing HTML snippets across different sites.
This PR adds initial support for CiviCRM to provide embeddable content on external websites. However, the mechanism is somewhat experimental. Consequently, it is implemented as a hidden extension (
oembed
).See also: https://lab.civicrm.org/dev/core/-/issues/2994
Technical Details
The standard protocol works like this:
Browse to a page that is interesting. Copy the URL. For example:
Open your favorite web-editor/CMS.
Paste-in the URL (or add an "Embed" widget... and paste-in the URL).
The web-editor/CMS performs a lookup via oEmbed, which returns a new snippet of HTML, eg
This snippet is basically the same content, but it's reformatted to fit into an external web-page.
oEmbed and
<iframe>
are technically different things. (Each mechanism can exist without the other.) But there appears to be a symbiosis -- if you want to embed content with interactivity/scripts/styles/forms, then the odds of getting through seem better with<iframe>
s. Hence, theoembed
extension builds on theiframe
extension. (*In this impelmentation, pages will get oEmbed features if-and-only-if they have<iframe>
support enabled per #29496.)After enabling the
oembed
extension, this settings page becomes available.Screenshot: Administer: oEmbed Settings
With the first option ("Auto Discovery") enabled, pages support the ordinary oEmbed pageflow -- and any visitor can use it. With the second option ("Explict Sharing"), you get more control over who/how of sharing. This panel becomes available to users with suitable permissions:
Screenshot: Cross-Site Sharing Panel
There are a few reasons for regarding this as an incubating/experimental extension: