🇦🇹Austria @hudri

hudri → created an issue. See original summary → .

This is not documented because it is not possible. If you want to add this feature to Drupal core, please help fixing issues 2142515 →

hudri → created an issue.

hudri → created an issue.

Hi ibraheem,
I've added some comments in your commit in the issue fork, please see

https://git.drupalcode.org/issue/tailwind_jit-3450150/-/commit/ec8ef5363...

There is no documentation because this simply does not exist. The module is just a "cookie banner", it only does the technical handling of injecting after consent. It does not document or store which users have given consent or when they have given consent.

AFAIK this is also not a requirement of the GDPR. This is something you might want to have to protect yourself in case of GDPR lawsuits, but AFAIK formally not a legal requirement of the GDPR (I'm no lawyer tough, so no guarantees here!)

And IMHO this module should not even do this, because then the module itself stores personalized data again, which opens a whole new can of worms. If you need this level of safety, a commercial CMP might be better suited for your case.

Fixed in version 1.1.2

Hi ibraheem,
thanks for your contribution. An UI input field for the tailwind.config.js would be nice and should work for all users. Just a few smaller things though:

1. We would need to separate config files, one for HTML requests and one for Ajax requests. So we can disable Tailwind's preflight for Ajax requests to reduce the weight of the injected CSS.
2. There is a typo in $form['tailwind_jit']['additinal_config']. Since we would need two inputs anyway, I would suggest somehint like $form['tailwind_jit']['ajax_config_file'] and $form['tailwind_jit']['html_config_file'] instead.
3. Could you please provide a MR instead on a patch file?

Thanks a lot

This is a known issue, and it is not possible to fix this in a meaningful way. Basically the architecture and philosophy of Tailwind and BigPipe are almost exact opposites:

• Tailwind JIT tries to generate a purged, minimized inline CSS on the server as early as possible for a perfectly optimized CSS with an ideal critical CSS rendering path.
• BigPipe renders blocks very late at page end with chunked streaming and injects them with client side JavaScript for a better perceived loading performance

I recommend to disable BigPipe completely. In my experience, the real word performance gain of BigPipe is neglectable. If you have blocks that are very slow, you could load them with "real" async Ajax requests, which a) work with Tailwind JIT and b) actually do deliver a real world performance gain.

Add warning / recommendation not to use services.yml in v10.3

@cyrusliew

Could you please test if the MR / patch fixes your problems?

https://git.drupalcode.org/project/tailwind_jit/-/merge_requests/8.patch

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

Thanks for your report, I'll take a look at it.

On a side note, by architecture using BipPipe with Tailwind JIT has some limitations:

If you've got a page like

<div class="outer_container">
  <span class="bigpiple_placeholder"> <!-- block will be injected here --> </span>
</div>

and CSS with child styles like

.outer_container .inner_style_from_a_bigpipe_replaced_block { ... }

