heykarthikwithu: Send Mail with Custom Email Template & with Dynamic values via Drupal Mail Service1/31/2021
Send Mail with Custom Email Template & with Dynamic values via Drupal Mail Service
Sending an email works with defining an email template (subject, text and possibly email headers) and the replacement values to use in the appropriate places in the template. Processed email templates are requested from hook_mail() from the module sending the email. Any module can modify the composed email message array using hook_mail_alter(). Finally \Drupal::service('plugin.manager.mail')->mail() sends the email, which can be reused if the exact same composed email is to be sent to multiple recipients. Originally from Drupal.org aggregator https://ift.tt/3oAbOs9
0 Comments
Drupal sites contain a settings.php file with site-specific settings, that is based off default.settings.php at the time the site is installed. As Drupal evolves, default.settings.php will change. Sometimes, it's worth incorporating those changes into the settings.php file for an already-installed site. This post runs through a low-friction way to keep on top of this house-keeping.
Blog Category:
Originally from Drupal.org aggregator https://ift.tt/3pB4TA9 A recent Wired article about the Parler data hack talked about how a hacker group was able to steal publicly available information from the Parler website using an Insecure Direct Object Reference (IDOR) or enumeration attack. This type of attack involves a hacker looking at the structure of the site and attempting to guess the next available resource by looking at the URL. Apparently, terabytes of Parler's data was downloaded by simply enumerating through the ID's of their publicly available posts. Taking an arbitrary example in Drupal, let's say that you had a content type called post that was loaded using the type and ID of the content in the URL. This means that when a user visits the post they might see a URL with the path /post/1. If a user wanted to see the next available post on the site then they could just increase the ID by one and see if the next post loads or not. It becomes almost trivial to build a script to download every post on the site by just looking through the ID of the posts. This is almost what happened in the Parler attack, although that attack was done through their API service rather than through their website, but the principle is the same. You might not think this is much of a problem, but you can actually leak a lot of information from a site like this without even realising it. Especially problematic is user profiles where improperly controlled user profile pages can mean that a site can leak all of their user data without hackers needing to break into the system. It doesn't have to be user profiles though, many users will post identifiable information in public posts and so any system that allows all of these posts to be enumerated will leak quite a lot of information that can be easily linked back to users. Originally from Drupal.org aggregator https://ift.tt/3cmRDeF Dries Buytaert: Acquia a Leader in the 2021 Gartner Magic Quadrant for Digital Experience Platforms1/29/2021 Today, for the second consecutive year, Acquia was named a Leader in Gartner's Magic Quadrant for Digital Experience Platforms (DXPs). Our leader position improved compared to last year. Acquia is now the number two. Market validation from Gartner on our vision is exciting and encouraging. In the report, the analysts note the Drupal community as a powerful entity that sets Acquia apart from closed-monoliths. Closed monolithic stacks and martech silos are quickly becoming a thing of the past. Drupal's scale, modularity and openness is a real differentiator. Mandatory disclaimer from GartnerGartner, Magic Quadrant for Digital Experience Platforms, Irina Guseva, Mick MacComascaigh, Mike Lowndes, January 27, 2021. This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Acquia. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. Originally from Drupal.org aggregator https://ift.tt/2YtcbKw What is hook_update_N()?Let’s say you are developing a Drupal module (custom or contrib) which tracks how many visitors landed on specific node pages, version 1 of your code might track visitors by nid (node id) in the database using a table like this:
Let’s set aside the debate over whether the above is a good idea or not, but once your code has been deployed live to production sites, that’s what the data will look like. This module might work very well for a long time, and then you might have the need to track not only nodes but also, say, taxonomy term pages. You might rethink what your database table to look like this:
To achieve this change when the first version of your database is already out in the wild, you need to tell target environments to update the database schema. This is done using hook_update_N(), and you would replace the N() by incremental numbers, something like this:
If this case 9 is the major version (Drupal 9) and 001 because this is the first update to your code. Each module tracks which version it’s using, so that if code introduces new hook_update_N() functions, it will know to run them only once. You can tell which schema version any installed module is using by running, for example:
This might tell you, for example, that Webform’s current schema is 8621. This means that the latest update hook that was run is Webform’s If you ever need to re-run an update hook (which happens rather rarely), you can update the schema, like this:
So what’s wrong with this?This works well almost all the time, and you can automate your deployment process to update the database, making sure your schemas are always in sync. However as developers and site users it is important to be aware of certain drawbacks of hook_update_N(), which I’ll get to in detail:
The shaky foundation of database-driven websitesThe idea of version control is paramount to how we conceive of computer code. If you’re following the precepts of continuous deployment, then every version of your code needs to “work” (that is, tests need to pass, or, at the very least, it needs to be installable). For example, let’s assume a bug makes it to your production for version 5 of your code, and you know this bug was not present on version 4 of your code, you should theoretically be able to check out version 4 and confirm it was working, then figure out what the difference it between version 4 and 5. In fact this is exactly how things work on static sites such as Jekyll: all your data and your functionality (Javascript) are in your codebase. Each version of your code will be internally coherent, and not rely on an external unversioned database to do something useful. On database-driven projects based on Drupal or Wordpress, if you check out version 4 of your codebase, it will probably not do anything useful without a database dump which was created using version 4 of your code. Therefore, although we all use version control for our code, we are almost fooling ourselves, because critical parts of our project are not version-controlled: the database dump, the Although it makes sense for certain elements to be a database or on In fact, the blog post you are reading right now is a file under version control on Jekyll, which you can see using this link, and not some collection of opaque, unversioned, entries in database tables with names like Oh, did I mention that I love Drupal? Tight code-database couplingLet’s imagine a world where the database schema never changed. A world where In such a world, you could take any version of your code, and any version of your database dump (say, the latest version), combine the two on a test environment, and debug errors at will. In the real world, every time any module updates the database schema, it makes the database more tightly coupled to the current version of the codebase. Let’s take our “number of visitors per entity” code we had earlier: if I use an old codebase which expects my table to contain fields “nid” and “visitors”, but my only available database dump has fields “type” “id”, “visitors”, the history of my carefully version-controlled codebase will be useless, and old versions will fail with an error such as:
Gradual deploymentsMostly we think of Drupal sites as being on a server with one copy of the codebase, and one copy of the database. So the concept of keeping the database and code “in sync” makes sense. But as more and more teams use containers and Kubernetes-type container-orchestration systems, high-traffic sites might have, say, one performance-optimized database, and then 5, 10 or 20 load-balanced copies of your PHP code. Acquia uses such a setup behind the scenes for its cloud hosting, so it’s good to develop with this in mind. On Acquia’s setup, each PHP container shares a single database, as well as the private and public files directories. But the PHP containers do not share the It’s important to realize this when building large files over several web requests, and can lead to hard-to-diagnose bugs such as:
But in addition to providing you with headaches such as the above issues, multiple containers can also allow you to do gradual deployments of new code, reducing the risk of failure. For example, let’s say you have 20 Drupal containers with 20 copies of your codebase, and each Drupal container is connected to a shared database, and shared files and private files directories. If you are deploying a risky update to your code, you might want to start by deploying it to 25% of the containers (5). Then if there are no adverse effects, scale up to 10 the next day, then the entire 20 the day after. Code that uses RollbacksLet’s forget about fancy container orchestration and just look at a typical Drupal website. A simple real-world site might have a “contact us” webform and some pages, plus some custom functionality. Let’s say you are deploying a change to your codebase which triggers a hook_update_N(). No matter the amount of unit tests, stage testing, there is always the possibility that a deployment to production might trigger unforseen issues. Let’s assume this is the case here. A typical deployment-to-production scenario would be:
In a situation like this, if you did not have hook_update_N()s in your code, you could simply roll back your codebase on production to the previous version. However, this is no longer an option because your database will not work with previous versions of your codebase: there is no hook_downgrad_N(). You are now forced to live with the latest version of your code, and all the benefits of version-controlling your code are for naught. Config managementLet us recall the elements which make up a Drupal website:
If you are using configuration management and a dev-stage-production workflow, there is a third category:
It is worth recalling a typical workflow:
At this point your field is in your production codebase but not your production database. Don’t forget: your deployment script already has “drush updb” in it. The question is: do you run “drush config-import” before or after “drush updb”? It turns out this is not that easy a question to answer. Drush also provides a Regardless of your deployment process, however, we need to take into account a more troubling possibility: In addition to relatively benign database schema updates, hook_update_N() can modify configuration as well. In such a case, if you are not careful to run hook_update_N() first on your development environment, then export the resulting configuration, then run your deployment, you may run into the following problem: Let’s look at a real-world example using the Webform module. Let’s install a new Drupal 8 site with Webform 5.23, then export our configuration, then upgrade to Webform 6.x and import our old configuration. We’ll this causes a bug, and we’ll see why after.
This puts your current site configuration into code. Among said configuration, let’s focus on a single piece of configuration from Webform:
The base path for webforms is form. This tells Webform to build URLs with a structure such as https://ift.tt/3pzw7Y6. Let’s now update webform, and our database.
In Webform’s But we are re-importing old config, which overwrites this change and reverts webform.settings:settings.default_page_base_path to “form”, not “/form” To see the type of hard-to-diagnose error this might lead to, you can now log into your Drupal site, visit /admin/structure/webform, create a webform named “test”, and click on the “View” tab. Because the base path lack the expected trailing prefix, you now get the “not found” URL /admin/structure/webform/manage/form/test, instead of the expected /form/test. In addition, this has a number of cascading effects including the creation of badly-formatted URL aliases which you can see at /admin/config/search/path. If you find yourself in this situation on production, you need to revert your Webform schema version on your development environment, export your config, reimoprt it on production, and resave your forms, and potentially fix all your paths starting with “form” on /admin/config/search/path so that they start with “/form”. To be fair, this is not the fault of the Webform maintainers. In my opinion it shows a fundamental frailty in hook_update_N() combined with lack of documentation on deployment best practices. However, if we strive for Drupal to be a robust framework, there should not be a single point of failure (in this case not strictly adhering to fickle, badly-documented deployment procedures) which can lead to major instability on production. How do we fix hook_update_N()?Here are a few approaches to avoid the potential damage done by hook_update_N(): Approach 1: don’t use hook_update_N()When possible, you might consider not using hook_update_N() at all. Consider our “number of visitors per node” module from earlier. Instead of a hook_udate_N(), your code could do something like this:
The above approach adds complexity to your code, which you can add to a “storage” abstraction class. Although not ideal, this does away with the need to use hook_update_N(). Approach 2: Don’t use hook_update_N() to update configurationUpdating configuration, as seen above, is even more dangerous than updating non-configuration database tables. So if at all possible, avoid it. In the Webform example given above, it might have been reasonable to consider keeping with the old non-leading-slash format for path prefixes, rather than update configuration. When you absolutely must update configuration, you could consider the possibility that certain users might have reimported old configuration, and provide error-checking and hook_requirements() (displaying error messages on the /admin/reports/status page) accordingly. Approach 3: Robust exception handlingDo not assume that your database schema is up-to-date. If you decide that it is worth update the schema from, for example, “nid” and “visitors” to “type”, “id”, “visitors”, when querying the database, you might want to consider the possibility that for whatever reason the database is not up-to-date. Here is some pseudo-code:
That way, if your database and code are not in sync, it’s not going to break your entire site. Approach 4: keep config changing logic idempotent and separate from update hooksLet’s look again at Webform’s I would recommend having a separate function to update config, and call that function from the update hook. That way, if a development team makes the mistake of not updating their configuration before importing it into production, it will become easier to run, say “my_module_update_configuration()”. Then, your hook_requirements() might perform some sanity checks to make sure your configuration is as expected (in this example, that the “webform.settings:settings.default_page_base_path” config item has a leading slash). If this smoke test fails, developers can be directed to run In addition, ResourcesWhat is hook_update_N()?Originally from Drupal.org aggregator https://ift.tt/3pq8G3f
The program committee shares about impostor syndrome and wants to remind community members that you know more than you give yourself credit for. Originally from Drupal.org aggregator https://ift.tt/3iUSMLG 8 Easy Ways to Improve Your Website Typography in Under 30 Minutes https://t.co/oFjdvxWBzm1/28/2021
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
April 2023
Categories |