Feature #18194
openMigration routine for CVs
0%
Description
When we introduce the new CV feature #17768 we will need to migrate over existing user data. Some initial thoughts for discussion:
- We should not create CVs for all existing users. How do we decide? I propose that we should only create them for users who have at least one "bottom" section filled in - Education, Positions, Publications, etc. Does anyone else have suggestions for how this should work?
- 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. Ones with lots of fields built in, etc.
- Should old data - ie the BP profile data - be deleted or kept? It depends in part on whether we will continue to use the BP profile data. I'm thinking in part of directory search. If we do this, we'll need a mechanism in the regular CV save routine that syncs the relevant fields to BP's profile data system.
The migrator will have to be one of the last things built, since it'll depend on the specifics of the CV block implementation. See #18192, #18193.
Files
Related issues
Updated by Boone Gorges 5 months ago
- Related to Feature #17768: CV Editing and Publishing added
Updated by Jeremy Felt 4 months ago
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.
Updated by Boone Gorges 4 months ago
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.
Updated by Boone Gorges 2 months ago
- Related to Feature #18467: "Positions" migration to new CV editor added
Updated by Boone Gorges 11 days ago
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.
Updated by Boone Gorges 11 days ago
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
Updated by Colin McDonald 6 days ago
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.
Updated by Sara Cannon 5 days ago
- File Social Icons.zip Social Icons.zip added
Ray - Here are some SVG's of social icons to refresh. Should we remove the IM, Flickr, and Delicious fields?
Updated by Boone Gorges 5 days ago
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.
Updated by Sara Cannon 5 days ago
- File Social Icons.zip Social Icons.zip added
Sounds good. I've re-attached the zip file with the icons so it include those. (it was pretty funny trying to find a modern Instant Messenger icon)