• Acquia has been selected to be ASU’s new website Hosting platform.   
• Acquia is spelled A C Q U I A and they specialize in Drupal CMS hosting.  
• They don’t host Wordpress sites, only Drupal sites. 
• If you have an ASU site built using Wordpress, you will need to find your own hosting platform before our Pantheon contract runs out in May of 2025 and run it through the appropriate ASU approval process for data governance, etc.
• Acquia in cooperation with ASU will begin to migrate sites from our former hosting provider Pantheon, to our new hosting provider Acquia late March of 2025 and we hope to be completely migrated over no later than August of 2025.
• There are benefits to hosting sites with Acquia, but the biggest will be shared code-base.  The database will still be separate for ASU sites, (images, content, users) but the configuration and version of Drupal (including Webspark) will be shared!  This will save ASU Site Administrators a lot of time and energy so you can build and create world class content, instead of figuring out why an update hook is giving you a hard time!
• If you would like to learn more about how to log into the Acquia Dashboard, and more specifics about how sites are deployed in Acquia we will have subsequent videos to show that.
• For now, please ensure your sites are updated, your contact information is accurate in the Inventory Sheet,  and understand that we will be announcing site-freezes as the migration schedule is released as sites will be migrated in batches.
• More videos forthcoming as well as if you want to dive into the official Acquia documentation it is available via their site or Acquia Academy.  However, your experience interacting with Acquia will likely not require you to know all the inner workings of the platform, so you can also wait until we release more ASU-centric presentations and videos.

• Sites in the Webspark Stacks and the ASU Drupal Stack will move from the former model that involved site owners applying upstream updates themselves, to a managed update model that relieves the site owner of that often complicated task. ET Web developers will now perform site updates with the goal that they be as seamless to site users and site owners as possible.
• Site owners may be asked to test and verify cloned copies of their sites that have been updated in a test environment prior to releases going to Production. This will help guard against bugs and regressions.
• ET Web will maintain a release calendar w/ release dates and target Drupal versions. This will enable our community of collaborators to ensure their code is up to date and compatible with the upcoming releases.
• ET Web will now perform two types of releases:
  • Upgrade releases (aka minor releases) - n.N.n : Scheduled quarterly 
    These will represent Drupal core upgrade releases. Target Drupal version announced in advance. WS2 major feature releases. Approximately 4 per year.
  • Patch releases (aka Security/Bugfix/Hotfix) - n.n.N : As needed, at least monthly, to address accessibility, bug, upgrade issues as well as deploy minor feature updates.
• We will continue to publish release notes at Announcements | Enterprise Technology Web Services
• We will require Trusted Partner developers to be provided by those units with sites responsible for custom code incorporated into the Webspark and ASU Drupal Stack platforms. If your site requires custom code, you’ll need a Trusted Partner. Trusted Partners have a responsibility to ensure their code is compatible with the upcoming release for the Stack their code is in.

Because Site builders in Stacks sites don’t maintain platform code and won’t need to deploy updates, access to Dev and Test environments isn’t necessary.

• For sites that want to maintain content approval workflows, the Content Moderation and Workflows modules can be enabled and configured to meet business needs.
• New features that need to be tested and approved first, such as views, can be constructed in a site without being publicly visible until they are ready by using publish and access settings in the platform.
• When sites require a more extensive build out that may be disruptive to a site, we can allow temporary access to a Test environment copy of a site, but these are temporary, and may be overwritten as needed to run the platform. Additionally, site owners can use a tool such as DDEV and their site backup to run a local copy of a site. When new features are developed, configurations may be exported through the site’s admin interface and imported into the the production site. Additional access may need to be requested to enable access to settings import/export.
• Lastly, a more involved, but powerful option is to create a “collection” of sites in your Acquia Site Factory group. With a collection you can designate a single site as the primary site, duplicate the site in the collection and develop variations that, when ready can be swapped into place as the primary site. Details on how collections work can be found in Acquia’s documentation.

Related links:

• Acquia’s official documentation
• Content Moderation (Drupal module)  
• Workflows (Drupal module) 
• Unpublishing Content in Drupal (how-to)  
• DDEV 
• Acquia Collections 

