Almost no one uses /update.php but instead runs drush updb or drush deploy (which invokes updb.) Drush allows commands to specify the kernel when executing, which can be drupal (standard), update, or installer. I know it's standard practice, but I prefer preserving caches and crafting appropriate cache invalidations when needed for deployments.) Is that it? The difference is that Drupal's caches are flushed before hook_post_update_NAME is invoked? We already are not getting cached values back, but defining a hook_post_update_NAME – empty or with content ensures all of Drupal's caches are flushed (which I'm not a fan of dumping all your caches in a deployment. Each post-update hook is then added to the batch.If there are post-update hooks, drupal_flush_all_caches is invoked to reset all of Drupal's caches.Then the post-update hooks are discovered.Each hook_update_N implementation is placed into the batch – ordered by module weight, its name alphanumerically, dependencies, and its N value.That's a whole other topic if you are curious.) I used this a lot when I worked at a company that provided a SaaS on Drupal. Update dependencies are resolved (yes, you can say one update hook is dependent on another with hook_update_dependencies.All installed module updates ( hook_update_N) are discovered.The magic is in \Drupal\system\Controller\DbUpdateController::triggerBatch. So far, nothing about hook_update_N or hook_post_update_NAME has occurred. To me, this is where the special differentiations should surface. This callback is where updates a processed in a batch. The \Symfony\Component\HttpKernel\HttpKernelInterface::handle method is overridden in the UpdateKernel to have minimal handling of the request. It does a basic bootstrap and then invokes the \Drupal\system\Controller\DbUpdateController::handle controller directly, returning its responses. It ensures all cache bins are instances of \Drupal\Core\Update\UpdateBackend, which extends the NullBackend. It wraps the regular cache backend and prevents reads, but it will purge the wrapped cache bin on deletion. It also defines the NullBackend cache service and decorates the cache factory service. This HttpKernel implementation always forces the container to be rebuilt for each request. It uses \Drupal\Core\Update\UpdateKernel. When you visit /update.php, Drupal uses a different kernel to handle updates. Okay, let's dig and see if we can sort this out. HINT! GREAT CONTRIBUTION AREA IF YOU ARE A DOCUMENTATION KIND OF PERSON!!! Please, steal from this post I do not have the bandwidth to convert this into a decent guide for developer documentation. One of the more difficult problems is that the Update API documentation does not mention hook_post_update_NAME. Just "I need to do X first, and Y second. Unfortunately, it does not clear up the decision for me. The last link he refers to is the change record for when automatic entity schema updates were removed. The other issue is a length detail on some quirks when updating configuration during update hooks. is a very good resource to understand the recommended way to install/update/uninstall entity types/fields in the update hooks. post-update hooks are used to update config entities, can be used for CRUD content entities but not recommended as site config might need and update see.update_N hooks are used when config or DB schema needs CRUD.post-update hooks run right after update_N hooks.The "Improve documentation for post update hooks and update hooks to clarify distinction" issue on. I know I have experienced some oddities when executing various hook_update_N in sequential order – purposely making two update hooks at once, so they run after each other. Maybe part of the reasoning is to handle different stages. but it also manipulates the database schema here. Then it uses hook_post_update_NAME to perform some data manipulation. It uses hook_update_N to modify field definitions, which are schema. The Workspaces module has a decent separation. There are configuration updates and changes to View entities in both update hooks, with no real differentiation or understanding of why. And, then, hook_post_update_NAME is for configuration changes and clearing caches once the schema changes have been finished.īut is that true? Does Drupal core follow this pattern? Finding examples in Drupal core was also tricky I had to switch back to the 8.9.x branch to get a good collection of references. My gut instinct is that hook_update_N is for schema and other database-related changes. I have ideas, but I was not sure about the concrete reasons. Today I realized that I had no idea when it was appropriate to use hook_update_N or hook_post_update_NAME.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |