Not sure if it has any meaning in our case? (Site is still installed properly in the end of the process)

Currently the Robofile isn't using all the capabilities of Robo. That is, there could be nicer use of existing tasks instead of $this->_exec('some bash commands'). We still enjoy writing those scripts in PHP rather than bash, but it could be improved.

Looks like we need this to get npm-asset to work as expected and download the packages into web/libraries/{name}

Let's have it similar to our other client projects, so upon ddev restart we'd get some users and content.
Would be nice for the Articles to have tags and an image

DDEV provides Mailhog, which features a JSON API. So it's quite easy to invoke those HTTP endpoints from PHPUnit tests and assert mail sending. This would treat Mailhog as a high level mock.

https://twitter.com/randyfay/status/1321436940344852480 -probably we'll have general DDEV + Travis outage soon: https://docs.docker.com/docker-hub/download-rate-limit/ - "Docker will gradually introduce these rate limits starting November 2nd, 2020."

From @adamhstewart

Interesting... If we had a single dockerhub pro account that was authenticated by Travis jobs, would that solve it? Is that even possible?

Desired format

Release 1.11

• Issue one (#11111)
  • Pull request one (#22222)
  • Pull request two (#444444)
• Issue Two (#999999)
  • Pull request (#1234567)

Contributors:

• User1
• User2
• User3

(authors of the issues and the pull requests enumerated above)

Technical notes

It will mean that the release notes script will require a personal access token to GitHub to gather all this information. I can save it locally to avoid to enter it again and again

We should rely on Redis caching out of the box. For small projects, it makes no harm, for large projects, it helps a lot.

We have ddev theme:watch - watches only for TW classes.

We have ddev robo theme:watch-debug, which is watching also for JS changes.

Let's change ddev theme:watch to call the robo. However the bigger issue here is that something is broken with the robo command. When it detecs a change in the JS file, it results with

Following a discussion with @amitaibu we'll be adding some paragraphs to basic pages.

Tasks

• Add paragraphs module (also update to use PEVB with Paragraphs integration)
• Add Hero paragraph
• Add Card and Cards paragraphs
• Add/Update frontend components as needed
• Add Pluggable entity view builders for the paragraphs to use the frontend components
• Add paragraphs field to Basic Page with options to add Hero and Cards paragraphs (Card is only addable through Cards paragraph)
• Add some migrated basic page content with paragraphs

I think is better to do this from the beginning of any project:

https://www.drupal.org/project/drupal/issues/2844452

For example instructions mentioned here: https://www.drupal.org/project/select2

It will be useful for local development in case a developer does not want to download all files.

So on deploy we'd copy and overwrite any existing settings.php on Pantheon's directory

https://github.com/Gizra/drupal-starter/blob/f40ef9df2a8b279ffb412b178f1b5f9934ee6e99/web/modules/custom/server_general/src/Controller/Homepage.php

Task

1. Add content type "Landing page"
2. Add Paragraph type "Views" with a field "field_views" which is a select list with hand picked Views.
3. Migrate a Homepage node, and set it in config to the the site's home page

First up, thank you for sharing the development of this project, it's brilliant.

On a fresh gizra/drupal-starter DDEV installation, the ddev robo theme:compile-debug command takes about 30 seconds to complete. This feels very slow when working on frontend tasks.

The same happens when using the ddev robo theme:watch-debug command, which basically invokes the theme:compile-debug on every change.

The Just-In-Time Mode from Tailwind, however, advertises lightning fast build times... even the biggest projects in about 800ms, so I was wondering what could be done to speed it up (or whether it's ultra fast for everyone else and this is just an issue with my setup, I use a Macbook).

For starters, we could shave off about 5 seconds by removing the drush cache:rebuild, since Twig and Drupal caching are often disabled anyway during development.

https://blog.travis-ci.com/docker-rate-limits

Seems we're already hitting this from time to time. Let's update travis to help us with this

Example https://github.com/Gizra/drupal-starter/blob/main/RoboFile.php#L143

ddev composer install
cp .ddev/config.local.yaml.example .ddev/config.local.yaml
ddev restart

And then I get this error

@AronNovak
As of now, compiling the theme may fail, but travis still pass:

//cc @amitaibu

Apparently, the aliases defined in migrate csv for landing pages aren't migrated as part of initial setup. They're instead generated automatically by pathauto.

Adding PR #263 for this

We have various different release notes generators in our projects, let's standardize it in the RoboFile

PHPCS doesn't check php syntax, missing test coverage will not detect this either.

There is an interesting project called https://github.com/VKCOM/noverify that I've been trying to check syntax errors locally. Let's see if this can be automated.

A fatal error waiting to be discovered by someone:

It might be interesting, as Tailwind is relatively new, it might be a publicly available base tailwind theme.

• Extract the https://github.com/Gizra/drupal-starter/blob/master/web/modules/custom/server_general/src/NodeViewBuilder.php logic to contrib module pluggable_entity_view_builder
• Add example module to that contrib
• Add tests
• Remove custom code from this repo in favor of the new module

Dependencies defined in .yml files like this:

dependencies:
  enforced:
    module:
      - server_migrate
    migration:
      - user
      - tags
      - media_image

Does not seems respected. The right syntax seems to be:

migration_dependencies:
  required:
      - user
      - tags
      - media_image
  optional: []

Issue

In current setup we have 2 commands for theme - ddev tw(theme watching) and ddev robo theme:compile(theme compiling), I suggest to make 2 ddev commands which will have similar namings - ddev theme:watch and ddev theme:compile

Issue

Upon clean installation we set the homepage to be /homepage on /admin/config/system/site-information . But if we check \Drupal::service('path.matcher')->isFrontPage(); it will return False. If we then manually change the URL and then back to /homepage and click save, then under the hood it changes it to the internal path (e.g. /node/21).

Task

1. Confirm my findings
2. Instead of setting it via config, after the migration is executed, we can set it.

Just thought of this as it's been in the back of my mind for a bit.

If we try to render entities in Views module's Preview window just as one example, the entities don't render because the server-theme-card.html.twig template cannot be found (for example) when using Claro/Seven.

This can be resolved if we just server_theme_theme (server theme's hook_theme) to server_general_theme and copy all the server-theme-* templates to be in the module's templates folder. This way in server_theme we're overriding templates provided by a module, and since they're provided from a module they should work in any theme such as Seven.

We should probably switch to the official TW Line Clamp plugin: https://github.com/tailwindlabs/tailwindcss-line-clamp

@AronNovak let's see if this brings us enough value - https://github.com/mglaman/phpstan-drupal

mariano Today I saw a 503 error from npm in a deployment script. This caused the deploy work but the css and js dist files where not included in the commit to pantheon QA. We should check this in drupal starter eventually

From @mariano-dagostino

This gets phpcs confused, and I can see why.

@adamhstewart I think server_theme could be better?

Right now it's possible that automatic deployment reverts already deployed changes.
Deployment jobs might be created like this:
Job A
Job B

But executed in this order:
Job B
Job A

Then changes from Job B are reverted essentially.
To prevent that, we could store the timestamp of the Git commit in the artifact repository to ensure that we never deploy outdated code.

• Divide into wrapped/ non-wrapped area
• Add JS to collapse all elements on load
• Click on title or some Expand/ collpase all buttons
• Or if in the url we'd have the Id of the element (e.g. /style-guide#element-to-open)

I see two errors:

• https://travis-ci.com/github/Gizra/drupal-starter/jobs/488157071#L1053
• https://travis-ci.com/github/Gizra/drupal-starter/jobs/488157071#L1086

https://www.drupal.org/project/advagg

We seem to rebuild those types almost every site, which could be good examples:

• Hero image
• Related content carousel. Let's use our slick, but convert the use of classes (e.g. carousel-wrapper) to attributes (<div data-carousel-wrapper ...>). So it's easier to spot those settings.

@andreytroeglazov for whenever you have some spare time 😄

• Install and enable XML sitemap
• Add Menu links from Main menu - And perhaps Articles node type too? @amitaibu how should we configure it?

Should we install pathauto + redirect too @amitaibu ?