🇷🇸Serbia @holo96

Thank you for reporting :)

I will leave this issue in open, because I would like to make cheeseburger compatible with olivero
I guess it is place where a lot of developers will test it.

@bwoods No, it does not depend on bootstrap
I recreated this with Olivero, but Claro and Gin works fine for me

Is this issue only on 5.1.x or 5.0.x too?

@dqd Will you apply suggested changes?

Agreed.

If we drop support for Drupal 9, which makes sense, we should probably drop support for Drush < 12 as well, see the Drush compatibility table. That is, we should drop drush/devel_entity_updates.drush8.inc entirely, rather than updating it.

This is what I was trying to say.
Maybe if we leave out changes in drush/devel_entity_updates.drush8.inc, you don't have to drop drupal 9 support at all.
But if it has to be changed, it can only be removed.

I would go back to my original solution

@naveenvalecha Only thing that is questionable for me is described in #4. But I guess file should be removed. Because minimum Drush version is 11 anyway.

This is probably acceptable while while debug is enabled
So checking smtp_debugging before getting smtp_debug from session could also work, patch attached

Setting this to critical since core's Automated Cron is using KernelEvents::TERMINATE, and it is surely common to send emails from cron or queues

@acbramley Here 🐛 Drupal 11: ArgumentCountError: Too few arguments to function Drupal\views\Plugin\views\field\BulkForm::__construct(), 7 passed Active you go

holo96 → created an issue.

Btw I think target branch is wrong it should be 4.2.x.
4.1.x will not be compatible with Drush 13, as mentioned in release.

We can either fix both, or 4.2.x

I just assumed there is no way you can use Drush 8 commands in Drupal >10.1. But I guess my assumption was wrong...

Attaching new patch.

event_dispatcher service has changed class in d11, switching typehint to Interface to keep compatibility with both Drupal 10 and 11.

As said here, route_match is required parameter in Drupal 11.

I also guess minimum version needs to be raised to Drupal 10.3.

Attaching new patch and switching status back to needs review.

@joachim Is naming only issue you have with this?

That's how it is named in module currently only variable init is missing, I guess it went missing in some point

I will create new patch..

I guess I am not allowed to move my own patch to reviewed and tested. But got to say I have developed significant amount of custom entities and fields with no issues.

holo96 → created an issue.

Patch from #3 does not apply anymore.

Also I don't think watchdog_exception should be exchanged in drush8 command.
It would basically make drush8 command useless. As new alternative is available only on from drupal >10.1. But not totally sure. Someone else should check it.

Anyway, tested this patch on drush 13 and drupal 11, works like expected.

Updating NULL values to either 'a:0:{}' (map field) or 'N;' (almost any other) on problematic column(s) once also resolves problem.
No patch needed. You can create update hook for this.

This works because problem is appearing only when you are adding field to entities with existing entries.

@kingfisher64 It is commited to dev and needs review

This will give nice backward compatible solution.
By default transitions will require update access on entity.

DavorHorvacki → created an issue.

+1 for this issue
Agreed with #18 and #19, forms are not always the use case.
Third party setting can be anything.
I needed to highlight some transition buttons for example.

This can be achieved if you get it from workflow definition ($workflow->getPluginDefinition()) rather than creating plugin instance, but merging !7 would be more elegant solution.

This patch should workout.

About cache, I think access is only statically cached based off bundle. So it shouldn't flood cache. But, maybe I am wrong?

DavorHorvacki → changed the visibility of the branch 2.0.x to active.

DavorHorvacki → changed the visibility of the branch 2.0.x to hidden.

DavorHorvacki → changed the visibility of the branch 2.0.x to hidden.

As mentioned by my issue 💬 Add create access context consistently Needs review when this was merged to 2.x...

Merge request is outdated and is not adding parent to context cosistently, for example
src/Plugin/Field/FieldWidget/InlineEntityFormComplex.php:385 is missing context at all.

Seems like this worked for me (settings.php):

    if (!InstallerKernel::installationAttempted()) {
      $settings['filecache']['directory']['default'] = '../filecache';
      $class_loader->addPsr4('Drupal\\filecache\\', 'modules/contrib/filecache/src');
      $settings['container_yamls'][] = 'modules/contrib/filecache/filecache.services.yml';
      $settings['cache']['default'] = 'cache.backend.file_system';
    }

I will test little bit more to see if I run into any other issues.
I think this is essential for first time deploy...

@Berdir Can we merge this one?

DavorHorvacki → created an issue.

It is most probably related.

I still haven't found what is causing this issue.
The client doesn't want to invest in my research anymore.
I still have the render cache disabled on production.

DavorHorvacki → created an issue.

@krima
I think style-src 'unsafe-inline' would resolve everything in this module.
Am I right?

Can we get this in next release?

@fgm I haven't got time to work on this.
Project that will use this is still not in active development state.
I've just tested if it will work as expected and seems it will.
I will inform you. We will test it first internally.

I will leave this issue open because I think it is good Idea to add contextual links to cheeseburger and also maybe we can add contextual links to rendered menus/taxonomies.

But for me it seems like contexutal links are working as expected.

We've decided to separate cheeseburger menu into two blocks based on mistakes we made in <4.x. So there are multiple reasons for this decision.

Maybe I can add contextual link to trigger

4.x entered maintenance state.

4.x entered maintenance only, and this is already supported on 5.x

Sounds like a good plan

@fgm Maybe I wasn't clear on which aliases I talking about, but by aliases I mean drush site alias that has nothing to do with mongo database aliases.

