Log message #4199251

# At Username Text
# Aug 21st 2019, 15:05 daniel.upshaw You will need to `npm install` your JavaScript dependencies
# Aug 21st 2019, 15:05 daniel.upshaw Does that make sense?
# Aug 21st 2019, 15:04 daniel.upshaw NPM is for JavaScript/CSS etc, Composer is for PHP
# Aug 21st 2019, 15:04 slackebot install of `npm` and thus no `bower`. Sorry for all the questions all at once, I figured I should put everything together.
# Aug 21st 2019, 15:04 slackebot Cake directory structure. A lot of this has me thinking I should either be using `npm` exclusively for frontend management or return to `bower`. In my original setup, I loaded frontend dependencies using `bower`, got the `dist` files in the correct `webroot` subfolders with custom paths in the `bower.json` file and then committed those frontend dependencies to the repo - effectively freezing them (this was mostly because our server doesn’t allow the
# Aug 21st 2019, 15:04 slackebot using Composer to bring the frontend libraries into the project, do I still need to use `npm install` to get the `dist` files into the right directories? If I still need to use `npm`, what is the benefit of using Composer? Does using `npn install` actually bring them into the Cake projects `webroot` directory? It seems this functionality is dictated by some additional information in the libraries `package.json` file, which wouldn’t be specific to a
# Aug 21st 2019, 15:04 mdotobie I know this isn’t a CakePHP-specific question but since it is my framework of choice, I figured I’d ask this here. From everything I’ve been doing, it’s possible to bring frontend libraries into my Cake project using composer. I seemed to be under the impression that it was doing its internal magic to link those frontend libraries into my `webroot` folder - but a recent bug seems to indicant that this isn’t the case. My question is
# Aug 21st 2019, 15:04 daniel.upshaw Fair :slightly_smiling_face: Thanks for the tip
# Aug 21st 2019, 15:04 admad Unnecessary double caching could actually be detrimental, cache reads aren't exactly free either :slightly_smiling_face:
# Aug 21st 2019, 15:03 daniel.upshaw Seems indicative of a bug, yes?
# Aug 21st 2019, 15:03 daniel.upshaw So strange that it only happens on the first page loa
# Aug 21st 2019, 15:01 daniel.upshaw I just wanted it to be speedy on all fronts
# Aug 21st 2019, 15:01 daniel.upshaw Right, I tried removing that
# Aug 21st 2019, 15:01 admad Why cache the query when you are already caching imploded results
# Aug 21st 2019, 15:01 daniel.upshaw If I hard code the string, it works fine
# Aug 21st 2019, 15:00 daniel.upshaw I'm not sure if it would make a difference, but it's in my `routes.php`, so aside from potential best practices I don't see how that could make a technical difference?
# Aug 21st 2019, 14:59 daniel.upshaw So strange
# Aug 21st 2019, 14:58 daniel.upshaw Much cleaner without the `new Collection` though!
# Aug 21st 2019, 14:58 slackebot ); });```
# Aug 21st 2019, 14:58 daniel.upshaw Hrm, oddly this still errs: ```$tagRoutesPiped = Cache::remember('tagRoutesPiped', function () { return (string)implode( '|', TableRegistry::getTableLocator() ->get('Tags') ->find('all') ->select(['alias']) ->where(['route' => 1]) ->cache('tagRoutes') ->all() ->extract('alias')->toArray()
# Aug 21st 2019, 14:57 admad so `->cache()->all()->extract()->toArray()`
# Aug 21st 2019, 14:56 daniel.upshaw That's really cool, I did not know that
# Aug 21st 2019, 14:56 daniel.upshaw Oh awesome!!!
# Aug 21st 2019, 14:56 admad btw resutlsets are also collections so creating a new collection is unnecessary
# Aug 21st 2019, 14:56 slackebot ->where(['route' => 1]) ->toArray() ))->extract('alias')->toArray() ); });```
# Aug 21st 2019, 14:56 slackebot ->cache('tagRoutes') ->toArray() ))->extract('alias')->toArray() ); });``` ``` $tagRoutesPiped = Cache::remember('tagRoutesPiped', function () { return (string)implode( '|', (new Collection( TableRegistry::getTableLocator() ->get('Tags') ->find('all') ->select(['alias'])
# Aug 21st 2019, 14:56 daniel.upshaw It's a great call.... though still error with both of these: ``` $tagRoutesPiped = Cache::remember('tagRoutesPiped', function () { return (string)implode( '|', (new Collection( TableRegistry::getTableLocator() ->get('Tags') ->find('all') ->select(['alias']) ->where(['route' => 1])
# Aug 21st 2019, 14:55 admad that will cause the query to be actually run and not give you the pdo serialization error
# Aug 21st 2019, 14:54 admad @daniel.upshaw add a `->toArray()` after `->cache()`
# Aug 21st 2019, 14:51 daniel.upshaw Same with this, no error: ``` $tagRoutesPiped = Cache::remember('tagRoutesPiped', function () { return implode( '|', ['test', 'this', 'debug'] ); });```
# Aug 21st 2019, 14:50 daniel.upshaw This does not show the error, if I `return 'string';`
# Aug 21st 2019, 14:50 daniel.upshaw ``` $tagRoutesPiped = Cache::remember('tagRoutesPiped', function () { return (string)implode( '|', (new Collection( TableRegistry::getTableLocator() ->get('Tags') ->find('all') ->select(['alias']) ->where(['route' => 1]) ))->extract('alias')->toArray() ); });```
# Aug 21st 2019, 14:45 daniel.upshaw For some reason, on the first page load with cache cleared, it is seeing a PDO instance somewhere
# Aug 21st 2019, 14:45 daniel.upshaw It's so strange, it still does it
# Aug 21st 2019, 14:45 daniel.upshaw I'll try force casting the `implode` result to `(string)`
# Aug 21st 2019, 14:44 daniel.upshaw `$tagRoutesPiped` is a string
# Aug 21st 2019, 14:44 daniel.upshaw But not on subsequent pageloads
# Aug 21st 2019, 14:44 daniel.upshaw That error happens after a clearing `tmp/*` and refreshing
# Aug 21st 2019, 14:44 daniel.upshaw `Error: You cannot serialize or unserialize PDO instances`
# Aug 21st 2019, 14:43 slackebot });```
# Aug 21st 2019, 14:43 daniel.upshaw ```$tagRoutesPiped = Cache::remember('tagRoutesPiped', function () { return implode( '|', (new Collection( TableRegistry::getTableLocator() ->get('Tags') ->find('all') ->select(['alias']) ->where(['route' => 1]) ->cache('tagRoutes') ))->extract('alias')->toArray() );