When I started this series on writing for developers and consultants, I thought of this piece first, but I couldn’t get the ideas to come together. Sometimes it takes a few tries.

Anytime you write something, you should be aware of what kind of document you’re writing and who is it for. The definition of “document” in this context is very broad it could be: an email, letter, solution design, chat messages, blog post, test script, work of fiction, book, poem, presentation, marketing slide deck, scope of work, and so on: anything that involves writing words.

For example, this is a blog post, about writing, meant for people who are developers or technology consultants who may have been told good writing isn’t important.

Common Work Documents

I’m going to put aside poems, novels, and other personal writing forms to focus here on work related writing. Developers need to be able to describe their work to other people. We also need to communicate about what is happening on a project, support one another, and ask for help. We do all these things with words, and often in writing.

In my career I’ve written a wide variety of documents as part of my work. A partial list (because I doubt I can think of everything to create a complete list) includes:

• Emails
  • to my boss
  • to colleagues or friends
  • to direct reports
  • to clients
  • to large mailing lists
• Solution Design Documents
• Scopes of Work
• Contracts
• Invoices
• Test Scripts
• Conference Talks
• Research Reports
• Chat Messages

Some require more detail and longer prose than others. Some are expected to be polished where others can tolerate typos and mistakes. But each has its own style, structure, audience, and expectations that the writer must meet.

A Document’s Purpose

When you start to wring something, know your purpose in writing.

Not all documents are created equal and so understanding your purpose is critical. Are you writing an Solution Design that needs to outline how you plan to solve all the hard problems in a project? Or are your writing an email to your boss asking for a few days off? Is this a research report meant to support an advocacy project or a cover letter for a resume? All of those are important things, but none should be written in the same tone or with the same style.

A Scope of Work (SOW) is a lasting artifact during a projects that sets the bounds of the work you’re going to complete. A sloppy SOW can cost you, or your employer, vast sums of money. A SOW writing purely to defended against those concerns may not express the client’s needs and interests, and result in them refusing to sign.

An email to a client might be a friendly reminder about pending deadlines, or a carefully crafted notes from a contentious meeting. Written well, both could leave you in a better place with your client. Written poor, both may cause your client to become frustrated with your sloppiness.

If you don’t know why you’re writing something, you are likely to write the wrong thing. At work, if you aren’t sure, ask for guidance.

A Document’s Audience

There is no such thing as a “general audience” you should always have a mental image of who you are writing to, and why.

We all know that it’s important to think about your audience, but we don’t always do this well. In part because determining the audience is sometimes a little complicated.

When your audience is the person or people you are writing to, you need to leverage your understanding of their knowledge, skill set, and project engagement. You want your text to meet them where they are.

Sometimes the audience you care about most, isn’t the direct subject of the message, but a 3rd party we know, or suspect, will read the document later. I find this is true particularly in contentious situations.

FOIA Warning

If you work in, for, or with government agencies in the US (and for similar reasons elsewhere as well) – including as a subcontractor – you should understand if your content is subject to a Freedom of Information Act requests. Sometimes your audience isn’t the person you are writing to at all, but the reporter who could read the message 2 years from now after they get copies of everything related to your project. In those settings, don’t put anything in writing you don’t want on the front page of a major newspaper.

But FOIA can also be a blessing for a developer who knows a bad decision is being made. Carefully worded expressions of concern, and requests for written confirmation of next steps, can trigger FIOA-cautious readers to recognize they need to follow your advice.

Finding the Right Level of Technical Detail

One of the hardest things for developers, and other people with lots of technical knowledge, to do well is communicate clearly about technical minutia. There is a balance to be struck between providing transparency and overwhelming readers with details. Developers have to think about details in our work. We also use field specific jargon that can be confusing to people whose work is in other areas.

Too often we confuse that specialized knowledge of our field, with intelligence. I have watched developers lose their audience in the nuances of small details, and come away announcing their audience was a bunch of idiots. Early in my career I was guilty of this as well. Assume you’re audience is as smart as you; they just know different stuff.

When you make that assumption you can avoid talking down to people, and start to work on finding their level.

The right level of technical detail will also vary by document type. When I’m exchanging emails with a client’s in-house developer we go deep into the weeds often. When I’m writing a SOW, the technical detail is nearly absent as we are defining functionality and purpose, not the exacting detail of how that functionality will be delivered.

