If you reinstall Drupal 8, you end up seeing a Fatal Error due to a race condition in Twig.

More details on Drupal.org (https://www.drupal.org/node/2429659) but the solution for now is to install the patch in the queue (https://www.drupal.org/files/issues/race_conditions_in_the-2429659-30.patch)

The Pantheon API module will need to be updated to Drupal 8. Additionally, our Pantheon cron will need to be updated to enable said module using the appropriate D8 method (https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Extension!ModuleHandler.php/function/ModuleHandler%3A%3Ainstall/8).

The settings.php sets the active directory, but it doesn't exist (http://cl.ly/image/0I0Q3v1t302V). Since CMI no longer uses this, do we even need to set this?

It looks like the menu paths for things like a node form mode called "test" is formatted like this:
admin/structure/display-modes/form/manage/node.test

This triggers a 403 error because I'm guessing that the *.test file pattern is forbidden by nginx extension mappings.

DROPS-7 had support for Pressflow's Smart Start, but Drupal 8 seems to have similar functionality in bootstrap.php.

Do we need to maintain or expand this functionality?

In cases where the PRESSFLOW_SETTINGS value is present (i.e. Kalabox) and the $drupal_hash_salt value isn't present, there is an error:

Notice: Undefined variable: drupal_hash_salt in /code/sites/default/settings.php

Proposed resolution would be to more firmly wrap the setting of the hash salt value to also require that is actually running on Pantheon which sets that value.

The installation profile is not properly set resulting in a couple notices on admin pages and this reporting in the system status:

Installation profile (-)

This error pops up before install.php is run:

PHP Fatal error: Call to a member function get() on a non-object in /srv/bindings/47a2c7752c4a4093958ddf323893d629/code/core/lib/Drupal.php on line 231

Presumably because we are running cron.php and it can't find the config. From Drupal.php line 231:

public static function config($name) {
return static::$container->get('config.factory')->get($name);
}

The latest Alpha 12 introduces the rebuild message for all new D8 sites:

"If you have just changed code (for example deployed a new module or moved an existing one) read http://drupal.org/documentation/rebuild"

How do I add services.yml file under default folder? I am trying to deploy that file using phpStorm but I am getting permission denied.

Help Drupal 7 folks who are used to the old path.

There is logic in drupal_get_filename() which tries to see if the "standard" install profile is available. However, when the module list is created the "standard" value doesnt show up so the drupal_get_filename() check fails. This causes an error on the status report page and is part of a larger problem that breaks CM operations with this error:

The configuration cannot be imported because it failed validation for the following reasons:
Unable to install the standard module since it does not exist.

There is currently a problem between you clone the database between environments where a /srv/binding path is hardcoded into bootstrap_config and key_value which creates an error until the cache is clear (which doesnt seem to happen automagically).

Drupal 7 uses an explicit version value in includes/bootstrap.inc to define what version it reports to the Update Manager.

Drupal 8 takes the "version" value in the first installed Drupal core module which in the standard install profile is Block.

There are a few core issues which may help solve this. https://www.drupal.org/node/2082931 is probably the most likely candidate.

Drupal 8 Beta 9 will fail during installation with an error like this:

Drupal\Core\Config\PreExistingConfigException: Configuration objects (system.cron, system.theme) provided by standard already exist in active configuration in Drupal\Core\Config\PreExistingConfigException::create() (line 70 of core/lib/Drupal/Core/Config/PreExistingConfigException.php).

If you manually go to core/install.php on an installed Drupal 8 site, you will see the following warning message:

Drupal already installed
To start over, you must empty your existing database and 
copy default.settings.php over settings.php.

It is easy to empty your database with terminus site wipe --site=xyzzy --env=dev, and in fact this is all that is necessary to re-install on Pantheon.

Unfortunately, if you copy your default.settings.php over your settings.php as the re-install instructions suggest, then you will delete the necessary include of settings.pantheon.php, which will break your Drupal 8 site.

We do not need to deal with this if we successfully replace settings.pantheon.php with injected variables per #56.

Why not remove the Drupal core history from DROPS-8? Very few developers, if any, actually access this history on their local site (versus on Drupal.org) and it slows down all sorts of operations since there is a lot of Drupal history.

There is logic in Drupal 8's _drupal_bootstrap_configuration() which will redirect a user to the install.php file if Drupal is not currently installed. The code looks like this:

if (empty($GLOBALS['databases']) && !drupal_installation_attempted()) {
include_once DIR . '/install.inc';
install_goto('core/install.php');
}

The problem is that we inject $GLOBALS['databases'] for all environments (regardless of if Drupal has been installed) which causes this goto logic to fail.

As of f3791f, there are some files in drops-8 that do not exist in Drupal 8 beta 15.

For example,
core/lib/Drupal/Core/ContentNegotiation.php exists in drops-8, but does not exist in beta 15.

Below I checkout beta15 from drupal.org, remove the core directory, replace it with the core directory from drops-8, and see the diffs with a git status.

jim@t5:~/repos/drupal$ git status
HEAD detached at 8.0.0-beta15
nothing to commit, working directory clean
jim@t5:~/repos/drupal$ rm -rf core/
jim@t5:~/repos/drupal$ cp -r ../drops-8/core .
jim@t5:~/repos/drupal$ git status
HEAD detached at 8.0.0-beta15
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   core/core.api.php

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        core/lib/Drupal/Core/ContentNegotiation.php
        core/lib/Drupal/Core/Database/Install/TaskException.php
        core/misc/feed.png
        core/misc/icons/ea2800/
        core/modules/locale/migration_templates/d6_locale_settings.yml
        core/modules/locale/src/Tests/Migrate/d6/
        core/modules/menu_link_content/src/Plugin/migrate/source/d6/
        core/modules/menu_link_content/tests/src/Unit/Plugin/migrate/source/d6/
        core/modules/menu_ui/migration_templates/d6_menu_settings.yml
        core/modules/menu_ui/src/Tests/Migrate/d6/
        core/modules/migrate/config/schema/migrate.load.schema.yml
        core/modules/migrate/src/MigratePassword.php
        core/modules/migrate/src/MigrateServiceProvider.php
        core/modules/migrate/src/Plugin/SourceEntityInterface.php
        core/modules/migrate/src/Plugin/migrate/destination/EntityComment.php
        core/modules/migrate/src/Plugin/migrate/destination/EntityCommentType.php
        core/modules/migrate/src/Plugin/migrate/destination/EntityDateFormat.php
        core/modules/migrate/src/Plugin/migrate/destination/EntityFile.php
        core/modules/migrate/src/Plugin/migrate/destination/EntityNodeType.php
        core/modules/migrate/src/Plugin/migrate/destination/EntityUser.php
        core/modules/migrate/src/Plugin/migrate/destination/UserData.php
        core/modules/migrate/src/Tests/EntityFileTest.php
        core/modules/migrate/tests/src/Unit/process/MigrationTest.php
        core/modules/migrate_drupal/migration_templates/
        core/modules/migrate_drupal/src/Entity/
        core/modules/migrate_drupal/src/MigrationStorage.php
        core/modules/migrate_drupal/src/Plugin/CckFieldMigrateSourceInterface.php
        core/modules/migrate_drupal/src/Plugin/MigrateLoadInterface.php
        core/modules/migrate_drupal/src/Plugin/migrate/cckfield/FileField.php
        core/modules/migrate_drupal/src/Plugin/migrate/cckfield/LinkField.php
        core/modules/migrate_drupal/src/Plugin/migrate/cckfield/TextField.php
        core/modules/migrate_drupal/src/Plugin/migrate/load/
        core/modules/migrate_drupal/src/Plugin/migrate/process/
        core/modules/migrate_drupal/src/Plugin/migrate/source/d6/
        core/modules/migrate_drupal/src/Tests/d6/MigrateCckFieldRevisionTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateCckFieldValuesTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateCommentTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateCommentTypeTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateCommentVariableDisplayBase.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateCommentVariableEntityDisplayTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateCommentVariableEntityFormDisplaySubjectTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateCommentVariableEntityFormDisplayTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateCommentVariableFieldTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateCommentVariableInstanceTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateFieldFormatterSettingsTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateFieldInstanceTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateFieldTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateFieldWidgetSettingsTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateFileConfigsTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateFileTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUploadBase.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUploadEntityDisplayTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUploadEntityFormDisplayTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUploadFieldTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUploadInstanceTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUploadTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserConfigsTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserContactSettingsTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserPictureEntityDisplayTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserPictureEntityFormDisplayTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserPictureFieldTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserPictureFileTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserPictureInstanceTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserProfileEntityDisplayTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserProfileEntityFormDisplayTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserProfileFieldInstanceTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserProfileFieldTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserProfileValuesTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserRoleTest.php
        core/modules/migrate_drupal/src/Tests/d6/MigrateUserTest.php
        core/modules/migrate_drupal/tests/src/Unit/MigrationStorageTest.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/CommentSourceWithHighWaterTest.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/CommentTest.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/CommentTestBase.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/FieldInstancePerViewModeTest.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/FieldInstanceTest.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/FieldTest.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/FileTest.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/ProfileFieldTest.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/RoleTest.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/TestComment.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/TestNode.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/TestNodeRevision.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/TestTerm.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/UserPictureTest.php
        core/modules/migrate_drupal/tests/src/Unit/source/d6/UserTest.php
        core/modules/search/src/Tests/Migrate/d6/MigrateSearchConfigsTest.php
        core/modules/system/css/system.module.css
        core/modules/system/css/system.theme.css
        core/modules/system/migration_templates/d6_menu.yml
        core/modules/system/src/FileAjaxForm.php
        core/modules/system/src/Plugin/migrate/source/d6/
        core/modules/system/src/Tests/Extension/InfoParserUnitTest.php
        core/modules/system/src/Tests/Extension/ModuleHandlerTest.php
        core/modules/system/src/Tests/Migrate/d6/MigrateMenuTest.php
        core/modules/system/src/Tests/PhpStorage/
        core/modules/system/tests/fixtures/broken.info.txt
        core/modules/system/tests/fixtures/common_test.info.txt
        core/modules/system/tests/fixtures/missing_key.info.txt
        core/modules/system/tests/fixtures/missing_keys.info.txt
        core/modules/system/tests/src/Unit/Migrate/
        core/modules/taxonomy/src/Plugin/migrate/load/
        core/modules/text/migration_templates/d6_text_settings.yml
        core/modules/text/src/Tests/Migrate/d6/
        core/modules/user/src/Tests/Views/UserUnitTestBase.php
        core/modules/views/src/Tests/Handler/FieldUnitTest.php
        core/modules/views/src/Tests/Plugin/DisplayUnitTest.php
        core/modules/views/src/Tests/Plugin/PluginUnitTestBase.php
        core/modules/views/src/Tests/ViewUnitTestBase.php
        core/modules/views/src/Tests/Wizard/WizardPluginBaseUnitTest.php
        core/tests/Drupal/Tests/Core/ContentNegotiationTest.php
        core/tests/Drupal/Tests/Standards/
        core/themes/bartik/css/components/admin.css
        core/themes/bartik/css/components/content.css
        core/themes/bartik/css/components/region-help.css
        core/themes/bartik/css/components/tips.css
        core/themes/bartik/css/components/user.css

no changes added to commit (use "git add" and/or "git commit -a")

Similar to #4, there seems to be confusion with the path during Drupal installation. Even with the workaround in #4, users are still directed to a broken URI:

http://dev-drupal-8-alpha-3-vi.gotpantheon.com/core/install.php/

My guess is the root cause is the same with #4, probably something to do with the redirection happening between install_settings_form() and install_profile_modules() during installation.

It wouldn't surprise me if this is some weird interaction with the batch processing, pantheon's php setup, and symphony routing magic.

Hi, I've been trying the Pantheon Drupal 8 beta out and attempted to configure the use of Private files.

I've added the following line to settings.pantheon.php
$settings['file_private_path'] = 'sites/default/files/private';

I've created the private folder via SFTP.

The private file system path is recognised on /admin/config/media/file-system, but I cannot select Private as the default download method (the option is not there).

I get the following error message on various pages, but seems to be consistently at /admin/config which seems to be saying the the .htaccess file cannot be created. This is regardless of the permissions on the private folder that I can set via SFTP.

Warning: file_exists(): Unable to find the wrapper "private" - did you forget to enable it when you configured PHP? in file_save_htaccess() (line 363 of core/includes/file.inc).
file_save_htaccess('private://', 1)
file_ensure_htaccess()
system_requirements('runtime')
call_user_func_array('system_requirements', Array)
Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array)
Drupal\system\SystemManager->listRequirements()
Drupal\system\SystemManager->checkRequirements()
Drupal\system\Controller\SystemController->overview('system.admin_config')
call_user_func_array(Array, Array)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1)
Stack\StackedHttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)