But anyway, having something like drush mongo:alias or drush mongo:connection_string would help.

But still to achieve what I desire I would also need to parse ssh connection from desired drush site alias, which I don't want to do since it is in drush out of box.

I love bash(shell), don't get me wrong, after all I need this to use in internal project build bash script, but I want to keep this part of functionality in drush.

@fgm Yes it will most probably have to run CLI tools underneath, not sure if other approach would make sense as I mentioned in base issue description. So drush would be here just for easier alias management.

I can put commands here once I am done with it, but based on this seems like you wont change your mind :)

Not sure about portability part. But it would be definitely more performant.

Just for consistency I want to be able to define aliases once (in drush).

Also most php container images don't have Mongo Database tools installed.

Thanks anyway.

@fgm Yes, sorry if this is already possible, but I haven't found anything like it.
I want to be able to sync remote mongo database.

So for example I have drush alias called "@dev"
I want to be able to copy database to my current environment "@self" from "@dev".

So exactly like default drush sql:sync but for mongodb:
https://www.drush.org/12.x/commands/sql_sync/

DavorHorvacki → created an issue.

@petednz Dev version → should be compatible with drupal 10.

@ Jaypan →  Yes, I am using redis, but this also happened with default db cache. 

Dunno if its important, but we recently switched php version (8.1 -> 8.2).

@prudloff Exactly, I've already switched to drush.

One more thing would be useful is to have export all. I've already created issue(https://github.com/drush-ops/drush/issues/5781), once it is done this module can be deprecated for good.

Seems like nobody is maintaining it anyway, I lost patience for issue 📌 Switch from webmozart/path-util to new package symfony/filesystem Needs review , and switched to drush.

Biggest issue is that I cannot reproduce this even with everything enabled.

It only appears on production after some time of usage.

As temporary solution I've disabled render cache on production, I hope I will find out what it is at some point.

@ Jaypan →  I've tried this, but no luck
Route is not only context missing

Only way I can recreate this is by unsetting #cache directly in local task block. So I guess for some reason cache is not bubbling up.

Do you think this can be product of addition of fibers 📌 Add Fibers support to Drupal\Core\Render\Renderer RTBC or maybe cache variation?

Issue seems completely random, because once appeared that user tabs are cached and other time tabs on custom entity.

DavorHorvacki → created an issue.

Just had this issue.
Patch resolved it.

It is possible that earlier versions of Drupal core included this library anyway, because it was working fine before.

+1 issue for concurrent edits.

My entity is neither translatable nor revisionable, but fields that are not exposed to form display at all are overwritten in case ajax (file uploads, multiple values fields etc.) is triggered. This can be huge issue that can result in data loss.

I also think entity shouldn't be cached at all.

Let's say products stock is managed by external service, it will be overwritten if someone is editing product even if stock is not exposed to form edit.

In mean time I've created matching 1.x patch, I think it can be applied to as this does not harm anything

I am also willing to create this patch for 1.x if you are willing to merge

Here I think I've covered all places.

DavorHorvacki → created an issue.

Working with this for quite some time

Here is combined patch.

I'll move this to Needs review but #36 stays unresolved.

Facing same Issue in 10.1.4
Yes, I guess someone should reopen issue

Okay, let's test it out little bit, and make release later

Test only!

I've added link field to test and separated it to new test file.

I won't be working on this issue further because I still think #19 is easiest all around solution, backward compatible.

@Pavel Sivtsov Thanks for your offer :D
I will try to create patch asap, hope by wednesday.
No need for money, this is open source project

For map field type default value after field is installed is 'a:0:{}' not 'N;', but NULL could work anyway

@Pavel Sivtsov someone needs to create patch or merge request
If I have time I will create it.

I've also added link to place block.

@keshavv Thanks for cooperation and patch.

I see url was deprecated ages ago so I guess we can safely replace it with toUrl

@keshavv I will apply patch tomorrow.

@ddd200 There are two separate blocks:

- Cheeseburger menu trigger
- Cheeseburger menu

Cheeseburger menu needs to be placed first so trigger block can actually trigger main cheeseburger menu..

You are trying to place `Cheeseburger menu trigger` without `Cheeseburger menu`

This is explained here.

@keshavv Do we need description all the time or only when there are no Menus to trigger? Perhaps this warning text should stand out more.

Duplicate of #3322572 🐛 Error: Block to trigger field is required Closed: works as designed ?

I guess I should add warning some warning text as this obviously confuses users...

If we are speaking about solutions, we've created a separate module which contains exactly the same formatter as swiftmailer (minimally modified).

And switched sender to SMTP Authentication Support →

Considering we need to migrate hundreds of websites, I believe this is the best option at the moment. It's likely to work seamlessly, so no testing is needed.

Some of my websites also heavily rely on the mailsystem (and the core system). For me, the additional features in the Symfony mailer are just not worth it.

No one reviewed it, so I closing it as wont fix

I realized text_long needs this formatting too...

Hope this patch solves this issue

@power.ua
I think best solution for this would be to create setting for this

Thanks Dan for your support! :D

This was actually my first project in Drupal, I hope I will find more time in future to further improve it :D

I see the issue here.
@obiwankenobi I guess last MR is unrelated

#6 is definitely improvement but users does not have to have basic_html text format.

Would filter_default_format() function fix it?

return ['value' => trim($data), 'format' => filter_default_format() ];

4.x will only receive bugfix, security and drupal update changes.