Web Development Overview

Summary

This webpage is intended to be an introductory, high-level guide for and vendors providing website development services to RIT. Vendors should work directly with RIT development representatives to determine the specific requirements of each product or project.

Printable version of the web development overview 


Sponsored Accounts & Access (Vendor/External Only)

A request for a vendor account is made to the ITS Service Desk. The request must include a description of how the account relates to the business of RIT, RIT faculty/staff sponsor, and an expiration date of one year or less.

You must follow RIT's Code of Conduct for Computer and Network Use. RIT Computer Accounts and the files stored in those accounts are the property of RIT. ITS and other departments with which accounts are associated have the right to review and delete accounts and their contents. Your account is valid if you are currently registered as an RIT student or currently employed as an RIT faculty or staff member.

Project Account Sponsor will request from vendor:

  • First/Last Name and middle initial of account holder
  • Job Title
  • Contact information

“Other Access Needed” includes:

  • Individual web account: Example: w-comp
  • Gitlab for the web account

Once the sponsored account is created, your project contact will reach out to you with the username and temporary password of your new RIT Computer Account. You will need to immediately visit start.rit.edu and change your password.

RIT Web Hosting Environment

Supported Technology

Please review our list of technical features available on the RIT Web Environment. 

Staging Site

Your development will likely take place in RIT’s staging environment. If you are working on an existing website/web account, ITS will copy down a current version of the production site to staging at your request. If it is a brand-new website or service, ITS will create the necessary area needed for the project.

You will need to work with your business client to determine if the Production website or service should be locked down during the course of development. Changes to code and content in Production will not be reflected in the staging website unless manually made. ITS will often work with a client to disable Production access, preventing changes and new content being created on their live sites during active development unless there is an important business reason to make changes to the Production site. You are responsible for reconciling any content or functionality difference between the two environments prior to release and during the support/stabilization period afterwards.

You can access the staging environment at : www staging.rit.edu/[sitename]

CLAWS Web Hosting Tool

While developing in Staging, one other important application you will be using is the CLAWS Web Hosting Tool (WHT). The WHT is where you interact with your site specific web account and can access important tools to assist you in your development. You are able to see PHP logs, reset website permissions, and get to your website(s) database via phpMyAdmin.

Once you have finished development in Staging, you also use the WHT to push files to Production using the Staging Changes tab. Deployment of new Drupal websites need to be coordinated with ITS as to ensure the website will function properly in Production. In the Staging Changes tab you are able to push files to Production or undo them if necessary.

You can access the CLAWS Web Hosting Tool at: https://claws.rit.edu/webhosting/

Additional Relevant Policies

ITS has created development policies on special topics. These are:

Drupal Development

ITS officially supports and recommends the use of the CMS Drupal for website development. ITS offers a multisite installation of Drupal so that users don’t have to worry about core or module updates for their website. ITS asks developers to please consider the following when developing in Drupal.

Required Procedures

  • Must utilize RIT’s custom Single Sign On module (rit_user_utils)
    • Options are provided via the module configuration page to allow non-RIT users access to the site if needed 
  • Refrain from disabling or uninstalling modules without consulting ITS
  • Utilize RIT’s custom Drupal theme
  • Must conform to RIT web, accessibility, security, and branding standards
  • Follow Web Content Accessibility Guidelines (WCAG) for Level AA compliance

Recommended Procedures

  • Website built in Bootstrap framework or in a mobile-first theme
    • If support of the site will be transitioned to ITS, we would prefer the site to be built in Bootstrap
  • For eCommerce applications, usage of Drupal Commerce with our custom Nelnet payment gateway module
  • Ensure that the standard Drupal regions are present in your theme
    • Custom regions are allowed to be defined, removing standard regions may cause issues with elements rendering (such as the administration menu)
  • If new modules are needed for your development, please contact ITS to have them reviewed

Discouraged Procedures

  • Usage of LDAP for authentication
  • Usage of Context to place blocks on pages
  • Attaching Webforms to all nodes
  • Development using gulp.js
  • Development using node.js/node modules

If you have any questions regarding RIT’s development procedures, please contact ITS.

Non-Drupal Development

While ITS encourages the use of Drupal, we understand that it is not appropriate for every project. When creating a non-drupal website, we still request that developers consider the following procedures.

Required Procedures

  • Must utilize RIT’s custom Single Sign On (SSO) solution (Shibboleth) for all RIT authentication
  • Must conform to RIT web, accessibility, security, and branding standards
  • Follow Web Content Accessibility Guidelines (WCAG) for Level AA compliance

Recommended Procedures

  • Website built using a Bootstrap framework or in a mobile-first theme
    • RIT offers an HTML exported template that can be leveraged for theming

Discouraged Procedures

If you have any questions regarding RIT’s development procedures, please contact ITS.

Production Checklist

While developing your website please refer to this checklist for guidelines and procedures. These should all be considered before your website is finished.

General

  • Along with submitting the Request to push to Production to ITS, request that ITS backup the current website on Production if one exists.
    • If there is an eCommerce component to your website, request that the NelNet piece of the project be enabled and configured for Production.
  • Create any redirects needed to map pages from the old site to pages on the new website.
    • At minimum, the main-level navigation links should be redirected to their new locations.

Testing for all Websites or Services

Before moving to PRODUCTION

  • Request students/other devs go through the site and report any bugs.
  • Make sure browser console is open and watch for any console errors.
  • Testing should be done in Incognito/Whatever disables cache and isn’t logged in.
  • Testing on Mac – Chrome, Firefox, Safari.
  • Testing on Windows - IE10/Edge, Chrome, Firefox, Safari.
  • Testing on Tablet, Mobile Device (both orientations).
  • Test all types of form submissions.
  • Test for for valid html: https://validator.w3.org/
  • Test speed results on Google Pagespeed Insights.
  • Test to make sure 404 and 403 works.
  • Set a calendar reminder for one week to check for the most frequent 404s and setup redirects.

Post-release to PRODUCTION

  • Enable Analytics.
  • Confirm that redirects are working as expected
  • Ensure that any references to Staging (links, assets, etc.) are pointing to Production.

Drupal Specific Testing

Before move to PRODUCTION

  • Check php and drupal error logs for anything that should be fixed.
  • Test at least one of each content type
  • Ensure that anonymous users have necessary permissions. Exclude content types that should not show up in search results.
  • Disable any Views/Blocks/Content Types that are obsolete or unused on the site.
  • Clear all test submissions from webforms and ensure forms are
  • Ensure any feed importers have run and imported latest content.
  • Comb through modules to make sure none are enabled that don’t need to be.
  • If there are subfolders created in the www folder, make sure they won’t conflict with any Drupal pages, and don’t create www/admin.

Post-release to PRODUCTION

  • Enable Caching and Aggregation - admin/config/development/performance.
  • Enable Analytics.
  • Turn on External Links Modules and set to ‘Open external links in a new window.’ with correct pattern matching to exclude internal links. For example, the pattern for www.rit.edu/diversity would be ‘.*rit\.edu\/diversity*.’ - admin/config/user-interface/extlink.
  • Run cron to ensure all content is indexed by search module. - admin/reports/status/run-cron.
  • Ensure any links that were necessary to hardcode in the staging site’s content or menu system have been updated to the production links. Searching in phpMyAdmin works well for this.

If you have any questions or concerns concerning the document, please contact your RIT development representative.