The more you can be in conversation with the people you’re working with about their background, the easier it will be to find the right level of detail to explain yourself clearly.

Summation

Hopefully by now it’s clear, this is an overview of approach, not detailed guidance. In a future post I plan to write about some of these specific documents types, and how to write them. Hopefully this overview gives you ideas and things to think about as you work on your next document.

As I said in my first post on this topic, communications skills for developers and consultants is an enormous topic. The plan for this series is evolving as I go. If you have suggestions or requests feel free to leave me a message.

The post Writing for Developers and Consultants: Know your Documents Types appeared first on Spinning Code.

Mike Goulding

Senior Drupal Engineer

Mike has been part of the Four Kitchens crew since 2018, where he works as a senior engineer and tech lead for a variety of Drupal and WordPress projects.

January 1, 1970

A common time-saver for organizations managing multiple Drupal sites is reducing to shared code in a concept called an upstream. This can be done through a hosting provider, continuous integration tooling, or old-fashioned copy-and-paste. (But don’t do that!)

This saves time by having most of the code shared by these sites stored in a single repository while allowing the sites to be somewhat unique from each other. It also avoids some of the overhead and pitfalls of a traditional Drupal multisite installation — something that several hosting providers haven’t been keen on recently.

A struggle that occurs when using the upstream technique is deploying a global configuration that should apply to all or some of the sites without removing what is uniquely theirs. In previous versions of Drupal, this was done using the Features module, and that is something that can still be done with some success. However, Features does come with some downsides regarding managing different configurations across sites.

In the setup described above, this becomes especially troublesome when configurations between sites need to be overridden. One site has a different field added to the blog content type, and the features import process can become painfully complex to deal with by itself.

So, what option do I suggest for upstreams and organizations managing multiple sites? Configuration Split. In particular, the latest iteration of this module, 2.x, which allows for easier conditional splitting and importing of configuration.

What is Configuration Split?

Configuration Split, or Config Split, as it is better known, has been around for a while, enabling many excellent uses. A quick example of how this module has been used would be enabling various modules and configuration between different environments for a site. It allows for importing different configuration files into a Drupal site based on certain set conditions.

Specifically, it allows for splitting up configuration into different groups that can be set to inactive or active programmatically. This is an improvement from both using the Features module and using other custom code to enable and disable things manually on different sites or environments.

Using Config Split simplifies configuration management by keeping development-specific modules and settings separate from the main site configuration. This helps maintain a cleaner environment on production and allows for automatic installation and removal of development-only features.

Additionally, Config Split can also be used for version control purposes. By splitting configuration into different groups, it becomes easier to track changes and roll back to previous configurations, if needed. This is especially useful for larger sites with multiple developers working on different features or environments.

Config Split 1.x

The initial release of Config Split opened up opportunities to do something different with Drupal configuration that wasn’t possible before with the default configuration management system. By allowing different groups of configuration that can be activated and deactivated, it empowers teams to easily bring different configurations to different situations.

Some common uses that we saw early on were enabling specific development modules and settings for use only in local development environments. This was previously something that would have to be built into tooling locally to script out. Now it just happens because of a condition placed into settings. It took some guesswork out of what would be enabled on which environment, and that was a big help.

The ecosystem for Config Split includes more than just enabling and disabling certain configuration. Another big part is Config Ignore, which makes it possible to have configuration that isn’t changed on import. The earliest version of this module was more conceptual than it is now, but it still provided a way to avoid exporting and importing changing configuration (like blocks), that was meant to exist only on live environments. When paired with Config Split, this offered great control over which configuration would be active and in-use in specific environments.

Stacking, patching, and more

Though it may seem in conflict with the glowing review above, Config Split didn’t always mean that managing configuration was easier or simpler. In fact, it often meant that there were even more configuration files to manage, and parsing changes to a file in a code review would make even the most senior engineer groan. It solved bigger problems than it caused, but there were still downsides that gave teams pause and sparked discussion of whether there was a better way.

Thankfully, there is a better way! The newest version of Config Split, 2.x, brought many big changes that make this easier to manage, along with a few useful bonuses. One improvement was the concept of patches for partial configuration splits. Partial changes from the default configuration can now be represented with much smaller yaml files that only show what was added and/or removed instead of repeating the entire file. This makes code reviews of the changes much, much easier to deal with!

