| [06:11:54] | <FarmerEd[m]> | Working on a settings menu for a module, but some settings won't update till cache is cleared. |
| [06:11:55] | <FarmerEd[m]> | Using drupal_flush_all_caches(); on save works, but I'm wondering if it should be used? |
| [06:45:33] | <mstenta[m]> | Farmer Ed: i don't think there's any harm. It is a heavy process to rebuild everything, but probably not terrible if it's only on settings form save |
| [06:46:00] | <mstenta[m]> | Could try to find a more targeted method, to rebuild only what you need |
| [06:47:15] | <mstenta[m]> | What are you rebuilding? Menus? Routes? |
| [06:47:24] | <FarmerEd[m]> | Menues |
| [06:47:27] | <FarmerEd[m]> | Menus |
| [06:48:14] | <FarmerEd[m]> | It may be a bit heavy alright, but wouldn't expect it to be changed too often either |
| [06:49:00] | <mstenta[m]> | I'm sure there's a targeted way to do that, but I don't know what it is :-) |
| [06:49:02] | <FarmerEd[m]> | would it be render cache? |
| [06:53:51] | <mstenta[m]> | No that's its own thing |
| [06:53:52] | <mstenta[m]> | Lots of caches :-) |
| [06:54:54] | <FarmerEd[m]> | OK.............. |
| [06:54:55] | <FarmerEd[m]> | But it seems to be working |
| [06:55:25] | <FarmerEd[m]> | \Drupal::service('cache.render')->invalidateAll(); |
| [06:56:58] | <FarmerEd[m]> | and it saves considerably quicker |
| [07:13:14] | <FarmerEd[m]> | also tried |
| [07:13:14] | <FarmerEd[m]> | \\Drupal::cache('menu')->invalidateAll() |
| [07:13:24] | <FarmerEd[m]> | but it didn't work |
| [07:21:47] | <mstenta[m]> | Well if it works 🤷 |
| [07:22:03] | <mstenta[m]> | I stand corrected |
| [07:23:39] | <FarmerEd[m]> | I think I will do some more testing, perhaps on a clean install later just to be sure. |
| [07:26:44] | <FarmerEd[m]> | But thanks, the real question was whether or not clearing the cache like this would be poor practice, so I suppose clearing the smallest portion possible is the answer. |
| [11:55:42] | <mstenta[m]> | Hey can't make the call today |
| [15:13:08] | <symbioquine[m]> | https://www.youtube.com/watch?v=hIOrNcLZRhc |
| [16:40:28] | <FarmerEd[m]> | symbioquine: I tried the calendar event ID option with the Google API, it prevents duplicate events being created alright unfortunately it does not overwrite by default, so will need to apply some logic to delete any existing event then post the new event in the case of updates. |
| [16:43:15] | <symbioquine[m]> | Can you catch the failed create and issue an update if the exception or response code indicates a duplicate? I think that would produce better failure modes. |
| [16:48:35] | <FarmerEd[m]> | Yes, of course, that would make more sense. |
| [16:48:35] | <symbioquine[m]> | Ideally it should return an [HTTP 409](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409) error with a suitable error message. |
| [16:48:43] | <FarmerEd[m]> | events` resulted in a `409 Conflict` response: { "error": { "errors": [ { "domain": "global", "reason": "duplicate |
| [16:49:15] | <symbioquine[m]> | 🤓 |
| [16:49:35] | <FarmerEd[m]> | and PATCH should be straight forward with the ID |
| [16:49:35] | <FarmerEd[m]> | PATCH https://www.googleapis.com/calendar/v3/calendars/calendarId/events/eventId |
| [16:50:45] | <FarmerEd[m]> | Cool, that will make for a much more robust workflow |
| [16:54:10] | <symbioquine[m]> | I wish they'd explicitly document in the update/patch API docs what happens if you specify a non-existent eventId... Depending how it's implemented, it's possible that your use-case can just always patch or update - even for the initial creation... |
| [16:54:21] | <symbioquine[m]> | Then it wouldn't require the second call |
| [16:55:00] | <symbioquine[m]> | For anybody else following along, the docs in question are: https://developers.google.com/calendar/api/v3/reference/events/patch |
| [16:55:12] | <FarmerEd[m]> | I can try that first then |
| [17:06:49] | <FarmerEd[m]> | Well unsurprisingly PATCH works for update but not creation. But there is enough to keep me going for now |
| [17:08:28] | <symbioquine[m]> | How about update for creation? |
| [17:09:23] | <FarmerEd[m]> | ? is PATCH not update |
| [17:10:03] | <FarmerEd[m]> | ah |
| [17:10:09] | <symbioquine[m]> | It looked like both exist as APIs |
| [17:10:09] | <FarmerEd[m]> | they have too many options |
| [17:14:39] | <FarmerEd[m]> | <symbioquine[m]> "🤓" <- Those glasses suit you |
| [17:16:24] | <FarmerEd[m]> | update is the winner |
| [17:18:25] | <symbioquine[m]> | Ha! Awesome! |
| [17:19:35] | <FarmerEd[m]> | leaves it simple, |
| [17:19:35] | <FarmerEd[m]> | only need to deal with the event if the calendar entry is no longer required now |
| [17:19:35] | <FarmerEd[m]> | but that can wit till tomorrow, so thanks v much. |
| [17:20:46] | <symbioquine[m]> | NP :) |