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.

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.

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

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!

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.

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.

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.

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)

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."

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).

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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).

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.

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?

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!

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.

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?

Great to hear this. Thank you, Jeremy!

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

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.

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.

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.

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.

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