| # |
Jul 14th 2017, 22:42 |
 ben |
I agree. We're just not *ready* for all the conventions. ;) |
| # |
Jul 14th 2017, 22:41 |
savant |
you’re free to make that change - and pull requests are welcome - but it seems of limited utility |
| # |
Jul 14th 2017, 22:41 |
savant |
but if you’re going to use cakephp/migrations, the point of cake is to have conventions |
| # |
Jul 14th 2017, 22:40 |
savant |
If you were going to use phinx directly, sure |
| # |
Jul 14th 2017, 22:40 |
savant |
just seems like busy work |
| # |
Jul 14th 2017, 22:38 |
ben |
Since migrations are a common are shared concept, it seems a bit more flexible, at least for us, to have a path for our migration files that's independent of any particular external solution, library, framework, etc. |
| # |
Jul 14th 2017, 22:35 |
savant |
seems like a hack for a legacy method that isnt going to be used further |
| # |
Jul 14th 2017, 22:34 |
savant |
might be easier to just move to the new solution from now on? |
| # |
Jul 14th 2017, 22:34 |
ben |
We prefer to keep them all together, and it's not such a "nested" path within our projects directory structure. |
| # |
Jul 14th 2017, 22:33 |
ben |
Yes, we have an existing path for migrations in our project with existing migrations, although not created using CakePHP's migration solution. |
| # |
Jul 14th 2017, 22:30 |
savant |
is there a reason you want it at another path? |
| # |
Jul 14th 2017, 22:30 |
ben |
That's it. Thanks, @savant. I see we can probably roll our own customized copy/version of method getOperationsPath() in this trait definition to make it happen. |
| # |
Jul 14th 2017, 22:23 |
savant |
does that answer help, @ben? |
| # |
Jul 14th 2017, 22:23 |
savant |
because it gets tricky with plugins |
| # |
Jul 14th 2017, 22:23 |
savant |
not sure there is an easy way to override this |
| # |
Jul 14th 2017, 22:23 |
savant |
https://github.com/cakephp/migrations/blob/1353d08cedfcde83fe4c1e493a977b62907439ef/src/Util/UtilTrait.php#L54 |
| # |
Jul 14th 2017, 22:22 |
savant |
yeah i think its in --source |
| # |
Jul 14th 2017, 22:20 |
savant |
let me check |
| # |
Jul 14th 2017, 22:20 |
savant |
we might hardcode the path, either within cakephp or in phinx itself |
| # |
Jul 14th 2017, 22:19 |
savant |
@ben not sure its configurable |
| # |
Jul 14th 2017, 22:17 |
ben |
We've done some digging through the code and docs, but it wasn't readily apparent. |
| # |
Jul 14th 2017, 21:57 |
slackebot |
"migrations" command issued)? If so, in what file(s) or where is it configured? |
| # |
Jul 14th 2017, 21:57 |
ben |
We're considering adopting CakePHP's migrations, especially because of its simple and powerful snapshot and DIFF feature implementation (i.e. simple compared the Doctrine), but would like to configure a custom path/location for the migration [class] files so they're created/maintained in another path within our project's directory structure. Is this configurable in a persistent manner (i.e. other than by specifying the "--source" option with each |
| # |
Jul 14th 2017, 21:56 |
ben |
I asked this earlier today, but the question didn't attract much attention, so I'm trying again: |
| # |
Jul 14th 2017, 21:20 |
phantomwatson |
@maymeow , what do you mean by it doesn't work? Your line with `toString()` doesn't appear to be doing anything with the string it generates. |
| # |
Jul 14th 2017, 20:31 |
maymeow |
can i pass array of objects to view template? For example `$log`and if i want to get items i doing it like this ``` foreach ($log as $item) { $item->getAuthor()->toString()); ``` but in templates it doesnt work... |
| # |
Jul 14th 2017, 20:20 |
savant |
markstory^ |
| # |
Jul 14th 2017, 20:19 |
phantomwatson |
It's been awhile since I've submitted a pull request. Is it preferred that they be pointed at new feature branches, development, or master? I'm looking to fix an old codesniffer bug. |
| # |
Jul 14th 2017, 19:43 |
sturm |
Oh? Hmmm… |
| # |
Jul 14th 2017, 19:40 |
admad |
And it's free :slightly_smiling_face: |
| # |
Jul 14th 2017, 19:40 |
admad |
@sturm eclipse pdt also shows you similar info |
| # |
Jul 14th 2017, 18:50 |
siran |
@sturm I wish they had a community edition... but at least there's a 'personal' $8.90/month license `https://www.jetbrains.com/phpstorm/buy/#edition=personal ` |
| # |
Jul 14th 2017, 18:48 |
cleptric |
No, the getters work the same as the old ones :slightly_smiling_face: The `getBody()` method is part of the `MessageInterface` so it just returns the stream object now. IIRC, you could just (string) typecast them to get the content |
| # |
Jul 14th 2017, 18:43 |
siran |
@cleptric you mean `getBody()`? what does inmutable means here? |
| # |
Jul 14th 2017, 18:33 |
cleptric |
@siran The new request/response methods handle your object in a immutable way |
| # |
Jul 14th 2017, 18:26 |
sturm |
Wish I had that kind of information in Visual Studio Code. |
| # |
Jul 14th 2017, 18:18 |
siran |
@mikesmoniker there is also a difference between _response->body() and ->getBody()... my editor was marking body() as deprecated, so I was using getBody() which doesn't work |
| # |
Jul 14th 2017, 18:13 |
gonzela2006 |
@siran Thanks for your suggestion but I think error logging should be the same for all exceptions |
| # |
Jul 14th 2017, 18:11 |
siran |
@gonzela2006 I also believe you can have your own error handler, there you should be able to configure loggin to whatever you want |
| # |
Jul 14th 2017, 18:09 |
siran |
@gonzela2006 maybe you can use your webserver's logs? would that help? |
| # |
Jul 14th 2017, 18:08 |
siran |
but body() does know where to look |