Project

General

Profile

Actions

Feature #12134

closed

Site cloning

Added by Colin McDonald over 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority name:
High
Assignee:
Category name:
Site cloning
Target version:
Start date:
2019-11-22
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

Hello, starting a fresh ticket here to consolidate our discussions on this feature for the spring 2020 release. In the group meeting last Friday we narrowed down our plan for this.

We want to focus on sites for now as groups have many more content types. And our main use case will be professors looking to clone their own sites, i.e. for a new semester's class. There may be a side use case where a professor clones their site for someone else (like someone teaching another section), but the main idea is that we're not doing shared cloning where someone can clone any site they'd like. There are a lot of technical and permissions issues there. The cloning will be initiated by a current admin of the site, and they'll be the admin of the clone (which they could then invite a new admin to).

We need to talk about what will and won't be carried over when cloning. We don't want people to have to go back and delete a bunch of things on the clone to get it ready, or of course for student content to be carried over (for privacy reasons, but also to have a clean slate for new students).

Other questions are whether cloned pages should be in draft form first or live, and whether plugins are carried over as well. Boone, do you have any opinions about those, or about how we might set cloning up as sort of a branch of the Wordpress Import/Export feature where you choose different types of content to be carried over?

Once we hash out a few more technical questions here, and anything else I'm forgetting, Sonja perhaps we could talk about how this might be best designed for people to make use of it.


Files

Cloning-UI-v1.png (379 KB) Cloning-UI-v1.png Sonja Leix, 2019-12-11 07:20 PM
Cloning-menu-item-v1.png (337 KB) Cloning-menu-item-v1.png Sonja Leix, 2019-12-11 07:20 PM
A-Cloning-option-frontend-v1.png (129 KB) A-Cloning-option-frontend-v1.png Sonja Leix, 2019-12-11 07:20 PM
Peek 2019-12-17 13-25.gif (1.64 MB) Peek 2019-12-17 13-25.gif Boone Gorges, 2019-12-17 02:41 PM
12134 Site Cloning-flow-v2.pdf (1.34 MB) 12134 Site Cloning-flow-v2.pdf Sonja Leix, 2020-01-07 12:25 PM
Clone-site-flow–design-v3.pdf (1.4 MB) Clone-site-flow–design-v3.pdf Sonja Leix, 2020-01-15 08:37 AM
Clone-site-flow–design-v4.pdf (1.37 MB) Clone-site-flow–design-v4.pdf Sonja Leix, 2020-01-24 07:02 PM
Clone-site-flow–design-v5.pdf (1.37 MB) Clone-site-flow–design-v5.pdf Sonja Leix, 2020-01-27 08:05 PM
group-site-2.png (147 KB) group-site-2.png Colin McDonald, 2020-01-28 09:37 AM
group-site-1.png (169 KB) group-site-1.png Colin McDonald, 2020-01-28 09:37 AM
Clone-site-flow–design-v6.pdf (1.78 MB) Clone-site-flow–design-v6.pdf Sonja Leix, 2020-01-30 07:58 PM
Clone-site-flow–design-v7.pdf (1.79 MB) Clone-site-flow–design-v7.pdf Sonja Leix, 2020-02-04 02:17 PM
Clone-site-flow–design-v8.pdf (1.78 MB) Clone-site-flow–design-v8.pdf Sonja Leix, 2020-02-04 08:04 PM
Clone-site-flow–design-v9.pdf (1.89 MB) Clone-site-flow–design-v9.pdf Sonja Leix, 2020-02-10 10:13 PM
Clone-site-flow–design-v10.pdf (1.89 MB) Clone-site-flow–design-v10.pdf Sonja Leix, 2020-02-12 03:44 PM
Clone-site-flow–design-v11.pdf (1.88 MB) Clone-site-flow–design-v11.pdf Sonja Leix, 2020-02-26 12:32 PM
icon-caution.svg (942 Bytes) icon-caution.svg SVG : caution icon Sonja Leix, 2020-03-05 01:49 PM
Screenshot 2020-05-12 00.47.57.png (97.7 KB) Screenshot 2020-05-12 00.47.57.png Sonja Leix, 2020-05-12 02:48 AM

Related issues

Related to CUNY Academic Commons - Bug #12771: Blog name uniqueness check doesn't work during blog creationResolvedBoone Gorges2020-05-08

Actions
Related to CUNY Academic Commons - Support #16291: Images coming up blank in Media LibraryResolvedRaymond Hoh2022-06-23

Actions
Actions #1

Updated by Boone Gorges over 4 years ago

I've added a few watchers who will want to read through this ticket.

Other questions are whether cloned pages should be in draft form first or live, and whether plugins are carried over as well. Boone, do you have any opinions about those, or about how we might set cloning up as sort of a branch of the Wordpress Import/Export feature where you choose different types of content to be carried over?

I leave it to the wisdom of the team to decide on the "draft" question. Active plugins should almost certainly be copied over, as should all other "settings" - active theme, etc. We will not use the WP Import/Export feature as a technical basis, though I can imagine that we might borrow some concepts from its UI, especially around the questions of selecting which content should be copied.

Actions #2

Updated by Sonja Leix over 4 years ago

Once we hash out a few more technical questions here, and anything else I'm forgetting, Sonja perhaps we could talk about how this might be best designed for people to make use of it.

I align with Boone in regards to cloning plugins, theme, and settings. Draft I'm also ok to leave up to the group, or there might be a setting in the UI.
In regards to the cloning interface and the options, what options do we want to surface? I took a very first stab at this, see attached.

Would the license and privacy policy also be cloned as is from the current site or should we include options for that in the cloning UI? Unless there is a compelling reason to, I would suggest to keep it simple and clone these options as they are on the original site.

