Campinas
Account created on 13 October 2015, over 9 years ago
  • Software Architect at CI&T 
#

Merge Requests

More

Recent comments

🇧🇷Brazil renatog Campinas

Aware about patch link on #41 however if MR is updated the patch is updates as well

So uploading the same patch in a file to avoid being updated. So it can be used on composer if needed

🇧🇷Brazil renatog Campinas

Sorry @renatog for removing the AJAX URL by mistake

No problems at all

I have added that back and working fine for me please review

Thank you so much! It's really a great start!

However I was thinking about an checkbox in the admin area
Example:
Go to accordion "Don't show again"
A new dropdown called: "Don't show again when:"
Two options:

  1. Marked the checkbox and right button clicked (default)
  2. Marked the checkbox and Modal closed by any means

The option #1 will continue as today (apply cookie only if checkbox is Marked and clicked in the right button)
If the user selects option #2 when close the Modal the logic on this MR would be applied, you know?

🇧🇷Brazil renatog Campinas

Nice catch! Thanks for reporting

🇧🇷Brazil renatog Campinas

Thanks for your effort on this! It's amazing

But the AJAX url has been removed intentionally?

/modal/ajax/hook-modal-submit

🇧🇷Brazil renatog Campinas

@ytsuhako I'm facing the same issue

aligns with CKEditor 5's behavior

Aware that is from CK side but did you have any solution on that?

Alternative, workaround, etc?

🇧🇷Brazil renatog Campinas

Moved to the dev branch

Thanks everyone

🇧🇷Brazil renatog Campinas

Update

🇧🇷Brazil renatog Campinas

Knowing that the right button allows to redirect to another URL, the important thing should be: Did I check the 'Don't show again' box, whatever button I choose to close the modal

Good catch

There is also a scenario where the end-users can mark the "don't show again" and closing the Modal using the ESC key or clicking outside. So it'll be closed without clicking in right or left button

I think would be great if has an option to consider the "don't show again" on these cases as well

I'm converting this issue into a "feature request" so we can have this idea mapped to be implemented in the future

🇧🇷Brazil renatog Campinas

It's a really interesting point

When created we assumed that the right button was the "OK button" and left button was like a "Cancel button"

For this reason the "Don't show again" was working only with the right button, you know?

However I think it's a interesting feature

Like, inside of configuration of "Don't show again" we can set if it would be applied by right button, left button or maybe both buttons

What do you think, is that makes sense?

🇧🇷Brazil renatog Campinas

Perfect!

So team can use via composer with composer require 'drupal/invite:3.0.x-dev@dev'

Next step we can create a beta version based on 3.0.x

Thank you so much @kensae

🇧🇷Brazil renatog Campinas

Ok, thanks for your effort on this

Moved to the dev branch 3.0.x. Honestly, I didn't finish all tests yet, but I don't want to block anyone on this. So moving to the dev branch can helps some people that want to test via composer, etc

Do you think is necessary anything else on this branch of it's everything done from your side?

🇧🇷Brazil renatog Campinas

does not apply to latest dev branch

So I think we can mark as "Needs Works", right?!
Plan is merge that into 3.0.x branch
If can't be merged now is necessary effort to fix that
So lets mark as NR to track that
If someone needs, can create a patch file to be applied on 3.0.0 via composer
However the MR should be merged into dev branch, so IMHO makes sense mark that to work

🇧🇷Brazil renatog Campinas

Thanks for merging that @jaseerkinangattil

Curiosity: I saw that was committed but the issue status still as "Needs Review". Is there something pending, or we can close as "fixed"?

🇧🇷Brazil renatog Campinas

Merged into dev branch

Thank you so much, everyone

🇧🇷Brazil renatog Campinas

Thanks for your feedback @zigazou

translation of "Add another class" and "Remove last added class" could be included as well

This one has been fixed at 🐛 Some button labels are not translatable Active

🇧🇷Brazil renatog Campinas

I'll work on the issue branch in this issue?

Can be

Unfortunately I don't have permission to add you as a co-maintainer yet
However, I just created the new branch 3.0.x-dev specifically for you
Feel free to create MR and patches pointing to this branch
I'll help merging them
When it's finished, we can release a beta-version

🇧🇷Brazil renatog Campinas

I'm a current maintainer (a little away from this project due to busy agenda) but if you want to contribute we can create a branch and I'm available to merge that