Along with additional improvements to how configuration imports and exports when splits are involved, another addition in the newer version of the module is stackable configuration. This means that splits that would previously have been in conflict, like adding a field and changing a label to a content type from different split groups, can now work together. This also means that test environments can better represent live environments while still enabling development modules and logging output without the configuration import complaining during the build.

This isn’t always the silver bullet for all of your problems. As we’ve discussed recently, there can be some steps that need documentation and considerations for maintenance to fully make use of Config Split on a build. This is especially something to consider when updates to other modules in use have updates that affect multiple configuration files.

Using Config Split to manage multiple sites

Recently, we have taken these improvements from Config Split and applied them to managing multiple sites and upstreams. Using set conditions like environmental variables or site names, we can use splits for features or configurations that are unique to individual sites in the project. In some ways this can feel like a stretch on the intended use case for the module, but it solves the problem well in the cases we have used it. I’ll illustrate more in a specific example where this has been used.

Let’s take a project where an organization is going to have multiple similar but unique websites. They have a small team, and want to manage these sites from a single repository to make deployments quick, but don’t want to prevent the sites from being somewhat different. In some ways, a Drupal multisite can resolve part of this issue, but there are hosting limitations for that. Additionally, the multisite doesn’t completely avoid the issue of configuration differences, as those sites would still be using different databases.

In this situation, we use a single repository and use a continuous integration tool like CircleCI to push the code from that repository to the different sites where they are hosted. In this repository, we set up Config Split for each site in the project and the global configuration based on an example or default site. This way, configuration and features that should be available for the whole project can be developed in one place and deployed to each site. We can also make small changes to sites that make them different without incurring a lot of extra weight.

In a single repository configuration, we have different settings.php files that are loaded based on environmental variables so that each site always imports the correct information. This allows for differences in settings, content types, fields, and other aspects of the site. All of this with just one repository to manage and deployed to different instances without the duplication of effort and review between them. Sites can share similar architecture and have some differences without requiring a lot of overhead. The changed files are easy to review at a glance, knowing that only what is or should be different will be present.

We’ll talk about this more as time goes on and the module continues to grow. Adding this module to the toolbox for a Drupal site really can make managing one or more sites easier and more consistent. Should existing sites using features or something similar move to Config Split? I strongly feel that it is simpler to manage and that the workflow is more enjoyable.

The post Managing configuration in Drupal upstreams appeared first on Four Kitchens.

When I first got into web development after graduating from university, I got excited about how easy it was to build a website. A bit of knowledge goes a long way. I learned HTML, CSS, Ruby on Rails, and PHP, and tried all kinds of platforms and content management systems. Sometimes it felt hard and sometimes easy. But it was those “aha” moments when I could prototype a site in an afternoon that really got me excited. Which is why I think Drupal Starshot is such a promising initiative.

The goal of Starshot is to create an out-of-the-box version of Drupal that fast-tracks people through building and launching a website. It’ll attract new users, on-board them quickly, and give them an instant feeling of empowerment.

Starshot will show new users that, yes, you can build enterprise websites with Drupal — but you can also use it to launch a campaign, create an event website, or evolve a digital presence for your startup business. 

The Initiative was announced at DrupalCon Portland 2024. Already, more than 386 individuals have pledged support, and dozens of companies have expressed interest too. Starshot is shaping up to be one of the most exciting large-scale initiatives in Drupal’s 23 year history.

“Without a doubt, Starshot will be the largest change to Drupal since the foundational rewrite to modern object-oriented PHP that occurred with Drupal 8.” 

– Mike Herschel, Senior Front-End Developer at Agileana, former elected member of the Drupal Association Board of Directors

Is Starshot a Rewrite of Drupal?

No, Starshot isn’t a rewrite. It is built on Drupal core and include many features from recent Drupal initiatives, including:

• Recipes, packaged features that give you content types and content listings
• Project Browser, for adding more functionality
• Experience Builder, the improved version of Layout Builder for drag-and-drop page building 
• Automatic Updates

Drupal Starshot will be available alongside traditional Drupal Core on the Drupal.org download page later this year. Selecting Starshot will install the necessary features for various website use cases, simplifying the process for new users. Traditional Drupal Core will continue to be available for more custom sites. 

Watch the Driesnote from DrupalCon Portland 2024 where Starshot was revealed:

