search

Labdoo / Labdoo-3.0

Labdoo 3.0
GNU General Public License v3.0
0 stars 4 forks source link

Update drush&core, add admin_toolbar and gin theme, export configuration. #3

Closed greggmarshall closed 2 years ago

greggmarshall commented 2 years ago

Updated drush and core, added admin_toolbar, adjusted enabled modules, added git admin theme, changed site themes to gin for admin and olivero for front end (until a custom Bootstrap theme is configured), added some additional documentation.

See individual commit messages for more details exactly what was done.

jrosgiralt commented 2 years ago

This is great @greggmarshall thanks. There are 235 files changed. Do you have a recommendation as to what files (or groups of files) I should focus on for reviewing this PR? I am guessing some files might have been programmatically changed?

greggmarshall commented 2 years ago

All of the files in config/default are generated when you do a configuration export. Generally when I review a PR with configuration in it, I scan the filenames looking to see if something looks out of place (e.g. if the PR was to enable and configure a mail module, I wouldn't expect to see configuration related to a content type (fields, nodes, etc) unless that mail module added a mail field that was added to a content type). Another configuration file I usually look at (in the file) is core.extension.yml, which are the modules enabled.

Beyond that composer.json changes are good to look at, but composer.lock is derived from composer.json and tends to be really large and generally hard to review so I skip it.

And any other file that isn't in config/default is worth a look.

https://github.com/greggmarshall/drupal-project-docs/blob/main/bitbucket-acquia-cloud-site-studio/CodeReviewProcess.md might be another resource we can include in a future PR.

jrosgiralt commented 2 years ago

All of the files in config/default are generated when you do a configuration export. Generally when I review a PR with configuration in it, I scan the filenames looking to see if something looks out of place (e.g. if the PR was to enable and configure a mail module, I wouldn't expect to see configuration related to a content type (fields, nodes, etc) unless that mail module added a mail field that was added to a content type). Another configuration file I usually look at (in the file) is core.extension.yml, which are the modules enabled.

Beyond that composer.json changes are good to look at, but composer.lock is derived from composer.json and tends to be really large and generally hard to review so I skip it.

And any other file that isn't in config/default is worth a look.

https://github.com/greggmarshall/drupal-project-docs/blob/main/bitbucket-acquia-cloud-site-studio/CodeReviewProcess.md might be another resource we can include in a future PR.

That's really a concise and very useful explanation, thank you @greggmarshall !