#1396 closed enhancement (fixed)
Allow Plugin pages to be oembedded like WP Posts
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Plugin Directory v3.0 | Priority: | normal |
Component: | Plugin Directory | Keywords: | good-first-bug needs-design |
Cc: |
Description
This may not be possible as I'm not 100% sure how the plugin repo is set up in terms of content storage, but it would be really great if we could enable oEmbed for plugins. The oEmbed content could essentially be the same as the plugin card that appears in the search results, which means we wouldn't have to write any additional markup and it would make linking to plugins from another site (say a blog post announcing a plugin release, for example) way more visually interesting and appealing.
Like I said though - I'm not sure if this would even be possible, but if so I think it would make a great enhancement to the repo and it would make sense if the same could be applied to themes as well.
Attachments (4)
Change History (32)
#2
@
9 years ago
Yeah I know about that plugin and it's very useful actually, but was just thinking that a native solution would be cooler if it could be implemented at some point.
#3
@
9 years ago
This isn't really feasible now, but we'll make sure the oEmbed output is good when we redo the plugin directory on WordPress.
#5
@
9 years ago
- Keywords needs-patch removed
Removing 'needs-patch' from components that are not open sourced yet, to help focus on tickets that actually need a patch.
#6
@
9 years ago
- Owner set to Otto42
- Status changed from new to accepted
Related: #1464
This is something I think we can do before updating the plugins directory as a whole, but in a way that will be forward compatible with the soon-to-be-converted directory. The embed logic is not difficult to do.
This ticket was mentioned in Slack in #meta by ocean90. View the logs.
9 years ago
#9
@
9 years ago
The new directory does not (yet) have oEmbed output. Should we customize the output a bit?
Probably not work fixing this in the old directory at this point, unless the code is already complete.
#10
@
9 years ago
I think we should definitely customise the oEmbed output for the new directory - no point in doing it for the old directory now, and this would be the best time to do it for the new one.
Like with the old directory, the easiest option would probably be to use the exact same markup that the plugin listing cards use, so there's no need to rewrite anything and we can just pull from the same templates.
This ticket was mentioned in Slack in #meta by webdevmattcrom. View the logs.
8 years ago
#12
@
8 years ago
- Owner Otto42 deleted
- Status changed from accepted to assigned
I actually started this for the old directory, but never finished it because of problems with the URL routing and bbPress 1.x.
Adding it to the new directory will be as simple as adding some embed.php templates to the theme, for the most part, so yes, I think we should focus on that instead.
#13
@
8 years ago
- Milestone set to Plugin Directory v3 - Future
So, embed already works on the new plugin directory, it just needs to look a lot better. I don't have a working meta environment right now so I can't really fix that.
#14
@
8 years ago
- Summary changed from Enable oEmbed for plugins to Allow Plugin pages to be oembedded like WP Posts
#16
@
8 years ago
I think we can mostly still go with the plugin cards, with some additional tweaks to make them match post embed cards a little more. The current plugin cards don't really look like cards (no border around them or shadow), and I don't think would look like an embed as-is.
#17
@
7 years ago
- Keywords good-first-bug needs-design added; needs-ui removed
This should be as simple as making an embed.php file in this theme:
https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/wporg-plugins
Starting with the base card view that WordPress has and perhaps adding the icon would be a good place to start.
#18
@
7 years ago
embed-starter.php is terrible proof-of-concept code that will show the existing plugin card as an embed, at the cost of tons of extra styling added for no reason. Also attached an example image.
This ticket was mentioned in Slack in #design by melchoyce. View the logs.
7 years ago
#20
@
7 years ago
If there's a designer interested in working on this, there's more background here: https://wordpress.slack.com/archives/C02S78ZAL/p1512498921000055 (bseekins is going to pass on this one, so it's open for any interested designer)
#21
@
7 years ago
Okay, I see that there was some confusion about this over in Slack, so I'll explain the concept a bit better.
Ever since 4.4, WordPress has had "Embeds" as a feature: https://wordpress.org/news/2015/12/clifford/
Basically, when you link to a WordPress post, instead of it just showing a link, it shows that neat little embedded box with more info and share buttons and the like.
The way this works internally is a bit irrelevant, but the short of it is that the box is an iframe to the post with /embed/ after it. Like this: https://wordpress.org/news/2015/12/clifford/embed/
The Plugins directory now runs WordPress, so it has embeds too: https://wordpress.org/plugins/akismet/embed/
The design for this box is adjustable. Easily so, because all you have to do is to make an embed.php in the theme and that gets used for that box instead.
Now, you can design that box any way you like. Has to be a box because it goes into an iframe on sites, but still, no real limits.
So, the idea is to design a box that looks better than the default box. One which has useful information about the plugin, which links to it, and so on. Doesn't have to have a Share button, as such, but that would be nice.
The design I show above I stole straight from the existing "cards" in the plugin directory. Doesn't have to look like that, necessarily. That was just already there and thus easy to do.
So, that's the goal. Design a box that has useful information about a single plugin. It should fit into a reasonably small space. The default space for the iframe is 600x338, but that's adjustable if needed.
Don't worry too much about the code, that's the easiest part of the problem to do for us. :)
#23
@
7 years ago
For sure, I've attached a stab at it below.
The card view from WordPress was an okay place to start, but there's a lot of grey in it, and arguably some stats there are less relevant when showing the embed on a site. Version and compatibility may be more relevant if the card offers a direct download link, but I'm going to assume we'd want to direct people to the plugin directory listing first? They'll have a chance to look at the version and ratings etc more in-depth there if they want, that frees up some room to keep the embed card clean.
I started with a very minimal one, similar to how it is now, and also made a version that has a bit more WP feeling in it. 600x338 is a bit of an awkward size, so I used 1024x356 for this example, though it has enough leeway to be responsive.
#24
@
7 years ago
Thanks @hedgefield, that top option feels right. We'll want to match the border and box-shadow styles from the post embeds:
border: 1px solid #e5e5e5; box-shadow: 0 1px 1px rgba(0,0,0,.05);
And probably the description text color, though in this case I actually think we need to adjust the post embed styles — the current color (#82878c
) doesn't pass contrast. Thinking we should go with #606A73
or #555D66
for both embed's paragraph color.
#25
@
7 years ago
Good points @melchoyce, thanks. Perhaps in abundance, but I updated the mockup with those suggestions. The shadow values don't exactly map to photoshop 1-to-1, but I got them as close as possible. I think 555D66 is the best color out of the two for the description.
I like the idea but until it happens you can use the "WP Plugin Info Card":
https://wordpress.org/plugins/wp-plugin-info-card/