| # |
Jul 2nd 2019, 12:49 |
 admad |
just fyi hybridauth finally releases its 3.0 final after over a year in RC with PHP 5.4+. I really don't want to support a lib which thinks it prudent to provided support for php 5.4 in 2019 |
| # |
Jul 2nd 2019, 12:46 |
dereuromark |
hmm ok, I still didnt switch yet |
| # |
Jul 2nd 2019, 12:45 |
admad |
@dereuromark I no longer use that plugin actively, switched to my social-auth plugin, so don't remember. |
| # |
Jul 2nd 2019, 12:38 |
dereuromark |
Can we attach the listener more globally? Or try eager loader the table we need here in the auth adapter maybe? |
| # |
Jul 2nd 2019, 12:38 |
dereuromark |
From the stack trace it seems the UsersTable is not init, thus no valid listener yet maybe? #0 /app/vendor/admad/cakephp-hybridauth/src/Auth/HybridAuthAuthenticate.php(319): ADmad\HybridAuth\Auth\HybridAuthAuthenticate->_newUser(Object(ADmad\HybridAuth\Model\Entity\SocialProfile)) |
| # |
Jul 2nd 2019, 12:37 |
dereuromark |
[RuntimeException] You must attach a listener for "HybridAuth.newUser" event which saves new user record and returns an user entity. |
| # |
Jul 2nd 2019, 12:37 |
dereuromark |
In some cases I seem to get |
| # |
Jul 2nd 2019, 12:37 |
dereuromark |
@admad you use (as documented) EventManager::instance()->on('HybridAuth.newUser', [$this, 'createUser']); as well? Inside the table? |
| # |
Jul 2nd 2019, 10:38 |
conehead |
I am running 3.8 |
| # |
Jul 2nd 2019, 10:37 |
neon1024 |
Hm, although that does mean still having to write the controller action class methods |
| # |
Jul 2nd 2019, 10:36 |
neon1024 |
I could use a callback class method |
| # |
Jul 2nd 2019, 10:36 |
neon1024 |
Ah, found it, https://crud.readthedocs.io/en/latest/events.html#action |
| # |
Jul 2nd 2019, 10:32 |
neon1024 |
Anyone know how I can contain tables for all controller actions using Crud? |
| # |
Jul 2nd 2019, 10:28 |
challgren |
You running 3.7? |
| # |
Jul 2nd 2019, 10:26 |
conehead |
Yes. I mean he still switched from default collation to the configured collation. But as they are the same now, that shouldnt make any difference now |
| # |
Jul 2nd 2019, 10:18 |
challgren |
Did the migrations run as intended? |
| # |
Jul 2nd 2019, 10:15 |
conehead |
Well challgren I now changed database default to `utf8_general_ci` Probably not the best solution, but it seems to work now |
| # |
Jul 2nd 2019, 10:07 |
challgren |
Nice thats probably the best solution cake 2 is old code and most of us forgot it |
| # |
Jul 2nd 2019, 09:56 |
Ecorce |
Finalement I went for a simple solution: passing variables into the Session, then extract them in the error view. |
| # |
Jul 2nd 2019, 09:54 |
conehead |
But you are using these settings? `'encoding' => 'utf8mb4',` And for the database `utf8mb4_unicode_ci`? Thank you very much for your support by the way |
| # |
Jul 2nd 2019, 09:53 |
conehead |
I removed all migrations. Just added 2 migrations with up and creating a table. First is utf8_general and next is mb4.... |
| # |
Jul 2nd 2019, 09:50 |
challgren |
Weird, I looked at all my migrations and I never once specified the collation and on production everything is correct. |
| # |
Jul 2nd 2019, 09:46 |
conehead |
@challgren This is getting more and more weird. In app.php I got `'encoding' => 'utf8mb4',` Database has `utf8mb4_unicode_ci` First tables are created with `utf8_general_ci` and then later they are created with `utf8mb4_unicode_ci` |
| # |
Jul 2nd 2019, 09:44 |
ndm |
@Exorce The exception renderer instantiates a new controller, hence your data isn't available. You could for example use a custom/extended exception that can be fed with additional data. The exception is available in view as `$error`. |
| # |
Jul 2nd 2019, 09:33 |
Ecorce |
Working on a NotFoundException (CakePHP 2.3.9), I try to set vars to the view but ther error handler seem to remove them. How can I pass vars to the view? |
| # |
Jul 2nd 2019, 09:32 |
Ecorce |
Hello there! |
| # |
Jul 2nd 2019, 09:30 |
challgren |
Well utf8mb4 is larger so you may need to rekey some TEXT fields |
| # |
Jul 2nd 2019, 09:30 |
conehead |
Getting more and more strange: `utf8mb4` gives me an error during one migration `Specified key was too long; max key length is 767 bytes` `utf8_general_ci` seems to be working fine. But I'd prefer `utf8mb4` |
| # |
Jul 2nd 2019, 09:25 |
challgren |
weird |
| # |
Jul 2nd 2019, 09:24 |
conehead |
But I cannot really reproduce it :P |
| # |
Jul 2nd 2019, 09:24 |
conehead |
Should create a simple example first |
| # |
Jul 2nd 2019, 09:23 |
challgren |
Weird, I’d suggest opening an issue at https://github.com/cakephp/migrations |
| # |
Jul 2nd 2019, 09:22 |
conehead |
Errm actually before those 2 migrations, there are 3 more that are executed correctly |
| # |
Jul 2nd 2019, 09:21 |
challgren |
My guess is the first table creates with the defaults and then something resets the collation and it defaults the to the db |
| # |
Jul 2nd 2019, 09:21 |
conehead |
Yep I will. Still wondering why this is happening at all |
| # |
Jul 2nd 2019, 09:21 |
challgren |
Set the db to utf8 and try again |
| # |
Jul 2nd 2019, 09:19 |
conehead |
second is swedish |
| # |
Jul 2nd 2019, 09:19 |
conehead |
First is utf8 |
| # |
Jul 2nd 2019, 09:19 |
conehead |
strange thing is... I created 2 Migrations. Just ``` Migration1: $this->table('a') ->create(); Migration2: $this->table('b') ->create(); ``` |
| # |
Jul 2nd 2019, 09:18 |
challgren |
I personally use utf8mb4 as my default and in my app.conf |
| # |
Jul 2nd 2019, 09:18 |
conehead |
well or incorrect |