Hello Everyone at LCM,

I think your template looks fantastic and ticks all the boxes for a "dream" build system for Drupal 8. But I am having trouble getting things up and running. This is the process I am following… But in the end I cannot access anything on http://localhost/8080. Can you see what I am missing?

These are the steps I have taken to try and get up and running with the scaffold.

composer create-project lastcall/drupal-scaffold PROJECTNAME

Move into the project root

cd PROJECTNAME

I don't have nvm installed so I updated my version of npm with:

npm install npm@latest -g

Install nodejs dependencies

npm install

Install bower and composer dependencies

gulp install

Edited the composer.json, package.json, and bower.json and rename the project as needed.

Renamed the scaffold theme to match my project (including JS and SCSS files).

Edited the project readme.md.

Initialize a new git repository and push work to it as normal

git init && git add . && git commit

Create a repo on github and push to origin...

Everything to this point is smooth.

With all the peices in place I think the next step is to get Drupal installed with a database.

If I were using drupal-composer/drupal-scaffold and I would run:

drupal site:install standard --langcode="en" \
--db-type="mysql" --db-host="127.0.0.1" \
--db-name="databasename" --db-user="root" \
--db-pass="root-user-password" --db-port="3306" \
--site-name="Site Name" \
--site-mail="[email protected]" \
--account-name="admin" \
--account-mail="[email protected]" \
--account-pass="admin" \
--no-interaction

But I would like to use Docker and follow your repos build philosophy. So I ran:

docker-compose -f docker-compose.yml -f docker-compose.debug.yml up

I thought this would create a Docker container and a database and install Drupal and give me access to it at:

• Varnish: You can still access the site behind varnish as you would with only the default config at http://localhost:8080
• Drupal: You can directly access the Drupal site, bypassing the reverse proxy at http://localhost:8081
• MySQL: You can make a direct connection from the command line using mysql -h 127.0.0.1 --port 33306 -u drupal -pdrupal drupal

However, when I go to http://localhost:8080 I get a "You don't have permission to access / on this server." with this kind of feedback from the console:

drupal_1   | 172.18.0.5 - - [03/Mar/2017:00:06:39 +0000] "GET / HTTP/1.1" 403 447 "-" "Mozilla/5.0 (Macintosh; Intel Mac O
S X 10_12_3) AppleWebKit/602.4.8 (KHTML, like Gecko) Version/10.0.3 Safari/602.4.8"
drupal_1   | 172.18.0.5 - - [03/Mar/2017:00:18:42 +0000] "GET / HTTP/1.1" 403 447 "-" "Mozilla/5.0 (Macintosh; Intel Mac O
S X 10_12_3) AppleWebKit/602.4.8 (KHTML, like Gecko) Version/10.0.3 Safari/602.4.8"
drupal_1   | [Fri Mar 03 00:18:42.082713 2017] [autoindex:error] [pid 16] [client 172.18.0.5:52858] AH01276: Cannot serve
directory /var/www/html/: No matching DirectoryIndex (index.php,index.html) found, and server-generated directory index fo
rbidden by Options directive

Obvisously, I am missing a step...

BTW, I can access a database named drupal at: mysql -h 127.0.0.1 --port 33306 but there are no tables in it, So I guess Docker is not actually installing Drupal?

I have worked with just about every aspect of this build environement except for Docker...

Can you see what is missing in my attempt to get Drupal up and running and served in a Docker container using your template?

Thanks very much for your help,
Stephen

Core puts config in sites/default/files/config{RANDOM_DIRNAME} by default, which is typically ignored by git. We should set the location to some place that's not .gitignored.

I typically end up moving it to a config directory at the project root, like Pantheon outlines here.

See #56 (comment)

Just like how we're handling the backstop testing. This is the only piece left that requires phantomjs, which is a huge binary.

The "Skip to main content" link should have some very basic styling applied to it by default. Nothing fancy, just something so it doesn't push the content around when it's focused.

It would be awesome to leverage ES6 in our javascript, and have something like browserify or webpack handle our requires or imports for us. This would make it a lot easier to build a lean javascript file that only includes the parts of foundation we actually use, for example.

I don't think we're quite ready to do this yet, but we should start investigating it.

See #56 (comment)

As it is this method grabs the database, but it leaves out all the image assets (and whatnot) referenced by the site.

For testing custom modules

There was some preliminary work done for this in #67 and #101, but there have been some changes on the Lando end, and we are shifting gears to adopt it as the sole local development infrastructure for the scaffold going forward, and a new issue helps reflect that.

Work for this is being done on the lando branch. There is a TODO.md file that outlines work still to be done, but for tracking purposes here are the pieces that I think are still remaining.

