jabrah
commented
3 years ago Choosing a theme
Besides the admin theme, we'll also need to choose (or choose not to use) a base theme for our custom theme, which ties into general public facing templates. I'm not especially excited about any options that I've come across, however I also think that not using a base theme will be prohibitively expensive in terms of development time. While playing around with Drupal, I basically started highly customizing Classy, one of the default themes that ships with Drupal.
IMO, I think classy would be a fine starting point for us. My main concern has to do with Drupal best practices. Because of my inexperience with Drupal, I expect much of what I (we) develop to end up being "bad" practice among the Drupal community. I don't expect to share our theme with the Drupal community, so best practices may not necessarily be as important, but it may make future maintenance more challenging.
We might check out the Bootstrap Drupal theme for coding practices.
Dealing with dependencies
"Installing" JS or CSS dependencies should be straightforward, since they just need to be declared in our theme's info.yml file and the dependencies will automatically be included in the Drupal UI. There are some other development questions such as setting up asset bundling, if desirable, and dev vs prod environments.
UI Project Layout
We need to formalize project/repository structure, especially when dealing with custom JS. Presumably, we'll develop our custom JS components directly in the custom theme to allow for much faster iteration. However this approach does have some drawbacks. I'm not necessarily advocating different approaches described below right now, but they may be worth considering in the future after development stabilizes somewhat.
- Having separate repositories would enforce separation of concerns between the component and the theme with the drawback of much more cumbersome integration testing (in the theme/templates) and updating. It also allows for much cleaner Git history, issue tracking, etc
- Instead of having the JS code reside in the theme's
js/directory, we could consider developing them as stand alone(ish) Drupal modules where the JS component is tied to a custom block that can be placed anywhere by a Drupal admin. This would allow less technical admins the ability to update configuration or move these components without having to update Twig templates in the theme.
Tasks
- [ ] Setup code repo in Github - we just need an empty repo to work with. For a name, perhaps
idc-isle-uioridc-isle-theme? - [x] Create project file hierarchy. This will be done manually, following Drupal guidelines https://www.drupal.org/docs/theming-drupal/drupal-theme-folder-structure (2d)
- [x] basic file structure
- [x] required drupal config files (yml, settings, etc)
- [x] Populate project README with an actual decent description of project goals. We will need to include descriptions for any custom JS components we make (1d for the initial version, will be iterated on)
- [x] Determine initial iteration of theme's regions. We can always modify this later (.5d)
- [x] First iteration of general layout. Grids or flex layouts? Breakpoints for responsiveness? This will involve a mixture of foundational CSS rules and HTML in templates (1w)
Acceptance criteria:
There is setup work to do on the project once the base repository has stabilized. This involves working to install the tailwind UI library whether by module or manual installation. It also involves installing stimulus.js for use of javascript without decoupling the UI. There are Drupal/php settings files that should be edited to enhance debugging drupal output. The public theme will almost certainly be different than the internally facing admin theme. We should land on an acceptable theme for admin UI.