How Will Starshot Enhance the Open Web?

Starshot will increase Drupal usage and bring the power of open source to even more people by lowering the barrier to entry. It’s a great opportunity to package a version of Drupal that’s more attractive, user-friendly, and engaging for newcomers. This initiative will bring long-overdue improvements to usability, while maintaining Drupal’s strengths: content architecture, security, and multilingual support.

A key component of Starshot's development is its focus on the "Builder" persona—users who aspire to create amazing websites with Drupal but may not have extensive web development experience. By leveraging user research with Builders, Starshot will tailor its features and the editing interface around their needs. This means that folks with limited technical expertise can harness the power of Drupal to bring their creative ideas to life.

Starshot can pre-package Drupal with default configurations and pre-configured modules, leveraging the flexible Recipes initiative, and using the new Experience Builder to enhance page creation. Starshot should significantly reduce development and maintenance costs for simpler web builds. Plus, it will set good UX standards for Drupal websites across the board.

“Let’s reach for the stars and bring the open web to all.”

– Dries Buytaert, Creator and Project Lead of Drupal

How Can I Contribute?

The first releases of Starshot should be available before the end of 2024. The initiative needs lots of support to make this a reality!

Make your pledge on the Starshot landing page or reach out to us with the details of your expertise and availability. We’ll be happy to connect you with a meaningful way to contribute.

Want to help with marketing efforts related to Startshot? Go to the Drupal Marketing page or reach out to me directly.

Take Your Drupal Skills to New Heights

I’ve trained countless people in Drupal and web development over the years — always with the aim of empowering them and inspiring the same passion I have for building websites. If you’re looking to enhance your knowledge and gain valuable tools, you’ve come to the right place. My team and I offer course packages and custom training for site builders, content editors, UX/UI designers, front-end and back-end developers, and entire teams.

Learn more about Drupal training with Evolving Web.  

+ more awesome articles by Evolving Web

We are thrilled to announce that Evolving Web has been honored with the Social Impact Award in the Inaugural Pantheon Partner Awards for our work on the Planned Parenthood Direct website. 

The winners were announced at the Pantheon Partner dinner, held during DrupalCon Portland on May 6, 2024. Congratulations to the other winners who took to the stage with us: 

• Elevated Third – Partner of the Year Award
• WebMD Ignite – Innovation Award
• HoundER – Rookie of the Year Award
• Forum One – Customer First Award
• Danny Pfeiffer – Friends of Pantheon Partners Award

Pantheon’s Partner Awards recognize the outstanding contributions of digital agencies that drive positive change. We’re proud to be acknowledged for our role in the Planned Parenthood Direct project, which supports reproductive rights and enhancing access to reproductive and sexual healthcare. Our work on the project demonstrates our commitment to creating impact through user-centric digital experiences.

A Mission-Driven Collaboration

In the U.S., reproductive and sexual health care services vary from state to state. Planned Parenthood Direct (PPD) aims to provide trusted care from anywhere by offering “on-the-go” services. We collaborated with PPD to build a secure, mobile-first website on that informs users of available services in their state. The site also encourages users to download the PPD app, which they can use to order birth control.

Designing for Impact and Inclusion

Our team undertook the challenge of creating a highly informative, accessible website that appeals to a younger audience.

• We created dedicated pages for each state, ensuring they’re easy for PPD to update and optimized for search engines.
• We created a new visual brand identity that incorporates bold design principles for a youthful, reassuring, and non-stigmatizing user experience.
• Our mobile-first approach ensured that the site meets the needs of an audience who prefer mobile devices.
• We also followed accessibility best practices to ensure a user-friendly experience for all, including users with disabilities. 

Protecting Users with Exceptional Security

Security was a paramount concern, given the political climate surrounding reproductive rights. We ensured a highly secure online experience using a decoupled architecture with Next.js for the front-end and Drupal 10 for the back-end. Hosting on Pantheon added additional layers of security, including HTTPS certificates and DDoS protection.

Setting PPD Up For Success & Growth 

Our work on the Planned Parenthood Direct website included the development of 17 custom components and 14 content types in Layout Builder. This empowers PPD’s content editors to create flexible, engaging, and visually appealing layouts. The results is streamlined content creation and management, allowing PPD to maintain and grow their website effectively.

Outstanding Results & Continued Commitment

