Log message #3943487

# At Username Text
# Oct 6th 2016, 16:54 Leidenfrost Hi all. I
# Oct 6th 2016, 16:45 hmic ok. just wanted to be sure you are not digging on the wrong side .p still: please let me know how you solved it
# Oct 6th 2016, 16:44 nemmons I understand that. I was just making a side comment that it would be nice to better understand the whole startup sequence. I agree that what i need to do to solve my particular problem here is what you're suggesting
# Oct 6th 2016, 16:43 hmic you cannot fix the initial problem - ever. as its "you need a user to auth a user", so this is not resolvable in the order the controller invokes things
# Oct 6th 2016, 16:43 hmic nemmons: you dont need to. you do need to find out how to attach/activate footprint later in the process
# Oct 6th 2016, 16:41 nemmons I really need to take some time and read through all this code so i can understand the controller startup sequence. It's all magic to me.
# Oct 6th 2016, 16:41 nemmons Unfortunately that's not working. I believe it's because it's the job of the FootprintAwareTrait to attach the FootprintListener to the table, so just adding the behavior in the beforeFilter isn't enough. But this gives me an avenue to explore so i appreciate you pointing me in the right direction
# Oct 6th 2016, 16:25 hmic let me know how its going
# Oct 6th 2016, 16:25 hmic beforeFilter *callback*, not *event* is late enough in the process to have the user authenticated already *imho* - just debug($this->Auth->user()) from there to verify.
# Oct 6th 2016, 16:24 hmic my idea - not tested - basically: AppController::beforeFilter() { TableRegistry->get('User')->attachBehavior('Footprint'); }
# Oct 6th 2016, 16:23 hmic if not, just use beforeFilter (callback!) to attach it
# Oct 6th 2016, 16:23 nemmons Okay, that all makes sense, thank you.
# Oct 6th 2016, 16:23 hmic there does even exist a proper event in the auth class, afterAuthenticate, i think
# Oct 6th 2016, 16:23 hmic hint: you can get the usertable from the tableregistry and manually attach the footprint behavior after the user has been authenticated
# Oct 6th 2016, 16:22 hmic you need to table to authenticate the user, so you cannot attach it to this table (in one go) - ever.
# Oct 6th 2016, 16:22 hmic easy answer: before the logged in user is not known, you cannot attach footprint to the talbe
# Oct 6th 2016, 16:20 nemmons @hmic oh, i see. I guess i don't understand the code base well enough yet to see how beforeFilter is relevant to my question. I'll keep reading.
# Oct 6th 2016, 16:18 hmic still: even though this is a mess, it has for sure not been changed since 3.0, so not since may - 2015!
# Oct 6th 2016, 16:18 hmic which are run on completely different times
# Oct 6th 2016, 16:17 hmic nemmons: i am talking about the beforeFilter callback and event
# Oct 6th 2016, 16:17 nemmons @hmic Thank you but I'm sorry, I'm not sure i understand what you mean here. $controller->startupProcess is called which dispatches the Controller.initialize and Controller.startup events, After the controller action is invoked, $controller->render is called which dispatches the beforeRender event.
# Oct 6th 2016, 16:16 hmic the solution to your problem is using an iframe and echoing the html in there - you might need to utilize js to get this done easily.
# Oct 6th 2016, 16:15 hmic julez, so you echoed it out already? - yes this breakes the whole thing. as you have a complete <html> page in there. this is one of the reasons i said you might want to only render the element.
# Oct 6th 2016, 16:14 hmic i am quite sure nothing in this sequence or names has changed since may.
# Oct 6th 2016, 16:14 hmic the controller starup sequence is quite a mess regarding the names of events and callbacks!
# Oct 6th 2016, 16:13 hmic nemmons: you need to distinguish between the callbacks and events
# Oct 6th 2016, 16:13 nemmons (For background, Footprint is working great in my app in general but it's not working for my Users table. I think it's because UsersTable is initialized in AppController::initialize but i'm trying to prove that to myself and determine a workaround)
# Oct 6th 2016, 16:12 hmic passing it already? without you doing anything to it? whats in the logs? oom?
# Oct 6th 2016, 16:12 slackebot definitely called before Controller::beforeRender().. Is it possible this has changed since May when you said this, or am i horribly misreading this code?
# Oct 6th 2016, 16:12 nemmons @admad if you have a second i'm wondering if you could clarify a statement you made regarding a closed Muffin/Footprint issue (https://github.com/UseMuffin/Footprint/issues/13>).. I came across it while trying to debug a problem I had. "A table initialized in Controller::beforeRender() won't get the footprint since AuthComponent::startup() has still not run." Looking in Http/ActionDispatcher-_invoke() it looks to me like component startup me
# Oct 6th 2016, 16:10 hmic good luck! feel free to ask for help
# Oct 6th 2016, 16:04 hmic so as i said: basically replace the cake folder with the new one and give it a shot
# Oct 6th 2016, 16:04 hmic additionally this sentence, the first one of the migration guide: "CakePHP 2.5 is a fully API compatible upgrade from 2.4"
# Oct 6th 2016, 16:03 hmic just run your testsuite
# Oct 6th 2016, 16:02 hmic you should really give it a try and dont hide after the unknown codebase and size - and time constraits and so on :p
# Oct 6th 2016, 16:01 hmic as you can see, its quite good. it tells about things that have changed and are common pitfalls to look out for and about new things that might be handy too
# Oct 6th 2016, 16:01 hmic follow the things mentioned in there. then go on till you hit a problem
# Oct 6th 2016, 16:00 hmic thats it. you start with 2.4 -> 2.5 of course
# Oct 6th 2016, 16:00 hmic there is actually!
# Oct 6th 2016, 15:59 Neon1024 Hah
# Oct 6th 2016, 15:58 hmic if you want it upgraded faster, tell me the url, i'd see if a known security vulnarablity makes your decision makers want to upgrade it :p