🇧🇷Brazil renatog Campinas

Good catch! Makes sense!

Could someone create a merge request with the same fix of this patch, please?

https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr...

With that we can merge easily though the GitLab UI, you know?

🇧🇷Brazil renatog Campinas

Hello @zigazou, thanks for reporting

Seems that is a duplication of 🐛 Missing div closing tag breaks block config layout Active

On issue above has a merge request. If possible could you confirm if that solution works for you, please?

If yes, feel free to mark as RTBC and we can merge that soon

Best regards

🇧🇷Brazil renatog Campinas

Ah, sorry @renatog, please rebase MR to 2.x branch

Got it, no problems

It's done!
MR rebased and now the target points to 2.0.x

🇧🇷Brazil renatog Campinas

MR Merged with '8.x-1.x'

🇧🇷Brazil renatog Campinas

No problems at all. Btw, thanks for reporting and providing the patch

I hope that we can commit soon

Best regards

🇧🇷Brazil renatog Campinas

Seems good

Merged to the dev branch

Thanks everyone

🇧🇷Brazil renatog Campinas

renatog made their first commit to this issue’s fork.

🇧🇷Brazil renatog Campinas

Really? 🤔

For me it's appearing as mergeable ( ref )

Ready to merge by members who can write to the target branch

Screenshot attached:

🇧🇷Brazil renatog Campinas

It’s expected. Only 3.0.x and 4.0.x are supported and anyone will commit on 8.x-1.x or 2.0.x anymore

Details

  • 3.0.x is based on 8.x-1.x
  • 4.0.x is based on 2.0.x
  • Only 3.0.x and 4.0.x will receive updates
  • Old versions won’t receive new commits anymore
  • Honestly I understand your point about the message of “unsupported”
  • But I can’t mark as “Supported by Maintainers”
  • Because is not true, since anyone will update these branches anymore
  • And If mark as “supported” it covers security policy
  • So would be necessary overhead duplicating effort applying fixing on these old versions
  • I’m sorry about the message of “not supported” but it’s the truth
  • If someone needs to remove the message My recommendation is updating as mentioned on Matrix - Upgrade Guidance

* If you are on 2.0.x: Upgrade to 4.0.x
* If you are on 8.x-1.x: Upgrade to 3.0.x

🇧🇷Brazil renatog Campinas

Yes, I think it makes sense for me

🇧🇷Brazil renatog Campinas

I didn't increment the hook_update because i don't have any table called "modal"

But the idea of this hook_update is set the default of this new field for all existent modals, you know?

  • So let's imagine that one website has 10 modals
  • This field don't exists yet
  • After this update, the field will be there
  • But should have a "default value" right?
  • For example, false, or 0
  • So, Maybe we need to create a hook update that:
  • A) Will load all Modals
  • B) Will set the default value for this new field (false or 0, etc)
  • C) Save
🇧🇷Brazil renatog Campinas

Verified that on MR we updated an existing hook_update, right?!

On this case we need to create a new exclusive hook update, because we can have websites running in production that already executed all pending hook updates, and this hook won’t be executed again

So, if possible, I’d suggest creating a new hook updated specifically for this

🇧🇷Brazil renatog Campinas

Amazing! Let’s test it

Thank you so much Vanessa! Really appreciates your contribution

🇧🇷Brazil renatog Campinas

In the function ModalPageService::loadModalsToShow(), is it possible to make a change ?
Change:

$modalsToShow[] = $modalToShow;
by

if($modalToShow)
$modalsToShow[] = $modalToShow;

Yes, it's possible

I'd suggest making this change in your local
If it works feel free to post a patch or Merge Request
We can test for other scenarios
If it works we can merge that into 5.x and 6.x

🇧🇷Brazil renatog Campinas

Interesting

You can have 1 modal on CMS that appears for 2 domains?

Like:

  • mydomain_modal1
  • mydomain_modal2
  • mydomain_modal3

And others

  • mydifferentdomain_modal1
  • mydifferentdomain_modal2
  • mydifferentdomain_modal3

And you have 2 sites using the same CMS?

Like

  1. www.mydomain.com
  2. www.mydifferentdomain.com

Is that?

How it works? Like multisites or using platform that has one module for 2 sites?

Asking just as a curiosity. Maybe we can think about a feature to allow this natively instead of hook, you know?

