# |
Jul 12th 2017, 15:39 |
jlroberts |
perfect, thats awesome, i think its supposed to autoload the functions.php file too though |
# |
Jul 12th 2017, 15:39 |
ericadeefox |
so. ok. doing a `$this->get()` or `$this->post()` request doesn't start a session, seemingly. I started each test with a `$this->get()` request and each of them still threw me 500s. hmm. |
# |
Jul 12th 2017, 15:38 |
jeremyharris |
that is loaded with composer’s autoloader. underneath the hood, it simply reads the namespace and discovers where the file is (based on conventions agreed upon by the PSR), and require’s the file for you |
# |
Jul 12th 2017, 15:38 |
jlroberts |
if it doesnt bootstrap cake, then how does 'use Cake\Utility\Security;' get autoloaded? im just curious... |
# |
Jul 12th 2017, 15:37 |
jlroberts |
ok |
# |
Jul 12th 2017, 15:36 |
jeremyharris |
the installer doesn’t “bootstrap” cake for you. that bootstrap process is what require’s the file in question |
# |
Jul 12th 2017, 15:36 |
jlroberts |
but why is it not global in Installer.php is the question |
# |
Jul 12th 2017, 15:35 |
jeremyharris |
if they were in a namespace, we’d need to do something like Cake\debug($var) everytime. they’re global for convenience |
# |
Jul 12th 2017, 15:35 |
jeremyharris |
remove the function_exist calls and you’ll see everything works just fine in a typical request (it is not loaded multiple times) |
# |
Jul 12th 2017, 15:35 |
slackebot |
~ Ferrero Roche |
# |
Jul 12th 2017, 15:35 |
slackebot |
Command sent from Slack by neon1024: |
# |
Jul 12th 2017, 15:34 |
neon1024 |
“Monsieur, with this Composer you are really spoiling us” |
# |
Jul 12th 2017, 15:34 |
jeremyharris |
no I think those just exist so you can overwrite them if you want, or to prevent collision in the global namespace |
# |
Jul 12th 2017, 15:34 |
jlroberts |
but thats the point, everytime the autoloader fires, it has to include the functions.php file, hence if (!function_exists(.... in functions.php |
# |
Jul 12th 2017, 15:33 |
jeremyharris |
just typical PHP stuff here |
# |
Jul 12th 2017, 15:33 |
jeremyharris |
those functions are in the global namespace, so cake just uses require to bring them into the application |
# |
Jul 12th 2017, 15:33 |
jeremyharris |
but it doesn’t and can’t, as those functions aren’t in a namespace, so the autoloader couldn’t find it even if it wanted to |
# |
Jul 12th 2017, 15:32 |
jlroberts |
ok, so somewhere, there is an autoloader, that is autoloading classes, from what I understand, that same autoloader needs to autoload the functions.php file |
# |
Jul 12th 2017, 15:31 |
jeremyharris |
it’s `require_once` by cake during bootstrap |
# |
Jul 12th 2017, 15:31 |
jeremyharris |
I mean, it’s not autoloaded by PHP |
# |
Jul 12th 2017, 15:31 |
jeremyharris |
it’s not even autoloaded by cake |
# |
Jul 12th 2017, 15:30 |
jeremyharris |
I think that’s the best way. It’s sort of how cake does it anyway during bootstrap |
# |
Jul 12th 2017, 15:30 |
jlroberts |
heh =] i just mean, we are using namespace's, use's, and autoloaders in CakePHP apps... |
# |
Jul 12th 2017, 15:30 |
neon1024 |
Mind blown. |
# |
Jul 12th 2017, 15:30 |
neon1024 |
:P |
# |
Jul 12th 2017, 15:30 |
neon1024 |
Coding PHP isn’t the right way?! |
# |
Jul 12th 2017, 15:29 |
jlroberts |
neon1024: thats exactly what I need, but I dont think thats the right way to do it |
# |
Jul 12th 2017, 15:29 |
neon1024 |
Sounds like you need `require($myPhpFile)` |
# |
Jul 12th 2017, 15:29 |
jlroberts |
the only place I see it is in autoload_files.php @generated by composer |
# |
Jul 12th 2017, 15:27 |
jlroberts |
Here is my github issue for more details, https://github.com/cakephp/app/issues/525 |
# |
Jul 12th 2017, 15:27 |
jlroberts |
ok fellas, I got a question for yall, I am trying to dispatch shells from app/src/Console/Installer.php, but it appears that the cakephp/src/Core/functions.php file is not autoloaded, however, the use statements in Installer.php is autoloaded... anyone know how cakephp/src/Core/functions.php is loaded outside of Installer.php? |
# |
Jul 12th 2017, 15:26 |
jeremyharris |
:+1: lemme know! |
# |
Jul 12th 2017, 15:26 |
ericadeefox |
ok backpedal, I'm gonna give rewriting these a shot before I gist em |
# |
Jul 12th 2017, 15:26 |
jeremyharris |
also, make sure there’s only one `$this->post()` and friends during each test case |
# |
Jul 12th 2017, 15:25 |
jeremyharris |
that’s usually how integration tests look. maybe gist one so I can see :slightly_smiling_face: |
# |
Jul 12th 2017, 15:25 |
ericadeefox |
does this mean I should rewrite my tests so that they _start_ with requests? like `$this->post()` or `$this->get()` at the beginning, so the session object is created right off the jump? |
# |
Jul 12th 2017, 15:24 |
ericadeefox |
so in testing, since the session object isn't created until a request is--oh, wait |
# |
Jul 12th 2017, 15:23 |
ericadeefox |
^that's basically what's happening. the plugin checks to see if a session has been started, then 500s and throws an error when it isn't. |
# |
Jul 12th 2017, 15:23 |
jeremyharris |
perhaps an FB class is instantiated early and checks the session? |
# |
Jul 12th 2017, 15:22 |
jeremyharris |
you shouldn’t need session_start anywhere. other integration tests work successfully using the session, no? |
# |
Jul 12th 2017, 15:22 |
jeremyharris |
ok so this is the process: `$this->session` just stores what you want to write, `$this->post()` starts by building a request, it sees you want to write session data, so it creates a session object and `$session->write()`s to it. `$session->write()` sees the session isn’t started yet, so it starts it for you. the request is then dispatched |