🇺🇸United States @amstercad

Changed 'drupal/example_project' to 'example' in the name: field, because otherwise gitlab-ci.yml pipelines fail because '/' is an illegal character.

My comment just above, ( #9 ✨ Add DDEV install option Needs review ) adheres to previous examples in this thread.

However this recipe works to install the latest Drupal10 release of the DXPR Marketing CMS → on DDEV:

mkdir <project-directory>
cd  <project-directory>
ddev config \
    --project-type=drupal10 \
    --docroot=web

ddev start
ddev composer create dxpr/dxpr-marketing-cms-project

# Since I'm pressed for time now, this is what I used to install the website (which provides a 
# username and password to start with:
ddev drush site:install -y

# because I'm too lazy to bother with that, I used this to get a login link:
ddev drush uli

On my Ubuntu workstation, I prefer not to install any LAMP stuff or Composer because DDEV handles all of that so well, (and everything is configurable at <project-name>/.ddev/config.yml). On any Debian derived Linux distribution all anyone needs to do is sudo apt install ddev. Simple as that.

For this reason the commands in #8 ✨ Add DDEV install option Needs review won't work for me. Here's what worked for me once DDEV has been installed:

git clone git@git.drupal.org:issue/operations-3389217.git

## Give the repo a more meaningful local project name:
mv operations-3389217 dxpr

cd dxpr

ddev config \
    --project-type=drupal10 \
    --docroot=web

ddev start
ddev composer install

Last command runs for a bit and the last 4 lines are links to the 4 local websites that all work nicely.

https://operations.ddev.site/project/add/default

...requests a Drupal Site Name, Drupal Site UUID, API Key, and GIT remote. :)

Where might this be better documented?

Gesso is not a base theme but is meant as a clean, largely blank slate starter theme for complex, custom designs.

That said, would you define USWDS Gesso as a Drupal subtheme → ? Does USWDS Gesso support Starterkit?

Now that file File Upload Secure Validator → is a module dependency, it seems reasonable this issue can be closed now.

Now that file File Upload Secure Validator → is a module dependency, it seems reasonable this issue can be closed now.

This functionality has been delivered. Please refer to this development release → .

In preparation for Drupal 11, please note the test failure of the current patch:

PHP 8.3 & MySQL 8, D10.2 Patch Failed to Apply

Drupal 11 requires PHP 8.3 → .

Cool! After I made the effort and wrote the tickets, then learned what I did, I thought I'd only wasted my time.

Thinking back to how I got everything to work for me on this workstation, upon realizing ddev was capable of doing all the heavy lifting itself, which is actually very much preferred to begin with, I have had to uninstall and verify I did uninstall all the LAMP stuff like PHP versions and Apache stuff from the Ubuntu OS. I know I ditched all that stuff, but I can't speak authoritatively what I did with regards to nvm and how it is installed on my workstation because to this day I admit my understanding of nvm is fuzzy.

Maybe the difference between us is my Drupal websites have been setup, (over and over again, i.e. multiple websites), using ddev plus my doc'd recipes from the get go, while you might be trying to modify an existing ddev/OS setup?

not by the .nvmrc in the theme directory

Where does .nvmrc come from to begin with? I am too lazy to look myself now.

btw we can take this to slack, but I don't find you there

That's another level and besides my being preoccupied in life currently, I'm mostly focused on a few specific areas of Drupal. Also chat + timezones is a thing. I'm old, it's late Sunday, maybe I should reconsider Drupal Slack on another day, I'd rather be outside biking or skating but the weather sucks. I'd prefer to run this public thread long if need be for the time being, but we should probably switch to email. Contact me via Drupal.org/contact. Grrr, sorry.

What OS are you using yourself?

Now I cannot explain myself why my ddev setup plus instructions work for me but not for you. But ddev + Drupal + radix 6 + bootstrap + webpack work reliably for me as I've described. My *only* issue, which is no one's fault(!) is I have had some difficulty keeping my downstream GIT subtheme sync'd with upstream Radix changes during the last few months as Radix has been developed and refined. But I've been using ddev on Ubuntu with PHPstorm and those aspects have been running reliably as an atomic clock on my workstation.

Does these links help?

https://ddev.readthedocs.io/en/stable/users/extend/customization-extendi...

https://ddev.readthedocs.io/en/stable/users/usage/commands/#nvm

https://ddev.readthedocs.io/en/stable/users/usage/commands/#npm

https://ddev.readthedocs.io/en/stable/users/usage/commands/#yarn

How do you make it run in the subdirectory where the theme is located?

