@doxigo

Any brave souls to provide a MR?

Glad to hear that, I was starting to doubt that decision, good to get it confirmed

I'm not sure if you are filing the issue under the correct branch or not Thomas but the 6.x does not have a proxy.js file but rather .env.local file, you might have mixed things up with 5.x documentation

And done, tagged 1.1.16

Hey Mikey, thanks a lot for the MR and the Gutenberg work, merged.

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

This causes the error mentioned above and I kinda don't see any way around recovering this

Nothing on my end, not actively working on nodeaccess at all, but I'd say let's give it a bit and see how things are and if all is good we can tag a new release

Thanks a lot Darren, merged.

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

Thanks Rajab for the update, I'll mark this as closed for now since it's not Radix related.

I have no idea Pierre, I haven't looked further into it but you can test on D11, generate some content with devel on let's say olivero, check the content generated and some throw the error. Works after re-saving it though

Have the same issue, the patch didn't work though

@Stephan and @Pierre, I looked a bit further into this, and it turns out at least based on the error I am getting this is not a Radix nor UI patterns issue but rather the D11 core I suspect.

So the error exists on Radix, Olivero, and any other SDC themes, it gets fixed if you just re-save the node.

Stephan, could you check please, and see if that's the case?

Great work, thank you. will check soon

doxigo → created an issue. See original summary → .

@Stephan I managed to recreate it with Drupal 11:

TypeError: Drupal\Component\Utility\Html::escape(): Argument #1 ($text) must be of type string, null given, called in /var/www/html/web/core/lib/Drupal/Core/Utility/LinkGenerator.php on line 198 in Drupal\Component\Utility\Html::escape() (line 431 of core/lib/Drupal/Component/Utility/Html.php).

I'll keep you guys posted on a fix.

@Stephan I somehow couldn't recreate the errors you mentioned on Drupal CMS. I'll try with Drupal 11 Core to see if that's the case. I suspect it might be a content-specific error.

Would be nice to know what error you were getting.

@Pierre still on my todo list to clean up the remaining components, definitely will give the SDC devel a go, thanks a lot for the help.

It's been a while since I last looked into this and I don't recall the reason for it Tom, I wonder if it's a core issue but we'll investigate, thanks

Thanks a lot, appreciate the work. I am not knowledgeable here as well, so I guess this is as good as it gets for now.

Thanks Marc-Antoine, should I expect a MR?

Thank you, I'll make sure to refer to our conversation when I'm on a call with my therapist. Cheers

Btw, instead of being hostile and calling your co-maintainer someone who stole your code, you could've just said, let's revamp 1.x instead of starting new fixes on 2.x 🙂

Something to think about for the future.

Begging is a big word, especially when I emailed you and told you to work together, wow, you have some issues, instead of reading on git branches please consider a therapist.
To wrap this up:
- So your only issue is that I opened a new branch instead of continuing on the 1.x branch? and you consider that as stealing? just a new branch?

Anyway, don't waste more of my time, best of luck :)

Marking this as Closed (due to lack of thinking capabilities)

Daniel, please consider what you are saying:
- I stole your work with a fix and introducing a new branch?
- You (Yes you have access as a maintainer to all the branches) could've also just merged the 2.0.x to 1.0.x if you wanted to, even though that's wrong, you should just start a new branch like I did :)
- Also did you reported me for creating a new branch :)))

Dear Daniel,
I'm really struggling with your lack of knowledge on how things work, a couple of things:
1. Your code is already open-source
2. I joined your project as a co-maintainer, created a new branch called 2.0.x and fixed this issue https://www.drupal.org/project/gutenberg_ai_tools/issues/3473966 ✨ Please consider using the Ai module Active
3. You sent me an email saying that I stole your code? I'm your co-maintainer FFS :)) If I am to steal your code, would I add a new branch on the same project? You know we both have access to all the branches on a project right?
4. The reason for a new branch is, your code is dependent on obsolete OpenAI module, I integrated it with the AI module, so backward compatibility requires you to create a new branch (please study on that)
5. AGAIN IT WAS STILL ON YOUR OWN PROJECT WHICH YOU HAD ACCESS
6. You kept asking me to opt-in your "Alpha" release into security coverage, you need to be stable first to even try to opt-in
7. Please study on git branches and reasons people branch out and backward compatibility

Marking this as "needs review"

Thanks Stephan, got rid of the whole thing

This is causing too many issues, I just pushed a fix by removing the type limitation on the rows. should be good for now but not the ideal solution.

Please test and let me know if it helped

oh nice catch, thank you Mohammed

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

All good, another MR maybe?

Done Vegard 😍

Great, thanks

Great work Jon, thanks, merged.

Great idea, could you please provide a MR maybe? if not let me know

Hey Dan, you are correct, I missed the breaking change part, it definitely is. We should ideally keep it and also add the new d-flex class.

Thanks for the updated MR James

Any update on this? it's been on production for me for a while and works as expected