then Tailwind JIT can not detect this inner style style due the structure of the source code. (Nevertheless the blocks need to be replaced properly, I'll check this.)

hudri → created an issue.

MR always removes the image loading setting from views plugin, which makes no sense in the context of an JSON or XML export

hudri → created an issue.

Fixed in v1.1.1

hudri → created an issue.

hudri → created an issue. See original summary → .

This bug is a bit annoying.

Contrib (e.g. Gin) is now copying this bug into their own codebase, just to make Config inspector shut up. And this again breaks theme 3rd party settings for everybody else :(

Olivero (and Gin) are incorrectly overwriting theme third party settings:

https://www.drupal.org/project/drupal/issues/3402885 🐛 [PP-1] olivero.settings config schema is wrong Postponed

"foo" is a path-relative link. Like domain.com/sub1/sub2/sub3 => domain.com/sub1/sub2/foo
"/foo" is a domain-relative link. Like domain.com/sub1/sub2/sub3 => domain.com/foo
Different things, both valid and both have their use cases.

In response to #156, nr. 1-3, please do NOT make any assumptions on link.

"random string" is a valid link. It will be url-encoded to "random%20string" though, but it is a perfectly valid relative url path. This is clearly a user mistake, not a bug. In our projects, we use and need all flavors of relative, absolute and schema links:

current-path-relative-links
/domain-relative-links
https://full-uri.com/link
whatsapp://send?phone=1234
mailto:john@doe.com
tel:01234567890
/taxonomy/[current_node_token:field_foo:entity:id]

Do we need the hard Drush dependency at all in the composer.json file? It is an optional CLI command, not a functional requirement. The module does it's job great via CLI and UI.

I'm proposing to completely remove the drush dependency from composer.json.

All patches and MR here are broken in 10.3.0 and don't work with jQuery UI modals.

#26 seems not relevant to this issue due I-Frame. The issue here is about CKeditor ballons in Ajax modals inside a simple < div >.

#27 does not work, the custom property --ck-z-modal is no longer used in v10.3.0, nor does .ck-body-wrapper have a CSS stacking context due missing position: relative; or similar.

Also the jQuery UI modal receives an inline postion style top: ......px. So even if we set position and z-index, the balloon is still incorrectly positioned from top.

Just for reference, this is how it looks on a non-sticky-table:

This example is from a multi-cardinality paragraph field. Both toggles (weight and columns) are rendered in source code, but only the weight toggle is used/visible (the column toggle is hidden, there is no responsive setting for this table)

Yes, I can still see the same issue on my test instance with 4.0.x, commit b95e4e3

Disabling the functionality is not a solution. This just hides the visual glitch, but also breaks the functionality of the responsive column toggle.

Tests from Drupal commerce users would be helpful, this would cross-check compatiblity with Inline Entity Form module.

I think this is the same as #3455080 🐛 Save button missing in modal for editing media using Media Library Edit module Fixed

I already have created a MR there, spare some time to test it?

My merge requests assumes that Gin content forms should never be used for Ajax requests, because forms in Ajax requests don't render the page template or the local actions block. This fixes it for the media library edit button, and theoretically this should also prevent similar problems with modules like Inline Entity Forms.

My assumption is a fairly broad approch, so feedback is welcome.

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

hudri → created an issue.

Here is a patch file for RC11, suitable for composer patches:

drupal.org/files/issues/2024-06-19/gin_3270626_cherrypick_for_rc11.patch →

Just a cherry-pick of commit ee8cb77e refitted for RC11.
(Please do not use this patch file for issue development, use merge requests to resolve the issue)

This is by design. Tailwind JIT is operating on theme level, so it always should load last, after any CSS from parent themes or modules.

To solve your problem, use the @layer base { ... } directive from Tailwind, which orders your CSS styles.

Or, if you don't want Tailwind's base styles at all, better do not include it in the Tailwind CSS input file:

@tailwind base; // <<< remove this line
@tailwind components;
@tailwind utilities;

Given the popularity of TailwindCSS and other utility class approaches, I think prefix and suffix are not sufficent. Prefix and suffix will cover many use cases, but taking the Tailwind syntax as an example, I would propose using a full regex to cover the following common use-cases:

Arbitrary values in Tailwind:
[100px,200px,300px] ==> min-h-[100px] or min-h-[200px] min-h-[300px]
Max or range breakpoints in Tailwind:
[sm,md,lg] ==> max-sm:hidden or max-md:hidden or max-lg:hidden

I've done something similar in my own custom style option plugin. Would love to see something similar in the module itself:

/**
 * Defines the HTML attribute style option plugin.
 *
 * @code
 * my_example_style_option:
 *   plugin: html_attribute
 *   # Preprocess the value with PHP's preg_place before rendering. E.g. massage an number input field
 *   # to a Tailwind CSS class. In the following example an input "1700" will be rendered as "max-w-[1700px]".
 *   value_preg_replace:
 *     pattern: '/^(\d+)$/'
 *     replacement: 'max-w-[${0}px]'
 * @endcode
 *
 * @StyleOption(
 *   id = "html_attribute",
 *   label = @Translation("Html attribute")
 * )
 */
class HtmlAttribute extends StyleOptionPluginBase {

  /* ... */

  public function build(array $build, string $region_id = NULL) {

    /* ... */

    if ($preg_replace = $this->getConfiguration('value_preg_replace')) {
      $value = preg_replace($preg_replace['pattern'], $preg_replace['replacement'], $value, $preg_replace['limit'] ?? -1);
    }
    if (empty($value)) {
      $value = 'INVALID_PREG_REPLACE_SUBJECT';
    }

    /* ... */

  }
}

Full code here:
https://bitbucket.org/webtourismus/designsystem/src/master/src/Plugin/St...

I've been thinking about this, and I'm currently not planning to merge this.

First I really want to avoid any opinions on the file / directory structure in the module. Some themes might use a ./css subfolder, some themes might even reference and external designsystem completeley outside the theme path.

The 2nd thing is, the upcoming TailwindCSS v4 is planning a CSS-first configuration, which uses the CSS file also for configuration, instead of the tailwind.config.js file. So we might end up with a knob in the UI that is going to be deprecated (or at least not the recommended config method) in a few month.

Thanks for your contribution, I hope the module is still useful for your project.

hudri → changed the visibility of the branch 3445965-disable-message-fields to hidden.

hudri → changed the visibility of the branch 11.x to hidden.

I don't know if this bug can be reliably reproduced and test-cased because of

In code of this service is called readdir() function and the entries are returned in the order in which they are stored by the filesystem (according php documentation).

and

* Because order of templates (related theme hooks) depends on filesystem, it may vary on every environment.

Basically PHP's readdir() has a built-in random behavior.

Given the unintrusive nature of this patch, can we add this without tests?

Ah, thanks for your feedback, I think I got.

But I'm still unsure if we can add this in the current form. If we merge this patch, we would loose the ability to use the @config directive inside a CSS input file. The hardcoded --config=theme_directory/tailwind.config.js from command line option would always overrule a @config "custom_tailwind.config.js" directive inside a CSS file.

I don't think HTMX would help to solve any of this module's issues. For me, the main issues with CookiesJSR are (in order of significance)

-) The CC-ND licence of CookiesJSR. The VueJS variant also is CC-ND licenced. AFAIK I'm not even allowed to ship a patched version of CookiesJSR to my clients. This is a huge problem. So far I could work around patching CookiesJSR's source with "creative" CSS and JS, but for me any code using the CC-ND licence is a problem that needs to be replaced.

-) The jQuery dependency. In our newer v10 projects, Cookies is the only module left still using jQuery. This is a huge footprint just for cookie management. Rewriting the interactions between Drupal/the module and the client component to Vanilla JS would be a much larger performance boost for us, than switchting from React to Vue or whatever JS framework of the day.