See attached thoughts in visuals:
Cloning-option-frontend-v1.png – the easiest way to include a cloning options is, if we implement the "My Sites" list. (Similar to http://redmine.gc.cuny.edu/issues/9651)
Cloning-menu-item-v1.png – the most intuitive place for a cloning option is within the Tools menu in the backend
Cloning-UI-v1.png – very first quick mockup of a cloning UI as a conversation starter

Is this sufficient as a basis for discussions on Friday?

Actions #3

Updated by Colin McDonald over 4 years ago

Hello Sonja, thanks for taking a thoughtful stab at this with a few steps of what the process will be. It's a lot easier to think about how this might work now, and yes, barring any other big feedback today, I think we can use this as a basis for discussion tomorrow.

Actions #4

Updated by Sonja Leix over 4 years ago

Thanks Colin. I've created a short walk-through video for the design explorations of this as well if you prefer to present it this way. You're also happy to walk the group through with just the designs.
You can download the walkthrough video here: https://drive.google.com/file/d/16u_68PjFQummCVl1pxMEhJ7DFRdklQw0/view?usp=sharing

Actions #5

Updated by Luke Waltzer over 4 years ago

This is really great. Looking forward to talking through today.

One element to consider on first read: might we create some data during the clone that shows and potentially maintains the connection to the original site? Could see this being useful in a number of ways over time.

More later!

Actions #6

Updated by Colin McDonald over 4 years ago

Hi Sonja, we decided on Friday that we'd like to put the cloning process into the main site creation flow, i.e. when you click on the Create a Site button. Glad to hear your thoughts on this, but we were thinking that if you're logged in and are the admin of any sites (since only site admins can clone, and only their own sites) you will see a Clone a Site button. It seems to me that this would make the most sense next to the Create a Site button on the main Create page, but maybe we can talk about that during the dev call, as I'm not sure we nailed that down.

Then, if you choose Clone you could have a menu of your different admin sites to choose one. After that, instead of being in the Wordpress admin area, what do you think of the next screen after choosing being the usual Site creation screen, but with all of the details from the cloned site pre-populated, and the Site Layout area removed (because all plugins and themes will just be carried over)?

We should confirm this on the dev call, but during the meeting we were leaning toward fewer options regarding what is cloned. We know we can't clone student content due to permissions, so I think we might just want to clone everything owned/associated with an admin account by default and leave it at that -- people can go back and delete things later from the cloned site if they'd like.

I was thinking we could also still leave the Clone Site drop-down option in the My Sites tab for admins, which would then take you into the flow described above with pre-populated options within the usual Site Creation screen.

Actions #7

Updated by Boone Gorges over 4 years ago

Hi all - As promised, I'm attaching a gif of the "create vs clone" toggle works on the OpenLab. You only see the section at the top of the page if you have cloneable sites (sites of which you're the administrator). When selecting 'Clone', you're able to select from your sites in the dropdown; after you do, certain fields further down the page are auto-filled based on the corresponding settings on the clone source. I imagine something similar for the Commons. In addition, I envision that certain bits of UI will be shown/hidden based on the Create/Clone toggle: for example, when creating a new site, you'll see Site Layout, but when cloning you won't see Site Layout but will see additional text (and perhaps more options?) related to the cloning process.

Actions #8

Updated by Sonja Leix about 4 years ago

Thanks all for the feedback and summary of the feedback from the meeting in December.

Please see attached the updated site creation flow, the primary screen where the user selects what to create will stay the same, I would recommend to not include another button to clone a site to keep it simple and not overwhelm the user with options. If we want to hint at cloning, we could update the copy there to inform about the option.

As Boone suggested, the clone site vs. create new site option only appears if the logged in user has clone-able sites (site the user is an admin of).

As discussed during our last dev call in December, rather than fully removing sections of the site creation flow where the cloning process won't allow the user to select options (e.g. the theme), I'd advocate that we should reveal the option to inform the user. This will help educate the user what is happening.

This is how I envision this new section to work: By default "Create New" is selected. Once the user selects "Clone Site" the dropdown of the available sites to clone from appears. Once a site is selected to clone from from the dropdown, the fields below will pre-populate.
Let's discuss and define what other sections or options we might might be locked in (e.g. the theme as indicated in this revision).

Question:
Would this cloning option also impact the "Site + Group" creation flow or just the Site creation flow?

Actions #9

Updated by Colin McDonald about 4 years ago

Hi Sonja, I took a stab at the copy areas that need filled out for this, as discussed on the dev call. Let me know if any of this is unclear. Thanks!

On Create page, Sites second column Key Benefits, last bullet point:

- If you are signed in as an admin of an existing Site (whether paired with a Group or not), you can clone it after clicking Create a Site or Create a Group + Site.

(I decided that this would be the easiest place for this note, as there is space in the Sites area. I think we can reference the next column over for Group + Site to save space there, but open to thoughts.)

Next Page

Create New or Clone Existing?
You can either start fresh with your Site or clone an existing Site (if you are an admin of it) to use as the basis for another site.

Note: For cloned sites, scroll down to adjust License and Privacy settings and see what elements will be copied over.

Site Layout

By default, the cloned site will retain the theme/layout of the chosen parent/existing site. These settings can be changed later.

Site Content (add section)

The cloned site will contain all content (posts, pages, media, etc) attributed only to an admin of the parent/existing site, to avoid permissions issues. Admins may want to change attributions of content before cloning or copy content manually after cloning.

Actions #10

Updated by Sonja Leix about 4 years ago

Thanks Colin, I’ve updated the copy as you provided for the most part (see attached). I’ve decided to not implement copy the way we discussed on the Site Group Creation Landing page. The cloning feature isn’t really a “key feature” as the others are and it’s odd to include it here. Instead I’ve added a “Admin Site Cloning Capability” market at the bottom of those two columns where it applies. I’ve added a “?” Icon, which would bring up a tooltip that explains what this means. We can place the text you provided in the tooltip or add a little more context since we are not quite as worried about length of text (thought we do want to keep it concise).

I’ve adjusted the copy on the Group+Site flow where the user can add the site as well. Here our users have three options (1. Create new site, 2. Connect existing site, 3. Clone existing site). This is an added layer of complexity that the user will feel. I started by adding three separate options but it felt heavy and a little confusing.

Colin, I’d love to get your help massaging the copy for the cloning option within the Group+Site flow. We want to make sure that users clearly understand what options we’re offering here. Please also let me know if “Admin Site Cloning Capability” works for you, happy to adjust this copy.

Boone, look at the UI options for the cloning options and let me know if this would even work (specifically talking about the “Clone this Site” checkbox in the Group+Site flow). I understand that this adds a layer of complexity when it comes to the content below between selecting the clone checkbox and not. Unclear if that would work on a technical level.

Actions #11

Updated by Laurie Hurson about 4 years ago

Hi All,

I have been following this and just wanted to weigh in and ask a few questions.