Just cd to the theme folder the regular way, then run the ddev npm install command.

These are the precise commands I use:

nvm use
ddev npm install

The first command does not use ddev but the second and all subsequent npm commands do.

You would have to run this within the container, right?

I like how there's no difference between a path within a ddev container and paths defined by the Operating System. The only difference is using a ddev prefix to run a command.

On the production server where ddev isn't used, drush is installed by Composer. To run drush from somewhere deep inside a regular Drupal website, you might do something like the example below, (instead of simply ddev drush uli):

../../../../vendor/drush/drush/drush uli

Doh! Bootstrap doesn't yet support @use.">doesn't yet support @use.

Doh! Bootstrap doesn't yet support @use.

Amstercad → created an issue.

Amstercad → created an issue.

Thank you very much Hosisam, you totally made my day! The module has been refactored -- I couldn't see the forest because all the trees were in the way.

Amstercad → created an issue.

Here's an example of similar code 🐛 Utility classes not being passed over into navbar component Closed: works as designed I've used recently to render Buttons from within the Card. Buttons can be rendered from the Card component just like the Media and Heading components in the linked example, so maybe this is another documentation issue.

Amstercad → created an issue.

As a DDEV user developing Radix stuff, I find it necessary to use these two commands as follows in order to setup and use a Radix subtheme, (Steps 1 & 2 of the automated setup instructions):

nvm use

ddev npm install

...hope that clarification helps. I have repeated that process many times of a lengthy period so trust me, it works solid. And that's all I have to say about nvm because that's all I know about it.

--> This works, but I wonder if there is a better way.

It is not necessary to use the command ddev ssh at all, (and all that that entails). It is not necessary to ssh into your website to do website theming.

DDEV installs all the necessary npm stuff, just like it does with composer stuff, so using ddev npm run watch to live-sync code changes or ddev composer up to update dendencies both work very well, for two different super-common examples.

As a rule, I choose not to install things like composer and npm on my, (Ubuntu), operating system of choice to ensure DDEV is managing those dependencies and their different versions entirely. That also makes altering environments as easy as editing a ddev settings files in .yml.

Which is an amazing thing actually, considering all it takes to install DDEV on something like Ubuntu is the sudo apt install ddev command.

Via composer.json is also how I keep websites patched, as do most Drupal developers I believe.

Thank you Ravi for the patch which has been committed.

Aha! I fixed card_link_url. I got card_link_url to work.

This is more of a documentation issue. The following is required in order to include a URL. If you carefully read the code, you can see this requirement.

Include this line in your template file:
button_html_tag: 'a',

This is the commit that breaks card_link_url.

My initial thought is because the include should really be an embed. It isn't such an easy edit to make however, without causing a hard crash.

Here's an explanation of how an embed differs from an include in a twig block.

This issue is blocking me at the moment, and I'm working on it.

If this is a pending concern, please submit a Merge Request.

It looks like you have not installed the VideoJS libraries using the npm install command. Also ensure core Drupal has been patched.

You should see a small icon on the right side of the video, centered vertically, when you hover over the video with your mouse. It is working for me. Clicking the icon will 'pop' the video out of the browser window and will display over other computer desktop windows.

I am using Firefox.

Confirming I'm seeing the same thing since the last few days. It seems there's a new spambot in town.

