[05:00:06] | * donblair[m] has quit (Quit: You have been kicked for being idle) |
[10:42:12] | <jgaehring[m]> | <paul121[m]> "interesting. I wonder if we..." <- oh, I just realized we actually never setup a GHA workflow for the blog repo, working on one now based on an old version of the farmOS workflow that also included a step for PR's |
[10:47:41] | <jgaehring[m]> | gonna update https://github.com/farmOS/farmOS-community-blog/issues/5 with some of these comments and push that workflow up as a PR in a moment |
[10:53:33] | <paul121[m]> | See https://github.com/farmOS/farmOS-community-blog/issues/4 !! |
[10:53:36] | <paul121[m]> | :-) |
[10:56:14] | <symbioquine[m]> | <paul121[m]> "interesting. I wonder if we..." <- I was kinda imagining this would be how it could work too |
[12:32:19] | <paul121[m]> | ohhh Farmer Ed someone just asked this in Drupal slack: |
[12:32:19] | <paul121[m]> | > When a new entity is created via a JSON:API POST, are any entity insert hooks/listeners called? |
[12:33:10] | <paul121[m]> | [Overa](https://drupal.slack.com/archives/C5A70F7D1/p1667390027951769) |
[12:33:11] | <mstenta[m]> | We didn't directly confirm that... but we think they are, right? |
[12:33:18] | <paul121[m]> | s/[Overa](// |
[12:33:43] | <paul121[m]> | Yeah we think they are. And the slack thread seems to indicate that they are as well |
[12:34:33] | <mstenta[m]> | It seemed to me like the Drupal core entity storage base class was invoking those hooks on $entity->save() so I feel pretty confident |
[12:37:46] | <FarmerEd[m]> | I haven't had time to look at it further yet, but I didn't get it to work for me. |
[12:39:21] | <FarmerEd[m]> | Although I thought it had previously (as in months ago) |
[12:41:35] | <symbioquine[m]> | <paul121[m]> "[Overa](https://drupal.slack.com..." <- I'm not much of a Slack user... how would I expect to be able to access that link? |
[12:42:32] | <paul121[m]> | sorry :-( I don't know of alternatives for that |
[12:43:44] | <symbioquine[m]> | I don't mean alternatives to Slack per se... just I'm not quite sure I follow the whole workspaces mechanism... would I need some sort of invite to access the link? |
[12:44:19] | <mstenta[m]> | (I'm still grumbling that Drupal moved off of IRC how ever many years ago now...) |
[12:44:59] | <mstenta[m]> | (I think I did see a thread where some were proposing moving to Matrix.org... probably not going to happen though... sunk cost and all) |
[12:45:17] | <symbioquine[m]> | Matrix seems like a pretty decent alternative to IRC, but as far as I can tell Slack seems like a needlessly walled garden thingy... |
[12:45:21] | <mstenta[m]> | I think you need to create a drupal.slack.com account symbioquine |
[12:45:44] | <symbioquine[m]> | ah |
[12:45:44] | <paul121[m]> | ah yeah the slack workspaces still confuse me. but yes ☝️ |
[12:46:19] | <paul121[m]> | and this thread is in the `#contenta` channel |
[12:47:42] | <symbioquine[m]> | Seems like drupal.org is having 500 errors :( |
[12:48:02] | <symbioquine[m]> | But I guess I'd need to follow this link once it's back online: https://www.drupal.org/join-slack |
[12:48:03] | <paul121[m]> | another annoyance of mine... only have a vague understanding that "contenta" is a prominent drupal organization... yet this is where all the Drupal API discussions happen 🙄 |
[12:48:11] | <symbioquine[m]> | https://webcache.googleusercontent.com/search?q=cache:UEAEy9YEPZUJ:https... |
[12:52:24] | <mstenta[m]> | drupal.slack.com should work directly symbioquine ? |
[12:52:39] | <mstenta[m]> | > Seems like drupal.org is having 500 errors :( |
[12:52:39] | <mstenta[m]> | I'm sure they are talking about it in the #infrastruture slack channel haha |
[12:52:46] | <paul121[m]> | maybe if we all just start talking about Drupal json:api, api, etc etc in a new matrix channel we can start the migration :-) |
[12:56:13] | <FarmerEd[m]> | I'm getting 500 errors trying install a module from drupal using composer too |
[12:56:29] | <mstenta[m]> | yea looks like some issues... |
[12:56:31] | <FarmerEd[m]> | also cant sign up for the slack channel at the moment |
[12:57:07] | <mstenta[m]> | https://twitter.com/drupal_infra/status/1588560960708829185 |
[12:57:08] | <mstenta[m]> | @drupal_infra is another place to check for those kinda things |
[12:57:45] | <mstenta[m]> | ouch seems to be pretty broad |
[12:57:46] | <symbioquine[m]> | Of course the links from the tweet also 500 🫠 |
[12:58:31] | <paul121[m]> | lets just take the day off folks |
[12:58:32] | <mstenta[m]> | https://giphy.com/gifs/community-fire-shocked-nLhdSinRtaL2E |
[12:58:39] | <paul121[m]> | it snowed here - first snow day :-) |
[12:58:47] | <mstenta[m]> | nice! |
[14:05:25] | <FarmerEd[m]> | Drupal.org seems to be back now |
[14:07:52] | <FarmerEd[m]> | Managed to checkout slack and use composer |
[14:25:40] | <FarmerEd[m]> | anyone seeing errors like: Uncaught PHP Exception Twig\\Error\\LoaderError: "Template "@claro/../images/src/hamburger-menu.svg" is not defined in "core/themes/claro/templates/navigation/menu-local-task.html.twig |
[14:26:12] | <mstenta[m]> | oh yea... that was an upstream issue that got fixed in Drupal 9.4.6 (if i remember correctly) |
[14:26:21] | <mstenta[m]> | farmOS 2.0.0-beta7 pins to that now |
[14:26:49] | <mstenta[m]> | if you rebuilt via composer, it inadvertently updated the twig library, which broke Gin/Claro themes |
[14:26:51] | <FarmerEd[m]> | Ah maybe need to update the dev image |
[14:27:10] | <mstenta[m]> | the other option (if you're not ready to update) is to manually pin the twig version in your `composer.json` |
[14:27:26] | <FarmerEd[m]> | yea, pretty much, fixed it by downgrading twig |
[14:27:31] | <mstenta[m]> | ah.. are you using the `docker-compose.development.yml` template? |
[14:27:51] | <FarmerEd[m]> | yes I think so |
[14:28:12] | <mstenta[m]> | if so, updating the `farmos/farmos:2.x-dev` docker image won't do it... because you have the whole built codebase mounted as a volume |
[14:28:31] | <mstenta[m]> | (if you were only mounting `sites` then you'd be using the codebase in the image) |
[14:28:47] | <FarmerEd[m]> | yes that would make sense |
[14:29:27] | <FarmerEd[m]> | its only a dev instance with very little in it so can be destroyed and started a fresh at this stage |
[14:30:55] | <FarmerEd[m]> | Was more just making sure there was awareness of the issue. |
[14:31:40] | <mstenta[m]> | thanks! yea i ran into that too |
[14:32:20] | <mstenta[m]> | (and MANY users of Gin and Claro themes) |
[14:32:34] | <mstenta[m]> | https://www.drupal.org/project/drupal/issues/3312270 |
[14:33:46] | <FarmerEd[m]> | no bother so, |
[14:33:46] | <FarmerEd[m]> | I had come across it last week too but hadn't made the composer connection and just restored the image as figured I'd just done something stupid |
[14:41:01] | <FarmerEd[m]> | Ok................. |
[14:41:01] | <FarmerEd[m]> | I may have discovered something |
[14:41:01] | <FarmerEd[m]> | hook_ENTITY_TYPE_update() is not working for me for entities created through the API but does from the UI |
[14:41:01] | <FarmerEd[m]> | hook_ENTITY_TYPE_insert() does work for entities created through the API |
[14:41:19] | <mstenta[m]> | OH! yesssss |
[14:41:26] | <mstenta[m]> | _update() only works with EDITS |
[14:41:32] | <mstenta[m]> | _insert() only works with CREATES |
[14:41:55] | <mstenta[m]> | oh wait... |
[14:42:05] | <mstenta[m]> | re-reading what you said more closely... |
[14:42:07] | <FarmerEd[m]> | but entities created in the UI still fire as an edit? |
[14:42:35] | <mstenta[m]> | gotcha |
[14:42:46] | <mstenta[m]> | maybe what's happening is they are being saved twice when you save through UI |
[14:42:50] | <mstenta[m]> | for some reason |
[14:42:52] | <FarmerEd[m]> | because they are created from a form |
[14:42:54] | <FarmerEd[m]> | ?? |
[14:43:16] | <mstenta[m]> | yea not sure! |
[14:43:22] | <mstenta[m]> | it must be saving it twice |
[14:43:25] | <mstenta[m]> | that would be my guess |
[14:43:40] | <mstenta[m]> | so the first one is an insert, and the second is an update (which you were seeing) |
[14:43:46] | <mstenta[m]> | (maybe?) |
[14:44:08] | <FarmerEd[m]> | would that not cause a version increment of the log? |
[14:44:58] | <mstenta[m]> | another revision you mean? not necessarily... i think that needs to be explicitly done... and we do that automatically for API and UI saves IIRC |
[14:45:25] | <mstenta[m]> | (but not for every ->save() that happens in code) |
[14:45:26] | <FarmerEd[m]> | Yes, brain couldn't come up with revision for some reason :D |
[14:48:31] | <FarmerEd[m]> | OK, so at least I know what's wrong with my module |
[14:48:31] | <FarmerEd[m]> | Might need to rethink a few bits, I thought it was nice that update, covered creation also, but it's a little annoying if the API and UI don't behave the same. |
[14:49:38] | <mstenta[m]> | yea you should always use _insert() and _update() separately |
[14:49:49] | <mstenta[m]> | i would be curious to figure out why BOTH are running on a UI creation though |
[14:50:09] | <mstenta[m]> | maybe that's a bug... or if not, then maybe you will want to filter out some of the _update() executions |
[14:51:17] | <mstenta[m]> | a traceback in _update() would probably tell us what's happening |
[14:51:22] | <FarmerEd[m]> | Yea, I can see the sense in that and it wouldn't be an issue if they both behaved the same |
[14:51:58] | <FarmerEd[m]> | API and UI that is |
[14:52:25] | <mstenta[m]> | yea i'm curious what else is firing |
[14:52:28] | <mstenta[m]> | and why it differs via API and UI |
[14:56:31] | <FarmerEd[m]> | Guess I need to go sort out a proper IDE for myself |
[14:58:21] | <mstenta[m]> | that would be best! but you could also get away with just throwing some logging lines into your hooks |
[14:58:36] | <mstenta[m]> | \Drupal::logger('mymodule')->error('my message'); |
[14:58:44] | <mstenta[m]> | that will put stuff in /admin/reports/dblog |
[14:59:11] | <mstenta[m]> | although it only works with strings... but one trick is to json encode a var and then log that |
[14:59:35] | <mstenta[m]> | \Drupal::logger('mymodule')->error(json_encode($var)); |
[14:59:52] | <mstenta[m]> | this might be fun: |
[15:00:01] | <mstenta[m]> | \Drupal::logger('mymodule')->error(json_encode(debug_backtrace())); |
[15:00:28] | <mstenta[m]> | or it might be crazy! 😄 |
[15:00:29] | <mstenta[m]> | gtg pick up kid from school 👋 |
[15:00:49] | <FarmerEd[m]> | No problem, thanks again |
[15:07:04] | <paul121[m]> | <mstenta[m]> "i would be curious to figure out..." <- Interesting! Curious if this is an asset or log. For logs we do have some logic that will update the log after creation if needed eg: copy the location geometry onto the log |
[15:08:59] | <FarmerEd[m]> | It is a log and that might make perfect sense, as I sent the bare minimum in the API to create a log with a note. |
[15:13:26] | <mstenta[m]> | That should be happening via API too though 🤔 |
[15:13:52] | <mstenta[m]> | But maybe you referenced a location in UI but not API? |
[15:15:26] | <FarmerEd[m]> | No was creating logs with the bare minimum in both cases. |
[15:15:59] | <mstenta[m]> | Hmm then that's probably not where the extra save is happening |
[15:16:24] | <mstenta[m]> | Might be worth confirming that this hypothesis of two saves is correct first |
[15:16:57] | <mstenta[m]> | By logging a simple string in both insert and update hooks |
[16:00:13] | <FarmerEd[m]> | I presume you mean using both hooks at the same time? |
[16:00:35] | <mstenta[m]> | yea |
[16:00:37] | <mstenta[m]> | with just a simple log message going to /admin/reports/dblog to see which fire |
[16:14:22] | <FarmerEd[m]> | More confused than ever now as they seem to be working the way they should?? |
[16:17:07] | <mstenta[m]> | are you seeing both insert and update fire when you create a log through the UI? |
[16:19:02] | <FarmerEd[m]> | I take it back,,,, both fire from the UI not sure I cleared the cache :D |
[16:20:01] | <FarmerEd[m]> | ACTION uploaded an image: (14KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/jJvuqmtDoWQ... > |
[16:21:06] | <mstenta[m]> | ok try adding this one to the update: |
[16:21:16] | <mstenta[m]> | > \Drupal::logger('mymodule')->error(json_encode(debug_backtrace())); |
[16:25:05] | <FarmerEd[m]> | comes back blank |
[16:26:28] | <mstenta[m]> | oh hmm |
[16:26:37] | <mstenta[m]> | maybe that can't be json encoded |
[16:26:55] | <mstenta[m]> | what about debug_backtrace()[0] |
[16:34:27] | <FarmerEd[m]> | just says array |
[16:34:59] | <FarmerEd[m]> | but I've noticed something and paul121 is probably right |
[16:35:54] | <FarmerEd[m]> | using an automatic log name fires both but a manual log name only fires one |
[16:36:26] | <mstenta[m]> | Ahhh |
[16:38:52] | <mstenta[m]> | https://git.drupalcode.org/project/log/-/blob/2.x/src/LogStorage.php#L65 |
[16:39:07] | <mstenta[m]> | I wonder if we could move that to a presave |
[16:39:32] | <mstenta[m]> | Oh wait nope |
[16:39:52] | <mstenta[m]> | // We must run the parent method before we set the name, so that new logs // have an ID that can be used in token replacements. // Also, we must run the parent method after the logic above, because the // parent method unsets $entity->original. |
[16:40:19] | <mstenta[m]> | In order to generate a name it needs a log ID |
[16:40:42] | <FarmerEd[m]> | of course |
[16:40:49] | <mstenta[m]> | Well at least you discovered the cause! |
[16:41:02] | <mstenta[m]> | And should be able to work around it? |
[16:44:46] | <FarmerEd[m]> | presumably, might need a bit more fiddling and testing but at least I know what I'm dealing with |
[17:00:01] | <FarmerEd[m]> | and just to confirm, omitting the log name from API triggers the update hook |
[17:02:40] | <mstenta[m]> | ah ha! great! |
[17:02:43] | <mstenta[m]> | thanks for checking all that |
[17:07:58] | <FarmerEd[m]> | Great to get it figured out, was digging myself into a hole for a while there. |
[17:07:58] | <FarmerEd[m]> | Now to scrap this module and make some plugins for the core notifications module. |