I like the phrasing for "Admin Site Cloning Capability" with the tool tip. It makes sense (to me) to separate this feature out and to use the tool tip to provide more info.

  • In Group+Site Creation - I do like the three options (new/connect/clone) at the top. I think if the clone option were to be hidden, perhaps within "connect" (-> connect existing or clone) it would be more confusing.
  • In Site Details: Will any of this auto-populate based on cloned site info such as title, campus, or purpose? Sorry if i missed a discussion about this. I dont think auto-population is important, and in fact, I think it might be worth while to have the admin fill out this info again since purpose or campus may have changed.
  • In Site Layout, if the cloned site used a template it displays (as seen) but if it didn't use a template, would it just be the copy with explanation? I think this is fine, just wanted to clarify.
  • In Site Content the copy says "Admins may want to change attributions of content before cloning". I am wondering what we are getting at here. It could suggest - "if you change authorship of students' work you can also move that", which I dont think we want to encourage. Maybe it could read something like:

The cloned site will contain all content (posts, pages, media, etc) attributed and created by the site administrator. Content not created or attributed to the site administrator will not be cloned to avoid permissions issues. Make sure any content you created on your site and want cloned is attributed to the administrator to ensure it is moved to the cloned site.

Actions #12

Updated by Sonja Leix about 4 years ago

Thanks Laurie, I'll reply to a few questions below and would like for Colin or Matt to chime in about the broader questions and feedback you had.

  • In Site Details: Will any of this auto-populate based on cloned site info such as title, campus, or purpose? Sorry if i missed a discussion about this. I dont think auto-population is important, and in fact, I think it might be worth while to have the admin fill out this info again since purpose or campus may have changed.

I think the idea here is to make it easier for Admins to close sites by pre-populating this information. It can be adjusted as needed by the Admin during the cloning process. But I'd love to hear from Colin and Matt if this functionality with aligned with community/admin goals.

  • In Site Layout, if the cloned site used a template it displays (as seen) but if it didn't use a template, would it just be the copy with explanation? I think this is fine, just wanted to clarify.

All sites use a template (what we call here "site layout", so even if it is the default template, something will be displayed here – Boone, correct me if I'm wrong)

Actions #13

Updated by Colin McDonald about 4 years ago

Hello, responding to a few things from the last two posts here after a discussion Matt and I had on the dev call yesterday:

- Admin Site Cloning Capability works for me too on the Create page, and I like the new placement, but I wonder if that line could be more clear: "Admins can clone their sites" maybe? Same idea, but seems more direct to me.

- Then yes, I think this edited version of what I had before works in the tooltip: If you are signed in as an admin of an existing Site (whether paired with a Group or not), you can clone it after clicking the Create a Site or Create a Group + Site button below.

- In the V3 mockup page 2, should it say Create New, Connect or Clone Existing? It says Choose right now.

- In the Group + Site flow (page 2 still), perhaps the note below the Clone option is a little longer: "An admin of a Site can choose to clone it here to use as the basis for a new Site. Scroll down to adjust the clone's License and Privacy settings and see what elements will be copied over."

- Matt and I talked about the auto-population and were thinking it would be good if all of the Site Details auto-populated down through Primary Purpose, but that if the Primary Purpose is Teaching then the sub-fields (disciplinary cluster and semester) should NOT auto-populate to make sure that those get filled in correctly/actively during this process. We could consider leaving campus blank as well as Laurie suggested, but perhaps it would be too confusing (or technically tricky) to just leave that main field blank. Curious what Boone thinks about this.

- Sounds good about displaying whatever template (i.e. theme, yes?) the existing site is using and will be transferred to the cloned site.

- Matt and I discussed using simpler copy for the Site Content section. I don't think we need to talk here about changing content attributions, or even encourage that. Maybe we link out to a help article explaining this more for those interested. Let's try this: "Only existing Site content authored by admins (posts, pages, media, etc.) will be copied over to the cloned Site, to avoid permissions issues."

Actions #14

Updated by Boone Gorges about 4 years ago

Boone, look at the UI options for the cloning options and let me know if this would even work (specifically talking about the “Clone this Site” checkbox in the Group+Site flow). I understand that this adds a layer of complexity when it comes to the content below between selecting the clone checkbox and not. Unclear if that would work on a technical level.

I don't see a technical reason why we shouldn't be able to make it work.

All sites use a template (what we call here "site layout", so even if it is the default template, something will be displayed here – Boone, correct me if I'm wrong)

You're correct that the template is inherited from the clone source. In fact, IMO, we don't need to show this section at all in the case of cloning, since I think it's clear from context and other copy that visual settings (including theme and other settings from the Template) will be part of the clone. As shown in v3, it takes up a ton of room for something that's non-modifiable. But if others feel it should be kept, I concur that the text should be static - there's nothing to select.

Admin Site Cloning Capability works for me too on the Create page, and I like the new placement, but I wonder if that line could be more clear: "Admins can clone their sites" maybe? Same idea, but seems more direct to me.

For what it's worth, I find it unnecessary to include this language at all on the Create portal. The purpose of the portal is to provide information that allows the user to select which of the 'Create' options is best for their purpose. It's not clear to me how 'cloneability' would help with this. Moreover, when we eventually build this feature for groups, you'll have three options, all of which will have the 'Cloneable' stamp.

- Matt and I talked about the auto-population and were thinking it would be good if all of the Site Details auto-populated down through Primary Purpose, but that if the Primary Purpose is Teaching then the sub-fields (disciplinary cluster and semester) should NOT auto-populate to make sure that those get filled in correctly/actively during this process. We could consider leaving campus blank as well as Laurie suggested, but perhaps it would be too confusing (or technically tricky) to just leave that main field blank. Curious what Boone thinks about this.

IMO we should populate everything except for Title (though perhaps the source title could be the placeholder text) and the Semester (which will always be different).

Actions #15

Updated by Sonja Leix about 4 years ago

Thanks for your feedback Matt, Colin and Boone.

I like the idea of removing the Site Layout section all-together. In the attached iteration, I've combined the text from Site Layout and the updated copy from Site Content into one section. Happy to adjust the copy more to make this more fluid and cohesive.

For what it's worth, I find it unnecessary to include this language at all on the Create portal. The purpose of the portal is to provide information that allows the user to select which of the 'Create' options is best for their purpose. It's not clear to me how 'cloneability' would help with this. Moreover, when we eventually build this feature for groups, you'll have three options, all of which will have the 'Cloneable' stamp.

The reason we've added it here is to inform about this new feature. I'm ok removing it if the team is ok with it. The first time a user goes through the updated creation flow they will learn about the new options for cloning in the interface. I left it in the attached iteration for now, but happy to remove if we come to a decision.

Pre-population
Since there are some disagreement on what should be pre-populated, I'll let Colin, Matt and Boone come to a conclusion. It should be driven by what makes most sense based on user goals and user error. Additionally the Site URL field also shouldn't be populated I think. Besides that, there are no strong opinions from my side on this.

Technical notes on how the options area (content below the "New, Choose and Clone" section) should build/populate with the selections:
On Site Creation page
1. By default, the "Create a New Site" option should be selected > The options for this default view should be blank and complete
2. When the user switches to "Clone an Existing Site", the options area should become blank (empty)
3. When the user selects an existing site in the cloning dropdown, the options below populate as per mockup (reduced options for cloned site), as well as pre-populate the agreed upon fields.

On Group+Site Creation page
1. By default, the "Create a New Site" option should be selected > The options for this default view should be blank and complete
2. When the user switches to "Connect or Clone an Existing Site", the options area should become blank (empty)
3. When the user selects an existing site in the "Connect or Clone an Existing Site" dropdown, the options below populate as per current implementation, options include: license, privacy options, site layout, group + site user roles)
4. When the user checks the "Clone this Site" option, the options area should be reflective of the cloning options (see mockup), as well as pre-populate the agreed upon fields.

Boone, let me know if this makes sense and works and is cohesive enough.

Actions #16

Updated by Boone Gorges about 4 years ago

I've combined the text from Site Layout and the updated copy from Site Content into one section.

I love this change.

3. When the user selects an existing site in the "Connect or Clone an Existing Site" dropdown, the options below populate as per current implementation, options include: license, privacy options, site layout, group + site user roles)

