🇬🇧United Kingdom @2dareis2do

Note that for backwards compatibility, the composer definition still depends on the ctools project, but it's no longer installed on new projects and existing projects may uninstall it if they are not using it.
https://www.drupal.org/project/pathauto/releases/8.x-1.11 →

I was wondering why this dependency is still installed but I can disable ctools without issue.

It seems to me you should be able remove from composer.json.

If people still need it there is nothing to stop them from including it in there dependencies or global project composer.json

e.g.

   "require": {
        "drupal/ctools": ^4*"
    },

This unnecessary dependency causes an unnecessary update as previous version of ctools is listed as unsupported.

That said, I do see a potential issue where ctools is still enabled in the database config. Removing it would be a breaking change. i.e. it is still needed to uninstall it. Potentially that would be a breaking (major) change.

Ok so it looks like social_post 4.x that is compatible with social_api 4.x is in the works.

https://www.drupal.org/project/social_post/issues/3307661 💬 Support Social API v4 RTBC

Perhaps it makes sense to add a a new branch/tag that supports that?

Ok so for social api 4.x we have social_api/src/Plugin/NetworkInterface.php

https://git.drupalcode.org/project/social_api/-/blob/4.0.x/src/Plugin/Ne...

<?php

namespace Drupal\social_api\Plugin;

use Drupal\Component\Plugin\PluginInspectionInterface;
use Drupal\Core\Plugin\ContainerFactoryPluginInterface;

/**
 * Defines an interface for Social Network plugins.
 */
interface NetworkInterface extends PluginInspectionInterface, ContainerFactoryPluginInterface {

  /**
   * Gets the underlying SDK library.
   *
   * @return mixed
   *   The SDK client.
   */
  public function getSdk(): mixed;

}

where as in 3.x branch it is just:

<?php

namespace Drupal\social_api\Plugin;

use Drupal\Component\Plugin\PluginInspectionInterface;
use Drupal\Core\Plugin\ContainerFactoryPluginInterface;

/**
 * Defines an interface for Social Network plugins.
 */
interface NetworkInterface extends PluginInspectionInterface, ContainerFactoryPluginInterface {

  /**
   * Gets the underlying SDK library.
   *
   * @return mixed
   *   The SDK client.
   */
  public function getSdk();

}

Notice how the signature has changed

in