TODO

• BLACKFIRE: Enable Blackfire in Lando (see this issue and this gist)
  • Update Blackfire docs in docs/tools/blackfire.md
• WDIO:
  • Disable, remove WDIO configuration
  • Documentation at docs/tools/wdio.md
• MANNEQUIN:
  • Add mannequin service to Lando config
  • Update Mannequin docs at docs/tools/mannequin.md
• VARNISH:
  • Determine if we still want a varnish service
  • If yes:
    • add varnish service to .lando.yml
  • If no:
    • Remove docker/default.vcl, docs in docs/tools/varnish.md
• DOCKER-COMPOSE: Since we're switching from docker-compose to lando it would be confusing to leave the docker-compose functionality in here, documented or not. We should remove config and references to the old docker-compose local infrastructure
  • Remove docker-compose.yml
  • Remove docker directory
• LOCAL DEVELOPMENT TOOLS:
  • Determine if we need the site-import tooling in appserver
  • If yes:
    • Add terminus commands and scripts for importing a database
    • Add acquia API commands for importing databases

Add more items for common use cases and code that can be repurposed to write additional tests.

Right now we're not adding any classes to things like nodes and views. It's helpful to have some basic top level classes for styling purposes. I see these being added through preprocess functions in scaffold.theme.

ex:

/**
 * Implements hook_preprocess_node().
 */
function scaffold_preprocess_node(&$vars) {
  $vars['attributes']['class'][] = 'node-type-' . $vars['node']->bundle();
}

Here's a starting place for things that would be great to have classes on (feel free to add others that'd be useful):

Nodes

• Bundle: node-type-{bundle}
• Status: status-{status}
• View Mode: view-mode-{view_mode}

Views

• View ID: view-{view_id}
• Views Display: view-display-{view_display}

Field

• Field Name: field-name-{field_name}

Any gulp tasks that require a web server should probably either fail with an explanation if the server isn't started, or actually start the server themselves. Implementation TBD.

One example would be Rick's Paragraphs template in LastCallMedia/Mannequin#93, but I don't think we want to use Paragraphs as an example here, since it doesn't come installed out of the box. So we could use:

• field.html.twig
• block.html.twig
• page.html.twig
• etc.

It would be nice if the setup instructions for this project didn't include both a composer install and a yarn install. We could hook into the post-install-cmd event to trigger a yarn/npm install if the appropriate binary is detected and we're also installing dev dependencies. This would cut a step to the install process and make sure people's npm dependencies are kept up to date.

Can't believe we don't have a pantheon.yml in this repository. Anyway, let's add some Quicksilver hooks to handle updb, and optionally, config import on deployments. I think it'd be great to just have a single script (deploy_code.php) that handles both, and gets called anytime you'd want those things to happen (clone_database, sync_code, deploy). This is a best practice, and helps ensure the deployment process is consistent.

.prose is sometimes handy to be able to style user entered long form text a different way from the global styles.

https://yarnpkg.com/

We should add these to the example settings.local.php file:

$settings['rebuild_access'] = TRUE;
$settings['skip_permissions_hardening'] = TRUE;

In particular, skipping permissions hardening will prevent us from needing to deal with a lot of permissions issues in local development.

gulp-phplint has a new release. We should update to it.

Settings.php is kind of tough to grok. I don't think we need all of the comments and commented out settings in there for one... it makes the important bits much harder to find, and I think we can assume anyone using a Composer build of Drupal already has an idea of what they want in settings.php.

Second, it tends to become a rats-nest of conditional overrides, mainly based around these dimensions:

• Hosting platform (Docker, Pantheon, Acquia)
• Environment (Local, Dev, Test, Prod)
• Request (HTTP/HTTPS redirects, etc).