It would be really good if the private file system worked out of the box as it does on the Pantheon Drupal 7 install.

Pantheon is running Drush 5 internally so even if you are running Drush 7 locally, you will get this error if you try to do Drush things to a Drupal 8 site:

Drush 5.10.0 does not support Drupal . Use Drush 4 instead. [error]
Unknown option: --db-url. See drush help core-status for available [error]
options. To suppress this error, add the option --strict=0.

Getting this trying to install Drupal 8 with beta10

Warning: file_put_contents(/srv/bindings/c4d5b76556834511adc9eabdd3fc78b7/code/sites/default/settings.php): failed to open stream: Permission denied in drupal_rewrite_settings() (line 319 of core/includes/install.inc).
drupal_rewrite_settings(Array)
install_write_profile(Array)
install_run_task(Array, Array)
install_run_tasks(Array)
install_drupal(Object)
Exception: Failed to modify <em class="placeholder">sites/default/settings.php</em>. Verify the file permissions. in drupal_rewrite_settings() (line 320 of core/includes/install.inc).
drupal_rewrite_settings(Array)
install_write_profile(Array)
install_run_task(Array, Array)
install_run_tasks(Array)
install_drupal(Object)

Install stops there

Drupal 8 currently requires a writeable settings.php to pass the install_verify_requirements() check even though it doesnt actually have to write anything when #8 and #2 are done.

