Closed Bug 865709 Opened 11 years ago Closed 11 years ago

Generate and inject social sharing metadata in Thimble Makes

Categories

(Webmaker Graveyard :: Thimble, defect)

Product:
Webmaker Graveyard
Component:
Thimble
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: humph, Assigned: thecount)

References

Details

Attachments

(1 file)

https://github.com/mozilla/thimble.webmaker.org/pull/36
2 bytes, text/plain
michiel
: review+
Details 
We want Thimble makes to show up properly in social media, see discussion in bug 865704.  To that end, we need to add a publish step where we take the document created by the user, examine it for existing Open Graph metadata, and add any/all that are missing.

In bug 862832 we are adding the concept of webmaker:* metadata.  This should work in combination with that, since they serve different purposes.  Where webmaker:* metadata is about passing metadata to the MakeAPI as it gets published, og:* metadata is about decorating the final product for consumption by external services.  The former is something our users put in documents, the latter something our tools generate/add automatically.  We might consider stripping the webmaker:* metadata after we process it--something to think about as we add a Remix button to Thimble (should the webmaker:* metadata you put in a doc get copied when you remix something?  I'm not sure yet).

I took a stab at a baseline for metadata we'd need to work well in social media sites, and it looks like this:

* URL
* Site Name
* Title
* Description
* Author
* Image
* Locale
* Last Updated Datetime

So we'd need to generate the following on a thing we publish with our tools:

<html>
<head>
  ...

  <!--Webmaker generated Social Sharing metadata-->
  <meta property="og:url" content="http://humph.mywebmaker.org/poetry">
  <meta property="og:site_name" content="Mozilla Webmaker">
  <meta property="og:title" content="My Amazing Web Poem">
  <meta property="og:description" content="A poem I wrote for the web">
  <meta property="og:author" content="David Humphrey">
  <meta property="og:image" content="http://thumbnail.webmaker.org/image.png">
  <meta property="og:locale" content="en_CA">
  <meta property="og:updated_time" content="2013-04-25T15:38:19.727Z"

  ...
</head>
...
</html>

See http://developers.facebook.com/docs/opengraph/creating-object-types/#properties for more details about content datatypes and formats (e.g., ISO 8601 for Datetime).
Here is a start.

https://github.com/mozilla/thimble.webmaker.org/pull/31

It's not pretty, and I have not yet figured out a way to strip out the tags on a load.

Seems the loadCode block is for loading from text, and not from a url. I need to do this when a project is loaded from a url (a remix).

It does however allow users to override any og tags with their own.

I also have not generated the tags content yet. Still laying framework here.

Also not pushing any of this into the makeAPI yet. It is easy enough to do, but I'm not 100% sure if that's the best idea or not. Putting it in the page itself seems more useful for what og tags do. Although I see no harm in storing it in the makeapi, and if people need to see it for something they can. Is that the idea?

Iframes are fussy...

More later.
Looking at bug 865704 it seems we do in fact want it in the makeapi.
I found how to strip them on a load.

I think I'm going to make a generateMetaTags and stripMetaTags set of functions. Reduce clutter.
Something Pomax mentioned in the pull request that I agree with after trying the above.

"have this information living on the actual page template with placeholder text that people can simply modify themselves?"

Would that be enough?
I agree that iframe hacking is not ideal.  Can you explain what you mean regarding placeholders?  I don't fully understand.
I think the idea is to have the default thimble document start with some og tags already in there, and let users update them as they see fit.

I would like it if the initial state of the data is something that makes sense, and not "foo", "bar", etc.

I am pretty sure we can do this with nunjucks.

This way we don't have to insert anything, only initiate things, and from there it is up to the user.
I don't think this will result in what we want.  What will happen is that people will mostly ignore it, and we'll have half-filled out metadata.

I want the Open Graph data to be generated so it's a value-add thing vs. a requirement.  If you include it yourself, we should keep what you have, and not add our own; but if you don't (99% of users), we'll do it for you.

It also breaks the remix case, where someone has unfinished metadata that we stuck there for them, someone else remixes, we go to inspect the document and see the old metadata and do nothing.

Not a good idea.
I actually agree with points on all ends. What I see being required is:

It should not be an iframe hack, and ideally server side.

Needs to be generated, and hidden to the user.

A remix would inject new data, for the new user instead of remixing the old meta tags.

The user can override it with their own tags. If that happens, we need to show the user created tags on an edit for just that user, and not hide them. If another user hits remix, they do not see the last users created tags, and only see any if they added the tag themselves.

I can make this work a number of ways, but I fear it'll not be ideal for one reason or another. example: inserting it into the raw html text server side.

I'll think on it, it is solvable, just not obvious to me.
If you want to do it all server side, maybe use jsdom https://github.com/tmpvar/jsdom
small nit in pull, r+ with that.
Attachment #743072 - Flags: review?(pomax) → review+
Comment on attachment 743072 [details]
https://github.com/mozilla/thimble.webmaker.org/pull/36

I have yet to figure out the url and s3 problem.

I am wondering if we want to split it into a new ticket?
Attachment #743072 - Flags: review+ → review?(pomax)
if there's an "and", file new issues for each "we need to figure this out" point.
Sorry, s3 and url is the same problem. I want to file it, and talk to Jon a bit on ideas too.

I feel republishing is a bit of a hack, and if it's all we can do, we can do it, but I don't see a rush on getting the url if the rest of the data is in there. So if there is a better solution than republishing, we can figure it out. We only lose url if we land this now, instead of holding off everything.
also, one last nit on the pull request.
as for #14, yes, definitely file this as a separate issue, it is not something that can, or should, hold up injecting OG data.
Attachment #743072 - Flags: review?(pomax) → review-
Comment on attachment 743072 [details]
https://github.com/mozilla/thimble.webmaker.org/pull/36

Should be all done now.

It was just some leftover vars from a previous implementation.

Moving forward from this ticket, I'll fill in the text on bug attachments.

Filing a new issue for the url now.
Attachment #743072 - Flags: review- → review?(pomax)
Attachment #743072 - Flags: review?(pomax) → review+
perfect, land it.
Staged: https://github.com/mozilla/thimble.webmaker.org/commit/de9d0ef7c0d0626aa0b4a11ea139d6b754570301
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
https://github.com/mozilla/thimble.webmaker.org/pull/36 is still unmerged. What happened here?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I did a squash and rebase on master, then pushed the result of that. It makes for really clean commit history. It is just what I am used to and do without thinking.

I apologize. I've seen how aware you are of pull requests, and did not consider how this method would not of been obvious from the pull request point of view.

I'll close the open pull request, and for next time figure out if I should continue doing this or not. I'm totally cool not doing it.
Scott: Continue to do what you're doing, but push your rebased branch up to github before you push to mozilla/master. Github will automatically close the pull request if the exact same commit gets merged into mozilla/master.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Blocks: 867195
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: