The Commons is a rich and flexible platform for hosting sites of all types. From conference websites to research blogs, from departmental resource hubs to sites in support of graduate seminars, the Commons provides a variety of tools that help you make your site look and work just the way you want.

For most uses, the plugins and themes provided by the Commons will be enough to create something robust. However, there may be instances where your use case requires tools or customizations that aren’t available on a default Commons site. This guide describes the services we offer to our “hosting partners” – Commons members who host custom WordPress sites as part of the Commons network. It outlines the non-standard customizations available on Commons sites, and describes some procedures and guidelines regarding how the Commons supports these customizations.

1. Domain mapping
   Sites created on the Commons have URLs of the form https://your-custom-subdomain.commons.gc.cuny.edu/. We support a service called “domain mapping”, which will allows you to map any domain that you own to a Commons site. So, your URLs will look like http://yourdomain.com/about-me/ instead of https://your-custom-subdomain.commons.gc.cuny.edu/about-me/. See the Codex article on domain mapping for more details on requesting a domain to be mapped to a site.A few examples of custom domains that are mapped to Commons sites:
   • http://preludenyc.org/
   • http://asianamericanyc.hunter.cuny.edu
   • http://murphyinstituteblog.org
   • http://keithmiyake.info/
   • http://globalization.gc.cuny.edu/
2. Plugin and theme requests
   The CUNY Academic Commons is built on WordPress. You may request the installation of specific WordPress plugins and themes by sending an email to commons@gc.cuny.edu or opening a request directly on our official bug tracker, providing the details in this form. Guidelines for plugin requests:
   1. Using existing tools – We strive to avoid installing plugins that duplicate existing functionality. Please carefully review the list of plugins already available on the Commons (Dashboard > Plugins) before requesting a new one, as it’s likely that your use case is covered by a plugin already installed on the system.
   2. Proprietary/”premium” plugins and themes
      1. We have a strong preference for plugins that are no-cost and provided under a GPL license. These tools align with the free software ethos of the Commons. They also make maintenance easier, since freely licensed tools generally participate in well-understood and accessible development workflows: updates are made available through wordpress.org, authors accept enhancement requests via GitHub or other public platforms, etc.
      2. That being said, we understand that commercial tools are sometimes the best option. These tools will be considered only when the requesting user has demonstrated that no viable free option is available.
      3. If a non-free plugin is used, we have a strong preference for products whose licenses allow us to offer the product to all sites on the Commons. This is often called an “unlimited” or “developer” license.
      4. Users requesting commercial tools are generally responsible for purchasing and maintaining the software license.
      5. In cases where the user has purchased the license, please note that the Commons development team is generally not aware of available updates, and does not generally have access to download them. As such, users or organizations that purchase commercial plugins or themes for use on the Commons must demonstrate a committment to checking for available updates and delivering them to the Commons team no less than every three months. Commercial plugin and theme shops often offer email notifications for available updates; we highly recommend subscribing to these notifications, and immediately passing updates along to the Commons team.
   3. Ask first – If you are unsure about a plugin or theme, please ask right away. We want to be sure that you don’t design your site to be entirely dependent on a plugin or theme that we can’t support.
3. Custom themes and plugins
   Have you developed a custom WordPress theme or plugin that you would like to use on your Commons blog? In most cases, we’re happy to host your code. A few special requirements to keep in mind when building for use on the Commons:
   • We are a WordPress Multisite installation where BuddyPress is network activated. Make sure that your plugin plays nice with Multisite. If your customization integrates into BuddyPress in some way, please contact our team first to be sure that your work will be compatible with our setup.
   • Please specify in your request whether your plugin/theme should be offered for all sites on the Commons network, or whether you’d prefer for their use to be limited to your site(s).
   • We love child themes, but before building a child theme for use on the Commons, please contact our dev team about your plans. In cases where the parent theme already runs on the Commons, it’s critical that your development take place against the same version. In cases where the parent theme would need to be added to the site, we want to be sure that we will be able to support the requested parent theme.
   • Themes should adhere to wordpress.org’s theme guidelines. Use the Theme Check plugin while developing locally to verify your compliance in advance.
   • All custom themes and plugins will undergo a detailed code review before being added to the Commons.
4. Support
   The Commons team is pleased to provide these hosting services to its members. However, please note that our team is small, and our primary responsibility is the development and maintenance of the Commons as a space for collaboration between members of the CUNY community. As such, we ask that hosting partners agree to the following caveats regarding support:
   • Hosting partners should contact the Commons team by email at support@cunycommons.zendesk.com to request the creation of an account on our Redmine installation http://redmine.gc.cuny.edu/projects/cunyac/, and should use that ticketing system for all support requests.
   • We make all reasonable efforts to respond to tickets in a timely manner, but please allow 24-48 hours for a response from a member of our team.
   • Content migrations – such as the import of WordPress posts and media – are generally the responsibility of the hosting partner. Please stage your content in such a way that it can be migrated with the WordPress export and import tools. If you have content that cannot be exported/imported in this manner, please contact our team to discuss possible migration strategies.

This entry is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license.