CUNY Academic Commons

There was a bit of talk in the dev chat about keeping the CV data and the Commons Profile header data separate. I'm wondering whether we can just use the CV's data as the main source of data. By that I mean, if a user has filled in their CV's name, pronouns, one-line bio, social links, etc, we will display that same data in the Commons Profile header and we will not show the "Account Settings > Edit Profile" screen at all. I've already got some code for this ready to go. The code uses the parse_blocks() function and thanks to the placeholders in those blocks, it is possible to extract data for specific blocks from the CV.

This is an interesting idea. But I think it ultimately limits what users can do with their CVs. You might imagine, for example, someone with a professional and a personal Twitter account; they might want one listed on the CV and another listed on the Commons Profile. Even Name - I can imagine someone who uses a different version of their name on a CV.

Keeping the CV and Profile fields separate might cause some confusion, but it allows for full flexibility. Syncing the two, on the other hand, eliminates some possible confusion at the cost of eliminating certain ways of filling in data. On balance, in this case, I think it's better to address the potential confusion with documentation. Happy to defer to what Sara and others think, though.

I also see both the benefits and drawbacks of this. I wonder if another argument against syncing is the item-by-item control over visibility that one has for the profile fields, whereas the CV fields are all totally public by design/default.

I guess this would be avoided somewhat by not showing the Edit Profile screen if the CV exists, but something doesn't feel quite right to me about showing this screen to some and not others, without a better way of making it clear why that's happening. In the documentation (which I agree we'll need a good amount of here), it's easier to instruct everyone if we know they're seeing the same things.

As I was writing my latest update to #17768 just now, it also struck me that it might be nice to clarify/separate the CV and the profile as much as possible. Right now one of our editing links is for CV/Profile and we use that language sometimes, but I think there's some benefit to helping people see them as separate in both functionality and overall purpose.

A first pass of the "Account Settings > Edit Profile" screen and revamped "Commons Profile" header is available for testing on cdev.

For the "Account Settings > Edit Profile" page, we will re-use the existing BuddyPress "Profile > Edit" page and hide the existing "Account Settings > Profile Visibility" page.

For the "Commons Profile" header, we will display the reconfigured profile fields and will use microformats markup as well for better parsing by apps and search engines utilizing microformats. See https://microformats.io/ for more info.

One issue I encountered when entering invalid info for the "Email Address", "Website" and "Blog" fields is we do not do any validation checking whatsoever when submitting the form. For the moment, I am doing some rudimentary checking to see if these fields have valid email and URL values respectively before displaying that info in the header, but we should add some error messages if a user attempts to add invalid data during submission.

I wonder if another argument against syncing is the item-by-item control over visibility that one has for the profile fields, whereas the CV fields are all totally public by design/default.

Yeah, having control over the profile field visibility is the main reason to keep the existing set up. However, entering that same core info (name, pronouns, one-line bio) on the CV again nullifies this advantage.

Hi Sara,

Good catch about all the social icons still being displayed in the header.

To follow-up on that, based on the first mockup displayed at the top of this ticket, was the intention to limit the social fields to just Facebook, Twitter and LinkedIn? If so, I can fix up the header so it only displays those three sites.

Regarding:

I get that maybe we want to sunset some of these socials for users, but if you already have them - they should be editable.

I think we shouldn't have some existing users being able to edit more social media sites than those users that will not have access to those sites. I think we should make a list of the social media sites we will want to display and retire ones like Delicious that we know are outdated. Would welcome others thoughts on this as well.

I think it's right that we should retire most of the social media sites, especially for the Commons Profile header. People can always add more to their CV if they'd like. In #17018 are the pulled numbers showing that most of these fields are rarely used, and likely not very recently at that.

Quick followup, I'd be in favor of just having Twitter, Linkedin and Facebook as the default fields.

Colin McDonald wrote in #note-11:

Quick followup, I'd be in favor of just having Twitter, Linkedin and Facebook as the default fields.

that sounds fine to me, as well

Quick followup, I'd be in favor of just having Twitter, Linkedin and Facebook as the default fields.

This is done and available for testing on cdev.

Here are links to the icons that we can use for Google Scholar and OrchidID. They have SVG downloads but let me know if you need me to format it a certain way and I can

Google Scholar Icon: https://fontawesome.com/icons/google-scholar?f=brands&s=solid
OrchidID Icon: https://fontawesome.com/icons/orcid?f=brands&s=solid

Thanks for finding this bug and for the recording, Colin.

The redirect issue is due to plugin conflicts with the CAC Advanced Profiles plugin and the CAC YOURLS shortlink plugin. Both plugins short-circuit the profile update routine by redirecting back to the main user's root profile, which would be the CV page if a user has a CV published.

• CAC Advanced Profiles - https://github.com/cuny-academic-commons/cac/commit/0e4a87d5a484ff6d7b78f549354d4d5e8e0f6fd9
• CAC YOURLS - https://github.com/cuny-academic-commons/cac/commit/54573b4967901ca6420af96c6f6089742184d010 . Boone, I decided to remove the CAC YOURLS profile validation routine and added the snippet in the CAC CV Editor plugin because the CV Editor now includes a Shortlink block, but let me know if you think this snippet should reside elsewhere.

Colin, the fixes are deployed on cdev. Feel free to test again to see if the redirect issue is still occurring.

Thanks, Ray! These fixes seem fine to me.

Looks good on CDEV to me too, thanks Ray!