When the memcache infrastructure is updated, patched, or auto-scaled, its network address gets updated dynamically, and your running Drupal 7 application does not natively look up the address. During such period, such Drupal 7 applications may experience temporary slowness or brief periods of 5xx errors. This is an existing issue with Drupal 7 and memcache.
Workaround:
Add the following configuration to your settings.php file:
$conf['memcache_persistent'] = FALSE;
This ensures that the application handles connection resets gracefully. However, this may increase the baseline response time by typically 1-2 seconds. Nevertheless, Acquia recommends that you add this property as it provides greater stability during platform maintenance. In addition, having this property in the settings.php file reduces impact during maintenances that result in a memcache clear. By implementing the provided workaround, you can mitigate the impact.
Copy or import of databases fails
If the definition of a VIEW contains the database name in its defining query, you cannot copy or import databases.
Workaround:
To remove any instances of the database name db-name-printed-here from the VIEW:
Confirm the database name as follows:
mysql> show databases;;;
+----------------------------------+
| Database |
+----------------------------------+
| information_schema |
| db-name-printed-here |
+----------------------------------+
2 rows in set (0.02 sec)
Identify the views that contain references of the database name as follows:
mysql> SELECT TABLE_NAME AS VIEW_NAME,TABLE_SCHEMA AS DB_NAME FROM INFORMATION_SCHEMA.VIEWS WHERE VIEW_DEFINITION like '%db-name-printed-here%';
+-------------------------------------------+----------------------------------+
| VIEW_NAME | DB_NAME |
+-------------------------------------------+----------------------------------+
| some-view-name | db-name-printed-here |
+-------------------------------------------+----------------------------------+
1 row in set (0.06 sec)
Review the VIEW and remove all occurrences of the database name from the SQL query as follows:
mysql> SHOW CREATE VIEW some-view-name \G
*************************** 1. row ***************************
View: some-view-name
Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`s10628`@`%` SQL SECURITY DEFINER VIEW `some-view-name` AS select `db-name-printed-here`.`watchdog`.`wid` AS `wid`,`db-name-printed-here`.`watchdog`.`severity` AS `severity`,`db-name-printed-here`.`watchdog`.`message` AS `message` from `db-name-printed-here`.`watchdog` where (`db-name-printed-here`.`watchdog`.`type` = 'cron')
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set (0.00 sec)
Process limit for Drupal, SSHD, Scheduled Tasks, and Cloud Hooks
You cannot have more than 5000 processes for Drupal, SSHD, scheduled tasks, and Cloud Hooks. If you exceed the process limit, the system restarts the service. This interrupts running requests and results in 50x errors for Drupal.
Note
If you run Shell commands from PHP in the background, such processes become defunct processes.
You cannot check the current number of processes on Drupal pods. However, you can view the process list on SSH pods.
Interruption in web requests taking longer than 10 minutes
Web requests that take longer than 10 minutes might be interrupted by routine platform maintenance activities.
Two daily backups
The Cloud Platform user interface may occasionally display two daily backup tasks for the same day, indicating the backups taken at different times of the day.
“End of script output before headers” error occurs if the HTTP response header exceeds 8 KB
Cloud Platform introduces a limit of 8 KB to HTTP response headers. When using HTTP headers, ensure that the header size does not exceed this limit. For example, this limit might be triggered when you use:
Acquia Purge module that is configured to output debug headers
Security Kit (seckit) module that is configured to output X-Content-Security-Policy headers
File copy operation takes longer in Cloud Platform compared to the non-Kubernetes version
The file copy operation in Cloud Platform takes longer as compared to the time taken in the non-Kubernetes version. This occurs because the files are first copied from the production environment to an intermediate ODE environment, and then to a migration environment. After the copy operation is complete, the system deletes the ODE environment, thereby keeping only the migration environment. This additional step in the migration process consumes more time.
Currently, you cannot increase the PHP file upload size values beyond the limits available in the Cloud Platform user interface. The maximum size for Cloud Platform is 1024 MB.
Upload a small dummy file of the next version of your software through the Drupal user interface. After that, you can access the Acquia Cloud service through SSH or SFTP, push the actual file, replacing the original dummy file. This process enables you to reference the file in Drupal and utilize it visually according to your preferences in Drupal.
memcache_admin incompatibility for FedRAMP customers
For FedRAMP customers, Cloud Platform uses individual mcrouter instances on each pod. This obscures information such as cache hits or misses and might misreport metrics on each report. Therefore, the memcache_admin module does not correctly report the status of memcache instances. Cumulative statistics, available memory, and evictions are reported as zero. In addition, other statistics might be misreported.
Workaround:
To gather memcache statistics, run the following command in an SSH session:
acquia-memcache stats
This command displays statistics from the available memcache instances.
Known issues
Issue with memcache in Drupal 7 applications
When the memcache infrastructure is updated, patched, or auto-scaled, its network address gets updated dynamically, and your running Drupal 7 application does not natively look up the address. During such period, such Drupal 7 applications may experience temporary slowness or brief periods of 5xx errors. This is an existing issue with Drupal 7 and memcache.
Workaround:
Add the following configuration to your settings.php file:
$conf['memcache_persistent'] = FALSE;
This ensures that the application handles connection resets gracefully. However, this may increase the baseline response time by typically 1-2 seconds. Nevertheless, Acquia recommends that you add this property as it provides greater stability during platform maintenance. In addition, having this property in the settings.php file reduces impact during maintenances that result in a memcache clear. By implementing the provided workaround, you can mitigate the impact.
Copy or import of databases fails
If the definition of a VIEW contains the database name in its defining query, you cannot copy or import databases.
Workaround:
To remove any instances of the database name db-name-printed-here from the VIEW:
Confirm the database name as follows:
mysql> show databases;;;
+----------------------------------+
| Database |
+----------------------------------+
| information_schema |
| db-name-printed-here |
+----------------------------------+
2 rows in set (0.02 sec)
Identify the views that contain references of the database name as follows:
mysql> SELECT TABLE_NAME AS VIEW_NAME,TABLE_SCHEMA AS DB_NAME FROM INFORMATION_SCHEMA.VIEWS WHERE VIEW_DEFINITION like '%db-name-printed-here%';
+-------------------------------------------+----------------------------------+
| VIEW_NAME | DB_NAME |
+-------------------------------------------+----------------------------------+
| some-view-name | db-name-printed-here |
+-------------------------------------------+----------------------------------+
1 row in set (0.06 sec)
Review the VIEW and remove all occurrences of the database name from the SQL query as follows:
mysql> SHOW CREATE VIEW some-view-name \G
*************************** 1. row ***************************
View: some-view-name
Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`s10628`@`%` SQL SECURITY DEFINER VIEW `some-view-name` AS select `db-name-printed-here`.`watchdog`.`wid` AS `wid`,`db-name-printed-here`.`watchdog`.`severity` AS `severity`,`db-name-printed-here`.`watchdog`.`message` AS `message` from `db-name-printed-here`.`watchdog` where (`db-name-printed-here`.`watchdog`.`type` = 'cron')
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set (0.00 sec)
Process limit for Drupal, SSHD, Scheduled Tasks, and Cloud Hooks
You cannot have more than 5000 processes for Drupal, SSHD, scheduled tasks, and Cloud Hooks. If you exceed the process limit, the system restarts the service. This interrupts running requests and results in 50x errors for Drupal.
Note
If you run Shell commands from PHP in the background, such processes become defunct processes.
You cannot check the current number of processes on Drupal pods. However, you can view the process list on SSH pods.
Interruption in web requests taking longer than 10 minutes
Web requests that take longer than 10 minutes might be interrupted by routine platform maintenance activities.
Two daily backups
The Cloud Platform user interface may occasionally display two daily backup tasks for the same day, indicating the backups taken at different times of the day.
“End of script output before headers” error occurs if the HTTP response header exceeds 8 KB
Cloud Platform introduces a limit of 8 KB to HTTP response headers. When using HTTP headers, ensure that the header size does not exceed this limit. For example, this limit might be triggered when you use:
Acquia Purge module that is configured to output debug headers
Security Kit (seckit) module that is configured to output X-Content-Security-Policy headers
File copy operation takes longer in Cloud Platform compared to the non-Kubernetes version
The file copy operation in Cloud Platform takes longer as compared to the time taken in the non-Kubernetes version. This occurs because the files are first copied from the production environment to an intermediate ODE environment, and then to a migration environment. After the copy operation is complete, the system deletes the ODE environment, thereby keeping only the migration environment. This additional step in the migration process consumes more time.
Currently, you cannot increase the PHP file upload size values beyond the limits available in the Cloud Platform user interface. The maximum size for Cloud Platform is 1024 MB.
Upload a small dummy file of the next version of your software through the Drupal user interface. After that, you can access the Acquia Cloud service through SSH or SFTP, push the actual file, replacing the original dummy file. This process enables you to reference the file in Drupal and utilize it visually according to your preferences in Drupal.
memcache_admin incompatibility for FedRAMP customers
For FedRAMP customers, Cloud Platform uses individual mcrouter instances on each pod. This obscures information such as cache hits or misses and might misreport metrics on each report. Therefore, the memcache_admin module does not correctly report the status of memcache instances. Cumulative statistics, available memory, and evictions are reported as zero. In addition, other statistics might be misreported.
Workaround:
To gather memcache statistics, run the following command in an SSH session:
acquia-memcache stats
This command displays statistics from the available memcache instances.
Change in mod_headers behavior in Cloud Platform
In the non-Kubernetes version, mod_headers directives in the .htaccess file are ignored for PHP and Drupal requests, and are only applied to static files. However, in Cloud Platform, mod_headers directives in the .htaccess file are applied. This might result in unexpected or unwanted changes in application behavior. Acquia recommends that you review your .htaccess file for mod_headers usage.
MySQL 5.7 features incompatibilities on Cloud Platform
Cloud Platform leverages AWS Aurora MySQL. A few of the MySQL 5.7 features are not supported on Cloud Platform. For more information, see list of unsupported MySQL 5.7 features.
Scheduled jobs must not use hardcoded host names in log paths
Scheduled jobs or cron jobs in Cloud Platform must not use hardcoded host names in log paths. However, if you use /shared/logs as the directory, you can use hardcoded paths.
Limitations with scheduled jobs
When you create scheduled jobs in Cloud Platform, your cron task duration must not be more than 3 hours. If your cron job lasts longer than that, it terminates.
Limitations with Cloud Hooks
The maximum duration of Cloud Hook scripts is 3 hours. If your Cloud Hook script lasts longer than that, it terminates.
Cloud Hook scripts and all child processes have a maximum memory limit of 2000 MB. If these processes exceed the available memory, the Cloud Hook logs display messages such as Killed or Exit status 137.
TLS connection issues in Ubuntu 22.04
OpenSSL 3.0.x enforces strict TLS compliance in Ubuntu 22.04. This compliance causes connection errors with external services that have improper TLS implementation. For example, you might get the following error:
Ensure that your external services are updated to meet TLS standards.
Issues in connecting with locally-installed MySQL Workbench
If you have MySQL Workbench installed locally, you might not be able to connect to Cloud Platform environments. This issue occurs for a few versions of MySQL Workbench.
If you face such issues :
Locate the database credentials listed on your Databases page.
Open Terminal on your local machine and run:
{ssh -L $LOCAL_PORT:$DB_HOST:3306 $SSH_STRING}
Here,
LOCAL_PORT is the port to which Workbench must connect when using localhost.
DB_HOST is the hostname obtained from the Cloud Platform user interface.
SSH_STRING is the full connection string from the Cloud Platform user interface. For example, user@something.
Code deployment in Cloud Platform can take a maximum of 1 hour. Environments on Cloud Platform may intermittently experience code deployment times taking more than 5 minutes. Ensure that you close your SSH session before starting your code deployment. If you are in an SSH session and start code deployment, the process might fail.
Git repositories in Cloud Platform must not exceed 2 GB. If your repository size exceeds this limit, code deployment tasks might fail without displaying any public logs. In such a case, you must verify that the combined size of all files in the specified Git branch or tag is less than 2 GB. For more information, visit Disk Storage.
Drupal watchdog logs not captured for SSH, Cloud Hooks, or Scheduled Jobs
Tasks executed through SSH, Cloud Hooks, or Scheduled Jobs do not run the syslog service. Logging done through the Drupal Logging API, also known as Watchdog, is only sent to the standard output and standard error channels, and not to the drupal-watchdog logs that can be downloaded from the Cloud Platform user interface or Cloud API.
If an application uses the Log Forwarding feature, this same logging is not sent to a log forwarding destination.
As a workaround, you must configure tasks to execute through HTTP request with the HTTP Drush Wrapper module. HTTP requests have an expiration of 10 minutes.
The database copy, backup, and restore operations are updated to maintain compatibility between MySQL 5.7 and MySQL 8. This ensures that these operations continue to function as expected during database version upgrade of MySQL. This update modifies any data in your database from utf8mb4_0900_ai_ci to utf8mb4_general_ci during these operations. Acquia could not target the specific collation or charset. Therefore, if your database contains content with the utf8mb4_0900_ai_ci collation, the system updates it to utf8mb4_general_ci.
This update does not apply to database dumps and restores that are done manually with Drush. Therefore, such operations might fail when you copy them between databases on different MySQL versions.
The automatic collation conversion described previously applies only when the destination database is MySQL 5.7. Customers who use MySQL 8.0 as the destination are not affected by this behavior. Therefore, the sed-based workaround is not required for MySQL 8 environments.
Workaround:
If you have a database dump that you have exported manually and you cannot import it properly, you can convert the file by running a command similar to the following:
You have a database backup file that is gzip-compressed in the current folder.
You are running a Cloud Platform SSH connection or Cloud IDE.
Therefore, you must update the command depending on your requirements.
Custom Varnish configurations with Acquia Purge
If your Cloud Platform application uses a Custom Varnish Configuration (cVCL) file to restrict access based on IP addresses, you might experience issues with the Acquia Purge module. This occurs because purge requests originate from Web EIP addresses. By default, such requests are blocked if you do not explicitly allowlist the Web EIPs in your cVCL.
Workaround:
Contact Acquia Support to enable Web EIPs.
Update your custom VCL to allowlist the Web EIP addresses.
Extra or missing logs in log downloads
When you download logs, you might get extra entries or missing logs in your downloaded file. However, the time displayed on the downloaded logs is correct.
Workaround: If you are missing specific logs, try to download logs for the previous or next day in addition to your original date range. Therefore, you can access logs that did not appear in your initial download.
Certain operations fail in PHP 8.4 for FedRAMP applications
PHP 8.4 includes OpenSSL 3.x, which has strict TLS security requirements. This impacts all operations that require SSL connectivity. For example, when you attempt to perform system backups in FedRAMP applications, you might get the following error:
If FIPS is enabled for your application, do not upgrade to PHP 8.4.
Download link for MySQL slow query logs does not work
You might not be able to download the MySQL slow query log through the Cloud Platform user interface.
Workaround:
You can check the MySQL slow query log stream and note the queries that cause issues. When you optimize a few of such queries, the log size is reduced. Thereafter, you can retry downloading the MySQL slow query log.
Manually deleted backups appear as active in the Cloud Platform user interface for up to 24 hours
If you delete a backup manually, the backup continues to appear in the list on the Databases page for about 24 hours.
Using the Cloud Platform API to download backups with ELBs present results in failures
When downloading database backups using the Cloud Platform API v2, users experience failures if an
The server resize Cancel button does not always work as expected
In the legacy Cloud Platform interface, when a user selects Resize > Cancel, occasionally the Cancel button does not dismiss the dialog box.
Database backup downloads fail while using latest version of Chrome
For Chrome version 87 or later, mixed content downloads were disabled. Owing to this, database backup downloads initiated in the Cloud user interface fail in some cases.
Workaround:
The Cloud Platform user interface displays the http version of the db backup download URL. You can specify this URL in a new browser window to restart the download.
Using Midnight Commander can cause file service interruptions
Cloud Platform Enterprise subscribers who use GNU Midnight Commander can experience service interruptions when trying to access their GFS mount. Acquia currently recommends that you do not use Midnight Commander with your Acquia-hosted websites.
Unable to perform database backups following the VCL access list update
After adding an access control list to your Varnish configuration file, you may not be able to download database backups through the Cloud user interface. It happens because while limiting access to your sites, your access control list also limits access to your Acquia default domain, such as example.prod.acquia-sites.com, that is required for database downloads to function.
To perform database backups:
In the access control list of your VCL, add the IP addresses that can download backups.
Issues occur with certain applications and methods after enabling FIPS in Cloud Classic applications
When you enable FIPS in a Cloud Classic environment, certain applications and methods might break. For example, Ruby might fail with the following error:
FIPS mode is enabled, bundler can't use the CompactIndex API
Workaround:
Modify your application to use only FIPS-approved cryptographic methods and avoid using methods like md5 that are prohibited in FIPS. For more information about FIPS-approved cryptographic methods, see supported methods.
Inaccurate storage reporting in the Cloud Platform user interface
Stack Metrics in the Cloud Platform user interface might display incorrect storage value. This value might be different from what you see when accessing the platform through SSH.
Workaround:
Use SSH to access /mnt/gfs to get the accurate data.
SQLite extensions not supported
SQLite extensions are not supported on Cloud Platform.
Cloud Platform is optimized for a managed MySQL-compatible database layer. Applications that try to use SQLite will encounter compatibility issues or fail to operate within the platform's infrastructure.
Workaround:
Applications that require SQLite must be refactored to use MySQL-compatible databases supported by the platform.
Service levels and incident handling on Acquia Cloud Platform
This issue applies to Cloud Platform customers on shared infrastructure.
Cloud Platform is designed for cost-efficiency and flexibility. Because the platform uses shared infrastructure such as shared load balancers, Acquia prioritizes immediate service restoration. To bring sites back online quickly, Support engineers often restart or fail over affected hardware. This process frequently clears the low-level system state needed for a definitive Root Cause Analysis (RCA). You receive an incident summary that describes the restoration steps. However, you might not receive a detailed forensic RCA or a single-fix preventive guarantee.
Workaround:
While platform architecture cannot be changed at the user level, you can reduce the impact of shared infrastructure incidents through Optimizing application performance by:
Enable Drupal page, block, and view caching.
Review cron jobs, database queries, and queues for long-running operations to improve efficiency.
Avoid uncached external API calls during the request cycle.
Known issues with PHP and Memcache
Issue with vendored packages in PHP 8.4
Using PHP 8.4 may cause deprecation warnings and Composer conflicts with certain Drupal and Drush combinations, such as Drupal 10.4.5 with Drush 13.4. This occurs due to incompatibilities with vendored packages or conflicting package versions.
New environments provision with Cloud Platform default PHP version
If a new Cloud Platform environment is provisioned by a CI/CD process, such as Acquia Pipelines or Acquia Code Studio, the new environment is provisioned with the default Cloud Platform PHP version. The new environment does not inherit the PHP settings from the source environment or CI/CD build. For more information on the default PHP version, visit default Cloud Platform PHP version.
Workaround:
You must set your desired PHP version for the new environment. You can configure the PHP version through the Cloud Platform user interface or the command line.
Cloud Platform user interface: Modify the PHP version for your application at the environment level with the configuration settings after the new environment is deployed.
: Change the PHP version with the following command:
Note
As the aliases are supported in MySQL 5.7 and MySQL 8.0, you can update your application code ahead of your Cloud Platform upgrade to MySQL 8.0.
I use the sql_mode value NO_AUTO_CREATE_USER in MySQL 5.7. Is this supported in MySQL 8.0?
In MySQL 8.0, the NO_AUTO_CREATE_USERsql_mode is deprecated. If you have this mode in your codebase, you might get the following error after you upgrade to MySQL 8.0:
AH_WARNING: The connection to database default on db-x.x.x failed after 3 attempts and is now failing over. Error was: SQLSTATE[42000]: Syntax error or access violation: 1231 Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER' request_id=""
Can I use Fast 404 module in sites that run MySQL 8.0 or later?
No, Fast 404 is incompatible with MySQL 8.0 and later. This impacts only the 7.x versions of Drupal and Fast 404.
If your sites use this module after they are upgraded to MySQL 8.0 and later, such sites might encounter degraded functionality and the following errors:
Note
This does not affect your actual data but only the comment text in your schema metadata.
How do I confirm that my Drupal version is compatible with MySQL 8.0?
Acquia will upgrade the MySQL version for Cloud Platform infrastructure from Aurora MySQL 5.7 to Aurora MySQL 8.0. The following Drupal versions are compatible with MySQL 8.0:
Drupal 7: Drupal 7.7.6 and later
Drupal 8: Drupal 8.6 and later
Workaround: If you are running an incompatible version of Drupal, upgrade to at least Drupal 7.76 or Drupal 8.6 before migrating to Cloud Platform. This will ensure compatibility with Aurora MySQL 8.0. For more information, visit Amazon Aurora major versions.
PHP 8.5 extension support on Ubuntu Focal
PHP 8.5 has specific limitations regarding extension support on Ubuntu Focalversion. The following extensions are not supported on PHP 8.5:
rdkafka
protobuf
grpc
PHP 8.5 does not support the gRPC extension on Ubuntu Jammy. Acquia will provide a follow-up release after the grcp extension is supported upstream for PHP 8.5.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Change in mod_headers behavior in Cloud Platform
In the non-Kubernetes version, mod_headers directives in the .htaccess file are ignored for PHP and Drupal requests, and are only applied to static files. However, in Cloud Platform, mod_headers directives in the .htaccess file are applied. This might result in unexpected or unwanted changes in application behavior. Acquia recommends that you review your .htaccess file for mod_headers usage.
MySQL 5.7 features incompatibilities on Cloud Platform
Cloud Platform leverages AWS Aurora MySQL. A few of the MySQL 5.7 features are not supported on Cloud Platform. For more information, see list of unsupported MySQL 5.7 features.
Scheduled jobs must not use hardcoded host names in log paths
Scheduled jobs or cron jobs in Cloud Platform must not use hardcoded host names in log paths. However, if you use /shared/logs as the directory, you can use hardcoded paths.
Limitations with scheduled jobs
When you create scheduled jobs in Cloud Platform, your cron task duration must not be more than 3 hours. If your cron job lasts longer than that, it terminates.
Limitations with Cloud Hooks
The maximum duration of Cloud Hook scripts is 3 hours. If your Cloud Hook script lasts longer than that, it terminates.
Cloud Hook scripts and all child processes have a maximum memory limit of 2000 MB. If these processes exceed the available memory, the Cloud Hook logs display messages such as Killed or Exit status 137.
TLS connection issues in Ubuntu 22.04
OpenSSL 3.0.x enforces strict TLS compliance in Ubuntu 22.04. This compliance causes connection errors with external services that have improper TLS implementation. For example, you might get the following error:
Ensure that your external services are updated to meet TLS standards.
Issues in connecting with locally-installed MySQL Workbench
If you have MySQL Workbench installed locally, you might not be able to connect to Cloud Platform environments. This issue occurs for a few versions of MySQL Workbench.
If you face such issues :
Locate the database credentials listed on your Databases page.
Open Terminal on your local machine and run:
{ssh -L $LOCAL_PORT:$DB_HOST:3306 $SSH_STRING}
Here,
LOCAL_PORT is the port to which Workbench must connect when using localhost.
DB_HOST is the hostname obtained from the Cloud Platform user interface.
SSH_STRING is the full connection string from the Cloud Platform user interface. For example, user@something.
Code deployment in Cloud Platform can take a maximum of 1 hour. Environments on Cloud Platform may intermittently experience code deployment times taking more than 5 minutes. Ensure that you close your SSH session before starting your code deployment. If you are in an SSH session and start code deployment, the process might fail.
Git repositories in Cloud Platform must not exceed 2 GB. If your repository size exceeds this limit, code deployment tasks might fail without displaying any public logs. In such a case, you must verify that the combined size of all files in the specified Git branch or tag is less than 2 GB. For more information, visit Disk Storage.
Drupal watchdog logs not captured for SSH, Cloud Hooks, or Scheduled Jobs
Tasks executed through SSH, Cloud Hooks, or Scheduled Jobs do not run the syslog service. Logging done through the Drupal Logging API, also known as Watchdog, is only sent to the standard output and standard error channels, and not to the drupal-watchdog logs that can be downloaded from the Cloud Platform user interface or Cloud API.
If an application uses the Log Forwarding feature, this same logging is not sent to a log forwarding destination.
As a workaround, you must configure tasks to execute through HTTP request with the HTTP Drush Wrapper module. HTTP requests have an expiration of 10 minutes.
The database copy, backup, and restore operations are updated to maintain compatibility between MySQL 5.7 and MySQL 8. This ensures that these operations continue to function as expected during database version upgrade of MySQL. This update modifies any data in your database from utf8mb4_0900_ai_ci to utf8mb4_general_ci during these operations. Acquia could not target the specific collation or charset. Therefore, if your database contains content with the utf8mb4_0900_ai_ci collation, the system updates it to utf8mb4_general_ci.
This update does not apply to database dumps and restores that are done manually with Drush. Therefore, such operations might fail when you copy them between databases on different MySQL versions.
The automatic collation conversion described previously applies only when the destination database is MySQL 5.7. Customers who use MySQL 8.0 as the destination are not affected by this behavior. Therefore, the sed-based workaround is not required for MySQL 8 environments.
Workaround:
If you have a database dump that you have exported manually and you cannot import it properly, you can convert the file by running a command similar to the following:
You have a database backup file that is gzip-compressed in the current folder.
You are running a Cloud Platform SSH connection or Cloud IDE.
Therefore, you must update the command depending on your requirements.
Custom Varnish configurations with Acquia Purge
If your Cloud Platform application uses a Custom Varnish Configuration (cVCL) file to restrict access based on IP addresses, you might experience issues with the Acquia Purge module. This occurs because purge requests originate from Web EIP addresses. By default, such requests are blocked if you do not explicitly allowlist the Web EIPs in your cVCL.
Workaround:
Contact Acquia Support to enable Web EIPs.
Update your custom VCL to allowlist the Web EIP addresses.
Extra or missing logs in log downloads
When you download logs, you might get extra entries or missing logs in your downloaded file. However, the time displayed on the downloaded logs is correct.
Workaround: If you are missing specific logs, try to download logs for the previous or next day in addition to your original date range. Therefore, you can access logs that did not appear in your initial download.
Certain operations fail in PHP 8.4 for FedRAMP applications
PHP 8.4 includes OpenSSL 3.x, which has strict TLS security requirements. This impacts all operations that require SSL connectivity. For example, when you attempt to perform system backups in FedRAMP applications, you might get the following error:
If FIPS is enabled for your application, do not upgrade to PHP 8.4.
Download link for MySQL slow query logs does not work
You might not be able to download the MySQL slow query log through the Cloud Platform user interface.
Workaround:
You can check the MySQL slow query log stream and note the queries that cause issues. When you optimize a few of such queries, the log size is reduced. Thereafter, you can retry downloading the MySQL slow query log.
Manually deleted backups appear as active in the Cloud Platform user interface for up to 24 hours
If you delete a backup manually, the backup continues to appear in the list on the Databases page for about 24 hours.
Using the Cloud Platform API to download backups with ELBs present results in failures
When downloading database backups using the Cloud Platform API v2, users experience failures if an
The server resize Cancel button does not always work as expected
In the legacy Cloud Platform interface, when a user selects Resize > Cancel, occasionally the Cancel button does not dismiss the dialog box.
Database backup downloads fail while using latest version of Chrome
For Chrome version 87 or later, mixed content downloads were disabled. Owing to this, database backup downloads initiated in the Cloud user interface fail in some cases.
Workaround:
The Cloud Platform user interface displays the http version of the db backup download URL. You can specify this URL in a new browser window to restart the download.
Using Midnight Commander can cause file service interruptions
Cloud Platform Enterprise subscribers who use GNU Midnight Commander can experience service interruptions when trying to access their GFS mount. Acquia currently recommends that you do not use Midnight Commander with your Acquia-hosted websites.
Unable to perform database backups following the VCL access list update
After adding an access control list to your Varnish configuration file, you may not be able to download database backups through the Cloud user interface. It happens because while limiting access to your sites, your access control list also limits access to your Acquia default domain, such as example.prod.acquia-sites.com, that is required for database downloads to function.
To perform database backups:
In the access control list of your VCL, add the IP addresses that can download backups.
Issues occur with certain applications and methods after enabling FIPS in Cloud Classic applications
When you enable FIPS in a Cloud Classic environment, certain applications and methods might break. For example, Ruby might fail with the following error:
FIPS mode is enabled, bundler can't use the CompactIndex API
Workaround:
Modify your application to use only FIPS-approved cryptographic methods and avoid using methods like md5 that are prohibited in FIPS. For more information about FIPS-approved cryptographic methods, see supported methods.
Inaccurate storage reporting in the Cloud Platform user interface
Stack Metrics in the Cloud Platform user interface might display incorrect storage value. This value might be different from what you see when accessing the platform through SSH.
Workaround:
Use SSH to access /mnt/gfs to get the accurate data.
SQLite extensions not supported
SQLite extensions are not supported on Cloud Platform.
Cloud Platform is optimized for a managed MySQL-compatible database layer. Applications that try to use SQLite will encounter compatibility issues or fail to operate within the platform's infrastructure.
Workaround:
Applications that require SQLite must be refactored to use MySQL-compatible databases supported by the platform.
Service levels and incident handling on Acquia Cloud Platform
This issue applies to Cloud Platform customers on shared infrastructure.
Cloud Platform is designed for cost-efficiency and flexibility. Because the platform uses shared infrastructure such as shared load balancers, Acquia prioritizes immediate service restoration. To bring sites back online quickly, Support engineers often restart or fail over affected hardware. This process frequently clears the low-level system state needed for a definitive Root Cause Analysis (RCA). You receive an incident summary that describes the restoration steps. However, you might not receive a detailed forensic RCA or a single-fix preventive guarantee.
Workaround:
While platform architecture cannot be changed at the user level, you can reduce the impact of shared infrastructure incidents through Optimizing application performance by:
Enable Drupal page, block, and view caching.
Review cron jobs, database queries, and queues for long-running operations to improve efficiency.
Avoid uncached external API calls during the request cycle.
Known issues with PHP and Memcache
Issue with vendored packages in PHP 8.4
Using PHP 8.4 may cause deprecation warnings and Composer conflicts with certain Drupal and Drush combinations, such as Drupal 10.4.5 with Drush 13.4. This occurs due to incompatibilities with vendored packages or conflicting package versions.
New environments provision with Cloud Platform default PHP version
If a new Cloud Platform environment is provisioned by a CI/CD process, such as Acquia Pipelines or Acquia Code Studio, the new environment is provisioned with the default Cloud Platform PHP version. The new environment does not inherit the PHP settings from the source environment or CI/CD build. For more information on the default PHP version, visit default Cloud Platform PHP version.
Workaround:
You must set your desired PHP version for the new environment. You can configure the PHP version through the Cloud Platform user interface or the command line.
Cloud Platform user interface: Modify the PHP version for your application at the environment level with the configuration settings after the new environment is deployed.
: Change the PHP version with the following command:
Note
As the aliases are supported in MySQL 5.7 and MySQL 8.0, you can update your application code ahead of your Cloud Platform upgrade to MySQL 8.0.
I use the sql_mode value NO_AUTO_CREATE_USER in MySQL 5.7. Is this supported in MySQL 8.0?
In MySQL 8.0, the NO_AUTO_CREATE_USERsql_mode is deprecated. If you have this mode in your codebase, you might get the following error after you upgrade to MySQL 8.0:
AH_WARNING: The connection to database default on db-x.x.x failed after 3 attempts and is now failing over. Error was: SQLSTATE[42000]: Syntax error or access violation: 1231 Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER' request_id=""
Can I use Fast 404 module in sites that run MySQL 8.0 or later?
No, Fast 404 is incompatible with MySQL 8.0 and later. This impacts only the 7.x versions of Drupal and Fast 404.
If your sites use this module after they are upgraded to MySQL 8.0 and later, such sites might encounter degraded functionality and the following errors:
Note
This does not affect your actual data but only the comment text in your schema metadata.
How do I confirm that my Drupal version is compatible with MySQL 8.0?
Acquia will upgrade the MySQL version for Cloud Platform infrastructure from Aurora MySQL 5.7 to Aurora MySQL 8.0. The following Drupal versions are compatible with MySQL 8.0:
Drupal 7: Drupal 7.7.6 and later
Drupal 8: Drupal 8.6 and later
Workaround: If you are running an incompatible version of Drupal, upgrade to at least Drupal 7.76 or Drupal 8.6 before migrating to Cloud Platform. This will ensure compatibility with Aurora MySQL 8.0. For more information, visit Amazon Aurora major versions.
PHP 8.5 extension support on Ubuntu Focal
PHP 8.5 has specific limitations regarding extension support on Ubuntu Focalversion. The following extensions are not supported on PHP 8.5:
rdkafka
protobuf
grpc
PHP 8.5 does not support the gRPC extension on Ubuntu Jammy. Acquia will provide a follow-up release after the grcp extension is supported upstream for PHP 8.5.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
pcntl_fork() is not supported in live code and can cause stability issues with PHP 8 and later.
Using the pcntl_fork() function with PHP 8 and later in website code can leak PHP processes. This crashes the site slowly. Acquia recommends that you do not use this function, as it might be disabled eventually. However, you can use it in CLI PHP scripts.
Known issues in the Cloud Platform user interface
Cloud Platform notification API does not display real-time results
The Cloud Platform notification API does not display real-time results. It typically returns a response within seconds, but sometimes can take several minutes to reflect the current state of the platform.
Cloud Platform displays a zlib “freed prematurely” message when inspecting tasks
When inspecting the output of any successful or failed task, the final line is: zlib(finalizer): the stream was freed prematurely. This message can be ignored.
XML is not an acceptable file type in Support tickets
The acceptable file listing on the customer-facing ticket submission page lists XML as an acceptable file type, but XML files are not accepted for upload.
Workaround:
Place the XML in a .zip file, and then attach the .zip file to the ticket.
The active domain for an environment cannot be changed
The active domain for an environment defaults to the first bare domain name, with or without the www prefix, and cannot be changed. Environments that have no top-level custom domains use the Acquia default domain as the active domain.
Environment
variables that start with followed by a number are removed
When you use environment variables in the Cloud UI, starting a sequence with $ followed by a number removes the first two characters.
For example, adding $23456 as an environment variable results in 3456.
Workaround:
When you use the environment variable in your code, manually prepend the first two characters to the variable. Acquia recommends that you validate your code to prevent any application issues when the issue is resolved.
Known issues with version control
Git checkouts fail after reporting non-existent changes to binary files
Git checkouts fail with the following error when non-text files contain a specific byte sequence and are not explicitly defined as binary files: Your local changes to the following files would be overwritten by checkout. Please, commit your changes or stash them.
Workaround:
Edit the following section of your .gitattributes file:
# Auto-detect text files, ensure they use LF.
* text=auto eol=lf
and then make one of the following changes:
Remove the line that begins with *.
Remove the eol=lf text.
Ensure that a specification line is added for every binary file extension used in your repository.
Deployed branches or tags cannot be deleted
Cloud Platform does not allow you to delete branches that are currently deployed to an environment. If you try to delete a branch from the command line, an error message like the following displays:
remote: Operation rejected: remote: Git branch or tag test_branch cannot be
deleted because it is currently deployed to testsite.prod
Cloud Platform displays an error message when pushing code to Git
When attempting to push code, some users may encounter error messages like the following example if the root account owns a directory, instead of the siteuser account:
remote: error: insufficient permission for adding an object to repository
database ./objects
Deployment keys must be associated with a user account
Cloud Platform does not support the use of deployment keys (machine keys) that are not associated with an individual user account. All SSH keys must be associated with a user account.
You might get a 404 error when you log in through Acquia Connector.
Workaround:
You must assign the Access to legacy product keys permission to your role and re-authenticate yourself.
Non-hosted applications have access issue while using Acquia Connector with Search
In non-hosted applications, only users with admin privileges can click the Sign in with Acquia option for authentication to the search functionality. Non-admin user roles like team lead and developer cannot access this option.
Acquia Connector 8.x-1.17 causes error during cron runs
Upgrading to Acquia Connector 8.x-1.17 introduces the following error and may interfere with cron runs:
Drupal websites connected to Acquia subscription will send heartbeat requests during each cron run. By default, cron runs at the beginning of each hour, which can cause the Acquia subscription service to receive thousands of simultaneous connections across all subscriber websites. This causes some requests to time out.
Workaround:
If your subscription service is experiencing timeouts, Acquia recommends that you modify your cron runs to not begin at the start of the hour.
The Acquia Connector module conflicts with Remote stream wrapper module
The current Drupal version requires Drush version 11 or later. Newer versions of Drush, that is, version 11 and later, must be installed through Composer. Acquia does not manage the update to the newer versions. For more information, see About Drush on Cloud Platform.
Drush aliases (YAML format) downloaded from cloud throw warnings for PHP 8.0
Using the Drush aliases from the Drush page in the Cloud Platform user interface might generate warnings with certain Drush commands if the site is running PHP 8.0.
The preceding block shows a sample Drush alias in the YAML format. If you run the drush uli command from your terminal, you might encounter the following warnings and deprecated messages:
$ vendor/bin/drush @default.dev uli
[warning] Undefined property: Drush\Commands\core\LoginCommands::$uri ExecTrait.php:38
[warning] does not appear to be a resolvable hostname or IP, not starting browser. You may need to use the --uri option in your command or site alias to indicate the correct URL of this site.
Deprecated: Required parameter $args follows optional parameter $command in /usr/local/drush9/vendor/drush/drush/includes/batch.inc on line 115
Deprecated: Required parameter $options follows optional parameter $command in /usr/local/drush9/vendor/drush/drush/includes/batch.inc on line 115
http://d9forcl57747.dev.acquia-sites.com/user/reset/1/1635526597/49RN0AE6RAINusSIxmSzRJgfoJmp3suVhdSFl2Vz2L0/login
The drush uli command works and returns the desired output even with the warnings. If these warnings block your development, remove the following segment from the yaml file:
paths:
drush-script: drush9
The current Drupal version is incompatible with certain Acquia Drush commands
Before the Acquia require line, add $_SERVER['PWD']=DRUPAL_ROOT;.
Save the settings.php file.
Drush aliases are downloaded only for active on-demand environments
Drush aliases for Cloud Platform CD environments are downloaded only if the environment is active.
Do not install Drush in your home directory
Installing Drush in your user directory can cause unexpected task failures. Acquia recommends that you require a site-local Drush as part of your codebase, not your home directory, and run your commands with a specific major version of Drush, as described in Using Drush on Cloud Platform.
An error message is displayed while running Drush 12 commands
Cloud Platform displays the following error message while running Drush 12 commands:
/bin/bash: /app/vendor/drush: No such file or directory
The Drush alias files that Cloud Platform generates are not compatible with Drush 12.
Cloud Platform CDN is not compatible with custom Varnish configurations
The Cloud Platform CDN does not support the use of custom Varnish configurations (custom VCLs) with Cloud Platform-hosted applications. Attempting to do so can cause Cloud Platform Enterprise to experience conflicting caching behavior.
The New Relic APM PHP extension is incompatible with Drupal 11.3 and later due to missing support for the Fibers PHP feature. Drupal 11.3 and later use Fibers to improve performance. Therefore, requests using Fibers are not displayed accurately in New Relic. Any sub-requests may not be traced, and transaction data may not be accurate.
Known issues with MySQL 5.7 to MySQL 8.0 upgrades
Before the platform database upgrade to MySQL 8.0, Acquia performs a series of automated pre-upgrade checks to identify any compatibility issues that can block or impact a successful upgrade. These checks scan Cloud Platform database clusters and individual databases for a range of potential issues, such as unsupported objects, deprecated features, or internal database artifacts left behind from previous upgrades or schema changes. Acquia's engineering team proactively resolves these incompatibilities where possible. For information about all the pre-check error descriptions, visit AWS Aurora MySQL.
A few common issues are:
Dangling FULLTEXT indexes or orphaned auxiliary columns
Unsupported storage engines
Invalid or deprecated data types
Tables with reserved keywords
Tables referencing removed features or system variables
I use the tx_isolation and tx_read_only variables in MySQL 5.7. Are these variables supported in MySQL 8.0?
No, the MySQL transaction variables, tx_isolation and tx_read_only are supported in MySQL 5.7 but are not supported in MySQL 8.0. Therefore, if you continue to use the legacy variables after you upgrade your application to MySQL 8.0, you might encounter the following errors:
Drupal might fail to connect to the database and log an error message. For example,
SQLSTATE[HY000]: General error: 1193 Unknown system variable 'tx_isolation'
If you use Drush to connect to Drupal, you might get different error messages based on your use case. For example,
SQLSTATE[HY000]: General error: 1193 Unknown system variable 'tx_isolation
or
Failed to connect to any database servers for database [DB UUID]
Workaround:
Replace the legacy variables, tx_isolation and tx_read_only with their aliases, transaction_isolation and transaction_read_only in your application code. These aliases are supported in MySQL 8.0 as well as MySQL 5.7. For example, if your settings.php file has the following:
SQL errors: This occurs because of deprecated or incompatible SQL syntax. For example, SQLSTATE[42000]: Syntax error or access violation: 1064.
Broken 404 pages: This occurs as the system displays blank pages and error messages because of missing files or inaccurate 404 pages.
Site instability: This causes unstable websites because of a large number of 404 errors. Such errors are caused by missing files, images, or bots, and can trigger memory use, "white screen of death" (WSOD), or inaccessible pages.
Performance degradation: This occurs because the site becomes non-responsive as 404s are not efficiently handled.
Inability to uninstall modules: After you upgrade to MySQL 8.0, you might not be able to update or uninstall this module correctly.
Workaround:
Uninstall or disable Fast 404 before upgrading to MySQL 8.0 and later.
Implement the code changes mentioned in the Fast 404 pages section in the Drupal core default.settings.php file.
Can I use certain reserved keywords in MySQL 8.0?
If your database or SQL queries use certain reserved keywords as unquoted column names, table names, or aliases, your code will fail in MySQL 8.0 with SQL syntax errors. For example:
RANK
SYSTEM
WINDOW
Such failures result in application features, deployments, or database migrations to break or become unavailable after the upgrade.
For example, the following SQL queries break in MySQL 8.0:
SELECT id, rank FROM mytable WHERE rank = 1;
SELECT * FROM system WHERE id = 1;
SELECT window FROM mytable;
Workaround: Use backticks (`) to quote reserved words:
SELECT id, `rank` FROM mytable WHERE `rank` = 1;
SELECT * FROM `system` WHERE id = 1;
SELECT `window` FROM mytable;
Solution:
Review the list of keywords new in MySQL 8.0 to identify any that may conflict with your existing database tables, columns, or aliases. For more information, visit MySQL 8.0 New Keywords and Reserved Words.
Audit your custom and contributed SQL queries, and your database schema, for use of these reserved words as unquoted identifiers.
Enclose these identifiers in backticks, or rename fields and tables to avoid reserved words.
Make these changes before upgrading to MySQL 8.0 to prevent SQL errors and application disruptions.
Can I use emojis or non-BMP Unicode in column comments with the UTF-8 character set in MySQL 8.0?
No. Before upgrading to MySQL 8.0, Cloud Platform checks for column comments that contain emojis or other non-BMP Unicode characters stored with the legacy UTF-8 character set, such as utf8mb3. If such characters are found, the system removes or replaces the comments so that the MySQL 8.0 upgrade does not block due to stricter character set validation. For more information visit Check for invalid utf8mb3 column comments.
Workaround:
Do one of the following:
Remove or replace all emojis and non-BMP Unicode characters from column comments before upgrading to MySQL 8.0.
Convert your table or column to use the utf8mb4 character set, which supports all Unicode characters.
Workaround:
If your application requires these extensions, ensure you are using a compatible combination of PHP version and Ubuntu operating system, or contact Acquia Support for guidance on alternative configurations.
Database backup fails when table definitions change
If a table structure in a database changes when a backup is in progress, the backup fails with an error similar to the following:
mysqldump: Error 1412: Table definition has changed, retry transaction when dumping table <table_name>
This failure typically occurs because application code or scheduled jobs, such as cron tasks to rebuild or alter tables, change the schema at runtime. This is an operational conflict rather than a platform defect. Cloud Platform requires a static schema snapshot to complete a backup.
Workaround:
Ensure that operations to change a schema do not overlap with the backup window:
Identify the source: Review application logs and custom cron jobs to identify processes that modify the specific table mentioned in the error.
Coordinate schedules: Access and adjust backup schedules in Cloud UI. Reschedule internal cron jobs or maintenance tasks so they do not run at the same time as database backups.
Acquia CLI (ACLI) not supported for MEO environments
ACLI does not support MEO environments. Commands that you run against MEO sites or environments can fail or result in unexpected behavior. Errors occur when you try to authenticate, list, or manage MEO applications and environments through ACLI. Use supported interfaces instead of ACLI to manage MEO environments.
Affected users: Customers who use MEO and try to manage those environments with ACLI must refer to supported interfaces.
Workaround:
Use Cloud Platform user interface and other supported tools to manage MEO environments instead of ACLI.
Do not use ACLI to provision, deploy to, or administer MEO environments.
Drupal 11.3.0 and later incompatibility with New Relic PHP agent
All versions of New Relic PHP agent are incompatible with Drupal 11.3.0 and later versions. Drupal 11.3.0 includes architectural changes to hook implementations that use PHP Fibers. When you run Drupal 11.3.0 or later, the New Relic PHP agent fails to collect
Application
Performance Monitoring (APM) data for certain Drupal transactions that use Fibers. Access to APM data in the New Relic UI remains unchanged, however, the data is incomplete.
New Relic confirmed this incompatibility and is working to develop a solution. Because of the complex architectural changes to support Fibers, New Relic estimates that support is available in early 2026.
Workaround:
To avoid issues with application monitoring or potential performance side effects, Acquia recommends that you complete one of the following:
Postpone the upgrade: Delay the upgrade of the application to Drupal 11.3.0 until New Relic releases a compatible version of the PHP agent.
Deactivate New Relic: To upgrade to Drupal 11.3.0 immediately, deactivate New Relic agent in Cloud Platform UI. To do this, delete the New Relic license key before the deployment. To upgrade to Drupal 11.3.0 before an updated agent is ready, deactivate New Relic on Cloud Platform. Acquia recommends it because the New Relic APM data is incomplete or inconsistent with actual use. To deactivate the agent, remove the New Relic license key through the UI.
Daily database backups on Cloud Platform might not trigger at the scheduled time. Database backups can run up to 12 hours later than the configured schedule. For example, a backup scheduled at 08:04 UTC might run at 20:00 UTC. This issue can occur across all environment types, such as Development, Staging, and Production.
The daily backup completes successfully, but at a different time than expected. This issue affects workflows that depend on backups that run in a specific time window, such as coordinated database restores or pre-deployment verification.
Workaround:
To create a backup at a specific time, use the Cloud Platform user interface to create an on-demand backup:
In the Databases section, click Back Up to manually trigger a database backup.
To ensure that a scheduled backup is complete, check the Activity log for the environment.
Duplicate SSH key
When users submit an SSH public key, Cloud Platform displays the following error message:
Error: Key already in use
The submitted SSH public key is already associated with another Cloud Platform user account. Acquia enforces key uniqueness across user accounts to maintain precise attribution and auditability of all SSH operations.
Workaround:
Generate and attach a unique SSH key pair to the account:
Create a new SSH public key pair with standard tools.
Log in to Cloud Platform, go to Account Settings > SSH Keys, and add the newly generated public key.
Delete the duplicate key from the account if necessary.
Update key references in local configurations such as ~/.ssh/config, CI/CD deployment pipelines, and custom deployment script.
When requesting the Acquia default domain, the subscriber’s self-service SSL certificate loads instead of the Acquia SSL certificate that covers the Acquia default domains. This behavior causes an SSL error in the browser. Install and activate two or more custom certificates on any affected environment to remove this error on the Acquia default domain.
Emergency-level logging broadcasts logged data to open SSH sessions
If a Drupal module logs information with the RFC 5424 severity of emergency, syslog broadcasts the information to open SSH sessions. These broadcasts can disrupt commands in progress, as indicated in the following example:
Subscribers upgrading their websites to newer versions of the current Drupal version, must rebuild website caches after the upgrading. Unexpected errors and problems with some page displays may occur until you rebuild caches.
Running update.php on the current Drupal version can display error messages
Attempting to run update.php on the current Drupal version fails with the following error message:
In order to run update.php you need to either be logged in as admin or have
set $settings['update_free_access']
Workaround:
Use one of the following methods:
Run drush updb to complete database updates.
Whenever you must run update.php, use your browser’s cookie manager to grab the session cookie from your current authenticated Drupal session, and then remove the leading S from the session name.
If you are running updates on your Dev or Stage environments, temporarily disable HTTPS while running updates.
Edit your settings.php file to temporarily set $settings['update_free_access'] to TRUE during your updates.
ADVANCED: Add the following code to your update.php file (directly following the use statements) to force Drupal to acknowledge the X-Forwarded-Proto value when determining if the request must be treated as HTTPS:
Altering the $databases array causes connection errors
Websites that alter the $databases array in settings.php to enable third-party database connections may experience connection errors when the connection setup is delayed in settings.php.
You cannot import a local website archive using the product interface
All Twig cache files for an environment are stored in a single directory
Clearing a website’s Twig caches clears the Twig caches for all websites hosted by that environment. For more information about how Cloud Platform stores Twig caches, visit Twig caches.
Resolution for Site Factory subscribers: Upgrade your installed version of the Site Factory Connector module to either version 8.x-1.59 and later, or version 8.x-2.59 or later (for Drush 9 support).
Websites running the current Drupal version can have theme change issues with Twig caches
When you change themes and perform a code deployment on Cloud Platform applications running the current Drupal version, you might experience issues where cached Twig templates fall out of sync on different web infrastructure. The problem arises from having separate copies of the compiled Twig templates on each web infrastructure and a related Drupal core issue.
Workaround:
When you make changes to themes in Cloud Platform Enterprise applications running the current Drupal version, connect to each web infrastructure, and run the following command to remove the outdated Twig templates:
drush @[sitename].[prod] --uri=http://[site_URL]/ ev '\Drupal\Core\PhpStorage\PhpStorageFactory::get("twig")->deleteAll();'
The AuthUserFile directive in .htaccess is not supported
The AuthUserFile directive in the Apache .htaccess file sets the name of a text file containing a list of users and passwords for user authentication. Cloud Platform does not support AuthUserFile, since its value must be either an absolute path or a path relative to the infrastructure root, and will not work across different Cloud Platform environments.
The SymLinksIfOwnerMatch option in .htaccess is not supported
Due to the configuration of directory ownership and permissions for your Cloud Platform application’s codebase and files directories, the SymLinksIfOwnerMatch option in your application’s .htaccess file prevents your web infrastructure from accessing any of the assets in your files directory. You must use the FollowSymLinks option instead.
Previous versions of Cloud Platform used LOGNAME differently
Do not use the LOGNAME environment variable to determine sitegroup or sitename in your .htaccess file or in other custom scripts.
Workaround:
Use the AH_SITE_NAME, AH_SITE_GROUP, or AH_SITE_ENVIRONMENTenvironment variables if you need environment-aware variables in your scripts.
Using mysqldump on MySQL 5.7 results in error
If you run mysqldump on MySQL 5.7, the following error occurs:
mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces
Workaround:
If you do not need to dump the tablespace information, invoke mysqldump with the –no-tablespaces option.
Issue with inactive load balancer when using log forwarding
When log forwarding is configured with a destination that includes an IP allowlist, the Cloud Platform user interface might display an error message for the inactive load balancer that indicates a connection issue or incorrect configuration. This occurs because the inactive load balancer uses a dynamic IP address until it becomes active. However, log forwarding from the primary or active load balancer functions correctly.
Issue with Fibers in Drupal 11.3 and later
The New Relic APM PHP extension is incompatible with Drupal 11.3 and later due to missing support for the Fibers PHP feature. Drupal 11.3 and later use Fibers to improve performance. Therefore, requests using Fibers are not displayed accurately in New Relic. Any sub-requests may not be traced, and transaction data may not be accurate.
pcntl_fork() is not supported in live code and can cause stability issues with PHP 8 and later.
Using the pcntl_fork() function with PHP 8 and later in website code can leak PHP processes. This crashes the site slowly. Acquia recommends that you do not use this function, as it might be disabled eventually. However, you can use it in CLI PHP scripts.
Known issues in the Cloud Platform user interface
Cloud Platform notification API does not display real-time results
The Cloud Platform notification API does not display real-time results. It typically returns a response within seconds, but sometimes can take several minutes to reflect the current state of the platform.
Cloud Platform displays a zlib “freed prematurely” message when inspecting tasks
When inspecting the output of any successful or failed task, the final line is: zlib(finalizer): the stream was freed prematurely. This message can be ignored.
XML is not an acceptable file type in Support tickets
The acceptable file listing on the customer-facing ticket submission page lists XML as an acceptable file type, but XML files are not accepted for upload.
Workaround:
Place the XML in a .zip file, and then attach the .zip file to the ticket.
The active domain for an environment cannot be changed
The active domain for an environment defaults to the first bare domain name, with or without the www prefix, and cannot be changed. Environments that have no top-level custom domains use the Acquia default domain as the active domain.
Environment
variables that start with followed by a number are removed
When you use environment variables in the Cloud UI, starting a sequence with $ followed by a number removes the first two characters.
For example, adding $23456 as an environment variable results in 3456.
Workaround:
When you use the environment variable in your code, manually prepend the first two characters to the variable. Acquia recommends that you validate your code to prevent any application issues when the issue is resolved.
Known issues with version control
Git checkouts fail after reporting non-existent changes to binary files
Git checkouts fail with the following error when non-text files contain a specific byte sequence and are not explicitly defined as binary files: Your local changes to the following files would be overwritten by checkout. Please, commit your changes or stash them.
Workaround:
Edit the following section of your .gitattributes file:
# Auto-detect text files, ensure they use LF.
* text=auto eol=lf
and then make one of the following changes:
Remove the line that begins with *.
Remove the eol=lf text.
Ensure that a specification line is added for every binary file extension used in your repository.
Deployed branches or tags cannot be deleted
Cloud Platform does not allow you to delete branches that are currently deployed to an environment. If you try to delete a branch from the command line, an error message like the following displays:
remote: Operation rejected: remote: Git branch or tag test_branch cannot be
deleted because it is currently deployed to testsite.prod
Cloud Platform displays an error message when pushing code to Git
When attempting to push code, some users may encounter error messages like the following example if the root account owns a directory, instead of the siteuser account:
remote: error: insufficient permission for adding an object to repository
database ./objects
Deployment keys must be associated with a user account
Cloud Platform does not support the use of deployment keys (machine keys) that are not associated with an individual user account. All SSH keys must be associated with a user account.
You might get a 404 error when you log in through Acquia Connector.
Workaround:
You must assign the Access to legacy product keys permission to your role and re-authenticate yourself.
Non-hosted applications have access issue while using Acquia Connector with Search
In non-hosted applications, only users with admin privileges can click the Sign in with Acquia option for authentication to the search functionality. Non-admin user roles like team lead and developer cannot access this option.
Acquia Connector 8.x-1.17 causes error during cron runs
Upgrading to Acquia Connector 8.x-1.17 introduces the following error and may interfere with cron runs:
Drupal websites connected to Acquia subscription will send heartbeat requests during each cron run. By default, cron runs at the beginning of each hour, which can cause the Acquia subscription service to receive thousands of simultaneous connections across all subscriber websites. This causes some requests to time out.
Workaround:
If your subscription service is experiencing timeouts, Acquia recommends that you modify your cron runs to not begin at the start of the hour.
The Acquia Connector module conflicts with Remote stream wrapper module
The current Drupal version requires Drush version 11 or later. Newer versions of Drush, that is, version 11 and later, must be installed through Composer. Acquia does not manage the update to the newer versions. For more information, see About Drush on Cloud Platform.
Drush aliases (YAML format) downloaded from cloud throw warnings for PHP 8.0
Using the Drush aliases from the Drush page in the Cloud Platform user interface might generate warnings with certain Drush commands if the site is running PHP 8.0.
The preceding block shows a sample Drush alias in the YAML format. If you run the drush uli command from your terminal, you might encounter the following warnings and deprecated messages:
$ vendor/bin/drush @default.dev uli
[warning] Undefined property: Drush\Commands\core\LoginCommands::$uri ExecTrait.php:38
[warning] does not appear to be a resolvable hostname or IP, not starting browser. You may need to use the --uri option in your command or site alias to indicate the correct URL of this site.
Deprecated: Required parameter $args follows optional parameter $command in /usr/local/drush9/vendor/drush/drush/includes/batch.inc on line 115
Deprecated: Required parameter $options follows optional parameter $command in /usr/local/drush9/vendor/drush/drush/includes/batch.inc on line 115
http://d9forcl57747.dev.acquia-sites.com/user/reset/1/1635526597/49RN0AE6RAINusSIxmSzRJgfoJmp3suVhdSFl2Vz2L0/login
The drush uli command works and returns the desired output even with the warnings. If these warnings block your development, remove the following segment from the yaml file:
paths:
drush-script: drush9
The current Drupal version is incompatible with certain Acquia Drush commands
Before the Acquia require line, add $_SERVER['PWD']=DRUPAL_ROOT;.
Save the settings.php file.
Drush aliases are downloaded only for active on-demand environments
Drush aliases for Cloud Platform CD environments are downloaded only if the environment is active.
Do not install Drush in your home directory
Installing Drush in your user directory can cause unexpected task failures. Acquia recommends that you require a site-local Drush as part of your codebase, not your home directory, and run your commands with a specific major version of Drush, as described in Using Drush on Cloud Platform.
An error message is displayed while running Drush 12 commands
Cloud Platform displays the following error message while running Drush 12 commands:
/bin/bash: /app/vendor/drush: No such file or directory
The Drush alias files that Cloud Platform generates are not compatible with Drush 12.
Cloud Platform CDN is not compatible with custom Varnish configurations
The Cloud Platform CDN does not support the use of custom Varnish configurations (custom VCLs) with Cloud Platform-hosted applications. Attempting to do so can cause Cloud Platform Enterprise to experience conflicting caching behavior.
The New Relic APM PHP extension is incompatible with Drupal 11.3 and later due to missing support for the Fibers PHP feature. Drupal 11.3 and later use Fibers to improve performance. Therefore, requests using Fibers are not displayed accurately in New Relic. Any sub-requests may not be traced, and transaction data may not be accurate.
Known issues with MySQL 5.7 to MySQL 8.0 upgrades
Before the platform database upgrade to MySQL 8.0, Acquia performs a series of automated pre-upgrade checks to identify any compatibility issues that can block or impact a successful upgrade. These checks scan Cloud Platform database clusters and individual databases for a range of potential issues, such as unsupported objects, deprecated features, or internal database artifacts left behind from previous upgrades or schema changes. Acquia's engineering team proactively resolves these incompatibilities where possible. For information about all the pre-check error descriptions, visit AWS Aurora MySQL.
A few common issues are:
Dangling FULLTEXT indexes or orphaned auxiliary columns
Unsupported storage engines
Invalid or deprecated data types
Tables with reserved keywords
Tables referencing removed features or system variables
I use the tx_isolation and tx_read_only variables in MySQL 5.7. Are these variables supported in MySQL 8.0?
No, the MySQL transaction variables, tx_isolation and tx_read_only are supported in MySQL 5.7 but are not supported in MySQL 8.0. Therefore, if you continue to use the legacy variables after you upgrade your application to MySQL 8.0, you might encounter the following errors:
Drupal might fail to connect to the database and log an error message. For example,
SQLSTATE[HY000]: General error: 1193 Unknown system variable 'tx_isolation'
If you use Drush to connect to Drupal, you might get different error messages based on your use case. For example,
SQLSTATE[HY000]: General error: 1193 Unknown system variable 'tx_isolation
or
Failed to connect to any database servers for database [DB UUID]
Workaround:
Replace the legacy variables, tx_isolation and tx_read_only with their aliases, transaction_isolation and transaction_read_only in your application code. These aliases are supported in MySQL 8.0 as well as MySQL 5.7. For example, if your settings.php file has the following:
SQL errors: This occurs because of deprecated or incompatible SQL syntax. For example, SQLSTATE[42000]: Syntax error or access violation: 1064.
Broken 404 pages: This occurs as the system displays blank pages and error messages because of missing files or inaccurate 404 pages.
Site instability: This causes unstable websites because of a large number of 404 errors. Such errors are caused by missing files, images, or bots, and can trigger memory use, "white screen of death" (WSOD), or inaccessible pages.
Performance degradation: This occurs because the site becomes non-responsive as 404s are not efficiently handled.
Inability to uninstall modules: After you upgrade to MySQL 8.0, you might not be able to update or uninstall this module correctly.
Workaround:
Uninstall or disable Fast 404 before upgrading to MySQL 8.0 and later.
Implement the code changes mentioned in the Fast 404 pages section in the Drupal core default.settings.php file.
Can I use certain reserved keywords in MySQL 8.0?
If your database or SQL queries use certain reserved keywords as unquoted column names, table names, or aliases, your code will fail in MySQL 8.0 with SQL syntax errors. For example:
RANK
SYSTEM
WINDOW
Such failures result in application features, deployments, or database migrations to break or become unavailable after the upgrade.
For example, the following SQL queries break in MySQL 8.0:
SELECT id, rank FROM mytable WHERE rank = 1;
SELECT * FROM system WHERE id = 1;
SELECT window FROM mytable;
Workaround: Use backticks (`) to quote reserved words:
SELECT id, `rank` FROM mytable WHERE `rank` = 1;
SELECT * FROM `system` WHERE id = 1;
SELECT `window` FROM mytable;
Solution:
Review the list of keywords new in MySQL 8.0 to identify any that may conflict with your existing database tables, columns, or aliases. For more information, visit MySQL 8.0 New Keywords and Reserved Words.
Audit your custom and contributed SQL queries, and your database schema, for use of these reserved words as unquoted identifiers.
Enclose these identifiers in backticks, or rename fields and tables to avoid reserved words.
Make these changes before upgrading to MySQL 8.0 to prevent SQL errors and application disruptions.
Can I use emojis or non-BMP Unicode in column comments with the UTF-8 character set in MySQL 8.0?
No. Before upgrading to MySQL 8.0, Cloud Platform checks for column comments that contain emojis or other non-BMP Unicode characters stored with the legacy UTF-8 character set, such as utf8mb3. If such characters are found, the system removes or replaces the comments so that the MySQL 8.0 upgrade does not block due to stricter character set validation. For more information visit Check for invalid utf8mb3 column comments.
Workaround:
Do one of the following:
Remove or replace all emojis and non-BMP Unicode characters from column comments before upgrading to MySQL 8.0.
Convert your table or column to use the utf8mb4 character set, which supports all Unicode characters.
Workaround:
If your application requires these extensions, ensure you are using a compatible combination of PHP version and Ubuntu operating system, or contact Acquia Support for guidance on alternative configurations.
Database backup fails when table definitions change
If a table structure in a database changes when a backup is in progress, the backup fails with an error similar to the following:
mysqldump: Error 1412: Table definition has changed, retry transaction when dumping table <table_name>
This failure typically occurs because application code or scheduled jobs, such as cron tasks to rebuild or alter tables, change the schema at runtime. This is an operational conflict rather than a platform defect. Cloud Platform requires a static schema snapshot to complete a backup.
Workaround:
Ensure that operations to change a schema do not overlap with the backup window:
Identify the source: Review application logs and custom cron jobs to identify processes that modify the specific table mentioned in the error.
Coordinate schedules: Access and adjust backup schedules in Cloud UI. Reschedule internal cron jobs or maintenance tasks so they do not run at the same time as database backups.
Acquia CLI (ACLI) not supported for MEO environments
ACLI does not support MEO environments. Commands that you run against MEO sites or environments can fail or result in unexpected behavior. Errors occur when you try to authenticate, list, or manage MEO applications and environments through ACLI. Use supported interfaces instead of ACLI to manage MEO environments.
Affected users: Customers who use MEO and try to manage those environments with ACLI must refer to supported interfaces.
Workaround:
Use Cloud Platform user interface and other supported tools to manage MEO environments instead of ACLI.
Do not use ACLI to provision, deploy to, or administer MEO environments.
Drupal 11.3.0 and later incompatibility with New Relic PHP agent
All versions of New Relic PHP agent are incompatible with Drupal 11.3.0 and later versions. Drupal 11.3.0 includes architectural changes to hook implementations that use PHP Fibers. When you run Drupal 11.3.0 or later, the New Relic PHP agent fails to collect
Application
Performance Monitoring (APM) data for certain Drupal transactions that use Fibers. Access to APM data in the New Relic UI remains unchanged, however, the data is incomplete.
New Relic confirmed this incompatibility and is working to develop a solution. Because of the complex architectural changes to support Fibers, New Relic estimates that support is available in early 2026.
Workaround:
To avoid issues with application monitoring or potential performance side effects, Acquia recommends that you complete one of the following:
Postpone the upgrade: Delay the upgrade of the application to Drupal 11.3.0 until New Relic releases a compatible version of the PHP agent.
Deactivate New Relic: To upgrade to Drupal 11.3.0 immediately, deactivate New Relic agent in Cloud Platform UI. To do this, delete the New Relic license key before the deployment. To upgrade to Drupal 11.3.0 before an updated agent is ready, deactivate New Relic on Cloud Platform. Acquia recommends it because the New Relic APM data is incomplete or inconsistent with actual use. To deactivate the agent, remove the New Relic license key through the UI.
Daily database backups on Cloud Platform might not trigger at the scheduled time. Database backups can run up to 12 hours later than the configured schedule. For example, a backup scheduled at 08:04 UTC might run at 20:00 UTC. This issue can occur across all environment types, such as Development, Staging, and Production.
The daily backup completes successfully, but at a different time than expected. This issue affects workflows that depend on backups that run in a specific time window, such as coordinated database restores or pre-deployment verification.
Workaround:
To create a backup at a specific time, use the Cloud Platform user interface to create an on-demand backup:
In the Databases section, click Back Up to manually trigger a database backup.
To ensure that a scheduled backup is complete, check the Activity log for the environment.
Duplicate SSH key
When users submit an SSH public key, Cloud Platform displays the following error message:
Error: Key already in use
The submitted SSH public key is already associated with another Cloud Platform user account. Acquia enforces key uniqueness across user accounts to maintain precise attribution and auditability of all SSH operations.
Workaround:
Generate and attach a unique SSH key pair to the account:
Create a new SSH public key pair with standard tools.
Log in to Cloud Platform, go to Account Settings > SSH Keys, and add the newly generated public key.
Delete the duplicate key from the account if necessary.
Update key references in local configurations such as ~/.ssh/config, CI/CD deployment pipelines, and custom deployment script.
When requesting the Acquia default domain, the subscriber’s self-service SSL certificate loads instead of the Acquia SSL certificate that covers the Acquia default domains. This behavior causes an SSL error in the browser. Install and activate two or more custom certificates on any affected environment to remove this error on the Acquia default domain.
Emergency-level logging broadcasts logged data to open SSH sessions
If a Drupal module logs information with the RFC 5424 severity of emergency, syslog broadcasts the information to open SSH sessions. These broadcasts can disrupt commands in progress, as indicated in the following example:
Subscribers upgrading their websites to newer versions of the current Drupal version, must rebuild website caches after the upgrading. Unexpected errors and problems with some page displays may occur until you rebuild caches.
Running update.php on the current Drupal version can display error messages
Attempting to run update.php on the current Drupal version fails with the following error message:
In order to run update.php you need to either be logged in as admin or have
set $settings['update_free_access']
Workaround:
Use one of the following methods:
Run drush updb to complete database updates.
Whenever you must run update.php, use your browser’s cookie manager to grab the session cookie from your current authenticated Drupal session, and then remove the leading S from the session name.
If you are running updates on your Dev or Stage environments, temporarily disable HTTPS while running updates.
Edit your settings.php file to temporarily set $settings['update_free_access'] to TRUE during your updates.
ADVANCED: Add the following code to your update.php file (directly following the use statements) to force Drupal to acknowledge the X-Forwarded-Proto value when determining if the request must be treated as HTTPS:
Altering the $databases array causes connection errors
Websites that alter the $databases array in settings.php to enable third-party database connections may experience connection errors when the connection setup is delayed in settings.php.
You cannot import a local website archive using the product interface
All Twig cache files for an environment are stored in a single directory
Clearing a website’s Twig caches clears the Twig caches for all websites hosted by that environment. For more information about how Cloud Platform stores Twig caches, visit Twig caches.
Resolution for Site Factory subscribers: Upgrade your installed version of the Site Factory Connector module to either version 8.x-1.59 and later, or version 8.x-2.59 or later (for Drush 9 support).
Websites running the current Drupal version can have theme change issues with Twig caches
When you change themes and perform a code deployment on Cloud Platform applications running the current Drupal version, you might experience issues where cached Twig templates fall out of sync on different web infrastructure. The problem arises from having separate copies of the compiled Twig templates on each web infrastructure and a related Drupal core issue.
Workaround:
When you make changes to themes in Cloud Platform Enterprise applications running the current Drupal version, connect to each web infrastructure, and run the following command to remove the outdated Twig templates:
drush @[sitename].[prod] --uri=http://[site_URL]/ ev '\Drupal\Core\PhpStorage\PhpStorageFactory::get("twig")->deleteAll();'
The AuthUserFile directive in .htaccess is not supported
The AuthUserFile directive in the Apache .htaccess file sets the name of a text file containing a list of users and passwords for user authentication. Cloud Platform does not support AuthUserFile, since its value must be either an absolute path or a path relative to the infrastructure root, and will not work across different Cloud Platform environments.
The SymLinksIfOwnerMatch option in .htaccess is not supported
Due to the configuration of directory ownership and permissions for your Cloud Platform application’s codebase and files directories, the SymLinksIfOwnerMatch option in your application’s .htaccess file prevents your web infrastructure from accessing any of the assets in your files directory. You must use the FollowSymLinks option instead.
Previous versions of Cloud Platform used LOGNAME differently
Do not use the LOGNAME environment variable to determine sitegroup or sitename in your .htaccess file or in other custom scripts.
Workaround:
Use the AH_SITE_NAME, AH_SITE_GROUP, or AH_SITE_ENVIRONMENTenvironment variables if you need environment-aware variables in your scripts.
Using mysqldump on MySQL 5.7 results in error
If you run mysqldump on MySQL 5.7, the following error occurs:
mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces
Workaround:
If you do not need to dump the tablespace information, invoke mysqldump with the –no-tablespaces option.
Issue with inactive load balancer when using log forwarding
When log forwarding is configured with a destination that includes an IP allowlist, the Cloud Platform user interface might display an error message for the inactive load balancer that indicates a connection issue or incorrect configuration. This occurs because the inactive load balancer uses a dynamic IP address until it becomes active. However, log forwarding from the primary or active load balancer functions correctly.
Issue with Fibers in Drupal 11.3 and later
The New Relic APM PHP extension is incompatible with Drupal 11.3 and later due to missing support for the Fibers PHP feature. Drupal 11.3 and later use Fibers to improve performance. Therefore, requests using Fibers are not displayed accurately in New Relic. Any sub-requests may not be traced, and transaction data may not be accurate.
Cloud Platform