Imagine a big gap here :-)

-) The external app / the external build step. To me CookiesJSR is something similar to a carousel JS lib like SplideJS: It is a quite isolated component with a lot of state and logic that needs to run on the client, and not on the server. So I think one externally build JS file is an acceptable tradeoff here.
E.g. I also had to patch SplideJS for my specific needs, but the build step is outsourced into a separate project, and multiple Drupal projects simply pull my patched SplideJS Git tag in composer.json. No NodeJS / extra built step required inside the Drupal project, the Drupal projects are still built- and deployable on any cheap vanilla PHP host. Could imagine doing the same with CookiesJSR.

HTMX primarly helps with client-server-interaction. Cookies just needs an initial initialization/config from the server, and then fully runs inside the client. IMHO this is a good architecture for this use-case, I don't want a server roundtrip after activating a service (group), it should run in the client. So I believe, even when core would switch to HTML, it would not change that much at all for this module. (Actually it should not change anything at all for this module, because we should use only Vanilla JS for interactions Drupal <==> client JS component).

Could you please explain why you need this? There already is the option to specify a tailwind config file by using Tailwind's @config directive, you just need a single one-liner on top of your Tailwind file, e.g.

~/web/themes/custom/my_frontend_theme/my_tailwind_file.css

@config "tailwind.config.js"; /* <== add this on top of your file */

@tailwind base;
@tailwind components;
@tailwind utilities;

.my_custom_styles {
  /* ... */
}

The advantage of this method is that it is not hardcoded, e.g. people using an external style library could pull in stuff from other folders.

Postponed due core's problems with 3rd party settings in themes.

I think I've got a related problem: My module has theme-specific settings. Previously I just my modules config settings into the root of theme.settings.yml. Inspired by the shortcut module, I now wanted to clean this up and move it into third party settings. Basically I wanted to update my config from

third_party_settings:
  shortcut:
    module_link: true
tailwind_jit:
  compile_html_requests: true
  html_input_file: 'foo.css'
  compile_ajax_requests: true
  ajax_input_file: 'bar.css'

to a proper schema

theme_settings.third_party.tailwind_jit:
  type: mapping
  label: 'Tailwind JIT settings'
  mapping:
    compile_html_requests:
      type: boolean
      label: 'Compile HTML requests'
    html_input_file:
      type: path
      label: 'Uncompiled CSS input file for HTML requests'
    compile_ajax_requests:
      type: boolean
      label: 'Compile Ajax requests'
    ajax_input_file:
      type: path
      label: 'Uncompiled CSS input file for Ajax requests'

and proper third party settings

third_party_settings:
  shortcut:
    module_link: true
  tailwind_jit:
    compile_html_requests: true
    html_input_file: 'foo.css'
    compile_ajax_requests: true
    ajax_input_file: 'bar.css'

The form hook is something like

function tailwind_jit_form_system_theme_settings_alter(&$form, FormStateInterface $form_state, $form_id = NULL) {
  $form['third_party_settings']['tailwind_jit'] = [
    '#type' => 'details',
    '#open' => TRUE,
    '#title' => t('Tailwind CSS Just-in-time compilation'),
    '#tree' => TRUE,
    '#parents' => ['third_party_settings', 'tailwind_jit'],
  ];
  $form['third_party_settings']['tailwind_jit']['compile_html_requests'] = [
    '#type' => 'checkbox',
    '#title' => t('Compile HTML requests'),
    '#default_value' => theme_get_setting('third_party_settings.tailwind_jit.compile_html_requests', $themeToBeConfigured),
  ];
  /* ...more form elements here... */
}

