Log message #4200137

# At Username Text
# Aug 28th 2019, 12:16 alexdd55976 thats weird
# Aug 28th 2019, 12:15 davorminchorov yeah, $var shows an array of data when I use `dd($var)` in the controller but `null` in the view for some reason
# Aug 28th 2019, 12:13 alexdd55976 and $var is filled?
# Aug 28th 2019, 12:12 alexdd55976 @davorminchorov you sure its the right view?
# Aug 28th 2019, 12:11 davorminchorov Hi, when I try to add a variable to the view / element, I use `$this->set('var', $var)` but for some reason, I am seeing anything when I try to use `dump($var)` in the view / element. Any ideas?
# Aug 28th 2019, 12:11 waspinator I've also never been sure what the best way was to develop a plugin for outside consumption, so I just keep everything in my plugin directory. Maybe a paragraph in the docs describing a good way to do this would be helpful. especially from someone who has published so many awesome plugins.
# Aug 28th 2019, 11:06 admad @rudy1976s then submit an issue to the docs repo github.com/cakephp/docs
# Aug 28th 2019, 10:16 rudy1976s hello I find a broken link in cake elastic search docs
# Aug 28th 2019, 10:05 kaliel Sorry i want to spend huge time on a plugin and i want to make it right and easily maintanable
# Aug 28th 2019, 10:04 kaliel so you start a new "blank" project to developp your plugin inside the "plugins" folder ?
# Aug 28th 2019, 10:02 dereuromark That is how you bake your plugin skeleton.
# Aug 28th 2019, 10:00 kaliel @dereuromark thank you. So you're not using the CLI to generate plugin's skeleton ?
# Aug 28th 2019, 09:56 dereuromark In 3.x it is nice that you have testing isolated inside this vendor package (vendor/bin/phpunit etc), while you can already work with it as demo inside the actual app. they dont interfere here in terms of testing.
# Aug 28th 2019, 09:55 dereuromark I usually start baking the skeleton and making sure the composer+autoload works already. Then I require it already in a project as vendor package. I have two open IDEs, project + plugin. Then I start developing the plugin with TDD, having (unit)tests for rapid prototyping right away. In Parallel I can easily confirm this also in real life app. Once all is nice, I push plugin code for travis.
# Aug 28th 2019, 09:52 alexdd55976 @kaliel @dereuromark intersting quesion.. would be interesting for me too
# Aug 28th 2019, 09:49 kaliel @dereuromark can i ask you what's your worflow when building a plugin ? Do you start a new dummy cakephp project, or do you build the plugin inside a live project ?
# Aug 28th 2019, 09:23 val It seems the simplest solution is to call `deleteAll` on dependent model as the first step
# Aug 28th 2019, 09:19 neon1024 @ricksaccous I sorted out my associated data marshaling issue. The answer was staring me in the face. It’s right in the docs, I just didn’t read properly. I have to add `Questions._joinData` to the `associated` key in `patchEntity` :face_palm:
# Aug 28th 2019, 09:19 dereuromark or you set a higher timeout limit, this way you have the nice user experience of having the option of undo a delete (like sending emails => abort)
# Aug 28th 2019, 09:18 dereuromark soft delete is just setting a flag, and then background takes care of it after a few seconds anyway.
# Aug 28th 2019, 09:18 dereuromark like soft-delete => queue hard delete
# Aug 28th 2019, 09:18 dereuromark PS: many would probably async offload that into a background (queue) task if it doesnt have to be all done in sync user interaction.
# Aug 28th 2019, 09:17 dereuromark you cant have it all including dependent record stuff. highly complex with all involved callback options.
# Aug 28th 2019, 09:16 dereuromark use deleteAll() and use manual cleanup if you need performance
# Aug 28th 2019, 09:16 dereuromark thats on purpose.
# Aug 28th 2019, 09:16 val I think there is performance problem in that `deleteMany`. It seems to execute many SQL statements instead of one like in `deleteAll`.
# Aug 28th 2019, 09:14 dereuromark And I recommend to always use the *ManyOrFail() ones to avoid silent failures.
# Aug 28th 2019, 09:14 dereuromark You could backport this deleteMany() into your code until 3.9 lands.
# Aug 28th 2019, 09:14 val 'dependent' is already set to `true` in the association
# Aug 28th 2019, 09:14 neon1024 To me `deleteAll()` with dependent could be very dangerous
# Aug 28th 2019, 09:13 neon1024 Probably need to call `delete()` with `dependent` set in the association
# Aug 28th 2019, 09:12 dereuromark ah sry, that is available only in 3.9 and 4.0 ( https://github.com/cakephp/cakephp/blob/3.next/src/ORM/Table.php#L2388 ), I am thinking already too far ahead.
# Aug 28th 2019, 09:09 val I meant `Table::deleteAll()`. There is no`deleteMany()` in Table class.
# Aug 28th 2019, 09:08 dereuromark update"All"() are atomic (no callbacks)
# Aug 28th 2019, 09:08 dereuromark the Many are supposed to be the ones non atomic afaik
# Aug 28th 2019, 09:07 dereuromark isnt there deleteMany()?
# Aug 28th 2019, 09:06 val Hi, is it intended that `deleteAll()` in 3.x does not delete dependent records like in 2.x?
# Aug 28th 2019, 09:05 development Ok, thanks @dereuromark!
# Aug 28th 2019, 09:04 dereuromark you can remove it, sniffers would do that for you as well. same namespace doesnt need it.
# Aug 28th 2019, 08:58 development When I bake a new controller, it adds this to the top of my file: namespace App\Controller; use App\Controller\AppController; PhpStorm tells me the 'use' is unused. Is this some kind of double declaration and if so, can someone tell me why bake adds both of them and if I can remove it since PhpStorm says it is unused?
# Aug 28th 2019, 08:10 neon1024 Morning everyone :wave: