Contrib.social

Multiple environments cause dxpr directory name problems

Open on Drupal.org →
Created on 30 November 2023, about 1 year ago
Updated 26 February 2024, 11 months ago

Problem/Motivation

The way dxpr_theme uses generated files causes problems when deploying to different environments.

We have 3 Drupal environments for a site: development, test, and production.

Someone changes the css via the dxpr_theme on the development environment using the dxpr_theme gui, saves the changes. The config changes are committed to git, the files under public are not.

The changes are pushed to test, and then the dxpr_theme breaks on the test enviroment (it can't find the css). The reason it breaks is that when you save the theme config on development, a new directory like 'public://color/dxpr_theme-e897fa47/' is created to hold the (new) css, the "e897fa47" changes per save. This is probably done to be able to serve 2 versions concurrently. However the (new) path is also in color.theme.dxpr_theme.yml under the stylesheets and files section. We check in this latter config file in git without checking in the files under public.

When we move the changes to our test environment, the dxpr_theme fails as it will try to get the css from the new directory (which would be ok on development), but this new directory does not exist on test.

The manual way around it is to go to test after deploying to it. Opening the dxpr_theme in the GUI, and saving it. This will regenerate the css files and update the theme config to point to the correct directory. This works, but is not so nice when you have a CI/CD pipeline.

Proposed resolution

Any way that the theme would work in a CI/CD pipeline over multiple environments would be ok.

Proposals:
1. A new drush command that mimicks the saving of the GUI. This way you can put an extra drush command in your CI/CD pipeline to update the directories and make the dxpr_theme work again. I have a prototype for this I will attach, and I prefer this one.
2. Something that automatically detects that the required dxpr_theme directory is not there and triggers a regeneration of it. This may be complex.
3. A way to specify which specific directory is used to generate the theme output files. Under normal circumstances we don't do changes on test and production, we will always do the changes on development and then deploy. And when we deploy it's all or nothing, serving concurrent versions for a while is not required for us.

Remaining tasks

Integrate the drush command in dxpr(_theme_helper), or find another way around the problem.

User interface changes

None

API changes

None

Data model changes

None

✨ Feature request
Status

Active

Version

6.0

Component

Code

Created by

sboden

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @sboden
  • Comment about 1 year ago →
    sboden

    For a proper name of a drush command, maybe "dxpr_theme:regenerate" or "dxpr_theme:cr" (preference for the regenerate).

  • Comment about 1 year ago →
    🇳🇱Netherlands jurriaanroelofs

    Hi sboden, thank you for your issue.
    The issue would be resolved in our 6.x releases which have factored out the color module. It's due to be released for production in January but I created an alpha release for you which is tested to work OK, but not yet integrated in our visual regression test suite, so please test it to meet your requirements yourself, too:
    https://www.drupal.org/project/dxpr_theme/releases/6.0.0-alpha1 →

    Note that if you have subtheme you should recreate it from the 6.x version, as your 5.x subtheme would still have "color module architecture".

    Regards,
    Jurriaan

  • Comment about 1 year ago →
    🇳🇱Netherlands jurriaanroelofs

    p.s. the alpha release does actually contain an update hook that should migrate your colors to the new system, this requires Drupal 9.4+ to work.

  • Comment about 1 year ago →
    sboden

    I upgrade dxpr_theme from 5.2 to 6.0.0-alpha1 on a Drupal 10.1: everything is looking good. And this issue is solved in there.

  • Comment about 1 year ago →
    🇳🇱Netherlands jurriaanroelofs

    Great, thank you for your feedback!

  • Comment about 1 year ago →
    sboden

    One strange possibly related thing. On Drupal 10.1 after I upgrade dxpr_theme, I tried to enable the layout_builder module by doing "drush en layout_builder", and then I get the error "The module color does not exist.". Trying the same on a backup copy of the project the layout_builder enables just fine.

  • Comment about 1 year ago →
    🇳🇱Netherlands jurriaanroelofs

    @sboden are you using our DXPR Marketing CMS distribution? You may need to remove the -color line from dxpr_marketing_cms.yml:

    https://git.drupalcode.org/project/dxpr_marketing_cms/-/blob/10.1.x/dxpr...

  • Comment 11 months ago →
    🇺🇸United States bsnodgrass

    I experienced this same issue and upgraded to dxpr_theme 6.0.0-beta1 which seemed to solve this problem.

    However the upgrade process was incomplete. Since I am on core 10.2.3 the core color module had been removed from core. Dependencies identified the color contrib project should be installed to replace it.

    Reviewing this today with @JurriaanRoelofs he identified there were conflicts with the contrib color module which were preventing colors from being properly implemented for use with the 6.0.0-beta dxpr-theme. Once this was uninstalled the issue was resolved. I will create a new issue if one does not already exist.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024