Even for 'connect an existing site'? Can we grey them out in this case? I feel like it introduces conceptual confusion (and technical complexity) if we allow these items to be edited in this context. As an alternative, perhaps we can hide the options fields altogether - or show a read-only text summary of the options data - when 'connect an existing' is selected.

About the combined choice 'Connect or Clone an Existing Site': Currently, the 'existing site' option appears during Group+Site if you are the admin of a site that is not already linked to a group. (A limitation of our one-to-one site+group relationships.) The dropdown only shows sites that are not linked to groups. With your suggested change, the dropdown must show all sites of which a user is admin. Without further modifications to the design, it won't be possible to tell simply by looking at the dropdown which of the sites are unlinked (and thus are available for linking) and which are linked (and thus are available for cloning only). IMHO this gets thorny fast, and we might be better served by breaking 'Clone an existing site' into a third top-level radio option, so that we have separate dropdowns for 'Connect' and 'Clone', with clearly differentiated purposes.

Actions #17

Updated by Sonja Leix about 4 years ago

> Even for 'connect an existing site'? Can we grey them out in this case? I feel like it introduces conceptual confusion (and technical complexity) if we allow these items to be edited in this context. As an alternative, perhaps we can hide the options fields altogether - or show a read-only text summary of the options data - when 'connect an existing' is selected.

How are we handling this currently? We should keep the flow and edit options as is for connecting existing sites if it's working.

About the combined choice 'Connect or Clone an Existing Site': Currently, the 'existing site' option appears during Group+Site if you are the admin of a site that is not already linked to a group. (A limitation of our one-to-one site+group relationships.) The dropdown only shows sites that are not linked to groups. With your suggested change, the dropdown must show all sites of which a user is admin. Without further modifications to the design, it won't be possible to tell simply by looking at the dropdown which of the sites are unlinked (and thus are available for linking) and which are linked (and thus are available for cloning only). IMHO this gets thorny fast, and we might be better served by breaking 'Clone an existing site' into a third top-level radio option, so that we have separate dropdowns for 'Connect' and 'Clone', with clearly differentiated purposes.

Thanks for clarifying the technical / logical limitations here, that makes a lot of sense. Yes, in this case I agree, we should have three separate options. I've made that change in the updated designs. I'd like to discuss if we can simplify the copy that goes with the cloning option "Note: An admin of a Site can choose to clone it here to use as the basis for a new Site. Scroll down to adjust the clone’s License and Privacy settings and see what elements will be copied over." I think it's a lot of information you user might not even need. I would suggest to shorten it to the essentials: "Note: As an admin of a Site, you can choose this option to clone it as the basis for a new one."
When a user toggles to "Clone an Existing Site" the dropdown of sites the user is an admin of appears. The note text shifts to below the dropdown.

Let's discuss tomorrow:
- Do we want to keep the "Admins can clone their sites" on the Creation Flow landing page
- What content do we want to pre-populate for cloned sites?
- How do we feel about the copy change below the cloning option (read above)
- Do we need to change anything for connecting existing sites when it comes to edit options (see Boone's previous question)?

Actions #18

Updated by Colin McDonald about 4 years ago

Thanks for all of the movement forward on this, Boone and Sonja. I'll get right to a few preliminary thoughts on the points in Sonja's last comment, which we'll pick up on the call today:

- To my mind, the issue with noting the cloning capability on the Creation Flow landing page is that there's something conceptually different between creating and cloning -- when you think of creating you're not necessarily thinking of copying something that already exists, so it could be good to explicitly note on the creation page that cloning is a possibility. I don't think it necessarily needs to be noted redundantly in each column, especially with group cloning coming as Boone notes. Perhaps it could be noted across the three columns in some text at the very bottom, underneath the blue buttons?

- I think we're pretty close to agreement on what content to pre-populate. We all agree that URL and title should be blank (and I like Boone's idea of using the existing site title as placeholder), then everything else should be pre-populated unless the existing site's purpose is Teaching. We can discuss leaving campus blank, but I don't think that we need to. Then within Teaching, we won't pre-populate Academic Term or Year, and I think it's fine to pre-populate Disciplinary Cluster as that's unlikely to change (Matt and I last week didn't discuss that field specifically).

- Small edit on the shorter copy modification below the cloning option: "Site admins can choose this option to clone one of their sites as the basis for a new one."

- I've attached screenshots here of how the connect an existing site screens look right now. It seems like we grey out Privacy Options but License and Layout and User Roles are all configurable within the flow. I'm not sure as much about the history/intention here and whether we want to go back and change it within the context of this cloning ticket. Let's discuss on the call.

Actions #19

Updated by Boone Gorges about 4 years ago

Sonja - From this morning's call, I'm confirming the following behavior: When creating Group+Site, on the Add Site panel, if you select 'Use one of your available sites', the following happens:

1. The License field remains, with the Choose License field available, but it does nothing after linking.
2. The selected radio button under Privacy Options is changed to reflect the privacy setting of the selected site and the option is disabled so that it cannot be changed.
3. Site Layout is present, but it does nothing after linking.
4. Group + Site User Roles is present, and it does work.

IMO, 4 is OK to keep (it's only relevant to group+site). 1 and 3 are clearly bugs. Either (a) they should behave like 2 (show the setting but don't make it changeable) or (b) all three sections (License, Privacy, Layout) should simply disappear when selecting an existing site. (b) is my strong preference, both because it's best for users and because it's easiest to implement.

Actions #20

Updated by Sonja Leix about 4 years ago

Boone Gorges wrote:

Sonja - From this morning's call, I'm confirming the following behavior: When creating Group+Site, on the Add Site panel, if you select 'Use one of your available sites', the following happens:

1. The License field remains, with the Choose License field available, but it does nothing after linking.
2. The selected radio button under Privacy Options is changed to reflect the privacy setting of the selected site and the option is disabled so that it cannot be changed.
3. Site Layout is present, but it does nothing after linking.
4. Group + Site User Roles is present, and it does work.

IMO, 4 is OK to keep (it's only relevant to group+site). 1 and 3 are clearly bugs. Either (a) they should behave like 2 (show the setting but don't make it changeable) or (b) all three sections (License, Privacy, Layout) should simply disappear when selecting an existing site. (b) is my strong preference, both because it's best for users and because it's easiest to implement.

Thanks Boone, I agree. We should remove sections 1-3.

Actions #21

Updated by Sonja Leix about 4 years ago

I've updated the mockups with incorporated feedback from our meeting on Tuesday, incl. the dismissible "new feature" notification on the first screen.

I've mocked up all the steps for tomorrow's presentation, this is why there are a lot of pages in the attached PDF. I'll explain everything tomorrow.

Actions #22

Updated by Colin McDonald about 4 years ago

Transferring my notes (with some proposed solutions) from the meeting today over here:

- Just say "Site Content" at bottom of flow, more eye-catching soft warning icon and change to this text: "Only existing site content (posts, pages, media, etc.) authored by any admin-level user will be copied over to the cloned site, to avoid permissions issues."

- For Connect and Clone radio buttons at top of Group + Site flow, show these notes under the drop-down when each button is selected and hide when not --
Connect: "You can connect to any existing Site of which you're an admin, and only if the Site isn't already connected to a Group."
Clone: "You can clone any Site of which you're an admin. Use the existing Site link above to ensure you're cloning the right one."
(this Clone message also appears in the same place on the Site flow)

- Show a clickable URL of a site that’s being chosen for cloning from the sites drop-down, so the admin can reference the link to make sure they're cloning the right site.

- When an existing site is selected from the drop-down for cloning, put helper text above the Site Domain and Site Title fields that shows the domain and title of the existing site as guidance for the cloned site's details to be entered. Perhaps it says "Site Domain (cloning from X)" and Site Title (cloning from X). Maybe these could both be clickable URLs also?

- If the cloned site is a Teaching purpose, make sure that the metadata or sub-fields of Disciplinary Cluster and Term show up also. Cluster should be pre-populated and Term blank.

- Make sure that if one of these fields is left blank when the user hits the submit/clone button, an error is triggered and they're prompted to fill in the blank fields.

List of existing site content to be cloned
- All media uploaded by any admin-level user
- All pages created by any admin-level user, and left as published
- All posts created by any admin-level user, and changed to drafts
- Only the user account of the cloning admin, all others removed but bylines/attribution to prior content retained
- Theme used by the existing site, even if it can't be actively chosen from the main Commons theme repository anymore (deprecation)
- Other "layout" elements like plugins

Actions #23

Updated by Sonja Leix about 4 years ago

Thanks Colin for summarizing the feedback.

Please review attached revised Cloning mockups.

Boone, I have a question for the options "Connect and Existing Site" in the Group+Site flow. Do we need the "Group + Site User Roles" options for this? I believe so, but am not 100% sure.

Actions #24

Updated by Boone Gorges about 4 years ago

Boone, I have a question for the options "Connect and Existing Site" in the Group+Site flow. Do we need the "Group + Site User Roles" options for this? I believe so, but am not 100% sure.

For 'Connect an Existing Site', I'd say yes.

Actions #25

Updated by Sonja Leix about 4 years ago

Thanks for clarifying, Boone.

Updated mockups attached for review.

Actions #26

Updated by Colin McDonald about 4 years ago

Thanks for these updates, Sonja. Here are my notes on v8:

- page 3, the "By filling out..." line is repeated under the Create or Clone grey box, can probably be deleted?

- page 4, the "By filling out..." line in the same place is different for cloning, but seems redundant with the other lines and can probably be removed. I think the Site Details header and the blank fields suggests already that you need to fill the form out to complete the process.

- Same on above two points for the Group + Site flow.

- page 7 and 9, do we need the line "Please select a site form the dropdown above to clone from." below the gray box or is that redundant with the helper gray text in the clone drop-down itself?

- Looks good on conditional fields showing up if Teaching is the Primary Purpose of the existing site, but I think we want to leave both Academic Term fields blank, since those will almost always be different (and a user will be prompted to fill them out if left blank, right?). Cluster can be pre-populated.

- I'm not sure that the "E.g." helps under the Domain and Title fields when cloning, and the term "cloned site" seems a little unclear to me on whether that's the existing or new/duplicated site. What if it says "Domain/Title of Site being cloned: XYZ" instead? Should this text be a bit more prominent, or distinguished that it's changed with or tied to the selection of the existing site in the drop-down above?

- Also on page 4 and 8, Site Title has a drop-down arrow on the right, but I assume this is just a text entry field?

- In the Group + Site flow, this line reads a little funny to me: "You can either create a new site, connect one of your existing sites or clone a site you are an admin of, to connect to your new Group." It's a tough one, because there are a couple variables to explain here. What if we ditched that sentence and just made the header and radio-button choices a little more descriptive? So it would look like:

Select Type of Site to Connect to Group:

--- New Site

--- Existing Site

--- Clone of an Existing Site