The new Planned Parenthood Direct website has been instrumental in continuing PPD’s mission to support human rights and ensure access to sexual and reproductive healthcare.

A big thank you to Pantheon for recognizing our efforts, and to Planned Parenthood Direct for trusting us with this important project. We’re honoured to have partnered with you both.

As we celebrate this award, we’re reminded of the importance of our work and the impact it has on communities. We look forward to future opportunities to make a difference.

Partner with us to turn your vision into a powerful digital experience that drives change. 

+ more awesome articles by Evolving Web

Dive into an in-depth conversation with Brian Perry as he unveils the latest updates and future trajectory of the API Client initiative. Discover how the Drupal API Client is revolutionizing the interaction with Drupal APIs, and explore the exciting opportunities it presents for web development enthusiasts. Join us as we unravel the journey of innovation and collaboration within the Drupal ecosystem.

Back in March I started to look at sponsors for the time I’m spending working on the Drupal core issue queue. It’s been a few months and I wanted to go back on all the sponsored commits I made as a Frontend Framework Manager, to show how the sponsorships helped Drupal for the past few months.

The sponsorship offer is simple: you send me a fixed monthly fee of 2500€, and I share the issue credit of every Drupal core commit that I make. I’m very thankful to Palantir.net and OPTASY who are sponsoring me. Thanks to them I was able to increase the amount of commits I can make to Drupal core. In the last 3 months I committed 61 issues (worth 610 weighted issue credits) and the more sponsors I have, the more time I can spend reviewing and committing issues.