Using Acquia Site Factory multi-tenant hosting, ASU's web platforms moves from a decentralized web hosting model that puts the burden of site maintenance on the site owner, to a managed Drupal offering that relieves site owners of the technical maintenance of the underlying software so they can focus on building the web experiences that drive student and faculty success at scale at ASU.

Acquia Site Factory sites, will be chunked into "stacks" sharing identical codebases:

• Webspark Stack
• Webspark Stack Drupal 9 (temporary)
• ASU Drupal Stack
• The College Stack

Download the slide deck.

If your business needs cannot reasonably be met with existing Stack site functionality,

• The first step is to confer with ET Web Platforms to determine if there are existing functionality or modules that could meet your requirements.
• If you still require a custom developed solution and your business unit is capable of the technical demands of the task and sustained resourcing for you to maintain that solution through the full software development lifecycle, including regular updates to remain compatible with Webspark/Drupal version upgrades, then consider requesting to become a Trusted Partner.
• Additional considerations:
  • The extent of the customizations you require. Full-blown web applications with extensive custom code may not be a good fit for the Site Factory Stacks platform and other options may need to be explored, such as ASU Enterprise hosting at significant additional cost.

For more information on how to be a Trusted Partner, please view the link. on this page titled "What is an ASU Web Trusted Partner?"

After migration to Acquia, SF sites with custom themes and subthemes will find their themes included in the platform codebase. The ET Web team will be working with those sites to identify next steps for long term theme management. We are currently exploring options, but will likely pursue moving themes to their own external repositories that will allow responsible teams to autonomously manage their themes and pull them into their SF sites.

What is an ASU Web Trusted Partner?

• A Trusted Partner is a developer associated with a site in the ASU Stack hosting (Webspark, ASU Drupal Stacks) who is granted access to ET Web Platforms' Code Studio development pipeline in order to maintain custom code associated with their site.

Do I need to be a Trusted Partner?

• The Webspark Stack provides an accessible, brand compliant, feature rich implementation of the ASU Unity Design System as part of the Drupal content management system (CMS). The ASU Drupal Stack provides the Drupal CMS without Unity.
• If your business needs cannot reasonably be met with existing Stack site functionality,
  • The first step is to confer with ET Web Platforms to determine if there are existing functionality or modules that could meet your requirements.
  • If you still require a custom developed solution and your business unit is capable of the technical demands of the task and sustained resourcing for you to maintain that solution through the full software development lifecycle, including regular updates to remain compatible with Webspark/Drupal version upgrades, then consider requesting to become a Trusted Partner.
  • Additional considerations:
    • The extent of the customizations you require. Full-blown web applications with extensive custom code may not be a good fit for the Stacks platform and other options may need to be explored, such as ASU Enterprise hosting at significant additional cost.
  • There is not currently a cost associated with being a Trusted Partner.

How do I become one?

Trusted Partners should submit a JSM ticket and attest to their capabilities to comply with the Trusted Partner Responsibilities and be capable of working with the technologies and business processes noted below. Seats in Acquia Code Studio are limited, and this affects the number of Trusted Partners we can have. Some prioritization may be implemented by Enterprise Technology.

Trusted Partners are expected to be capable of

• Developing and maintaining code
  • Aware of Drupal coding practices and APIs
  • Understand how to write secure code
  • Be capable of ensuring the UI’s provided by their code is Accessible, per WCAG 2.1
• Able to work with Git
  • Working with a repository: Checking out code. Committing updates. Working with branches. Resolving merge conflicts.
  • Able to learn to use our pull request/merge request-based workflow
• Working with the ET Web Development Pipeline
  • Accomplished using the above technologies within the Acquia Code Studio platform.

NOTE: The JSM Form to become a Trusted Partner is not yet available but we will post it here when it goes live.

What does a Site Factory Group represent at ASU?

A group in the Site Factory Management Console is an entity that serves as a container for a group of sites. One or more users can be granted membership to a group in order to gain privileges to create, update and remove the sites in the group and to manage other members.

