| # |
Feb 2nd 2018, 14:28 |
hmic |
i just wanted to get a sane date format, turns out, all friday gone before it's fixed :and |
| # |
Feb 2nd 2018, 14:26 |
 admad |
you can link the gist in your bug report :slightly_smiling_face: |
| # |
Feb 2nd 2018, 14:07 |
hmic |
https://gist.github.com/hmic/793fd42ea8c68f8ed6339497e9989830 |
| # |
Feb 2nd 2018, 14:01 |
admad |
with test case :slightly_smiling_face: |
| # |
Feb 2nd 2018, 14:00 |
admad |
File a bug report |
| # |
Feb 2nd 2018, 14:00 |
hmic |
this ought to be a quite simple task :Ü |
| # |
Feb 2nd 2018, 13:59 |
hmic |
it does. just nesting everything one layer deeper everytime you call it |
| # |
Feb 2nd 2018, 13:59 |
admad |
wtf, normalizing an array twice shouldn't mess it up |
| # |
Feb 2nd 2018, 13:54 |
hmic |
but cant do that, the View::loadHelpers() calls that method (again) and nests the array again, instead of recognising it is in the correct form already |
| # |
Feb 2nd 2018, 13:53 |
hmic |
good hint |
| # |
Feb 2nd 2018, 13:49 |
admad |
do `$this->helpers = $this->helpers()->normalizeArray($this->helpers);` first :slightly_smiling_face: |
| # |
Feb 2nd 2018, 13:47 |
hmic |
so i need to check all the elements, if numerically indexed, and remove if i want to load an alias for them :/ |
| # |
Feb 2nd 2018, 13:47 |
hmic |
still the HtmlHelper is in the $this->helpers like: [0 => 'Html'] while the alias, which should overwrite/remove the former one is ['Html' => 'BootstrapUI.Html'] of course |
| # |
Feb 2nd 2018, 13:46 |
hmic |
thats what i fixed already |
| # |
Feb 2nd 2018, 13:46 |
admad |
"CrudView.CrudView" would be split internally and the alias would still be "CrudView" in helper registry |
| # |
Feb 2nd 2018, 13:41 |
hmic |
even worse, if i change that to use an alias too, it complains Html is loaded already later on, as this is loaded in the default appview, unaliased... :[ |
| # |
Feb 2nd 2018, 13:40 |
hmic |
looks good at first sight, but it's actually not. as my alias for CrudView is "CrudView", while it gets loaded as "CrudView.CrudView" in the method |
| # |
Feb 2nd 2018, 13:39 |
hmic |
i changed _setupHelpers to set $this->helpers accordingly, not using $this->loadHelper() anymore |
| # |
Feb 2nd 2018, 13:39 |
hmic |
admad: it's not as easy as i thought it should be still :/ |
| # |
Feb 2nd 2018, 13:23 |
hmic |
all of them are locking correctly, all of them allow for multiple webservers and loadbalancing too, both of which (local) files don't |
| # |
Feb 2nd 2018, 13:23 |
k4t |
yes, memcache should solve it |
| # |
Feb 2nd 2018, 13:22 |
hmic |
change the session config to use database (worst case), or any cache, memcache is more than common, redis works too |
| # |
Feb 2nd 2018, 13:22 |
hmic |
thats a php thing and known forever |
| # |
Feb 2nd 2018, 13:22 |
hmic |
k4t: file sessions are not concurrent. |
| # |
Feb 2nd 2018, 13:21 |
k4t |
for storing sessions |
| # |
Feb 2nd 2018, 13:21 |
k4t |
instead of forcing users to use some kind of cache engines |
| # |
Feb 2nd 2018, 13:21 |
k4t |
to be honest I understand the problem, and security reasons behind session renew logic, but is it possible to fix it somehow on framework side? |
| # |
Feb 2nd 2018, 13:20 |
k4t |
as such thing can happen |
| # |
Feb 2nd 2018, 13:19 |
k4t |
does it means that keeping session in files in completely useless? |
| # |
Feb 2nd 2018, 13:19 |
hmic |
slaps k4t |
| # |
Feb 2nd 2018, 13:18 |
k4t |
@admad as a workaround I started writing directly to $_SESSION :( |
| # |
Feb 2nd 2018, 13:17 |
hmic |
let me try |
| # |
Feb 2nd 2018, 13:17 |
hmic |
makes sense |
| # |
Feb 2nd 2018, 13:17 |
admad |
k4t: your problem seems to happen because the session file if still locked from previous request when new request is made. I would suggest using a cache engine backed session instead of default file based sessions |
| # |
Feb 2nd 2018, 13:14 |
admad |
*_setupHelpers() |
| # |
Feb 2nd 2018, 13:14 |
admad |
hence my suggestion to update _setHelpers() to modify $helpers instead of loading helpers directly through loadHelper() |
| # |
Feb 2nd 2018, 13:13 |
admad |
hmic: loadHelper() does, but CrudView loads it's custom helpers through initialize() which is called before loadHelpers() hence the aliases already loaded are ignored |
| # |
Feb 2nd 2018, 13:10 |
k4t |
I found some similar problems on GitHub: https://github.com/cakephp/cakephp/issues/5988 Unfortunetelly they do not solve my case. |
| # |
Feb 2nd 2018, 13:10 |
k4t |
I am using Cake 3.1.14, PHP 5.6. Session cookies are handled by Cake, but the same problem appear when I change it to php. |
| # |
Feb 2nd 2018, 13:09 |
k4t |
I discovered that error is caused by Cake session renew logic, exactly by that line in Session.php Cake file: session_regenerate_id(true); When I set session_regenerate_id flag to false then everything is fine (becuase session file is not deleted). This happens when I am writing to session via $this->Auth->setUser($user) (but it is random); |
| # |
Feb 2nd 2018, 13:09 |
k4t |
Guys I have big issue with session in CakePHP, when I keep opening multiple tabs in browser fast then session is lost and following error is displayed: "session_regenerate_id(): Session object destruction failed". Here is more detailed log: https://gist.github.com/K4T/6584c957355da498c18d260abd1a4ddd |