Then we let the different notes that pop up when selecting one of the buttons do the rest of the work.

Actions #27

Updated by Boone Gorges about 4 years ago

  • Category name set to Site cloning
  • Assignee changed from Boone Gorges to Jeremy Felt
Actions #28

Updated by Sonja Leix about 4 years ago

Thanks Colin.

I've made all the changes – see attached, and I have one question:

I'm not sure that the "E.g." helps under the Domain and Title fields when cloning, and the term "cloned site" seems a little unclear to me on whether that's the existing or new/duplicated site. What if it says "Domain/Title of Site being cloned: XYZ" instead? Should this text be a bit more prominent, or distinguished that it's changed with or tied to the selection of the existing site in the drop-down above?

I think this copy is a little confusing to begin with. We have the title and URL of the original site at the top. Do we really need this text?

Actions #29

Updated by Colin McDonald about 4 years ago

Hi Sonja, this is looking good. Just a couple of things:

- On page 8, I think that the top box retained some old copy. The title says Create New, Connect or Clone Existing? instead of Select Type of Site to Connect to Group and it has the sentence underneath that title that we cut elsewhere.

- What is the screen on page 9 showing? That goes back to the Create a Site flow?

- On showing the existing site's title and URL in the form area when cloning, the feedback from our last group meeting was that it would be good to have that there, even if it's a bit redundant since we also show it above, to show to the user that they have correctly chosen the site that they want and the form has recognized their choice. Sort of a reinforcing couple pieces of information. I think if it simply says "Domain/Title of Site being cloned: XYZ" that will be fine, and maybe the link is a little more prominent than just grayed-out note text.

Actions #30

Updated by Sonja Leix about 4 years ago

Thanks Colin. Sorry for missing the meeting yesterday. Made those small tweaks.

- What is the screen on page 9 showing? That goes back to the Create a Site flow?

I've reordered the pages, so it makes more sense.

Please review and let me know if this is good to move into development. Thanks.

Actions #31

Updated by Colin McDonald about 4 years ago

Thanks Sonja, this looks good and we'll review with the group on Friday for final approval.

Actions #32

Updated by Colin McDonald about 4 years ago

Notes from the Friday group meeting:

- Cloning feature alert message on the Create page is only shown to admins, including those who become admins after the feature is released, but it won’t be shown after the 2022 academic year ends (when the feature is no longer "new") or when the alert is dismissed, whichever comes first for each admin.

- Site Content section of Cloning flow will say:

"Only existing site content (posts, pages, media, etc.) authored by any admin-level user will be copied over to the cloned site, to avoid permissions issues.
By default, the only user account on the cloned site will be the admin creating the clone (more users can be added later).
Content authored by other admins will retain that attribution, and other admins will be notified of the completed clone."

- Notifications to the "other" (i.e. non-cloning) admins of a cloned site:

Subject: User X (username) has cloned the Site: Y (title)

Body: You are receiving this message because you are an admin of the Site X (title/link) that was just cloned by another admin of the Site, the user Y (username/link), to create the new Site Z (title/link). Any content authored by you on Site X (title) was copied over with its original attribution to you. Please contact user (username/link) with any questions about the cloned site.

- Remove the Choose license button in the License section, and the "Choose a suitable license..." line. Instead, just display the license badge and title/link, then underneath that say "The existing site's license is carried over to the cloned site. This can be changed later via the Dashboard." Then in Settings > Writing where the Creative Commons section is for a cloned site, we will want a dismissable box saying "Click here for documentation on changing the license of a cloned site." Link to come.

- We need to make sure we save the "lineage" of parents and their clones to potentially surface or reference later as use cases build up.

Actions #33

Updated by Sonja Leix about 4 years ago

Thanks Colin for summarizing the feedback.

Hi Team,
please review the updated revisions (v11) and share your final feedback.

Boone,
All of these updated and new screens should be pretty straight forward for mobile, but I'm happy to mock up anything you need. Please advise.

Actions #34

Updated by Laurie Hurson about 4 years ago

This looks great!

My only suggestion is a few minimal changes to the clone content notification wording, edits below. I defer to the team on the final wording.

"Only existing site content (posts, pages, media, etc.) authored by any admin-level user will be copied over to the cloned site to avoid permissions issues. By default, the only user account on the cloned site will be the admin creating the clone (more users can be added later). Content authored by other admins will retain the original attribution, and other admins will be notified that the original site has been cloned.

Actions #35

Updated by Colin McDonald about 4 years ago

Thanks, Laurie. Maybe this is a little more clear (and we've been using existing site rather than original, though we could discuss whether one or the other is better):

"Only existing site content (posts, pages, media, etc.) authored by any admin-level user will be copied over to the cloned site to avoid permissions issues. By default, the only user account on the cloned site will be the admin creating the clone (more users can be added later). Other admins of the existing site will be notified that it has been cloned, and content authored by other admins on the existing site will still be attributed to them on the cloned site."

I'm transferring the mockups over to the group Forum for final feedback, hoping we can do final signoff during the upcoming Tuesday call.

Actions #36

Updated by Jeremy Felt about 4 years ago

I'm dropping in a draft of technical specs for development. There are a couple of questions I think will be pretty straight forward to clear. Please highlight anything else that seems off or too ambiguous. (And excuse any verbosity as I'm still learning the system a bit.)

Questions:

  • Should we plan on removing the interstitial code manually after 2 terms or set some kind of expiration in code?
  • In the "Create a Group + Site" workflow: Campus, Primary Purpose, and, if "Teaching", Academic Term and Disciplinary Cluster are all selected as part of the group details. How should we consolidate those with any conflicts from the site being cloned?

Page: Start Creating on the Commons

The existing commons.gc.cuny.edu/create/ page is accessed through “Create a Group” or “Create a Site”. This page currently provides options to “Create a Group”, “Create a Site”, or “Create a Group + Site”.

  • Add an interstitial with a description of the new “Clone a Site” feature.
    • The interstitial appears for all users who are admins of existing site.
    • The interstitial can be dismissed. This action will be recorded in user meta so that the user does not see the interstitial again.
    • The interstitial will be displayed for 2 terms. It should manually be removed from the code base at that point. (or should we put a date in code to hide it)

The “Create a Group” page is not changing. The “Create a Site” and “Create a Group + Site” pages are changing to support site cloning.