This does not work correctly, there are two problems:
1) The schema is not used/validated, the boolean value is still stored as (int) 0 / 1 and not as (bool) true / false
2) When submitting the form, it saves all my values, but wipes the existing config from shortcut module.

Reading @berdir's comment, is shortcut a bad example? Should I avoid third party settings for themes at all?

This issue is closed in favor #3447020 📌 Convert settings to third party settings Active . The module's settings are already living in code in YML in my_theme.settings.yml. The linked issue describes the current schema, and the upcoming change.

hudri → created an issue.

hudri → created an issue.

hudri → created an issue.

I've been testing a bit, the changes from #1038316 📌 Allow for deletion of a single value of a multiple value field Fixed broke a lot of things in Paragraphs. I'm currently getting best results with patch from #2, in multi-lingual and nested scenarios. The patch from #5 has issues with nested paragraphs, in my case the < table >'s expanded horizontally far beyond the container < div >.

This also is a duplicate of #3418303

I believe this is related to (over even the same issue as) issue 3418303 🐛 New structure for template_preprocess_field_multiple_value_form Needs work

Default presentation attributes (fill/stroke/etc) should be moved off from SVG tags if it reduces the weight, and placed as Internal CSS

Please don't do this, especially not in core. I even propose to avoid CSS styles and encourage the use of presentation attributes, as they are very easy to overrule in CSS by contrib+custom modules and themes. To avoid repetition and weight, better use an intermediate group (e.g. <g fill="currentcolor">) instead.

Do not re-enter the dark age of CSS selector specifity battles

.my-custom-admin-sub-theme .gin-theme #contrib-module a svg path.something { color: blue !important; }
.my-custom-admin-sub-theme .gin-theme #contrib-module a:hover svg path.something { color: red !!!!!!!!!important; }

Did you enable the filter in the text filter settings of CKeditor?

/admin/config/content/formats

Wow, kudos to @chOdec for finding this bug.

This bug is a worst-case scenario for DX, because it introduces a random and non-deterministic behavior in template and hook processing.

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

This is not a bug. It is clearly documented on the module's page that you have to render the attributes object in all your templates using LP.

Due this bug it is not possible to activate those options, so I don't think an update hook could reliably fix this.

We are using patch #42 for years now very successfully with many different endpoints. Moving to reviewed & tested.

Migrate sources are so vastly different that - for me - it is much easier and faster to write a PHP callback than to find and study and update 437 different list/item source plugin modules. And very often those plugins are NOT (re-) usable because endpoint A returns an array [] on root, endpoint B returns an object [] on root, endpoint C returns an HTTP-Code 404 when the last page number was passed and endpoint D just returns an HTTP200 with no content. PHP callbacks just work. For years. (Sorry for the rant, but the more different sources you have to migrate from, the more useful this simple patch is.)

+1 from me to include this feature into migrate_plus.

This module is based on a hook / core patch → that actually never made it into core. Instead hook_field_widget_complete_form_alter was introduced in Drupal v9.2 → . But the v10 patch never fixed any of this.

Here is a good link demonstrating unescaped symbols in HTML class names and their represenation inside CSS:

https://mothereff.in/css-escapes

The current patch still is an arbitrary Drupalism, e.g. it still does not allow ampersand or square brackets (which are used in TailwindCSS for inline selectors like [&_.my_child_container:text-red]).

The CSS class validator should follow official specs, not outdated shortcuts. Given the spec allows basically every symbol to be used as class name, maintaining an self-invented allow list is IMHO conceptionally flawed.

Also inadequate encoding (like e.g. the HTML ampersand encoding from &_something<div class="&amp;_something"> must be avoided: The ampersand is a valid symbol inside HTML class names, encoding it to an HTML entity results in an incorrect class name. (CSS itself does backslash prefixed hex encoding when it needs encoding, but encoding inside CSS files follows different rules than encoding CSS class names inside HTML)

hudri → created an issue.

+1 for #6 from ahebrank. Tested ony my local system, it works in a modal window too. Using .visually-hidden should be a safe bet for any theme.

Here is a stale patch file for RC9 for use inside composer.json.

The MR no longer applies beyond dev, the patch file cherry-picked all all of DieterHolvoet's work. Not intented for development!

Fix typo

Added extra steps to @scott_euser's guide for creating a patch of an MR for an older stable release. I'm not a git grandmaster, but I think it is necessary (or at least more fail-safe) to explicitly check out the desired target release and cherry-pick in there, otherwise you might end up with a patch for the dev branch again. I used refs/tags/TARGET_RELEASE instead of a branch name because this way the guide also works with alpha, beta and RC releases.

hudri → created an issue.

@magtak

Could you please try merge request nr. 152 from https://www.drupal.org/project/layout_paragraphs/issues/3417765 and test if it fixes your problem too?