I'm getting the error, "The directory sites/default/config is not writable." So, I can't get D8 installed on Pantheon at present.

Since the syntax for cache clearing changed from "drush cc all" to "drush cache-rebuild", the Pantheon backend will need to be updated to use the new syntax when the "Clear Caches" button is pushed.

For now, you can still call cache clear from your own command line version of Drush or through the Drupal UI.

This issue on Drupal.org (https://drupal.org/node/1858196) may be causing this installation error:

Symfony\Component\DependencyInjection\Exception\InvalidArgumentException: The service definition "field.info" does not exist. in Symfony\Component\DependencyInjection\ContainerBuilder->getDefinition() (line 873 of core/vendor/symfony/dependency-injection/Symfony/Component/DependencyInjection/ContainerBuilder.php).

Currently blocking installation of D8 on Pantheon.

I'm trying to configure my pantheon dev to accept CORS Request, Drupal 8 don't accept this by default in core until 8.1 according to Dries https://www.drupal.org/node/1869548#comment-9365043

So I did some changes in .htaccess

# Intercept OPTIONS calls
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule .* / [R=200,L]

and

<IfModule mod_headers.c>
  Header always set Access-Control-Allow-Origin "*"
  Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, PATCH, DELETE"
  Header always set Access-Control-Allow-Headers: Authorization
</IfModule>

These options works in other environments but in Pantheon the changes are not working.

Any suggestions?

Notice: Undefined index: name in system_requirements() (line 45 of core/modules/system/system.install).
system_requirements('runtime')
call_user_func_array('system_requirements', Array)
Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array)
Drupal\system\SystemManager->listRequirements()
Drupal\system\Controller\SystemInfoController->status()