🇧🇷Brazil renatog Campinas

Good catch

I think we should update here: https://git.drupalcode.org/project/modal_page/-/blob/5.1.0/modal_page.in...
To ^10.3

Or remove this dependency: https://git.drupalcode.org/project/modal_page/-/blob/5.1.0/modal_page.in...

You're right

I don't remember why we have this dependency on 'drupal:system (>= 10.3)'

Will be necessary investigate better

Anyway, I'm not sure if it's critical. Maybe you can't install Modal, but I wouldn't break the site for example

If you have a different opinion why do you think it's critical, please let me know

🇧🇷Brazil renatog Campinas

Awesome! Really appreciated!

Let's test that

Thank you so much

🇧🇷Brazil renatog Campinas

Thanks for reporting @joseft40

The proposed solutions seems good

I'm busy in the last days but if you're able to provide a patch it'll be very useful

🇧🇷Brazil renatog Campinas

I see in my drupal /admin/modules/update the recommended version 3.0

Yes, probably it's because of sequence number on semver

In the release notes of 3.0.x asks to upgrade from 8.x: https://www.drupal.org/project/block_class/releases/3.0.0

Upgrade from 8.x-1.x:
If you are using 8.x-1.x-dev or 8.x-1.4 versions of the module, then you should consider upgrading to respectively 3.0.x-dev and 3.0.0

please then also make it so, that people with the 2.0.12 version see as recommended version 4.0

I marked 4.0.x as recommended by maintainer
Let's see if it helps

I will update to version 4.0 because of the explanation of this thread. Thanks!

Great! My pleasure

🇧🇷Brazil renatog Campinas

just upgraded successfully to v4.0

Amazing! I'm happy to help

thank you for your fast clarification

My pleasure

🇧🇷Brazil renatog Campinas

FYI: Added a Matrix of compatibly and a guidance for the upgrade: https://www.drupal.org/project/block_class#matrix

Any feedbacks on this guideline feel free to let me know

🇧🇷Brazil renatog Campinas

Hello @nojj

Added the orientation at Matrix of compatibility: https://www.drupal.org/project/block_class#matrix

Summary:

  • Had a confusion on release version
  • We had 1.x and 2.x
  • 3.x created from 1.x
  • Users on 2.x that upgrade to 3.x did a downgrade
  • So the recommendation is: if you're on 2.x update to 4.x
  • More info at 📌 2.x release vs 3.x release: Which should I use? Active
🇧🇷Brazil renatog Campinas

As agreed, created 4.0.0 based on 2.x

🇧🇷Brazil renatog Campinas

Please don't merge yet, I'm improving a little bit the MR

I'll move as Needs Review when it's done

🇧🇷Brazil renatog Campinas

Please don't merge yet, I'm improving a little bit the MR

I'll move as Needs Review when it's done

🇧🇷Brazil renatog Campinas

Please don't merge yet, I'm improving a little bit the MR

I'll move as Needs Review when it's done

🇧🇷Brazil renatog Campinas

+1 on this -- please make the 2.x version have a bigger number than the downgraded 3.x version!
Ok, I'm on it

🇧🇷Brazil renatog Campinas

maintainer should release a 4.x being just 2.x but with a higher version

I can help on this ☝️

Context:
I'm a maintainer
However a little away from the project in the last months due to busy agenda on my other projects
I wasn't the responsible for creating 3.x from 1.x
But I agree with on this initiative, as mentioned on #4
So if you agree I can go ahead with suggestion #10 and releasing 4.x from 2.x

🇧🇷Brazil renatog Campinas

Maybe we should add ^10.3 on the .info and composer.json as the 10.2.x is not supported

But the check that you introduced is also valid

Yes, the check is like a fallback just to avoid break someone, but agreed that the info update, would be nice

If you can report an issue, will be really appreciated. If not I can do this later

I also added a Matrix in the project page to help with the supported version

🇧🇷Brazil renatog Campinas

Moved to the dev branch

Thanks everyone

🇧🇷Brazil renatog Campinas

Issue above is fixed at 🐛 Render plain image is deprecated Needs work

Tested and it's really working fine

🇧🇷Brazil renatog Campinas

After using code from MR I open "/admin/structure/modal/add" and there is a unexpected error