we have

  /**
   * {@inheritdoc}
   */
  protected function initSdk() {
    $class_name = '\Abraham\TwitterOAuth\TwitterOAuth';
    if (!class_exists($class_name)) {
      throw new SocialApiException(sprintf('The PHP SDK for X could not be found. Class: %s.', $class_name));
    }

    /** @var \Drupal\social_post_x\Settings\XPostSettings $settings */
    $settings = $this->settings;

    retu

so perhaps this need to be updated so that we have

protected function initSdk(): mixed {

That said I am still not sure why you have social_api 4.x installed?

Sorry previous comments about the signature were incorrect. Please ignore.

One thing I was wondering is how you managed to install social_api 4.x as from what I can see social_post has dependency of 3.x?

The latest version of social_post is still 3.x afict

https://git.drupalcode.org/project/social_post/-/blob/3.x/composer.json?...

rolling back solr_api from 1.35 to 1.34 seems to fix the issue for me for now.

Rolling back to from search api from 1.35 to 1.34 seems to resolve the problem for me (for now).

I tried commenting put DependencySerializationTrait as per #4 but then I still receive

Fatal error: Declaration of Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend::__sleep() must be compatible with Drupal\search_api\Backend\BackendPluginBase::__sleep(): array in /var/www/html/web/modules/contrib/search_api_solr/src/Plugin/search_api/backend/SearchApiSolrBackend.php on line 5077

Also created 1.0.0 release

I have had a think about this.

Despite the notice:

Until a project has security advisory coverage, it is recommended to only make pre-release versions.

As this is simply a recommendation, I see no reason why I cannot create a release/tag. This makes sense, especially when specifying version dependencies. Creating a release also enables me to get rid of .git folder than can be hundreds on megabytes in some circumstances.

It would be great to have security coverage, but I don't think this is the be all and end all.

With regards the point made previously about existing maintainers, why are there so many projects that have virtually been abandoned, but still maintain their security coverage privilege?

correction

new module

p.s. based on my experience I tend to agree with most of the points raised in your article and comments

This in particular seems strange to me

a new contributor's module is picked apart before they can opt into security coverage (and make a full release) but once you are past that one-time gate you can publish half-baked modules with releases *and* opt into security coverage without any review.

Also the process is too long.

While I did receive some useful feedback from the review process, and was certainly grateful for the pointers, tips and encouragement, which were probably given voluntarily, ultimately this was deprioritised and put off indefinitely afaict. The fact that this is probably a typical experience for new contributors does seem to me an area for some concern for the future of Drupal. While on the one hand Drupal seems to take pride in its Open Source roots, and seeks to encourage innovation and new contributors, on the other hand it makes the process longer and more difficult than it probably should be. This seems to stifling innovation and growth, while at the same time weighted or favouring those who do have the right access to make official releases.

Certainly I look at the quality of some of the official contributed releases and am left scratching my head wondering about how this works. The system does not seem to be consistent. Why is that existing contributors seem to be able to publish what they want but new contributors struggle to do anything?

Looking here it seems the decision to only give green to only those with security coverage is deliberate

https://www.drupal.org/project/drupalorg/issues/2457643 →

So to answer your question there does not seem to be anything preventing me from creating a full release.

That said, it will remain yellow until or if I do get the security coverage.

Hi Ben

Thanks for your tips.

As suggested I have looked at this again. I have managed to create a release (1.0.0) by creating and pushing that tag, and then selecting that as the release under version control page/tab .

To do this I had to opt out of security advisory. Please see attached screenshots.

Hi Ben

Thanks for the feedback.

I have not been able to get authorisation to publish a full release for a while now

https://www.drupal.org/project/projectapplications/issues/2508285 →

https://www.drupal.org/project/projectapplications/issues/3370221 →

It looks like the signature has changed on 4.x branch. I n particular sdk is a mixed type. mixed type was introduced in php 8.0. Probably this needs updating so that the child class has the same.

e.g.

3.x

 /**
   * Sets the underlying SDK library.
   *
   * @return mixed
   *   The initialized 3rd party library instance.
   *
   * @throws \Drupal\social_api\SocialApiException
   *   If the SDK library does not exist or other validation fails.
   */
  abstract protected function initSdk(): mixed;

4.x

  /**
   * The SDK client.
   *
   * @var mixed
   */
  protected mixed $sdk = NULL;

I think the quick fix (and to check this) would be to make sure you are using social post 3.x

e.g. in your project require

"drupal/social_post": "^3.0",

1. Probably need to specify a version of social_post that is compatible currently 3.x
2. Test with 4.x version and a make sure signature is the same
3. Make 4.x compatible

Hi Dave

Thanks for posting this issue.

I have this working locally but I am using with

            "name": "drupal/social_api",
            "version": "3.1.0",

I have not really looked into this but it sounds like something may have broken this in social_api 4.x

Can anyone explain why this has been set to needs work.

Patch here works for me without issue.

I should mention that the recommended use of some of these attributes is quite complicated.

e.g.

as
This attribute is required when rel="preload" has been set on the
element, optional when rel="modulepreload" has been set, and otherwise should not be used. It specifies the type of content being loaded by the
, which is necessary for request matching, application of correct content security policy, and setting of correct Accept request header.

Furthermore, rel="preload" uses this as a signal for request prioritization. The table below lists the valid values for this attribute and the elements or resources they apply to.

Value Applies To
audio elements
document

and elements embed elements fetch fetch, XHR Note: This value also requires to contain the crossorigin attribute, see CORS-enabled fetches. font CSS @font-face Note: This value also requires to contain the crossorigin attribute, see CORS-enabled fetches. image and elements with srcset or imageset attributes, SVG elements, CSS *-image rules object elements script elements, Worker importScripts style elements, CSS @import track elements video elements worker Worker, SharedWorker

Looks like we have support for Link tag in /metatag/src/Plugin/metatag/Tag/LinkRelBase.php

This is being used by metatag/metatag_favicons/src/Plugin/metatag/Tag/LinkSizesBase.php

The pattern is different though. It looks like we have support for predefined fields that are not repeatable.

In that sense this requirement is a bit like a custom meta tag in that we can define new attributes on the fly, rather than filling in one of several pre defined fields that are also relevant.

The main difference with custom metatags is:

1. that we assume the link tag is always the same.
2. we support more than 2 attributes

e.g of use of use of link tag uisng an attribute other than rel="preload"

<link rel="icon" href="favicon.ico" />

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link

list of all attributes supported:

1. as
2. blocking (experimental)
3. crossorigin
4. disabled
5. fetchpriority
6. href
7. hreflang
8. imagesizes
9. imagesrcset
10. integrity
11. media
12. referrerpolicy
13. rel
14. sizes
15. title
16. type

Non standard

1. methods
2. target

Obsolete

1. charset
2. rev

Also link attribute supports use of global attributes:

These are:

1. accesskey
2. autocapitalize
3. autofocus
4. class
5. contenteditable
6. data-*
7. dir
8. draggable
9. enterkeyhint
10. exportparts
11. hidden
12. id
13. inert
14. inputmode
15. is
16. itemid
17. itemprop
18. itemref
19. itemscope
20. itemtype
21. lang
22. nonce
23. part
24. popover
25. role
26. slot
27. spellcheck
28. style
29. tabindex
30. title (same as above )
31. translate
32. virtualkeyboardpolicy (experimental)

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attributes

Looking at the schema for field_metatags_value it looks a bit like this:

{
"image_src": "[node:field_picture:entity:field_media_image]",
"og_image": "[node:field_picture:entity:field_media_image]",
"og_image_secure_url": "[node:field_picture:entity:field_media_image]",
"og_image_url": "[node:field_picture:entity:field_media_image]",
"twitter_cards_image": "[node:field_picture]",
}

Notice the relationship here is one to one i.e. each key has a single value. In this case each item is a token.

What I think might be required here is to be able to pass an associative array of items.

e.g. for <link rel="preload" href="style.css" as="style" />

"link_preload": [ 
  "href" : "[site:css-path]",
  "as" : "style",
  "on" : "null",
  "media" : "null",
  "crossorigin" : "null",
  "type": "null",
]

Notice in this example we may also need a token for [site:css-path], (if this doesn't exist already).

for <link rel="preload" href="main.js" as="script" />

We may need a similar [site:js-path] token

Whats interesting about <link rel="stylesheet" href="style.css" /> is that the rel attribute is different. Of course this is handled by drupal front end theme already, but it begs the question, do we need to make the relative attribute configurable as well?

Possible relationship values listed here. Certainly there are a number of them that can be applied to the link tag:

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel

for example 2 <link rel="preload" href="flower.avif" as="image" type="image/avif" /> we could have something like:

"link": [ 
  "rel" : "preload",
  "href" : "[node:field_picture:entity:field_media_image]",
  "as" : "image",
  "on" : "null",
  "media" : "null",
  "crossorigin" : "null",
  "type": "image/avif",
]

In this example it would also be good to have a token for the image type e.g. [node:field_picture:entity:field_media_image:type]

we do have [node:field_image:entity:extension]

for example 3 - cors enabled fetches

e.g.

<link
    rel="preload"
    href="fonts/cicle_fina-webfont.woff2"
    as="font"
    type="font/woff2"
    crossorigin />

something like:

"link": [ 
  "rel" : "preload",
  "href" : "fonts/cicle_fina-webfont.woff2",
  "as" : "font",
  "on" : "null",
  "media" : "null",
  "crossorigin" : "true",
  "type": "font/woff2",
]

Finally for media e.g.

<link
    rel="preload"
    href="bg-image-narrow.png"
    as="image"
    media="(max-width: 600px)" />
  <link
    rel="preload"
    href="bg-image-wide.png"
    as="image"
    media="(min-width: 601px)" />

something like:

"link": [ 
  "rel" : "preload",
  "href" : [node:field_image:large],
  "as" : "image",
  "on" : "null",
  "media" : ""(max-width: 600px)",
  "crossorigin" : "null",
  "type": "null",
]

So here we have the challenge of multiple attributes all with the same name.

So perhaps this might be a better schema.

"link": [
  0 => [ 
    "rel" : "preload",
    "href" : [node:field_image:small],
    "as" : "image",
    "on" : "null",
    "media" : ""(max-width: 600px)",
    "crossorigin" : "null",
    "type": "null",
  1 => [
    "rel" : "preload",
    "href" : [node:field_image:large],
    "as" : "image",
    "on" : "null",
    "media" : "(min-width: 601px)",
    "crossorigin" : "null",
    "type": "null",
  ]
]

So in this example we end up with something like:

{
  "image_src": "[node:field_picture:entity:field_media_image]",
  "og_image": "[node:field_picture:entity:field_media_image]",
  "og_image_secure_url": "[node:field_picture:entity:field_media_image]",
  "og_image_url": "[node:field_picture:entity:field_media_image]",
  "twitter_cards_image": "[node:field_picture]",
  "link": [
    [ 
      "rel" : "preload",
      "href" : [node:field_image:small],
      "as" : "image",
      "on" : "null",
      "media" : "(max-width: 600px)",
      "crossorigin" : "null",
      "type": "null",
    ],
    [
      "rel" : "preload",
      "href" : [node:field_image:large],
      "as" : "image",
      "on" : "null",
      "media" : "(min-width: 601px)",
      "crossorigin" : "null",
      "type": "null",
    ]
  ]
}

reworked slightly to:

1. allow classes to be applied to row without need for default classes to be enabled (this assumes the default class is view-content.
2. Allow default container class to be enabled or disabled. The default is to enable.
3. Along similar lines, added support to allow default "empty" container class to be enabled or not. The default is to enable.
4. Reworked descriptions. Explain that custom classes can be separated by space if using more than one.

Previously the custom row class would only work if the default value was selected.

Created Search API views ajax module that works as described, e.g. no pagination

https://www.drupal.org/project/search_api_views_ajax →

fixes white space

Just a note, although not overridden by display, these settings seem to be overridden by type of display. e.g. block, page etc (which is good)

Just to follow up on this I believe that a class should be able to be added on a view by view basis. I have created a core issue for this:

https://www.drupal.org/project/drupal/issues/3450377 📌 Remove dependency on hardcoded classes in views template Needs work

To help get the ball rolling I have created an issue for creating a module that supports the use of rel=preload attribute in head using link tag

https://www.drupal.org/project/metatag/issues/3450705 ✨ Add preload Meta as a submodule (Preload Metatags UI) Active

2dareis2do → created an issue.

+1 #16

Re-upload #13 patch as my composer expects patch to be relative to the core install.

I have a peculiar issue with one view that is filtered by a certain content type. For some reason it appears to only show half of the required items! If I switch the content type then it appears fine.

Also, with this same view, the more link has disappeared from the block version of this view. Applying this patch seems to fix the more link issue for me.

Many thanks

fix undefined array error

There might be a use case for a preload metatag submodule

as determines the type so I think that is required.

Probably more than 2 attributes are required:

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload

Added patch that allows you to set the row container class form views style options

Ok so with the following string/token

https://i0.wp.com/www.brixtonbuzz.com/wp-content/uploads/2024/05/streatham-food-1.jpg" as="image

I am able to generate:

<link rel="preload" href="https://i0.wp.com/www.brixtonbuzz.com/wp-content/uploads/2024/05/streatham-food-1.jpg&quot; as=&quot;image">

However browser is still complaining:

<link rel=preload> cannot have the empty string as `as` value

So I guess as="image" might be confusing it. Not sure.

Sorry, i was still on 1.x

updating to 2 and fatal error is no more!

So as mentioned I am trying to get the custom attribute as mentioned above

If I enter

[node:field_picture:entity:field_media_image]" on="image, test" on="image

I get the following output:

<link rel="preload" href="&quot; on=&quot;image">
<link rel="preload" href="&quot;test&quot; on=&quot;image">

So it seems that token is not being replaced and the quotes are a bit strange. Also it took me a while to figure out how to get that far!

2dareis2do → created an issue.

2dareis2do → created an issue.

I am trying to add the following custom meta tag:

<link rel="preload" as="image" href="image.webp">

Patch applies without issue.

After enabling this metatag submodule, I have option to create custom metatag. I am not sure how or if I can create my custom tag? See attached screenshot.

When trying to add new custom metetag I am getting the following:

Fatal error: Trait "Drupal\metatag\MetatagSeparator" not found in /var/www/html/web/modules/contrib/metatag/metatag_custom_tags/src/Plugin/metatag/Tag/MetaTagCustomTag.php on line 35

Looking at the codebase and change I cannot find any MetatagSeparator class?

https://git.drupalcode.org/project/metatag/-/merge_requests/94.diff

2dareis2do → created an issue.

2dareis2do → created an issue.

Thanks Cilefen.

Yes that looks very similar but there is no patch there afaict.

Actually https://www.drupal.org/project/token/issues/2924873#comment-15605052 🐛 Summary token not fully handled in fields Needs review seems to work with some modifications.

Looks like this is contrib issue.

This patch kind of works for me. I have a field name field_feed_item_description which is of type "Text (formatted, long, with summary)" The logic did not apply with the following conditions:

isset($field_item->$property_name) && $field_item instanceOf TextWithSummaryItem

actually i discovered in my case that field_item is

$field_item instanceOf Drupal\text\Plugin\Field\FieldType\TextItemBase

Also isset($field_item->$property_name)

is sort of like saying

isset($field_item->summary)

in web/core/modules/node/node.tokens.inc

we have the following logic:

            // If the summary was requested and is not empty, use it.
            if ($name == 'summary' && !empty($item->summary)) {
              $output = $item->summary_processed;
            }

So my feeling is $field_item->summary is not always available.

2dareis2do → created an issue. See original summary → .

What I would add is that trim_length is not exposed as an option if not using either trimmed or summary and trimmed setting.

It seems rather crude that every image, including those above the line have loading="lazy" added by default.

https://webtips.dev/how-to-lazy-load-images-with-intersection-observer

As an alternative to a base theme, I have created a custom theme starter kit.
The benefit of a starter kit is it provides all the tools needed to get you quickly started, without the added complexity of inheriting from a a base theme. I believe this approach is more optimal as well, i.e. less theme overrides. You also get to manage what assets are complied and included.

https://www.drupal.org/project/bootstrap_sass_starter_kit →

Just to follow up on my previous comment when applying custom styles to header tags, h1, h2, h3 etc, the only way i could get it to work on another theme was to load the whole of bootstrap (including css reset/normalise etc).

Very strange.

I have had this issue with a couple of sites now. i.e. index.php showing on Plesk web-server with being served with both Apache and Nginx. As soon as redirect module is enabled the 'index.php' part of the url goes away.

Erratic.

#57 looks interesting.

(On plesk, favicon.ico is also used/loaded from admin ui when available now. see https://docs.plesk.com/release-notes/obsidian/change-log/#plesk-18057)

expand

Ok I have looked at this. I think this really belongs with the settings for the 'content' region but that is handled through a loop so not easy to insert. Possibly easier to remove from there and put here. Not sure.

I have renamed Container to Main to try and clarify that this only applies to the main region (that also includes content)

The other thing I have done is to hide the add class setting form element if the region is set to use a clean region. This is due to the fact that regions classes do not seem to be output if a clean wrapper is selected. There is probably a way to handle this asynchronously (hide/show) but I have just done if for page load for now.

I have checked and class is being applied. See attached

What is interesting here is that the header only supports fluid and fixed width i.e. container and container-fluid classes. Perhaps they shoudl support the same as the body?

From what I can tell the main difference here is how the layout adjusts at smaller viewports. max-width is the same apart from fluid, which is set at 100%.

https://getbootstrap.com/docs/5.3/layout/containers/#how-they-work

Thanks.

I updated search block config. Key was wrong

Ok, looking at standard install profile it does seem like search is enabled by default. It probably does make sense to show this by default as well.

I have made a few changes around here. This is limited by what Drupal offers out of the box in terms of theming elements. Certainly tools like formdazzle or other template suggestions might help improve the specificity of templates used and hence can be fine tuned. e.g. perhaps a suggestion that distinguishes a search menu block from a search block (i.e. just an form with input field and button) may help to improve how this works.

Anyway here are the changes:

1. Removed duplicate search boxes being shown (narrow, wide)
2. Moved to show search block in primary nav
3. Realigned items including user nav. the me-auto class here sets the alignment. (interestingly of the first search input is too wide on the style guide (nav item) this can be set with width auto to improve things here)
4. Made secondary colour to be default
5. Added more colours to choose from (buttons)

attaching screenshots showing un-styled search block

I have decided to remove the duplicate entries for now. Also moving to default to primary menu as per getbootsrtap site.

My feeling is some additional theming may be required to get this to look as it should.

Will leave this ticket open for now with that in mind.

Hi Ravi

Thanks for the feedback.

Is this just an issue with search block?

Personally I am using solr with search_api. I have tried enabling search block and cannot reproduce

That is is I can place search block in either region

What I do see is that it looks like search block is enabled in

config/optional/block.block.bootstrap_sass_starter_kit_search_form_wide.yml

e.g.

langcode: en
status: true
dependencies:
  module:
    - search
  theme:
    - bootstrap_sass_starter_kit
id: bootstrap_sass_starter_kit_search_form_wide
theme: bootstrap_sass_starter_kit
region: top_header_form
weight: -7
provider: null
plugin: search_form_block
settings:
  id: search_form_block
  label: 'Search form (wide)'
  label_display: '0'
  provider: search
  page_id: ''
visibility: {  }

Perhaps it has been added twice, once by you ad once by the install config ? Maybe check your regions and layout for the theme.

Perhaps I could simply remove this as search is not enabled by default in Drupal afaict.

2dareis2do → created an issue.

My ide is not helping me with these syntax errors e.g. for templates/commerce/checkout/commerce-checkout-order-summary.html.twig and it looks ok to me at first look.

rector error

bootstrap_sass_starter_kit - themes/contrib/bootstrap_sass_starter_kit/templates/commerce/checkout/commerce-checkout-order-summary.html.twig:
+----------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| severity | line | message |
+----------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| error | 31 | Twig template themes/contrib/bootstrap_sass_starter_kit/templates/commerce/checkout/commerce-checkout-order-summary.html.twig contains a syntax error and cannot be parsed. |
+----------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Code:

{#
/**
 * @file
 * Default theme implementation for the checkout order summary.
 *
 * The rendered order totals come from commerce-order-total-summary.html.twig.
 * See commerce-order-receipt.html.twig for examples of manual total theming.
 *
 * Available variables:
 * - order_entity: The order entity.
 * - checkout_step: The current checkout step.
 * - totals: An array of order total values with the following keys:
 *   - subtotal: The order subtotal price.
 *   - adjustments: An array of adjustment totals:
 *     - type: The adjustment type.
 *     - label: The adjustment label.
 *     - total: The adjustment total price.
 *     - weight: The adjustment weight, taken from the adjustment type.
 *   - total: The order total price.
 * - rendered_totals: The rendered order totals.
 */
#}
<div{{ attributes.addClass('checkout-order-summary', 'table-responsive-sm') }}>
  {% block order_items %}
    <table class="table table-striped table-hover table-sm">
      <tbody>
      {% for order_item in order_entity.getItems %}
        <tr>
          <td>{{ order_item.getQuantity|number_format }}&nbsp;x</td>
          {% if order_item.hasPurchasedEntity %}
            <td>{{ order_item.getPurchasedEntity|commerce_entity_render('summary') }}</td>
          {% else %}
            <td>{{- order_item.label -}}</td>
          {% endif %}
          <td>{{- order_item.getTotalPrice|commerce_price_format -}}</td>
        </tr>
      {% endfor %}
      </tbody>
    </table>
  {% endblock %}
  {% block totals %}
    {{ rendered_totals }}
  {% endblock %}
</div>

Ok I have decided to create https://www.drupal.org/project/bootstrap_sass_starter_kit →

This is a turnkey that allows you to set up and start using a custom theme in 5 minutes. The difference from "bootstrap sass" is it allows you to create a new custom theme that utilises bootstrap sass without having to depend on a base theme.

@ravi, feel free to check it out and see what you think.

Added related issue that also mentions packaging info having to be deleted

2dareis2do → created an issue.

Sorry the issue with create_subtheme.sh is actually with bootstrao_sass

bootstrap _barrio seems to handle this.

e.g.

if [[ "$OSTYPE" == "darwin"* ]]; then
  grep -Rl bootstrap_barrio_subtheme .|xargs sed -i '' -e "s/bootstrap_barrio_subtheme/$CUSTOM_BARRIO/"
else
  grep -Rl bootstrap_barrio_subtheme .|xargs sed -i -e "s/bootstrap_barrio_subtheme/$CUSTOM_BARRIO/"
fi

Yes, there are some things (not everything) worth keeping from Barrio. These can be copied across if needed. My feeling is this can be slimmed down and simplified considerably.

To start with it is probably easier to as you say, clone everything.

I would also look to simplify and possibly remove:

1. colour scheme settings from UI and overrides
2. option to load via cdn
3. installation of twitter bootstrap via composer
4. setting classes by region (keep this is templates)

We can still use sed to create the new theme from the starter-kit similar to how we are doing with bootstrap_sass.

Ultimately I believe it should be much easier to get started with creating, customising and creating your own custom theme.

Thankyou

Actually it's better not to add

in templates/views/views-view-unformatted.html.twig
and templates/views/views-view-masonry.html.twig

because infinite scroll will insert multiple rows.

A better approach is to provide a template suggestion for the container template based on available theme suggestions if available

e.g.

function MY_SASS_THEMENAME_theme_suggestions_container_alter(array &$suggestions, array $variables)
{
  $container = $variables['element'];
 
  if (isset($container[0]["#theme"])) {
    $suggestions[] = 'container__' . end($container[0]["#theme"]);
  }


}

Then I can make sure 'row' class is added there

e.g.

{#
/**
 * @file
 * Theme override of a container used to wrap child elements.
 *
 * Used for grouped form items. Can also be used as a theme wrapper for any
 * renderable element, to surround it with a <div> and HTML attributes.
 * See the @link forms_api_reference.html Form API reference @endlink for more
 * information on the #theme_wrappers render array property.
 *
 * Available variables:
 * - attributes: HTML attributes for the containing element.
 * - children: The rendered child elements of the container.
 * - has_parent: A flag to indicate that the container has one or more parent
     containers.
 *
 * @see template_preprocess_container()
 */
#}
{%
  set classes = [
    has_parent ? 'js-form-wrapper',
    has_parent ? 'form-wrapper',
    has_parent ? 'mb-3',
    'row',
  ]
%}
<div{{ attributes.addClass(classes) }}>
  {{ children }}
</div>

Looking at this again I believe that the only reason to use row class is in a list view.

For this reason i think it is beneficial to as row class to a direct parent on col class variants where possible.

My solution is to remove other variants of row in the front end theme and to add to parent where we have a list view e.g.

in templates/views/views-view-unformatted.html.twig
in templates/views/views-view-masonry.html.twig

I have modified templates that output row data as follows

e.g.

{#
/**
 * @file
 * Theme override to display a view of unformatted rows.
 *
 * Available variables:
 * - title: The title of this group of rows. May be empty.
 * - rows: A list of the view's row items.
 *   - attributes: The row's HTML attributes.
 *   - content: The row's content.
 * - view: The view object.
 * - default_row_class: A flag indicating whether default classes should be
 *   used on rows.
 *
 * @see template_preprocess_views_view_unformatted()
 */
#}
{% if title %}
  <h3>{{ title }}</h3>
{% endif %}
{% if rows %}
<div class="row">
{% for row in rows %}
  {%
    set row_classes = [
      default_row_class ? 'views-row',
    ]
  %}
  <div{{ row.attributes.addClass(row_classes) }}>
    {{ row.content }}
  </div>
{% endfor %}
</div>
{% endif %}

rows container with row class is output if there are rows to be output