Configure the Swift Mailer module by using the “t” mode¶

To use the sendmail transport, you must configure the Swift Mailer module by using the t mode. For more information, see Swift Mailer settings for Cloud Platform.

Use shared paths when using the flock command¶

When using the flock command to prevent commands from executing concurrently, ensure that the lock file is written to a location that is writable and not ephemeral. In Cloud Classic, paths such as /tmp could be used for flock since all the jobs would execute on the same servers. However, that directory is not shared across multiple containers on Cloud Next. Therefore, Acquia recommends that you use the Drupal private files directory located at /mnt/gfs/${AH_SITE_NAME}/files-private.

An example usage of flock on Cloud Next that is also compatible with Cloud Classic:

flock -x -n /mnt/gfs/${AH_SITE_NAME}/files-private/flock.example -c "echo 'hello world'"

Reduce the frequency of cron jobs¶

Cloud Next does not support scheduled cron jobs running every one minute. If you have any scheduled jobs that run at a frequency of 1 minute, you must reduce their frequency so that they do not run more than once every 5 minutes.

1. Sign in to the Cloud Platform user interface.
2. Select an application and an environment.
3. Click Scheduled Jobs.
4. Locate all jobs with frequency: * * * * * or Every Minute.
5. Update the frequency for such jobs to: */5 * * * *.
6. Test your application to verify that it works as expected.

If you do not make this change by the time your environments are upgraded, any cron jobs running too frequently are automatically set to a lesser frequency. This might impact the normal operations of your sites if not tested beforehand.

If your application requires higher-frequency cron jobs, you can use a wrapper script to perform the necessary tasks in a loop. For example, you can use the following:

#!/bin/bash

# The end timestamp is now + 300 seconds (5 minutes).
 end=$(( $(date +%s) + 300 ))

 while : ; do
 start=$(date +%s)

 # This is where you run the drush command, wget,
 # curl, etc. that you would like to execute once a
 # minute.
 drush queue-run example_queue

 # Ensure it does not run more frequently than once
 # per minute by sleeping if the command takes less
 # than a minute to execute.
 sleep $(( 60 - $(date +%s) + $start ))

 # Exit the loop if the current timestamp exceeds the
 # end timestamp.
 [ $(date +%s) -lt $end ] || break
 done

Disable the Memcached binary protocol¶

The Memcached binary protocol is not supported in Cloud Next environments. It is a deprecated feature of Memcached since Memcached 1.6.0, but is still supported in Cloud Classic.

Cloud Next leverages mcrouter, which only supports the ASCII protocol for Memcached. If you enable binary protocol in Cloud Next environments, Drupal and PHP cannot communicate with Memcached. The application fails to set or get cache items, but does not return an error message.

In your settings.php file or any file included in the settings.php file that contains Drupal Memcache module configurations, remove or comment out any lines similar to the following that set the OPT_BINARY_PROTOCOL parameter to true:

$settings['memcache']['options'][Memcached::OPT_BINARY_PROTOCOL] = TRUE;

Use the Drupal Memcache module later than 8.x-2.0¶

Include files used in Cloud Next reference the MemcacheTimestampInvalidator class, which is not provided by the Memcache module prior to 8.x-2.0-beta1. Therefore, using older versions of the Memcache module triggers a fatal PHP error when bootstrapping Drupal.

You must update applications to the latest stable release of the Memcache module.

Update SimpleSAMLphp code¶

Customers with SimpleSAMLphp in an application must make a few changes before upgrading to Cloud Next to ensure ongoing compatibility with both Cloud Classic and Cloud Next. For more information, see Updating SimpleSAMLphp configuration for Cloud Next.

Limit code repository size to 2 GB¶

To ensure reliable deployments in Cloud Next, application codebases must not exceed 2 GB. Application codebases that exceed 2 GB experience timeouts or failure during deployments.

You must review your repo for any files that can be stored in a public files directory. For example, large image assets, audio/video files, and PDFs.

Additionally, you must verify that public files directories, such as sites/default/files, are not committed to the repository. Once deployed to Cloud Platform, the distributed file system is mounted in that location. This hides anything that you commit to the repository.

Disable live development¶

The live development feature is deprecated and is unavailable for environments running on the Cloud Next infrastructure or Site Factory. Acquia recommends that you use Cloud IDE instead. For more information, see disabling live development.

Limit the size of PHP directives¶

During your upgrade to Cloud Next, these values are adjusted as needed so that they are within the limits.

Limit the PHP Max File Upload concurrency to 20¶

In Cloud Next, the max_file_uploads PHP directive is limited to the default value of 20. During your upgrade, your application is adjusted to match this limit.

Avoid sharing database tables¶

In Cloud Next, you cannot configure your multisite installation to share database tables, such as users, sessions, and profiles tables, across multiple websites. Therefore, you must adjust your application to not use shared tables.

Remove dependency on custom PHP extensions¶

Custom PHP extensions, including the ones that are compiled and included in your codebase, are not supported in Cloud Next. You must change your application to remove dependency on custom extensions, or contact your Acquia account team for assistance.

Avoid using MyISAM database tables¶

The MyISAM table engine is unavailable in Cloud Next. Although InnoDB is the default database for Drupal since the release of Drupal 7.0, Cloud Platform supports MyISAM tables prior to Cloud Next.

To determine if your current database tables use the MyISAM engine, use:

SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'MyISAM';

Apply Cloud Platform’s limitations for custom environment variables¶

Cloud Platform has the following limitations for custom variables:

• Maximum 5000 bytes for each variable value
• Maximum 255 bytes for each variable name
• 100 kilobytes in total (all variables with their names and values)
• Variable name and value must not contain tabs, spaces, or quotation marks.

For more information, see Creating custom environment variables.

Applications on the “Welcome” tag are not upgraded¶

For existing Cloud Classic applications that must be upgraded to Cloud Next, Acquia does not upgrade your application until it is running a full Drupal install. Applications still deployed from the WELCOME tag are put on hold for upgrade scheduling.