Page: Create a Site

  • Add an area at the top of the page to choose between “Create a New Site” and “Clone an Existing Site”.
    • If the user is not an admin of an existing site, this option should not be provided.
  • If "Create a New Site" (default) is selected, display the form of new site information.
    • Add an option to choose the site's license.
    • Add an option to choose the site's layout.
  • If “Clone an Existing Site” is selected, display a drop-down of existing sites of which the user is an admin.
    • Once selected, display a form to capture additional site information.
      • Site domain is left empty. The domain of the site being cloned is displayed as a placeholder.
      • Site title is left empty. The title of the site being cloned is displayed as a placeholder.
      • Campus is prepopulated with the existing options assigned to the site being cloned.
      • Primary purpose is prepopulated with the existing purpose assigned to the site being cloned.
        • If “Teaching” is selected as the primary purpose, options for Academic Term and Disciplinary Clusters are displayed. Disciplinary Clusters is populated with the existing data.
      • The existing license from the cloned site is displayed, but not immediately modifiable.
      • A choice of Privacy Options is listed.
      • A notice displays informing the admin what information will be cloned.
    • Once cloned, a congratulations page displays the results of the clone.

Page: Create a Group + Site

The initial portion of the “Create a Group + Site” workflow remains the same. Group details, settings, and photo are completed before adding a site in the final step.

  • An area at the top of the page is added for “Select Type of Site to Connect to Group”
    • This is similar to the existing page, but separates the selection from the rest of the form, clarifies the language for each option, and adds a new option for “Clone an Existing Site.”
  • If "Create a New Site" is selected, display the existing site details form.
    • Add an option to choose the site's license.
    • Add an option to choose the site's layout.
  • If "Connect an Existing Site" is selected, display a drop-down of existing sites of which the user is an admin.
    • Remove the existing "Privacy Options" selection from this screen. Privacy is unchanged on the site and set on a previous step for the group.
  • If “Clone an Existing Site” is selected, display a drop-down of existing sites of which the user is an admin.
    • Once selected, display a form to capture additional site information.
      • Site domain is left empty. The domain of the site being cloned is displayed as a placeholder.
      • Site title is left empty. The title of the site being cloned is displayed as a placeholder.
      • Campus is prepopulated with the existing options assigned to the site being cloned.
      • Primary purpose is prepopulated with the existing purpose assigned to the site being cloned.
        • If “Teaching” is selected as the primary purpose, options for Academic Term and Disciplinary Clusters are displayed. Disciplinary Clusters is populated with the existing data.
      • The existing license from the cloned site is displayed, but not immediately modifiable.
      • A choice of Privacy Options is listed.
      • A notice displays informing the admin what information will be cloned.
    • Once cloned, a congratulations page displays the results of the clone.

Cloned Data

  • All content associated with any admin user on the site being cloned is copied.
    • This includes posts, media.
    • Attribution is retained through user ID attached to the content, but admin users other than the user cloning the site will be assigned no role on the new site.
    • All admins with cloned content received an email notification.
  • All terms are copied over.
  • Most site options are copied over.
    • Exclude home, siteurl, other site specific options (TBD).
Actions #37

Updated by Boone Gorges about 4 years ago

Thanks, Jeremy! This is looking great. Responses to your questions, followed by a couple of clarifications on your spec.

Should we plan on removing the interstitial code manually after 2 terms or set some kind of expiration in code?

I'd go ahead and set the expiration in code. Let's expire it on 2021-06-01. Otherwise we will forget :)

In the "Create a Group + Site" workflow: Campus, Primary Purpose, and, if "Teaching", Academic Term and Disciplinary Cluster are all selected as part of the group details. How should we consolidate those with any conflicts from the site being cloned?

Good question. Currently, 'Group + Site' ask first for the group details, and then uses those to set the default values for the site details on the 'Site' tab. Users are able to modify these values if they wish, and we make no attempt to screen for conflicts. For cloning, I would suggest that we do the same, and inherit from the group setting. This means that, on this screen, we will not be changing the value of these fields based on what's selected from the Clone dropdown. My assumption is that, since the user has already taken the trouble to set these values in the first step of group creation, we should respect these decisions on the Site tab rather than presuming to override them (and giving them no obvious way to revert from the clone source's details to the group's details).

On the spec:

  • I believe that the two bullet points here - License and Layout - already exist, so no action should be needed here.
  • Under Group + Site, let's be sure we only show the 'Clone' option if the user has sites to clone (implied here but worth clarifying)
  • On clone, if the clone source has Administrators other than the user currently performing the clone, we will send an email notification. See https://redmine.gc.cuny.edu/issues/12134#note-32.
  • Let's be sure that we are storing some minimal amount of information about clone history, as we will want to surface it in some future version. In the past we have used BP's blogmeta tables for this; see https://github.com/cuny-academic-commons/cac/blob/1.16.x/wp-content/mu-plugins/cac-functions.php#L2033 for an example. I'd suggest doing the same. (We started doing this before WP had its own blogmeta table. We could migrate at some point, but for now let's keep everything in one place.) At a minimum, store the ID of the source site, and the timestamp of the clone event.
Actions #38

Updated by Sonja Leix about 4 years ago

Colin McDonald wrote:

Thanks, Laurie. Maybe this is a little more clear (and we've been using existing site rather than original, though we could discuss whether one or the other is better):

"Only existing site content (posts, pages, media, etc.) authored by any admin-level user will be copied over to the cloned site to avoid permissions issues. By default, the only user account on the cloned site will be the admin creating the clone (more users can be added later). Other admins of the existing site will be notified that it has been cloned, and content authored by other admins on the existing site will still be attributed to them on the cloned site."

I'm transferring the mockups over to the group Forum for final feedback, hoping we can do final signoff during the upcoming Tuesday call.

Thanks Laurie and Colin for the update suggestions.
Are we good to use the copy, Colin, you've tweaked (quoted above)? Any other revisions or can I present a final mockup with these changes for final sign off?

Actions #39

Updated by Colin McDonald about 4 years ago

Jeremy, thanks so much for the thorough specs. I think one thing to add is the dismissable message we want to appear for any cloned Site on the Settings > Writing screen in the Wordpress admin, where the Creative Commons section is, saying "Click here for documentation on changing the license of a cloned site." Link to come.

Sonja, yes let's use the tweaked copy and proceed to the final mockup. Thanks!

Actions #40

Updated by Sonja Leix about 4 years ago

Thanks Colin.

Hi Jeremy,
please find the final approved designs for implementation here:
https://xd.adobe.com/view/6e7dc813-5596-4a73-6da8-7d3cf903d837-184c/

If you have design questions, please either post them here or you can also use the commenting feature of XD. To see all the specs, please switch to "view specs" in the skinny right sidebar (code icon below the comment icon). There you'll see general specs. Once you click on an element you'll see element specific specs. Let me know if you have any questions.
You can attached find the SVG of the caution icon used in the new designs.

Actions #41

Updated by Jeremy Felt almost 4 years ago

I have the first (second?) draft of this feature up on the `feature/site-cloning` branch and have opened a pull request with some notes embedded throughout the changes. https://github.com/cuny-academic-commons/cac/pull/2

There are a couple refinements that I've identified, but overall I think it's ready for Boone to put eyes on when he has some time.

Actions #42

Updated by Boone Gorges almost 4 years ago

  • Related to Bug #12771: Blog name uniqueness check doesn't work during blog creation added
Actions #43

Updated by Boone Gorges almost 4 years ago

Hi all -

A note to say that Ray and I have finished an initial review of Jeremy's work, and it looks good and tests well. Well done, Jeremy! I know it's not easy to be thrown into so much complex legacy code.

The feature is available on cdev for testing. I think the next step will be a design review from Sonja, to ensure that we haven't missed anything glaring in the comps. Sonja, could you have a look?

Actions #44

Updated by Matt Gold almost 4 years ago

Great to hear this. Thank you, Jeremy!

Actions #45

Updated by Sonja Leix almost 4 years ago

Thanks Jeremy and Boone. I took a look and tested the various ways we're introducing cloning within the Site and Group+Site creation flows. I've also reviewed the dismisable feature intro box on the creation landing page. Everything is looking great and as expected.

Only thing I've noticed is that the buttons on the confirmation page overlap over two lines in the group+site creation flow. Let's make sure that we're testing both on desktop and mobile to catch all those minor tweaks.

Question somewhat related, but not directly: A non-related question... is it normal that I can't access any of my sites on cdev? When I click on the link from various places like the site directory, the my site directory or the link within the new cloning interfaces, I simply land on the commons homepage.

Actions #46

Updated by Boone Gorges almost 4 years ago

Question somewhat related, but not directly: A non-related question... is it normal that I can't access any of my sites on cdev? When I click on the link from various places like the site directory, the my site directory or the link within the new cloning interfaces, I simply land on the commons homepage.

Yes, it's expected. Add the new subdomain to the cdev line in your /etc/hosts file:

146.96.128.252   commons.gc.cuny.edu sonjatest1.commons.gc.cuny.edu sonjatest2.commons.gc.cuny.edu
Actions #47

Updated by Sonja Leix almost 4 years ago

Boone Gorges wrote:

Question somewhat related, but not directly: A non-related question... is it normal that I can't access any of my sites on cdev? When I click on the link from various places like the site directory, the my site directory or the link within the new cloning interfaces, I simply land on the commons homepage.

Yes, it's expected. Add the new subdomain to the cdev line in your /etc/hosts file:

[...]

Thanks for clarifying, that makes a lot of sense.

Actions #48

Updated by Boone Gorges almost 4 years ago

Jeremy - Following up on Tuesday's discussion with some clarification about 'commonsadmin'.

New sites are created with a 'layout' or 'template', which means that their default config and content is cloned from our template sites (currently teaching-template, default-template, academic-portfolio-template). These sites have a bunch of default content that is attributed to the 'commonsadmin' user, and we should be including this content when cloning via your feature.

Locally, you probably already have this setup - check teaching-template.commons.gc.cuny.edu and see if content is attributed to 'commonsadmin'. If not, create a user with that user_login, then set the user as the author of all pages and posts across those three template sites. I've just done this on the shared CDEV testing environment, for reference.

Then, I think the only change necessary in your cloning routine will be to get_user_by( 'login', 'commonsadmin' ), and then add that user to the whitelist of users whose content is preserved after clone.

Actions #49

Updated by Colin McDonald almost 4 years ago

Hello, below is a series of feedback from Scott on cloning from the forum. We didn't have anything else on cloning shared there, other than some questions I had in earlier discussions mostly about the commonsadmin.

- First I cloned the “Help Wanted” site. Everything worked perfectly except that it uses the Contact-7 plugin, and the two forms were not copied over.

- Then I cloned the “Visions of Greatness at BCC” site, which has hundreds of images and pages – initially I thought I saw issues with the theme’s settings (Bridge is a complicated theme), but when I went to the original site, I saw that it too was somewhat broken in CDEV. So the cloned site and the original seemed pretty consistent.

- Then I cloned the GCDI site and the screen froze (probably an environmental issue). I went back and saw that indeed the site was cloned. The site uses the old Simplicity theme (which is not in prod anymore) and it has a custom post type called “mini features” that appear on the landing page. I noticed that only the mini features that I created were copied over (perhaps the others were written by non-admins), and that the links in them were to pages on the original site. The menu did not get copied over correctly (just one item in menu rather than five). The slider was correctly copied, but the links in the slider items pointed to the original site. Also the original site had two contact forms, and they were not copied.

Actions #50

Updated by Jeremy Felt over 3 years ago

Hey everyone,

I pushed a handful of changes up to a `fix/site-cloning-feedback` branch: https://github.com/cuny-academic-commons/cac/tree/fix/site-cloning-feedback

  • Content owned by the commonsadmin account is now preserved after clone.
  • All prefixed tables are now copied from the source site.
  • Fixed a possible PHP notice in a case where no content is owned by a user other than the cloning admin.
  • Added an `IF EXISTS` to the `DROP TABLE` where to avoid unnecessary MySQL complaints.
  • Adjusted a handful of items for mobile layouts through the site cloning flow.
Actions #51

Updated by Boone Gorges over 3 years ago

  • Status changed from In Progress to Resolved

Let's close this ticket out. If any bugs remain, we'll address in a new ticket.

Thanks to all and especially to Jeremy for work on this feature!

Actions #52

Updated by Matt Gold over 3 years ago

Huge thanks, Jeremy, with kudos for your first big project on the Commons!!!

Actions #53

Updated by Raymond Hoh almost 2 years ago

  • Related to Support #16291: Images coming up blank in Media Library added
Actions

Also available in: Atom PDF