🇵🇱Poland @prauat

Hi, I've just finished porting this module to drupal version 9 and 10, Currently the payment can be done and fixed handling of failed authorization which wasn't detected and checkout process wasn't interrupted resulting with order state change even in case of failed payment.

Testing manual is here, you need t register in sandbox environment:
https://developers.payu.com/en/overview.html

You can also find a testing CC's (credit cards) here https://developers.payu.com/en/overview.html#sandbox_cards

- Fix for most of code style warnings and errors
- Revert of type hinting
- Add type hinting for primitive type string for following methods:

core/lib/Drupal/Component/Utility/Xss.php

-  protected static function needsRemoval(array $html_tags, $elem) {
+  protected static function needsRemoval(array $html_tags, string $elem) {

core/modules/editor/src/EditorXssFilter/Standard.php

-  protected static function needsRemoval(array $html_tags, $elem) {
+  protected static function needsRemoval(array $html_tags, string $elem) {

I don't see a reason why $elem shouldn't be typed here

@murrow yes, but I also see there type hinting removed which @smustgrave mentioned. Why did this type has been removed?

-   * @param string[] $html_tags
+   * @param $html_tags
    *   The list of HTML tags.
-   * @param string $elem
+   * @param $elem

@sourabhjain, @murrow are you taking care of this patch or should I do it as I'm in need of that functionality?

Patch fixing everything except README.md code example

prauat → created an issue.

Patch with suggestions applied.

Second patch with suggestions applied.

prauat → created an issue.

Patch with solution

prauat → created an issue.

Thanks, patch applied

Thanks, patch applied

Hi @dalemoore against which version you've been trying to apply patch?

To be honest I haven't been digging deeper into cause of this, but yes my current twig is "twig/twig": "^3.4.3".

@jannakha no it's not adding configurable classes should be preferred solution instead of adding more and more CSS which is then removed in various fixes. Moreover you're sacrificing the ease of use for normal user because when making subtheme advanced users can change regions?

What about settings that are not used anywhere but still display on settings page?
https://git.drupalcode.org/project/bootstrap5/-/blob/1.1.x/src/SettingsM...

$form['body_details']['b5_top_container_config'] = [
      '#type' => 'textarea',
      '#title' => t('Website container type configuration'),
      '#default_value' => theme_get_setting('b5_top_container_config'),
      '#description' => t("Format: <classes|label> on each line, e.g. <br><pre>container|fixed<br />container-fluid m-0 p-0|fluid</pre>"),
    ];

Correct me if I'm wrong but what is the purpose of this? As I haven't found it anywhere in the code beside SettingsManager.

At last for customize CSS I though that bootstrap is used to limit bothering with CSS to minimum and reuse prepared CSS.

Please forgive me I've forgot about phpcs because being in rush to deploy website.

@ressa Yes.

Interesting feature. I wonder if Drupal core allows something like this. Did you check that?

I just got in very similar situation where making drupal authorization backend was the fastest option and faced the same problem. In answer to your question, yes that's possible. Thanks to using service decoration that is mentioned here dynamic services and decoration → . Patch for this functionality included for 2.3.x.

@smustgrave Can you tick this as reviewed?

CarlyGerard
She/Her/Hers
CreditAttribution: CarlyGerard at Western Washington University commented 2 months ago

Since this seems to be an overall review of the $adminTags variable and allowed elements in general, I'd like to propose the element be considered as allowed markup in addition to the , , and
tags.

There are tickets like https://www.drupal.org/project/drupal/issues/3217767 → that have expressed a want for it, and use cases in our Drupal instance where the element gets stripped away from patterns because it's not an allowed tag--causing developers to create hacky or less accessible workarounds when a native should be used.

I'm not sure if that suggestion needs a new ticket since this covers "new html5 elements," but figured I should throw it out there anyway so it's at least known and can be addressed.

<button> tag should be definitely added to list of allowed tags, moreover I don't see any specific reason why it's not allowed. It's allowed by full html text format. Lack of <button> tag produces strange situation where placing simple button on a page needs tricky hacks. Since all content produced by Global: Custom Text gets filtered button is removed from field content even if it was previously allowed by text format, but if instead of using fields content is displayed by views it's allowed.

Now let's assume that <button> is not allowed and try to change it to <a> for example in content type body managed by CKEditor5 so from:

<button class="rounded-pill btn-rounded" type="button">
   Label
   <span><i class="fas fa-arrow-right"> </i></span>
</button>

we change to that:

<a class="rounded-pill btn-rounded">
   Label
   <span><i class="fas fa-arrow-right"> </i></span>
</a>

But one of CKEditor5 filters is correcting HTML to take care of user publishing content and instead of wanted markup we get:

    <a class="rounded-pill btn-rounded" type="button">Label&nbsp;</a>

This time CKEditor5 filtered <span> and <i> changing it to   but if we use <button> CKEditor5 lefts syntax intact.

Why placing simple <button> on site when using fields is almost impossible when using fields?

I forgot about patching bootstrap layout builder you need this patch for D10 compatibility.
You also need to patch bootstrap styles 📌 Fix Drupal 10 Change of JS jquery/once to Drupal core/once, migrate JS API Fixed but you've already seen it.