Thank you Jon for this, could you please provide the MR?

Perfect work James, merged

Thanks James, I'm not sure if flex-row and flex-wrap are needed, are they? can you test without? if so update the MR?

Hey James, Thanks for a nice find, please provide the MR, I appreciate it, thanks

Thank you, merged

Hey guys 👋

I have a long todo list to add to this module but unfortunately, don't have a lot of free time, I'll see if I can open up sometime if possible.

Thank you Jon, merged

This is correct as is, changing the background color of Gutenberg parts is out of admin theme control. If you want to change the background color of Gutenberg, you need to take care of that outside of the admin theme.

Marking this as Closed for now, feel free to re-open

I'm unsure if this is the correct fix, even though it doesn't hurt to apply your patch and help other people with an extra headache, I assume Mercury editor should pass an empty '' string instead of null. Maybe add a ticket over at their issue queue → as well.

Regardless I applied your patch since it's okay to have this, thanks.

Thanks again Phil, merged. I also updated the docs.

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

Lovely, thanks Philippe, merged

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

Ideally, we should just check and tag a D11-compatible version of 4.x and 5.x
Not necessarily supporting it but rather making it possible to upgrade.

thanks

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

Hey Dan, this sounds about right to me, at some point, I slowly tried to convert them but seems like I never finished. That aside, I don't believe there would be any breaking change with this, so feel free to get this going.

Thanks a lot

Thank you James, rebased

Yes, I just haven't gotten to it yet, sorry. Could you maybe provide a MR? if not I'll check soon

No. But you can always Sub-theme any theme yourself.

thanks, merged

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

Thanks, merged.

thanks, merged

Okay I pushed a backward compatibility fix for this since one of my projects also got hit with this. marking this as fixed for now, and taggign a stable release 6.0.0 🎉

Perfect Dan, I wanted to merge it but seems like MR is in draft

Hey Dan,

A couple of notes on my end regarding the issue:

> Currently when a radix template changes, existing sites will not receive the change without manually copying the change from the starterkit to their sub-theme.

That's by design, and I believe that's okay to be like this, any older website that is already built, shouldn't be needing to change their markup (eg. templates and so on), so what they currently have should suffice. If they are keen on being updated, they should manually review and update if needed.

> When the change is accompanied by a corresponding change to the component, this can cause incompatibility where none would otherwise occur.

This is the tricky part, but we've been doing this since 8.x.4.x more or less, we just need to be more mindful of backward compatibility when changing the components.

> Also, core discovers the templates in the starterkit and uses them in the absence of a template in the sub-theme.

That's the core problem to be addressed, when we set the starterkit: true it should just ignore the templates, but for now let me take a look, I might have some solutions for this, eg. fully remove the starterkit once it gets copied

Even though this is okay to add the issues here, if anything we should add the related issues to Github repo: https://github.com/doxigo/drupal-radix-cli

That aside, glad your issue is fixed once you updated your node path, I can look into this further see if it's something we can help with or not.

Okay we will definitely will have unhappy users, but what's done is done. I suppose we can keep the 6.0.x since in Drupal, 6.1 and 6.0 is not that different. Also we are still on RC, so we have an excuse :)

to add my two cents:
If we make a change that has breaks things for existing websites, we should do a revert for now. if it's a major change that we can't live without, we can do a new major release even and move forward with that. Otherwise not all people will find this thread.

Hey James, thanks for a thorough testing, in the end if watching the build does the job, go for it. In my head, we needed to watch the source rather than the build but if it fails as you suggest, well... it fails.

There's no harm in switching the browserSync watch in general.

@jamesoakley Yes to all. any SCSS/non-build JS files (the ones that start with a _) should be watched. could you do a MR then please?

Hey guys, I'd say that could possibly make sense in some scenarios but not generally no. but there might be some downsides:
- Watching build files could cause recursive reloading
- Build files are outputs, not sources
- Changes to build files are already handled by laravel-mix

in general we can do a bit of testing and see how it turns out to be but BrowserSync should only watch source files

Hey guys,

Dan as I mentioned in the email:

I believe this could be a breaking change and break every website that there is if it’s in the core Radix. That aside the I can’t recall on top of my head about the error that this causes in multilingual pages, and the issue but I know that I’ve used the path alias based suggestions quite a lot.

If it were up to me, I’d try to fix it rather removing it, but feel free to make your own decision.

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

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

Perfect, thanks

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

lovely, thanks. merged

Thanks, merged

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

Thanks, merged

Seems to be some conflicts post merging other MRs

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

Thanks, merged

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

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

Could you please provide a MR?

Thanks for the MR, merged

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

@erier even though that does work with Autodocs but the "Show code" part still does nothing. Am I missing something? does that work for you?

I agree, we should get rid of {% apply spaceless %}
I would really appreciate a MR if possible

Thanks a lot for the MR Nicholas, merged

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

Thanks a lot ckng, merged.
Pierre I'll check and see what we can do.

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

Closing, as it is fixed in Gin