@bbenjamin is going to be working on a system to abstract the detection logic and make it more understandable, but we're still going to need a way to apply overrides based on what gets detected. @jlandfried mentioned that he really liked Deeson's approach (https://github.com/teamdeeson/cdd-demo/tree/master/src/settings) of splitting the overrides into separate files, and I tend to agree, although I think it should probably be split based on the dimensions we've defined above rather than individual features as they've done.

The lines I want to draw around this are:

• Production requests should be as fast as possible - file_exists checks should not happen in the production environment if we can possibly avoid it.
• I don't want to actually add settings.*.php for every possible permutation - only the ones we're going to provide support for out of the box (eg: Docker and Pantheon, prod and dev).

Pantheon uses CACHE_HOST, CACHE_PORT, CACHE_PASSWORD environment variables in settings.php to indicate redis configuration. We should change our Docker environments to match these variables, and move any redis settings out of settings.docker.php and into the main settings.php.

Rough specs:

As a developer, I should be able to define a test that checks for visual differences on key pages.
As a developer, I should be able to commit a reference snapshot to the repository of each key page that is expected to match.
When gulp test:css is run, I should see a failure if the current snapshot does not match the reference snapshot.

From https://github.com/pantheon-systems/drops-8/blob/master/sites/default/settings.pantheon.php

Should run composer validate and be included in gulp check.

I have this running on my local just fine. I tried to push this to a Pantheon instance and I'm receving this error:

`Warning: require(/var/www/web/../vendor/autoload.php): failed to open stream: No such file or directory in /var/www/web/autoload.php on line 17

Fatal error: require(): Failed opening required '/var/www/web/../vendor/autoload.php' (include_path='.:/usr/local/lib/php') in /var/www/web/autoload.php on line 17`

We're currently only pulling in Foundation. I can't think of a compelling reason to stick with Bower over NPM here, and it means one less dependency.

Dependabot can't resolve your PHP dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

The "https://packages.drupal.org/8/packages.json" file could not be downloaded (HTTP/1.1 502 Gateway Error)

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

Hi there, I have been developing with Drupal-Scaffold for a couple of months now and installed several modules by composer all with no problem.

I did run composer update recently (I should have specified what to update but I didn't so...) anyway I am getting this message now when I try to install a module...

$ composer require drupal/geshifilter
Using version ^1.1 for drupal/geshifilter
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - drupal/console 1.0.0-rc15 requires drupal/console-core 1.0.0-rc15 -> satisfiable by drupal/console-core[1.0.0-rc15].
    - drupal/console 1.0.0-rc15 requires drupal/console-core 1.0.0-rc15 -> satisfiable by drupal/console-core[1.0.0-rc15].
    - drupal/console 1.0.0-rc15 requires drupal/console-core 1.0.0-rc15 -> satisfiable by drupal/console-core[1.0.0-rc15].
    - Removal request for drupal/console-core == 1.0.0.0-RC15
    - Installation request for drupal/console 1.0.0-rc15 -> satisfiable by drupal/console[1.0.0-rc15].


Installation failed, reverting ./composer.json to its original content.

I can read this feedback but I don't know what to do about it... Can anyone explain what actions I can take to get past this...

I know this is a composer issue but maybe it has something to do with the configuration of the Drupal-Scaffold... So, if anyone recognizes the problem and can help me out it would be much appreciated...

Thanks

Right now out of the box there's no styling for basic form validation elements, it'd be nice to not have to start from scratch with this on each project.

At the very least we could handle:

• Labels for required fields
  • Just an asterisk to the right of the label (span.form-required)?
• Indication for inputs that don't pass form validation
  • Just a red outline around the input with a .error class?

Feel free to add any other things that might be useful here, but these are the ones that jumped out at me.

We should automatically generate a stylesheet for use with the WYSIWYG editor.

Hi There,

Here's something I found with regards to installation and the custom theme.

The current readme advises editing the .js and .scss filenames from "scaffold" to "YOUR-CUSTOM-THEME-NAME".

If you just edit these filenames and run: gulp build:watch (which I assume is the correct command to run when its time to get down to theming,)... and then go to the front-end and check the console you'll probably find errors like these

GET http://127.0.0.1:8080/web/themes/custom/smblog/dist/css/scaffold.css?omkayh 
127.0.0.1/:791 GET http://127.0.0.1:8080/web/themes/custom/smblog/dist/js/libs.js?v=1 
127.0.0.1/:792 GET http://127.0.0.1:8080/web/themes/custom/smblog/dist/js/scaffold.js?v=1 404 (Not Found)

My custom theme name is "smblog". So what is going on here?

Looking into themes/custom and gulpconfig.js it is clear that if you want rename the "scaffold" theme to your custom name, you need to find all the instances of "scaffold" in your custom theme.

These are the changes I think need to be made...

1. gulpconfig.js do a "search and replace" here ("scaffold" is used in source and dest paths by Gulp)
2. Rename the custom theme folder
3. Rename .js file and .scss file
4. Rename the scaffold.info.yml and scaffold.libraries.yml
5. Edit the scaffold.info.yml and scaffold.libraries.yml to use your custom theme name
6. Change the namespace in Patterns.php
7. Edit _logo.scss

Once you do all that, hey presto! There are no errors in the console and foundation is loading...

All this should be obvious, I guess, but for anyone else who might find this useful...

Of course if you want to get up and working quickly, just don't rename the custom file...