Also happens on the Configuration page, perhaps elsewhere as well.

Does not happen on a stock Drupal-8 site. Does not seem to cause any adverse effects, beyond the appearance of the notice itself.

Fatal error: Call to undefined function install_display_output() in /core/includes/errors.inc on line 240 after accepting #51.

We have a nice .gitignore for DROPS-7 (https://github.com/pantheon-systems/drops-7/blob/master/.gitignore) which can be included in DROPS-8 with whatever updates.

This hopefully will fix an issue where a symlink for sites/default/files is created which prevents code from being deployed to other environments.

Out of 4 install attempts, I've got one success. During installation, sometimes get error:

Additional uncaught exception thrown while handling exception.

Original

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "user_role" entity type does not exist. in Drupal\Core\Entity\EntityManager->getDefinition() (line 199 of /srv/bindings/54fb337c7aed447994968d7f496eb4c8/code/core/lib/Drupal/Core/Entity/EntityManager.php).

Drupal\Core\Entity\EntityManager->getDefinition('user_role')
Drupal\Core\Entity\EntityManager->getController('user_role', 'storage', 'getStorageClass')
Drupal\Core\Entity\EntityManager->getStorage('user_role')
Drupal\Core\Session\UserSession->hasPermission('access administration pages')
Drupal\Core\Session\AccountProxy->hasPermission('access administration pages')
user_template_preprocess_default_variables_alter(Array, NULL, NULL)
Drupal\Core\Extension\ModuleHandler->alter('template_preprocess_default_variables', Array)
_template_preprocess_default_variables()
template_preprocess(Array, 'install_page', Array)
_theme('install_page', Array)
drupal_render(Array)
Drupal\Core\Page\DefaultHtmlPageRenderer::renderPage(Array, 'Choose language', 'install', Array)
install_display_output(Array, Array)
install_drupal()
Additional

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "user_role" entity type does not exist. in Drupal\Core\Entity\EntityManager->getDefinition() (line 199 of /srv/bindings/54fb337c7aed447994968d7f496eb4c8/code/core/lib/Drupal/Core/Entity/EntityManager.php).

Drupal\Core\Entity\EntityManager->getDefinition('user_role')
Drupal\Core\Entity\EntityManager->getController('user_role', 'storage', 'getStorageClass')
Drupal\Core\Entity\EntityManager->getStorage('user_role')
Drupal\Core\Session\UserSession->hasPermission('access administration pages')
Drupal\Core\Session\AccountProxy->hasPermission('access administration pages')
user_template_preprocess_default_variables_alter(Array, NULL, NULL)
Drupal\Core\Extension\ModuleHandler->alter('template_preprocess_default_variables', Array)
_template_preprocess_default_variables()
template_preprocess(Array, 'install_page', Array)
_theme('install_page', Array)
drupal_render(Array)
Drupal\Core\Page\DefaultHtmlPageRenderer::renderPage(Array, 'Error', 'install', Array)
install_display_output(Array, Array)
_drupal_log_error(Array, 1)
_drupal_exception_handler(Object)

On the website it shows up as:

If you have just changed code (for example deployed a new module or moved an existing one) read http://drupal.org/documentation/rebuild

It seems like PHP syntax / fatal PHP errors don't show up in any Apache, Nginx, or FPM, logs nor watchdog logs.

I'm trying the Drupal 8 drop on Pantheon, and installed the Prepopulate module (9b5b27b). That module currently has a bug that causes forms that have pre-populated forms to blow up on submit (specifically, node edit forms). The error that PHP actually throws is "Fatal error: [] operator not supported for strings" (https://www.drupal.org/node/2499991), but the only way to find this out was to copy the site locally and use Acquia Dev Desktop.

Nothing in the Pantheon platform was able to provide the error message -- we were just getting a WSOD. We tried turning up the error level, using the Devel module with error handling, etc. This was in the "Dev" environment on Pantheon, too.

I even turned on New Relic support but the errors did not get reported back to New Relic.

Surely there must be a way to get the platform to log these errors somewhere or show them on the page, no?

On Dev Desktop the error showed up on-page immediately, so is it possible that Pantheon has show errors set to FALSE on the server?

D8 Installer says:
"The directory sites/default/config is not writable. An automated attempt to create this directory failed, possibly due to a permissions problem. To proceed with the installation, either create the directory and modify its permissions manually or ensure that the installer has the permissions to create it automatically. For more information, see INSTALL.txt or the online handbook."
Any idea?

I am trying to import a Configuration Manager tar-ball, but I get this message:

Could not extract the contents of the tar file. The error message is Error while opening {./sites/default/config/block.block.classy_admin.yml} in write binary mode

I have tried both a config tar-ball from your server and one from a local Drupal instance clone and neither work. Also, I’ve successfully imported the config from pantheon server into local.

To reproduce:

1. Enable Configuration Manager
2. Go to /admin/config/development/configuration/full/export
3. “Export” config.tar.gz
4. Go to /admin/config/development/configuration/full/import
5. “Choose File” and select the config.tar.gz that was downloaded
6. Click “Upload”
7. Get Error message

Unlike the installation process for Drupal 7, Drupal 8 requires (on behalf of CMI) that the values for the configuration directories be available to settings.php. This is typically written during installation and look like this:

$config_directories['active']['path'] = 'config_1-lRVHZQPcBvES1GZkcB4OMzcH9qHNiqTxhEj706e3U/active';
$config_directories['staging']['path'] = 'config_1-lRVHZQPcBvES1GZkcB4OMzcH9qHNiqTxhEj706e3U/staging';

Since we want to skip this step all together, we will need to figure out how to modify this write/read behavior so that Pantheon can define the $config_directories values in the same way we currently do for the $databases.

Seems more like a support thing but this is what I get when I try to use Drush 7 with our D8 install.

xxxxxxxxxxxxxxxxxx#: d7 @C8.dev cex
Drush 5.10.0 does not support Drupal . Use Drush 4 instead.              [error]

Fatal error: Class 'Drupal' not found in /srv/bindings/7f516237c15e4b4ea38f27e9daff4bf5/code/core/includes/bootstrap.inc on line 178
Ok
Drush command terminated abnormally due to an unrecoverable error.       [error]
Error: Class 'Drupal' not found in
/srv/bindings/7f516237c15e4b4ea38f27e9daff4bf5/code/core/includes/bootstrap.inc,
line 178

There seems to be a problem with POST operations. If you are using the Overlay module you get this error:

Blocked a frame with origin "http://dev-drupal-8-alpha-3-iii.gotpantheon.com" from accessing a frame with origin "null". The frame requesting access has a protocol of "http", the frame being accessed has a protocol of "data". Protocols must match.
overlay-parent.js?v=1.0:277
Drupal.overlay.loadChild overlay-parent.js?v=1.0:277
proxy jquery.js?v=2.0.3:731
jQuery.event.dispatch jquery.js?v=2.0.3:4676
elemData.handle

If you are not using Overlay, you get redirected to the internal port:

http://dev-drupal-8-alpha-3-iii.gotpantheon.com:12318/node/4

Likely related to issue #4

As per usual, DROPS will need to override drupal_settings_initialize() to allow us to inject our database values directly.

-- Define $databases in a cleaner way with checking to see if it is already set
-- Do not use the $$ global variable override. Iterate through known global variables.

D8 rolls with a .gitignore file - https://www.drupal.org/node/1170538. It should be reviewed to see if it breaks the experience of using D8 on Pantheon.

I'm consistently receiving this error. The first time was several months ago. But I'm still seeing it today. I mentioned this in passing in #21 in my most recent update.

Allowed memory size of 268435456 bytes exhausted (tried to allocate 265027628 bytes)core/lib/Drupal/Core/Render/BareHtmlPageRenderer.php:70

Drupal 8 periodically writes the following warning:

Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your sites/default/files/config/active directory which contains the following lines

(file contents omitted)

Of course, .htaccess is not relevant on Pantheon, and we already have this location blocked in nginx. However, we should get this message out of the "Recent Log Messages", either by adding an .htaccess file there ourselves, or perhaps by removing this configuration location (I think that Drupal 8 recently removed the "active" store).

I just created a Drupal 8 beta site (5e178f5e-36bb-4f96-9b29-02bc72598cd8). I added a custom install profile to the repo and am attempting to re-install with that profile. During install I get the following errors:

Warning: file_put_contents(/srv/bindings/dc5d5b0332b24f779b180a2ea275c7db/code/sites/default/settings.php): failed to open stream: Permission denied in drupal_rewrite_settings() (line 318 of core/includes/install.inc).

drupal_rewrite_settings(Array)
install_write_profile(Array)
install_run_task(Array, Array)
install_run_tasks(Array)
install_drupal(Object)

Exception: Failed to modify <em class="placeholder">sites/default/settings.php</em>. Verify the file permissions. in drupal_rewrite_settings() (line 319 of core/includes/install.inc).

drupal_rewrite_settings(Array)
install_write_profile(Array)
install_run_task(Array, Array)
install_run_tasks(Array)
install_drupal(Object)

There is an error during Drupal 8 installation where the internal port that Pantheon uses is exposed to the end user through sort of redirect logic. This pushes users to links that look like:

http://dev-drupal-8-alpha-3-iii.gotpantheon.com:12318/core/install.php/

We will need to figure out where/when Drupal 8 gets this value and address it appropriately.

default.settings.php contains this example:

/**
 * Load services definition file.
 */
$settings['container_yamls'][] = __DIR__ . '/services.yml';

We need to add this to settings.php or settings.pantheon.php; the question is, which one?

Most sites will probably keep this in the default location. It seems unlikely that Pantheon will ever want to change this value for a customer (further down the road), so I'd guess that it would be more convenient to put it in settings.php.

The distinction is minor, though.

This is currently a problem:

RuntimeException: Missing $settings['hash_salt'] in settings.php. in drupal_get_hash_salt() (line 1514 of core/includes/bootstrap.inc).

This was working on beta-2, but when I went to install beta-3, selecting Spanish or any other language than English resulted in a redirect loop. I can locally install beta-3, so this must be issue on the pantheon environment.

Before RC we need to make a few cleanups to settings.php:

-- Use $_ENV['PANTHEON_ENVIRONMENT'] as a check for Pantheon
-- Make sure to use proper $drupal_hash_salt value from $_ENV['drupal_hash_salt']
-- Review development.services.yml handling in settings.php
-- Move logic to pantheon.settings.php and include it from settings.php