Error: Call to undefined method Drupal\Core\Render\Renderer::renderInIsolation() in Drupal\modal_page\Form\ModalForm->form() (line 118 of /app/web/modules/contrib/modal_page/src/Form/ModalForm.php).

Drupal 10.2.7

🇧🇷Brazil renatog Campinas

Rolling back to NR, because seems not related to this MR

🇧🇷Brazil renatog Campinas

After using code from MR I open "/admin/structure/modal/add" and there is a unexpected error

Error: Call to undefined method Drupal\Core\Render\Renderer::renderInIsolation() in Drupal\modal_page\Form\ModalForm->form() (line 118 of /app/web/modules/contrib/modal_page/src/Form/ModalForm.php).

🇧🇷Brazil renatog Campinas

Thank you for reviewing @renatog

My pleasure! Appreciated your effort on this @eduardo-morales-alberti

Are there any pending issues?

Not from my side. It's ready to be reviewed?

On #7 you marked as "Needs work"
On #8 you updated the MR but the status wasn't updated to "Needs Review" so I assumed that was pending something else
If everything is ok, please update to NR and we can test that and move forward

🇧🇷Brazil renatog Campinas

Merged to the dev branch: 6.0.x

Since it's a considerable milestone we're going to create a beta-version based on 6.x and keep the stable on 5.x

After a time when it's tested by users, we'll make 6.x stable

Thanks everyone, it's amazing

🇧🇷Brazil renatog Campinas

Any news? we tested it, and works properly

Tested and confirmed that it works fine

🇧🇷Brazil renatog Campinas

Do you know if this problem happens in the last stable version as well?

@ex-dj ?

🇧🇷Brazil renatog Campinas

Moved to the dev branch

Thanks for the nice catch

🇧🇷Brazil renatog Campinas

If we want to maintain drupal 9, then we should check if renderInIsolation exists, but supporting drupal 9 and 11 is not recommended

Agreed

Tested and works well

🇧🇷Brazil renatog Campinas

Nevermid, I saw that the rest of logic and really makes sense this logic

🇧🇷Brazil renatog Campinas

Hey Eduardo, thanks for your effort helping Modal project

About your update on MR, seems that we can reduce one condition here:

if (isset($variables['page'])) {
  if (!isset($variables['page']['#cache']['tags'])) {
    $variables['page']['#cache']['tags'] = [];
  }

To this, right?

if (isset($variables['page']) && !isset($variables['page']['#cache']['tags'])) {
  $variables['page']['#cache']['tags'] = [];
}
🇧🇷Brazil renatog Campinas

Moved to the dev branch: 5.0.x

Thanks a lot everyone

🇧🇷Brazil renatog Campinas

Nice! Thanks for your feedback

I'll try to focus on this

🇧🇷Brazil renatog Campinas

Sorry, I didn't have time to merge that before but it's on my plans

I'll test that and merge as soon as possible

🇧🇷Brazil renatog Campinas

Thanks! Merged into 5.0.x

🇧🇷Brazil renatog Campinas

Merged into the dev branch

Thanks everyone

🇧🇷Brazil renatog Campinas

Added the README.md as suggested on #12

🇧🇷Brazil renatog Campinas

confirmed that loadMultiple() don't works

🇧🇷Brazil renatog Campinas

Appreciated @gslente

Marking as NR

🇧🇷Brazil renatog Campinas

Thanks for that

'#options' => loadMultiple()

I didn't run yet, but this code above really works to get roles? 🤔

🇧🇷Brazil renatog Campinas

made the suggested change of moving (and modifying) the check to skip processing if garage collector is disabled, into hook_cron instead of being within the service itself

Appreciated

Seems really good, but as suggested on #12 I think would be nice if we update the README.md with this functionality

🇧🇷Brazil renatog Campinas

Thanks for sharing your feedback @flyke

🇧🇷Brazil renatog Campinas

Thanks for your contribution

Marking as "Needs Work" because MR #55 has changes non-related to this issue. E.g. README, etc

🇧🇷Brazil renatog Campinas

Moving to "Needs Work" because needs a merge request or patch

🇧🇷Brazil renatog Campinas

That's a great catch

Thank you so much for reporting

🇧🇷Brazil renatog Campinas

One thing, you can use ternary operator or ?? instead of this construction

Definitely

Makes sense, I'll work on this

Production build 0.71.5 2024