:( Some breakage has recently occurred to the Card component:

This breaks the site: card_text: content.body, whereas this works fine: card_text: content.body|default(),

Also, card_link_url is broken in that no URL renders. There's no <a href="/example"> in the web page source code.

I have experienced this error around last Wednesday or Thursday and then it seems to have gone away. All else I can say is I work to pull down changes using git as changes become available.

It was really frustrating while I hunted down the error! Oh, I do remember temporarily working around the error by switching to the Claro theme to make my website changes using Layout Builder, then I switched back to the bootstrap subtheme under development.

Amstercad → created an issue.

deleted

Sohail, regrettably I can't match your results with regards to the Card card_image_src field. I can't get any Media image to work in that particular field.

Your example does nothing for me:
file_url(content.field_media_image[0]['#item'].entity.uri.value),

This version yields the following result:
file_url(content.field_media_image[0]['#media'].field_media_image.entity.uri.value
/sites/default/files/image.jpg

And this version yields the following:
content.field_media_image[0]['#media'].field_media_image.entity.uri.value
public://image.jpg

...for whatever reason, my prior comment failed to include this screen scapture of what I see on a fresh Drupal install when I try to edit a Section using these tools, given the details I've previously written about.

This new recipe with layout_builder_iframe_modal is working for me on a newly developed Drupal 10.2.2 website, however the functional style-sheets of one of the modules fails to load in the new modal window when a Section is clicked. What displays is only HTML except for the section at the bottom which uses a stylesheet from the Claro theme.

Selecting a desired radio button to set section widths successfully is not something obvious to do, and tabbing to select isn't possible either. In my case, clicking about 3cm to the right and down a bit selects the desired radio button. Most people would regard a setup like mine as failing completely, but aside from a critical stylesheet failing to load, Bootstrap Layout Builder and Bootstrap Styles are functional and overall useful on this website, thank goodness! I need the Layout Builder breakpoints more than anything.

It is not clear to me what stylesheet is failing to load, or why. Or even which module it belongs to. The console doesn't give a clue either, however FireFox devtools sometimes displays an error message that can be clicked away that says a stylesheet failed to load. So far I cannot consistently make that error message appear.

For what it is worth, this is a new install so I never had this recipe working with Media Library Theme Reset earlier. This is my composer.json:

require section:

        "drupal/bootstrap_layout_builder": "^2.1",           <-- 2.1.2
        "drupal/bootstrap_styles": "^1.1",                        <-- 1.1.5
        "drupal/layout_builder_iframe_modal": "^1.3",    <-- 1.3.0

Patches section:

            "drupal/bootstrap_layout_builder": {
                "#3325151": "https://git.drupalcode.org/project/bootstrap_layout_builder/-/merge_requests/22.diff",
                "3335356: Clean up UI for 2x branch": "https://git.drupalcode.org/project/bootstrap_layout_builder/-/merge_requests/24.diff"
            },
            "drupal/layout_builder_iframe_modal": {
                "3342501: Uncaught exception 'TypeError' with message": "https://www.drupal.org/files/issues/2023-12-04/check_for_non_null_route_name.patch"
            },
            "drupal/bootstrap_styles": {
                "#3325150: Media Library Theme Reset not supported":  "https://www.drupal.org/files/issues/2023-12-15/3325150-media-library-theme-reset-ns-31.patch",
                "3282082: Support Bootstrap 5 on bootstrap_styles module.": "https://www.drupal.org/files/issues/2022-06-14/Fix-support-bootstrap-5-on-bootstrap-styles-3282082-%233.patch",
                "3402358: aos.local is never loading": "https://www.drupal.org/files/issues/2023-11-17/bootstrap_styles-3402358-2.patch",
                "3402978: Text Alignment icons do not appear with Bootstrap 5": "https://www.drupal.org/files/issues/2023-11-20/3402978-text-alignment-bootstrap5-compatibility-2.patch"
            }

I'm willing to help you, but I can't go ahead and learn 5.x code, (with Components, uggh, ...too old skool.), because I'm so focused on 6.x with SDC. SDC is the future.

I cannot imagine my answer is immediately useful for you, however if you can get to Radix 6.x (ultra-special SDC Edition) I think I can be more helpful for you. For what it is worth, SDC is the future of Drupal front end theming, so go for it. If you want to ask why, I'll try to give you an answer, but until then, https://idiazroncero.com/en/certainties/component-based-design-using-sin...

Did you change your template file to match your theme changes?

For example, if your template is mytheme > templates > node--article--card-common.html.twig

...has that file been edited from something like: {% embed 'radix:card' with {

...into {% embed 'radix:mytheme' with {

Doing so is a critical step and I don't see that step written in your question.

Amstercad → created an issue.

Everything looks and feels much better with all the documentation having been included in the various appropriate places. Thanks for the help this week. I think we can close this issue now.

Amstercad → created an issue.

Thank you sourabhjain. I went through the rest of the Radix 6.0 template files and added Drupal 10.1 Starterkit API documentation for each, and then added them all to the Merge Request you started.

Amstercad → created an issue.

Amstercad → created an issue.

Amstercad → created an issue.

Thank you both for your support. Tirupati Singh had the answer -- That field needed to be turned on. I really needed the answer in #3 🐛 Site slogan fails to display in the site branding block Active too, after studying the code yesterday and not seeing anything wrong. No doubt someone else will trip up just like I did, and hopefully a search engine will bring them here.

Amstercad → created an issue.

Thank you doxigo, the fix is good.

Sorry doxigo, but I am not seeing this fixed yet.

Amstercad → created an issue.

Thank you larowlan. The situation is clear to me now. There are no bugs and everything works well as designed. This issue is closed.

Ah, that's confused me before

You and me both. No doubt as SDC becomes more mainstream a search engine will propose this thread to someone, so I'll clearly document what's happening as it is not obvious.

Whether or not Layout Builder or SDC renders the Content Type depends on a checkbox setting, for each View Mode.

There are 3 Content Types in the Umami website example. In each Content Type only one of the View Modes use Layout Builder, the rest use SDC if they're used at all. Only the Full content View Mode uses Layout Builder.

For example, these are the View Modes used by the Recipe Content Type:

Default
Card
Card Common
Card common alt
Full content*
Teaser

* The Layout Builder checkbox is on.

I disagree, this issue is not working as designed. I've clarified the bug. Those checkmarks should be displayed as being on and they're not by default. True, Layout Builder is working as designed, however those checkmarks displaying incorrectly are the bug. If you agree, please reopen.

Yes, I agree the Layout tab displaying on the node page is working as designed.

Yes, I see you are correct larowlan. Thank you for the example. It works as designed, independently of SDC.

Still, I see a bug worth noting here. If you look at this URL:

/admin/structure/types/manage/recipe/display

Use Layout Builder is unchecked. Also, Allow each content item to have its layout customized, fails to display when Use Layout Builder is checked on, as is normal behavior. Both checkboxes should be checked on to remove the bug.

The reason it works this way is because Configuration Management works with the current code during the installation of the website profile. Had the buttons worked as expected, I would not have been fooled as I was.

Of course both SDC and Layout Builder can be used alongside each other, however Layout Builder is not actually being used in the Umami demo website. The CM code Larowlan points to are just legacy settings that are wholly unused now. Those are format settings someone can select if they want, but they aren't actually being used. Maybe I am wrong. If so, someone please show me what Layout Builder is actually being used for.

Calling Layout Builder a requirement when it actually isn't being used isn't fair for people trying to learn Drupal Best Practices by reverse-engineering this working code. The new implementation of Umami demo makes not only much use of SDC but also View Modes. Previously Layout Builder was used. The new Umami demo website code functions very much like Mario Hernandez has presented and documented using the legacy Components → module.

I've spent much time recently reverse-engineering the Umami demo website recently to better implement SDC myself. This code is the best 'documentation' for getting SDC to work myself. Seeing legacy Layout Builder cruft is confusing for people in my situation.

Don't get me wrong, I really like Layout Builder. I just don't think it is fair to keep this legacy, unused cruft as a pre-installed requirement for no good reason.

The recipe Content Type is not using Layout Builder as a Display, so I don't see how Layout Builder is being used. Thank you @larowlan for your reply, I hope you can clarify further.

I think if I used Configuration Management → and had some time and patience, I could strip out the requirement from the repo.

Amstercad → created an issue.

Amstercad → made their first commit to this issue’s fork.

A few months have passed since your post, but perhaps this newer USWDS module → and its maintainers might help your cause. The maintainers have also presented their effort so far. I hope you'll publish your progress and results if you can, or you can contact me directly.

The USWDS governor theme makes good use of Software Directory Components (SDC). SDC is part of core Drupal 10.1.

IMHO, both the drush script and the core Drupal script should be supported, and why not? They both work so long as the Starterkit code meets the required specification. And valid documentation mentioning support for both scripts should exist.

If the drush script offers more features and documents make that clear, then good. Many people will use Radix having used other themes before, and those themes might be using the Drupal core script at core/scripts/drupal. True, those are two different scripts with diverging capabilities perhaps, but either will get the job done. At the end of the day, I think it is fair to say that's what people want and if there's no additional development costs, why not support both scripted methods?

One script only requires PHP while the other script requires a drush setup that some people might find too much of a hassle for the purpose.

Notice the changes in this code for form.twig. utility_classes is now form_utility_classes. However form_utility_classes is used in four places, not three as in the GIT commit in question. With the code below, the website renders fine.

That's all I have tested for. I didn't test the form component.

{% set form_utility_classes = form_utility_classes ? form_utility_classes : [] %}

{%
  set classes = [
    'form',
    is_inline ? 'form-inline',
  ]|merge(form_utility_classes)
%}

<form{{ attributes.addClass(classes) }}>
  {{ children }}
</form>

I created a clean Drupal site with only Radix 6.0.x and the rendering fails with the same error as written above. That's what I can report for the moment.

"utility_classes" are called from all over the place. For example this .yml file.

In components/form/form.twig, replacing this line:

{% set form_utility_classes = form_utility_classes ? form_utility_classes : [] %}

with this line allows the website to render again:

{% set utility_classes = utility_classes ? utility_classes : [] %}

I'd submit a patch to change it back, but I'm not sure what you were trying to achieve.

Amstercad → created an issue.