CUNY Academic Commons

It would be good to discuss this at the team meeting, but I think your proposed metric ("at least one 'bottom' section filled in") is reasonable

We'll have to build block markup using a pipeline like serialize_blocks(). This is likely to be subject to all sorts of issues with character encoding, etc, so we'll have to find some outlier profiles to use for testing.

Is any of the existing data in HTML? Dealing with arbitrary tags while importing into a block structure would be the most annoying.

Is any of the existing data in HTML? Dealing with arbitrary tags while importing into a block structure would be the most annoying.

Yes, though it's a pretty limited subset. Aside from inline elements like <em> and <a>, there are paragraphs and, IIRC, lists. So I don't think it'll be overly finicky to translate.

Work-in-progress migration routine https://gist.github.com/boonebgorges/60467a056ec9f26a044ace3e4d52fdc9

It's not fully rigged up in that it doesn't yet create the CV post type, but this is trivial to add. I've run this with various types of profiles and it seems to handle most types of content pretty well.

Some outstanding issues, for my own reference:
- The following social-ish fields exist on the Commons but are not yet being migrated: ORCID ID, Google Scholar, Academia.edu, Delicious. We may want to scrap Delicious. The other three aren't natively supported by WordPress, so we need to write our own custom variations.
- A couple cac-cv-editor blocks aren't properly rendering for me. Not sure yet whether this is a bug in my migrator or in cac-cv-editor. These are: cv-last-active and cv-profile-navigation.
- When we come up with the placeholder text for various fields, I'll have to update the script.
- There's no logic built in yet for determining whether a user should in fact have a CV created, ie my suggestion that we create if a user has at least one "bottom" section.

Quick follow-up that I figured out non-rendering blocks. The block-renderer requests were 403ing, which was happening because no postId was being sent by ServerSideRender. I've added the necessary urlQueryArgs: https://github.com/cuny-academic-commons/cac/commit/956c123d765c73db2f7506224cf0ee11d286de59

Regarding the fields like Delicious to be scrapped, it seems that we never closed the loop on ticket #17018 and the data we pulled on how active these fields are. Here's the main takeaway:

I don't have the ability to determine when people added the data. As you'd probably guess, things like IM, Flickr, Delicious have been defunct for years, and all existing instances are probably ancient. Here are current raw numbers for each (again, out of ~39,000 user accounts):

- IM: 272
- Flickr ID: 227
- Delicious ID: 194
- ORCID ID: 152
- Google Scholar: 161
- Blog URL: 804
- I don't see an RSS field, but the Website field has: 2343

All of these except Blog URL and Website seem like candidates for removal to me. People could always add this info in a freeform block/field. But perhaps we can ask Luke/Matt/Laurie/etc on an upcoming call if things like ORCID and Google Scholar are particularly important in an academic setting to offer.

Sara, we're not going to remove anything for this interim release - it's a reskin only. We'll discuss whether and how to remove other fields as part of this ticket.