In the creation of Groups, we will attempt to reflect the business unit responsible for the sites contained, but not be constrained by the official ASU org structure. We will avoid using sub-groups to represent hierarchical org structures, and will strive to align groups with the major business units and the web staff for those units.

As example of flexibility, if we have a group that represents a collaboration between two units, we may opt to create a group for that collaborative group.

Site Factory Management Console Group Member Types

https://docs.acquia.com/site-factory/docs/manage/website/users 

To add a new user to a group in Acquia, navigate to the group's detail page in the Site Factory Management Console, click "Manage" in the "Members" section, enter the username of the user you want to add, and click "Add User" to assign them to the group.  You can also manage user access to groups by editing their roles and permissions within the group details page.

Related Links:

• Managing users and groups (documentation)

   

To gain access to the ASU Acquia workspace, please fill out the form linked below.  Please note, it is a requirement that you are an active Faculty or Staff affiliated with Arizona State University.  If you are a student or a vendor needing access, please also supply additional information in the fields provided within the form.

NOTE: The JSM Form to get an account is not yet available but we will post it here when it goes live.

To spin up a new site using Site Factory in Acquia:

• First log in to the Site Factory Management Console.

   

• Select the Group you would like your site to exist in.
• Then in the upper right, click "Create a new site".
• Input the site URL, and select the appropriate Stack and installation profile if needed.
• And finally click "Create site" to generate your new website

NOTE: You will need Site Builder permissions and membership in at least one group to perform this action.

Site Factory Management Console User Roles

SFMC roles are granted on an application-wide basis.

• Site Collections can be used to group multiple variations on a site and designate one as the primary site.
• When using Collections, one should pay careful attention to any content modifications, since each site will have it’s own independent database, and each will need to be updated independently so that both versions of the site remain current.

Related Links:

• Collections (documentation)

We have published a page showing our Acquia 2025 pricing model and will continue to update its content with details as they become available.

In consolidating our sites into stacked codebases that can be managed by Enterprise Technology, it was necessary provide a curated Modules and Themes administration experience that doesn’t expose customizations that exist for only one site to all other tenants within the stack. In our migration to Acquia we’ve instituted a governance system that

1. Adds the new roles “Site builder” and “Content editor”.
2. Copies the user associated with user 1 to a new account and grants it the “Site builder” role and updates ownership of content owned by this user so it retains ownership. User 1 is then disabled.
3. All other “Administrator” users are updated so they will become “Site builder” users.
4. In general, the Site builder user should have the same access as Administrator with the following exceptions:
   1. The core modules and themes pages are now replaced with “ASU Modules” and “ASU Themes” pages that provides curated access to modules and themes.
   2. Permissions the Site Builder can manage will be limited. Site builders will get all permissions for the modules they enable. And Site builders can grant roles to other users but they cannot create new ones. As we move forward we’ll be working with our users to determine what works best to balance the safeguards we require with the need for flexibility. 

See "What is ASU Governance in Acquia Site Factory?" FAQ answer for more information.

After migrations have completed, we will be evaluating the 300+ modules site owners have added to their sites to determine functional gaps we need to standardize on a shared, sustainable solution for, and then working with all site owners to provide paths to make that transition as an organization.

Modules will be evaluated for long-term inclusion in the platform based on the following criteria

• General
  • Solution is accessible or can be made accessible with reasonable usage.
  • Solution is secure.
  • Solution (if module) shows evidence of widespread adoption and is under active development OR if abandoned, ET Web development team would be capable of forking or assuming ownership.
  • Dependencies required by the solution are minimal AND are evaluated favorably themselves.
  • Solution is in alignment with Drupal trends and/or platform trends.
  • Solution does not force a strongly opinionated architectural implementation that may block or complicate future development and/or updates.
• Webspark Stack
  • General criteria, plus…
  • Appropriateness for ASU Brand Standards

  • Solution avoids introducing functionality that runs counter to the Webspark 2 / Unity Design 

    System architectural vision.

  • Solves for the greater good of the ASU web community.

All criteria could be met, yet without the agreement of ET Web Platforms team and leadership, requests may still be rejected.