1. Differentiate visually dragging with and without hierarchy A nice improvement for editors working a lot with lists and trees
2. Sticky table header is not sticky if --drupal-displace-offset-top is not defined
3. [jQuery 4] ajax.js and jquery.form.js use deprecated function $.parseJSON() Preparing for the next release of jQuery 4 with some cleanup.
4. cspell check is broken in commit-code-check.sh Sometimes we break the CI and it needs to be fixed 🤷
5. CKEditor admin toolbar config buttons using ::before to add content: have invalid screen reader text It takes dedication to land those accessibility fixes, kudos to our accessibility contributors.
6. Linking in CKEditor 5: URLs with top-level domain but without protocol should get a protocol added automatically
7. #states disable property has stopped working for submit button and other elements Sometimes when we clean-up code, we clean too much and break some other parts of the code
8. Setting width for sticky-header is broken
9. Negotiate max width/height of oEmbed assets more intelligently
10. States API doesn't work with multiple select fields This was a a 13 years old issue! It _always_ feels good to close an issue that old.
11. Add deprecation/bc support for library-overrides when files are moved Making sure backwards compatibility is working and useful
12. Remove default event from collpased nav-tabs button
13. [DrupalHtmlEngine] HTML-reserved characters (>, <, &) in <script> and <style> tag are converted to HTML entities It happens that we fix things for uses cases that stretch the reasonable (like having whole script tags in a WYSIWYG field)
14. Olivero: Show content preview checkbox is not center aligned with the layout builder buttons. Even a minor issue of a misaligned text by a few pixels is worth fixing
15. Drupal.theme.progressBar() does not escape output correctly
16. filter_autop should ignore twig.config debug html comments Making sure Developer experience doesn't impact regular users
17. tablePositionSticky should not be called on a non-array variable
18. CKEditor 5 table cell vertical align "middle" doesn't work
19. Move system/base component CSS to respective libraries where they exist A surprising performance improvement. There are still some low hanging fruits to improve the default frontend performance of Drupal
20. Remove country setting from the installer When you don't need a piece of data, just don't collect it
21. Media Library widget display doesn't return to first page on applying filters
22. Deprecate and remove the AJAX replace method That was a leftover D7 era deprecation
23. Claro should use libraries-extend for views_ui.css Even in core it happens that we don't use the right way to do something
24. Removal :tabbable usage in dialog.js Some more jQuery 4 preparation
25. Close icon is ovrlapping the title text in modal in claro Yes, typos can make it in the commit log
26. Convert Olivero's teaser into a single directory component Slowly but surely we're adding Single directory components to Drupal core
27. Refactor (if feasible) uses of the jQuery animate function to use Vanilla/native More CSS awesomeness making JavaScript code disapear
28. [11.x] Update to jQuery 4.0.x beta Drupal staying on the bleading edge of frontend developement :)
29. Refactor some uses of the jQuery parents function to use vanillaJS Did a small post earlier about this, CSS is really very good
30. [regression] Uncaught TypeError: Cannot read properties of null (reading 'style') (toolbar.js)
31. JSDoc for ajax command "changed" is incorrect There was a bunch of documentation fixes around this time
32. menu_heading_id variable is not set in menu-region--footer.html.twig
33. Add @file documentation to navigation.html.twig layout template
34. Add @file documentation to menu-region--footer.html.twig template
35. Views UI action buttons create janky layout shift on page load Polishing the loading of pages with heavy JS usage is important to show we care about UX
36. Remove bottom radius on hover state of expanded sub menu item
37. Setting empty URL when making embedded media a link in CKEditor5 causes JS errors
38. Update color of submenu title text
39. Collapsed nav-tabs status not exposed to screen reader There is a good number of accessibility fixes after this one, always nice to commit
40. Incorrect padding on child menu items
41. Claro: Form labels that are disabled have too low color contrast
42. Claro should not hardcode decimal list style type for <ol>
43. Some of string comparisons should use String.prototype.startsWith() or String.prototype.endsWith() Removing regular expressions as much as we can is a noble goal
44. Location of "Skip to Main" link below admin toolbar in Claro is problematic for screen magnifier users
45. Focus states on mobile second level navigation items can get cut off in Olivero
46. Regression: Shortcuts menu flickers when the page is loaded Those toolbar flickering issues are tricky. Thankfully the new navigation module code is simpler than the existing Toolbar code, so it's much much easier to deal with
47. escapeAdmin.js functionality should be removed(it not used anymore) Removed the feature that removed the overlay… for now, escapeAdmin will be back one way or another)
48. Navigation module offsets the Olivero skip link element
49. Umami page.tpl.php breaks block placeholders Sometime themes can break really nice Drupal features (like bigpipe)
50. Claro CSS for dropbutton items adds large gap of white space
51. Replace dialogContentResize jQuery event with CustomEvent Those events issues are really exciting, we're moving away slowly from jQuery for event management
52. Umami views should use responsive grid Another case of core not using the awesome features we provide, not anymore :)
53. Claro highlighted row not communicated to keyboard users
54. Fix overflow visibility for wrapper content in navigation CSS
55. Claro details component does not have the right class
56. Make drupal.tableheader only use CSS for sticky table headers I will always welcome CSS-removing-JS patches
57. Mismatch between implementation and description for Drupal.Message.prototype.remove().
58. "Skip to main content" link skips over content that is essential to the page, banner role should be for global content
59. Add pdureau as a co-maintainer for the Theme API with a focus on SDC Adding new maintainers is too rare. In this case the community is better for having him around
60. Choose an icon for the Announcements link
61. Remove deprecated moved_files entries in core

Many of these issues are maintenance focused, it’s not shiny, it’s not exciting, and it needs to be done. Sponsoring big initiatives like Starshot is exciting, let’s not forget the unexciting day to day that keeps things running. If you’re interested in supporting my work on Drupal core and keep the frontend fixes coming, consider sponsoring me.

Recently, we built a queue worker to send emails asynchronously, meeting a client's unique requirements to ensure email delivery. There is a lot of movement in the Drupal contribution space to innovate on the mailer. Traditionally, Drupal uses a plain PHP mailer to deliver transactional emails such as sign-up confirmation or password reset instructions. Nowadays, many websites rely on the contribution module Drupal Symfony Mailer to use the framework mailer by Symfony and leverage the flexible setup of mailer policies, transport, and HTML theming with templates. What needs to be added to the mix are easy-to-implement ways to send emails asynchronously. Today, we announce the first stable release of the new contribution module Symfony Mailer Queue.

Today, we will take a step back from reviewing the Migrate API. Instead, we will have an overview of content and configuration entities in Drupal 10. This is important for two reasons. Read more mauricio Wed, 05/29/2024 - 07:40

The person with the most trouble with duplicate material is the content writer. The hardest task is having to start over and make the necessary corrections after spending hours writing something and discovering that your content is plagiarized. 

This not only gives you a lot of work to do, but it may also interfere with the SEO of your website. Further, we’ll discuss the main problems brought on by duplicate content and discuss how the Drupal SEO module might assist in resolving this issue.