This is sort of a meta-issue that I noticed while reviewing the Umami code (most likely, it needs to be broken up into sub-issues).

The profile and theme are really fantastic! But an overall trend I saw is that the theme hardcodes several assumptions about how the profile will be configured. Some examples:

  1. It hardcodes the placement of particular fields in the template files, thereby causing the reordering capability of Drupal's "Manage Display" screen to not work correctly. This was noted at https://www.drupal.org/project/drupal/issues/2904243#comment-12346261 and subsequent comments such as https://www.drupal.org/project/drupal/issues/2904243#comment-12408008 previously, but I don't think there's an issue for it.
  2. In general, the theme has a lot of code designed to work with specifically-named fields. So if a site administrator tried to recreate some aspect of the profile with different field names, the styling would be off.
  3. There are a number of images shipped with the theme, some of which would make more sense as content so that they could be configured, or be used if the site switches to a different theme.

One result of this is that if, for example, you install the profile and then switch to a different theme (such as Bartik) it looks really bad. I wouldn't expect it to look beautiful, of course, but it would be nice if it were at least roughly functional. (Although in fairness, a lot of these problems might be either Bartik's fault or due to the fact that the themes have different region names so the blocks get switched to unusual places in Bartik.)

More generally, the goal of this profile is an "Out of the Box" demo, but:

  • If a lot of custom code in the theme is required to achieve the goals of the profile, then it doesn't really demo what Drupal does "out of the box".
  • If it causes some of Drupal's standard admin functionality to not work correctly, then it's not really an effective "demo" of Drupal's content-management and site-building capabilities.

Issue fork drupal-2938911

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

David_Rothstein created an issue. See original summary.

markconroy’s picture

markconroy commented
Issue tags: +dclondon
markconroy’s picture

markconroy commented
Status: Active » Postponed
Issue tags: +Umami new feature

I'm going to mark this as postponed for now, and let's revisit it asap once we get unhidden. I think this will make a great topic for discussion and hopefully we can iron out all the concerns sooner rather than later. (Others are free to work on it in the meantime if they wish).

I am attaching the 'Umami new feature' tag to this item.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

eli-t’s picture

eli-t
he/him
Primary language English
Location Manchester
commented
Status: Postponed » Active
Issue tags: +DrupalEurope, +Novice

Unpostponing now we are unhidden.

I think a lot of this has actually been addressed in #2983576: Support display setting changes in Demo Umami's Article and Recipe full page view modes

Suggest re-reviewing @David_Rothstein's concerns in the issue summary against the latest version of Drupal and identifying which still apply.

jacine’s picture

jacine
she/her
Location New York
commented

One result of this is that if, for example, you install the profile and then switch to a different theme (such as Bartik) it looks really bad. I wouldn't expect it to look beautiful, of course, but it would be nice if it were at least roughly functional. (Although in fairness, a lot of these problems might be either Bartik's fault or due to the fact that the themes have different region names so the blocks get switched to unusual places in Bartik.)

On this point specifically, I don’t think this should be Umami's problem. It's not Unami's fault that Bartik's block configuration is located in the Standard profile config, and as I just learned, including Bartik's block config in config/install as the Standard profile does, without installing Bartik causes dependency issues. Omitting Bartik’s block config, as is happening with the Umami profile (and likely others in contrib) results in it never installing “properly” because Bartik itself does not include its Block config. It resides in the Standard profile.

I think relocating the configuration to Bartik is the proper fix: #2642590: Move Bartik block config into the Bartik theme

However, if that doesn’t happen, another option that works in my testing, is to include Bartik’s configuration as “optional”. This gets around the dependency issue, and if after installation, a user decides to install Bartik, the configuration is used, and the blocks are placed properly.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

finnsky made their first commit to this issue’s fork.

finnsky opened merge request !8727

finnsky’s picture

finnsky commented
Status: Active » Needs review
Issue tags: -dclondon, -Umami new feature, -DrupalEurope, -Novice

I've replaced 3 preprocesses with css only

smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work
Issue tags: +Needs issue summary update, +Needs title update

Briefly looking at the MR and the title/summary and not super clear what is being fixed, I see it's moving some css around in the MR. So tagged for both.

acbramley’s picture

acbramley commented
Status: Needs work » Postponed (maintainer needs more info)

I would be inclined to close this as works as designed. As far as I know, Umami is for demonstration purposes only. The profile has "Expiermental" in the name and the description denotes it is to "show off some of Drupal's capabilities".

I think trying to fix everything in the IS could be somewhat wasted effort. I don't think people are expected to install it, modify fields, config, etc and have it continue to work perfectly. Same goes for installing it and then switching themes.

Setting to PMNMI to see if anyone else feels similarly.

finnsky’s picture

finnsky commented

I might need to move what I did into a separate task.

smustgrave’s picture

smustgrave commented

Wanted to bump this 1 more time

markconroy’s picture

markconroy commented
  1. It hardcodes the placement of particular fields in the template files, thereby causing the reordering capability of Drupal's "Manage Display" screen to not work correctly. This was noted at https://www.drupal.org/project/drupal/issues/2904243#comment-12346261 and subsequent comments such as https://www.drupal.org/project/drupal/issues/2904243#comment-12408008 previously, but I don't think there's an issue for it.I think this has been fixed. You can use the manage display page settings now for all the view modes. This was a requirement as far as I remember for the profile being unhidden.
  2. In general, the theme has a lot of code designed to work with specifically-named fields. So if a site administrator tried to recreate some aspect of the profile with different field names, the styling would be off.I'm not sure how we get around this when developing something as specific as a recipe magazine.
  3. There are a number of images shipped with the theme, some of which would make more sense as content so that they could be configured, or be used if the site switches to a different theme.I don't think this is an issue. Looking in the images folder, all we have is icons from the old classy theme, and some SVGs (like the chef's hat for our recipes page).

Some of my thoughts on the 3 items in the IS ^

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.