Planet Drupal

Like many folks, I've been fascinated by the incredible evolution of AI tools in 2023. At the same time, I've been working to figure out exactly where AI fits into my various roles as a Drupal developer, trainer, and business owner.

In this blog post, I detail a recent exploration I made into using AI (GitHub Copilot, to be precise) to generate a PhpUnit test in a Drupal contrib module that I maintain.

tl;dr I was impressed.

Prerequisites

For this exercise, I used Visual Studio Code with the GitHub Copilot extension installed. I am using the Copilot Business plan ($19/month, but there is a free trial available).

The task

The Markdown Easy contrib module includes a very simple service class with no dependencies that implements a single method. Normally, Drupal service classes would require a kernel test (due to dependencies,) but in this case a simple unit test will do the job.

While using Drush's generate command has generally been my preferred method for scaffolding a test class, I found that using Copilot provides a much more advanced starting point. But, like anything else generated via AI, knowledge of the right way to perform a task is not optional. Code generated by AI might be correct, but blind confidence in what the AI provides will surely get you into trouble sooner, rather than later.

The getFilterWeights() method that we tested is a relatively simple method that returns an array of filter weights for three filters related to the configuration of the Markdown Easy text filter. The method takes a single parameter: an array of filters assigned to a text format. This method ensures that the configured order of filters related to Markdown Easy provides a secure experience.

Therefore, it makes sense that the unit test should pass in several sets of filters to the getFilterWeights() method and ensure that the returned array is correct - a fairly simple test that utilizes a data provider. To be honest, if I wasn't experimenting with using Copilot to generate tests, I probably wouldn't have this test, as it is almost trivial.

Regardless, adding test coverage to custom or contrib modules is a fantastic way of building modules where sustainability is a top priority. This is one of the reasons why writing PhpUnit tests is a prominent aspect of the Professional Module Development course that I teach. 

Using the Copilot contextual menu - attempt 1

In this example, I placed my cursor at the end of the method name and then navigated the contextual menu to Copilot | Generate tests

By default, this will attempt to create the unit test class in markdown_easy/src/MarkdownUtilityTests.php, which is not the best-practice for location for tests in Drupal modules. Luckily, we can modify the location via the Create as option.

This results in a Save as dialog box in which we can specify the proper location for the test:

The test file is created in the proper place, but (at least in my test) it oddly didn't include an opening <?php tag, nor a namespace. Luckily, Copilot didn't make me work too hard on the namespace, as it correctly suggested the proper namespace via its autocomplete feature:

Once I manually added these (as well as declare(strict_types = 1);), the resulting test was:

<?php declare(strict_types = 1); namespace Drupal\Tests\markdown_easy\Unit; use Drupal\markdown_easy\MarkdownUtility; use Drupal\Tests\UnitTestCase; /** * Tests the MarkdownUtility class. * * @group markdown_easy */ class MarkdownUtilityTest extends UnitTestCase { /** * Tests the getFilterWeights method. */ public function testGetFilterWeights() { $markdownUtility = new MarkdownUtility(); // Test case 1: Empty filters array. $filters = []; $expectedWeights = []; $this->assertEquals($expectedWeights, $markdownUtility->getFilterWeights($filters)); // Test case 2: Non-empty filters array. $filters = [ 'filter1' => 10, 'filter2' => 5, 'filter3' => 15, ]; $expectedWeights = [ 'filter1' => 10, 'filter2' => 5, 'filter3' => 15, ]; $this->assertEquals($expectedWeights, $markdownUtility->getFilterWeights($filters)); // Test case 3: Filters array with duplicate keys. $filters = [ 'filter1' => 10, 'filter2' => 5, 'filter1' => 15, ]; $expectedWeights = [ 'filter1' => 15, 'filter2' => 5, ]; $this->assertEquals($expectedWeights, $markdownUtility->getFilterWeights($filters)); } }

As-is, this test does not pass, as Copilot missed the fact that the method will only return the weights of specific filters, so using filter1, filter2, etc.. doesn't help much...

Using the Copilot contextual menu - attempt 2

In this attempt, I highlighted the entire getFilterWeights() method and then selected Generate tests from the contextual menu. The result (without any changes on my part) was much better:

<?php namespace Drupal\Tests\markdown_easy\Unit; use Drupal\Tests\UnitTestCase; use Drupal\markdown_easy\MarkdownUtility; /** * Unit Test coverage for MarkdownUtility. * * @coversDefaultClass \Drupal\markdown_easy\MarkdownUtility * * @group markdown_easy */ class MarkdownUtilityTest extends UnitTestCase { /** * Tests the getFilterWeights method. * * @covers ::getFilterWeights */ public function testGetFilterWeights(): void { $markdownUtility = new MarkdownUtility(); // Create a sample array of filters. $filters = [ 'filter_html' => [ 'status' => true, 'weight' => 10, ], 'filter_autop' => [ 'status' => true, 'weight' => 20, ], 'markdown_easy' => [ 'status' => true, 'weight' => 30, ], ]; // Call the getFilterWeights method. $result = $markdownUtility->getFilterWeights($filters); // Assert that the weights are set correctly. $this->assertEquals(10, $result['filter_html']); $this->assertEquals(20, $result['filter_autop']); $this->assertEquals(30, $result['markdown_easy']); } }

Not only did Copilot get the opening PHP tag and the namespace correct, but the quality of the test was much better, and passed without any changes. However; this test was generated with only a single set of test data, so I decided to try again…

Using the contextual menu - attempt 3

In this attempt, I again highlighted the entire getFilterWeights() method and then proceeded to select Generate tests again from the contextual menu. The result was much better (but again oddly missing the opening PHP tag):

namespace Drupal\Tests\markdown_easy\Unit; use Drupal\Tests\UnitTestCase; use Drupal\markdown_easy\MarkdownUtility; /** * Tests the MarkdownUtility class. * * @group markdown_easy */ class MarkdownUtilityTest extends UnitTestCase { /** * Tests the getFilterWeights method. */ public function testGetFilterWeights() { $markdownUtility = new MarkdownUtility(); // Test case 1: All filters are disabled. $filters = [ 'filter_html' => ['status' => FALSE], 'filter_autop' => ['status' => FALSE], 'markdown_easy' => ['status' => FALSE], ]; $expectedWeights = [ 'filter_html' => NULL, 'filter_autop' => NULL, 'markdown_easy' => NULL, ]; $this->assertEquals($expectedWeights, $markdownUtility->getFilterWeights($filters)); // Test case 2: Only filter_html is enabled. $filters = [ 'filter_html' => ['status' => TRUE, 'weight' => 10], 'filter_autop' => ['status' => FALSE], 'markdown_easy' => ['status' => FALSE], ]; $expectedWeights = [ 'filter_html' => 10, 'filter_autop' => NULL, 'markdown_easy' => NULL, ]; $this->assertEquals($expectedWeights, $markdownUtility->getFilterWeights($filters)); // Test case 3: All filters are enabled with different weights. $filters = [ 'filter_html' => ['status' => TRUE, 'weight' => 10], 'filter_autop' => ['status' => TRUE, 'weight' => 20], 'markdown_easy' => ['status' => TRUE, 'weight' => 30], ]; $expectedWeights = [ 'filter_html' => 10, 'filter_autop' => 20, 'markdown_easy' => 30, ]; $this->assertEquals($expectedWeights, $markdownUtility->getFilterWeights($filters)); } }

In this attempt, the test was created with three sets of data, and passed without any changes (other than adding the opening PHP tag). But, can we use Copilot to make it better? Ideally, the three sets of input data should be provided as part of a PhpUnit data provider method.

Refactoring the test method to use a PhpUnit data provider

To achieve this, I placed my cursor inside the test method, and selected Copilot | Start inline chat, and entered the prompt: "Can we refactor this method to use a data provider?" The result displayed the proposed result in a Visual Studio Code diff (similar to what is used when resolving Git code conflicts,) with the option for me to either Accept, Discard, or Regenerate (represented by a circle-arrow icon) the proposed solution. I accepted, and the resulting code took a little bit of massaging to make correct. While Copilot did properly create the data provider method and updated the test method, it left a bunch of the original test method code at the bottom of the class, outside of any method. Once I (easily) removed this artifact, the test passed as expected.

The resulting code was:

<?php declare(strict_types = 1); namespace Drupal\Tests\markdown_easy\Unit; use Drupal\markdown_easy\MarkdownUtility; use Drupal\Tests\UnitTestCase; /** * Tests the MarkdownUtility class. * * @group markdown_easy */ class MarkdownUtilityTest extends UnitTestCase { /** * Data provider for testing the getFilterWeights method. * * @return array * An array of test cases. */ public function filterWeightsDataProvider(): array { return [ [ [ 'filter_html' => ['status' => FALSE], 'filter_autop' => ['status' => FALSE], 'markdown_easy' => ['status' => FALSE], ], [ 'filter_html' => NULL, 'filter_autop' => NULL, 'markdown_easy' => NULL, ], ], [ [ 'filter_html' => ['status' => TRUE, 'weight' => 10], 'filter_autop' => ['status' => FALSE], 'markdown_easy' => ['status' => FALSE], ], [ 'filter_html' => 10, 'filter_autop' => NULL, 'markdown_easy' => NULL, ], ], [ [ 'filter_html' => ['status' => TRUE, 'weight' => 10], 'filter_autop' => ['status' => TRUE, 'weight' => 20], 'markdown_easy' => ['status' => TRUE, 'weight' => 30], ], [ 'filter_html' => 10, 'filter_autop' => 20, 'markdown_easy' => 30, ], ], ]; } /** * Tests the getFilterWeights method. * * @dataProvider filterWeightsDataProvider */ public function testGetFilterWeights(array $filters, array $expectedWeights) { $markdownUtility = new MarkdownUtility(); $this->assertEquals($expectedWeights, $markdownUtility->getFilterWeights($filters)); } }

So, that's not too bad for a few minutes of work! But, as a stickler for clean code, there was still some work ahead for me to get an acceptable PhpStan report. 

Code quality changes

Overall, the quality of the code that was provided by Copilot was really good. But, this comes with the caveat that I utilize the PHP Sniffer & Beautifier Visual Studio Code extension (configured to use Drupal coding standards,) so it could be that code generated by Copilot is automatically formatted as it is generated (I really have no idea.). The bottom line is that I had zero phpcs issues in the code generated by Copilot.

For PhpStan, I normally try to achieve level 6 compliance - this can be especially tricky when it comes to "no value type specified in iterable type" issues. Without getting into the details of solving issues of this type, I decided to let Copilot have a go at updating the docblock for the filterWeightsDataProvider() method - and much to my surprise, it was able to provide a reasonable fix:

The process to update the docblock for the testGetFilterWeights() method wasn't as simple, as it was missing the parameter information, so I added that manually and then used Copilot in a similar manner to solve the PhpStan issue.

There was an additional, minor, PhpStan issue that I solved manually as well. With that, I had achieved zero PhpStan level 6 issues, a clean phpcs report, and a passing test! 🎉

This new test has been committed to the module.

Lesson learned

1. Context matters (a lot) when generating tests (any code, really) using Copilot. In my (limited) experience, the files open in Visual Studio Code, where the cursor is, and what is highlighted makes a significant difference in the results provided. 

2. Do not be afraid to use the Regenerate button (the circle-arrow icon) when generating any code, including tests. I have found that if I don't like the initial result, regenerating often results in a much better option the second or third time around.

3. The Start Inline Chat option in the contextual menu is rapidly becoming my new best coding friend. Do not be afraid to experiment with it and use it more than you think you should. I find it very useful for making code more concise, suggesting documentation descriptions, and giving me a headstart in scaffolding entire methods. 
4. This should go without saying, but don't trust anything that is generated by Copilot. This is a tool that you should look at to save time, but not solve problems for you.

Header image generated using ChatGPT4.

Thanks to Andy Giles and Cindy Garcia for reviewing this blog post. Cindy is a graduate of both Drupal Career Online and Professional Module Development. Andy is the owner of Blue Oak Interactive. 

Markdown is a text processing library that takes readable text and converts it into HTML. Started over 20 years ago, it is now a widely-used library that makes it easy for people to write text documents that can be easily and predictably converted into HTML.

Quick example - the Markdown syntax "this is **important**" converts to "this is important" after passing through a Markdown converter.

There are many "flavors" of Markdown today - most include the basic syntax and many include their version of "extended Markdown". Examples include Github-flavored Markdown and CommonMark.

Predictably, there have been Markdown-related Drupal contrib modules for a number of years, with the standard being the predictably named Markdown module. Started in 2008, it is currently used by about 5,000 Drupal sites (down from a high of more than 12,000 sites a few years ago).

Unfortunately, as of the publishing of this blog post, the current iteration of the Markdown module does not yet have a full release compatible with Drupal 10, although there are efforts ongoing to remedy this.

Why a new module?

DrupalEasy.com uses the Markdown syntax for some of its content. During our effort to upgrade DrupalEasy.com, the Markdown module became our last blocker to achieving that goal.

We took the time to review the current state of the Markdown module and its effort to be upgraded for Drupal 10, and in the end, we decided to pursue a simpler (in terms of module configuration,) less-time-consuming (in terms of contribution time,) and sustainable (in terms of ease of future upgrades) solution.

The existing Markdown module is configurable - really configurable. Some might say "too configurable".

One of the main configuration choices one has to make when using the Markdown module is choosing which Markdown library to utilize. The various open-source Markdown-processor libraries implement their own flavor of Markdown (like the Github and CommonMark libraries mentioned above). In fact, the Markdown module allows you to utilize multiple Markdown processor libraries. Once a library is selected, there are a myriad of additional configuration options available for each library and for each text format where the Markdown filter is utilized. Configuring the Markdown module in a secure manner is (in our experience) a bit of a chore.

I have no doubt that there are users of the Markdown module that require that level of control and fine-grained configuration. In those cases, the Markdown module is probably their best choice.

But, what about users who don't need that level of control? Users who just want to process Markdown formatted text into basic HTML with a minimum of fuss using a tried-and-true Markdown library. It is for these users that the Markdown Easy module was created.

What makes Markdown Easy different?

In short:

1. It is opinionated about the Markdown library - it uses CommonMark. Full stop.
2. It is opinionated about its configuration - it is configured to be as secure as possible.
3. It is easy to install and configure (see 1 and 2 above).

It was decided early on that the CommonMark library would be a dependency of Markdown Easy. It has more than 150 million installs on Packagist.org and is considered by many as the "gold standard" of Markdown libraries. In addition, it comes with the "Github-flavored Markdown" option as well. Selecting between these two "flavors" of Markdown is the only configuration option you have in Markdown Easy.

The module is preconfigured to be as secure as possible. Configured incorrectly, a Markdown library will output virtually any HTML tag - some that can be abused by bad actors. For example, the Markdown Easy module (by default) does not allow unsafe links or HTML tags to be processed (both of these options can be overridden with a Markdown Easy hook implementation). Additionally, validation of any text format utilizing the Markdown Easy filter requires that both the "Limit HTML" and "Convert line breaks" Drupal core filters be enabled and set to run in a prescribed order to ensure secure usage and consistent results (again, this can be overridden with a hook).

What features are planned for future versions of Markdown Easy?

Not many.

The goal is to have an easy-to-maintain (between major versions of Drupal core,) easy-to-configure (for site-builders,) and easy-to-customize (via Drupal hooks) module.

The only feature that we are currently interested in adding is the option of a GitLab-flavored Markdown library.

Is this module ready for prime-time?

We think so. In fact, the article that you're reading was written in Markdown and processed into HTML by the Markdown Easy module (with the exception of the logo - standard HTML was used for styling purposes).

Full documentation, including examples for overriding default validation and configuration, is available on drupal.org.

Markdown Easy's code base is primarily validation and automated test code. The filter plugin is 129 lines of code while validation and automated tests include over 700 lines of code.

We are using Drupal.org's Gitlab CI to run the tests in both Drupal 9 and Drupal 10 on every merge request and the module is covered by Drupal's security advisory policy.

We invite you to check it out and let us know what you think!

If you’re reading this blog post, something had to bring you here as opposed to the other roughly 600 million blogs out there. Perhaps you’re a regular visitor to this site. Maybe you Googled “writing tips for better web copy” and this showed up. Or you might be one of our social media followers and liked the look of this title. Search engines are a lot smarter than they were ten years ago. Gone are the days when you could “cheat” the system by front-loading your text with a bunch of keywords. Today’s SEO reads for quality of content as well as keywords. But once you’ve got a web user’s attention, you want to keep it — and hopefully encourage them to visit other pages of your site and take whatever actions you want them to take. Again, quality web content is key.

How to ensure a smooth Drupal 7 migration with content, design, and technology audits

In this article, we focus on tackling the organizational challenges that come with the technical realities of the migration away from Drupal 7 to newer, up-to-date versions of the content management system​​. We outline a strategic blueprint for a successful Drupal 7 migration, centered around three critical audits:

• Content audit: Evaluating which content should be carried over to the new platform.
• Design audit: Seizing opportunities to enhance the site’s design during the rebuild.
• Technical audit: Refining the site architecture and meticulously planning the technical aspects of the migration.

This is the perfect catalyst and opportunity for your organization to assess and not just transition, but to reconstruct your digital presence to meet your future goals and challenges.

As the clock ticks towards January 2025, the End of Life (EOL) for Drupal 7 looms on the horizon. Moving away from Drupal 7 marks a critical juncture. Since Drupal 8 and above are significantly different in architecture from Drupal 7, the move requires a comprehensive migration. The good news is that the upgrade paths from Drupal 8 and above are smoother, so the step up from Drupal 7 represents a unique, one-time effort, which will pay itself off in longer site life cycles and higher ROI on that investment.

The core principle guiding this migration strategy is the alignment of technical implementation and design with the initial content audit. This approach ensures that the rebuild is driven by content needs, rather than forcing content to conform to a predetermined site structure.

Some key organizational challenges issues when navigating this technical shift away from Drupal 7 revolve around governance, starting by understanding the existing content on your website, assigning responsibility for it, and ensuring its relevance and quality throughout the migration process.

This technical inflection point can and should also spark a broader debate about the extent of redesign and transformation needed during the migration. IT and marketing teams should be discussing, in a nutshell, “What do we have? What can be better? What do we need to make that happen?”

Palantir.net is a Drupal Association–Certified Migration Partner. We have the technical expertise, experience, and strategic insight required to help steer you through this vital transition. Whether through our Continuous Delivery Portfolio (CDP) or web modernization services, Palantir is ready to assist you in navigating the complexities of the D7 EOL upgrade.

Content audit: Decluttering the house

At the heart of any successful migration lies a well-executed content audit, a responsibility primarily shouldered by the Marketing team. This vital process streamlines the migration by identifying what content truly needs to be transferred to the new platform and what can be retired.

The essence of a content audit

The key questions to address during the audit are: What content do we need? What can we do without? These decisions should be data-driven, relying on analytics to assess the relevance and usage of the content. Key metrics include page views, content validity, and user engagement.

If you don’t like having a cluttered house, you don’t just decide to build a slightly bigger house, then move all your clutter into it. It would be a better idea to take a look at what’s actually cluttering your house first, then decide what you need to build. In the same way, letting content drive your technical decisions is the better approach.

The complexity of a given migration is often more dependent on the variety of different content types than the volume of content. Once a system for migrating a specific type of content, like blog posts, is developed, it can run autonomously while the technical team focuses on other content types. For this reason, a site with numerous content types requires a more intricate migration plan compared to one with fewer types. A content audit can help reduce the number of content types and with it the resulting effort needed.

Tips for conducting a successful content audit

 The following considerations can help make your content audit a smooth and effective process:

• Develop a comprehensive content inventory: Start by cataloging every piece of content on your website. This step is crucial as it allows you to see the full scope of your existing content and understand what requires improvement, discarding, or migration. Document key details of each content piece, such as URLs, titles, purpose, format, number of internal links, and other relevant information.
• Make data-driven decisions: Use tools like Google Analytics and Google Search Console to review content performance, examining metrics like traffic, engagement, bounce rates, time on page, and conversion rates. This quantitative analysis helps inform your content strategy and guides decisions on what content needs updating or removal.
• Complement data with qualitative decisions: Compare your content against benchmarks that align with your goals and audience needs. Assess the content for user experience, compliance with your style guide, and potential improvements. Decide on actions for each content piece, such as keeping, updating, consolidating, or removing, based on their relevance, quality, and performance.
• Involve a content strategist: An expert content strategist can help with all the above tasks and aid you in preparing a migration framework. They will help align your content with your marketing and branding goals, as well as UX design and information architecture. If you don’t have an internal content strategist, Palantir can provide one if we help you with your migration. 

Content as opportunity for a redesign

Conducting a content audit does more than just streamline the migration process. It can also unveil opportunities for a redesign of your site’s information and content architecture, aligned with a new content strategy. This process is not just about elimination, but also about discovery — uncovering what content is most valued by users. Not only are you finding out what you don’t need, but you’re hopefully finding out what's really important as well.

Given that moving from Drupal 7 to Drupal 10 essentially entails a complete site rebuild, there lies a golden opportunity to design the site around the content. This approach ensures that the site architecture complements and enhances the content, rather than forcing content to fit into a pre-existing structure.

The insights won here feed into the second crucial stage of a Drupal 7 migration: the design audit.

Design audit: An opportunity for enhancing UX

A design audit is where you and your Marketing team evaluate the current design’s effectiveness and explore the potential for a redesign. It goes hand-in-hand with a content audit.

Design audit objectives

• Evaluate current design effectiveness: Before deciding on a redesign, critically assess how well your current design serves your content and users. Does it facilitate easy navigation? Is it aesthetically pleasing and functionally efficient?
• Consider compatibility with Drupal 10: Drupal 10 brings new features and capabilities. The design audit of a Drupal 7 website usually reveals a rigid, template-based layout system, limiting content display versatility. By migrating to Drupal 10 and utilizing its advanced Layout Builder, the redesign can offer dynamic, user-friendly layouts, enhancing user engagement and providing flexibility for content strategy adaptations.
  
  Note that, while migrating away from Drupal 7, you essentially rebuild your site. Even if you choose to retain the existing design, adapting the look and feel to the newer Drupal version will require some level of reworking as well. If your existing design seems incompatible or would require extensive modifications, it might be more efficient to opt for a new design.
• Align design with content strategy: The design should complement and enhance the content, not overshadow it. A design audit should involve close coordination with content strategists to ensure that the design facilitates the content’s purpose and enhances user engagement.
• Explore modern design trends: Technology and design trends evolve rapidly. Use this migration as an opportunity to refresh your website’s look and feel to stay relevant and appealing to your audience.
• Accessibility enhancement: Focus on improving the overall user experience for everyone. This includes optimizing the site for various devices and improving accessibility, for instance, compliance with A11Y guidelines.

Palantir not only offers technical expertise in migration processes but also provides skilled designers who can seamlessly collaborate with your team. Our designers are adept at working alongside content strategists. They ensure that you end up with a cohesive system that effectively supports and enhances your content strategy, ensuring that every aspect of your site’s design is driven by and aligned with your overall content goals.

Technical audit: Engineering a future-ready framework

Next up, your internal IT team should perform a comprehensive technical audit. If necessary, this stage can overlap with the content audits. However, we recommend that your migration should be primarily driven by the insights gained from your content audit.

The ultimate goal of the technical audit is preparing for a new Drupal environment. This means understanding how the identified technical elements will function in the new system and planning for any necessary adaptations or developments.

Data architecture audit

The technical audit begins with a detailed analysis of how data is structured in the current Drupal 7 site. This involves examining the entity relationships and the architecture of data storage. Understanding how different pieces of content are interlinked and how they reference each other is essential. This step not only overlaps with the content audit but also sets the stage for a smooth technical transition to Drupal 10.

Custom functionality and integration evaluation

A critical aspect of the technical audit is assessing any custom functionalities or third-party integrations present in the current system. This includes custom plug-in modules, single sign-on mechanisms, and other unique features. Each custom element that you migrate over is something you have to maintain, potentially throughout the lifetime of the site. The decision to migrate these elements should be based on their current value and necessity. During the audit, aim to determine which functionalities are essential and how they can be adapted or redeveloped for Drupal 10.

Driving collaborative decision-making

Collaboration between the IT/technical, marketing, content strategy, and design teams is vital in deciding what to keep (and migrate) and what to discard — regarding site content, architecture, code, and functionality. The technical audit, outlining the functionalities and integrations of the current site, guides the planning and decision-making process following the insights you gain from the content and design audits.

Conclusion: Charting the course of a Drupal migration

As we’ve seen, the journey away from Drupal 7 involves three main audits:

• the content audit, which acts as a decluttering exercise;
• the design audit, seizing opportunities to enhance user experience;
• and the technical audit, engineering a future-ready framework. 

The content audit is the central pillar, and content strategy should drive the technical implementation and design decisions. This approach ensures a migration process where content seamlessly integrates into an efficient, updated site structure, rather than being confined by it.

Palantir is here to help and guide you through a successful migration from Drupal 7 to the future of your online digital presence. We are a Drupal Association–certified migration partner, with years of experience with intricate processes. Our expertise in content strategy, design innovation, and technical proficiency makes us an ideal full-service partner for navigating the complexities of a D7 end-of-life upgrade.

If you’re considering this critical step in your digital strategy, we invite you to explore how Palantir’s Continuous Delivery Portfolio (CDP) and web modernization services can transform your digital presence.

Content Strategy Design Drupal Drupal CDP Strategy

Media has changed a lot with new technology. Organizations need to connect with their audience using modern methods. Big media companies use digital tech to reach people on different platforms and make more money.

Top media networks have many websites and social media pages to reach more people. They create websites for different groups. In the age of Web 3.0, having a strong online presence is crucial. Drupal helps with that, improving the customer experience and increasing conversion by 25% for one media client we worked with.

Why is Drupal Preferred Over Other CMS? 

Media relies on content, and that content needs to bring in revenue in a scalable way. To achieve this while keeping things easy to manage, you need the right Content Management System (CMS). Considering the constant flow of new content, choosing the right CMS is crucial.

Once upon a time, at a conference, the lead developers from a selection of frameworks sat down in the same room and agreed on some standards for all their projects to use. The aim was to make PHP frameworks and libraries easier to combine for users. That is when php-fig: the PHP Framework Interop Group was born. This group of awesome individuals oversees the PHP Standards Recommendations (PSRs). The PHP Standard Recommendation (PSR) is a PHP specification published by the PHP Framework Interoperability Group (PHP-FIG). It serves the standardization of programming concepts in PHP. The aim is to enable interoperability of components. The PHP-FIG is formed by several PHP frameworks founders. Dive into this article to learn about different PSRs and how you can adhere to them. PSR-0 & PSR-4 These describe a specification for auto loading classes from file paths. PSR-0 and PSR-4 are both standards concerning namespaces, class names and file paths. This PSR also describes where to place files that will be autoloaded according to the specification. Auto loading Autoloading is a functionality to help developers including  PHP classes automatically without writing cluttered include/require statements everywhere.In PHP, class's definition is loaded with require or include statements in the files they are being called i.e., prior to using it as shown below.  include 'Utility/Test Example.php'; $exampleObj = new TestExample(); The above approach raises some issues as if we have tens of external classes to be used in a file and we start writing lines of require/include statements right at the beginning of a source file.  To overcome this issue PHP 5 introduced the magic function __autoload() which is automatically called when your code references a class or interface that hasn’t been loaded yet. void _autoload (string $classname);Here’s an example of a basic __autoload() implementation:  <?php function _autoload($className) { $filename = 'Utility/’ . $className . '.php'; if (is_readable($filename)) {The major drawback to the autoload() function is that you can only provide one autoloader with it. PHP 5.1.2 introduced another autoloading function (spl_autoload_register) for coping with_autoload 's limitation. The major drawback to the __autoload() function is that you can only provide one autoloader with it. PHP 5.1.2 introduced another autoloading function (spl_autoload_register) for coping with __autoload 's limitation.  The introduction of spl_autoload_register() gave programmers the ability to create an autoload chain, a series of functions that can be called to try and load a class or interface.  For example: require $filename; } } $exampleObj= new TestExample(); <?php function utilityAutoloader($className) { $filename = 'Utility/’ , $className '.php'; if (is_readable($filename)) { require $filename; } } function functionAutoloader($className) { $filename = 'Functions/’ . $className . '.php'; if (is_readable($filename)) { require $filename; } } spl_autoload_register('utilityAutoloader'); sp1_autoload_register('functionAutoloader');Autoloading was  such a great idea that every project started to use it. Inevitably everyone created their own version of autoloader as uniform standards were lacking. Clearly, PHP desperately needed a standard for autoloader, which is how PSR-0 was born. The latest accepted autoloader standard is PSR-4.  PSR-0 (Autoloading Standard) Overview of PSR-0: A fully-qualified namespace and class must have the following structure \\(\)* Each namespace must have a top-level namespace (“Vendor Name”). Each namespace can have as many sub-namespaces as it wishes. Each namespace separator is converted to a DIRECTORY_SEPARATOR when loading from the file system. Each _ character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR. The _ character has no special meaning in the namespace. The fully-qualified namespace and class are suffixed with .php when loading from the file system. Alphabetic characters in vendor names, namespaces, and class names may be of any combination of lowercase and uppercase. Examples: \Doctrine\Common\IsolatedClassLoader =>/path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php \Symfony\Core\Request =>/path/to/project/lib/vendor/Symfony/Core/Request.php PSR-4 (Autoloading Standard) Overview of PSR-4: The term “class” refers to classes, interfaces, traits, and other similar structures. A fully qualified class name has the following form:\(\)*\ The fully qualified class name MUST have a top-level namespace name, also known as a “vendor namespace”. The fully qualified class name MAY have one or more sub-namespace names. The fully qualified class name MUST have a terminating class name. Underscores have no special meaning in any portion of the fully qualified class name. Alphabetic characters in the fully qualified class name MAY be any combination of lowercase and uppercase. All class names MUST be referenced in a case-sensitive fashion. Example for PSR-4 based Autoloading using Composer: Consider the following directory structure to achieve PSR-4 based autoloading using composer. Create a composer.json file using composer init. If not, you can create one manually now in your project’s root. specbee@specbee-HP-ProBook-640-G1: /var/www/html/psr$ touch composer.json Set up PSR4 autoloading by editing the composer.json file as shown below: { “autoload” : { “psr-4” : { “Codecourse\\’ : “src/” } } } Here, CodeCourse is a vendor name of your application, you can use this name while namespacing files inside of your src directory ,such as: namespace CodeCourse\Filters;Or namespace CodeCourse\Repositories;          etc, And src is your application’s directory that you want to autoload. Next, open up your terminal and type in the following command to install autoloading files in your project.This will generate the vendor directory and autoload.php file inside of it. specbee@specbee-HP-ProBook-640-G1:/var/www/html/psr$ composer dump-autoload -0 Let’s first create a couple of classes inside of the CodeCourse directory. Create AuthFilters.php inside CodeCourse/Filters The above example causes a side effect, i.e., loading a file named “file.php”. Files must be in UTF-8 without BOM(Byte Order Mark). Namespaces and class names must follow the standards in PSR-0 and PSR-4. Here is an example that illustrates the basic naming conventions for properties, classes, and methods. <?php class Classname { public $firstProperty; //Don’t declare multiple properties in a single line public static $StaticProperty; public function firstMethod() { //definition… } } ?>PSR-2 (Coding Style Guide) Overview of PSR-2: You must follow the PSR-1 coding standards. 4 spaces must be used for indents. Using tabs is not allowed. There is no limit to line length, but it should be under 120 characters, and best if under 80. There must be one blank line after namespace declaration and there must be one blank line after the block of use declaration. Opening curly braces for classes and methods must go on the next line and closing curly braces must go on the line after the body. Methods and properties must be defined with abstract/final first, followed with public/protected, and finally static keyword. You must not put a newline before curly braces in conditional statements. You must not put any spaces before ( and ) in conditional statements. An example for defining classes: You must open the curly braces on the new line and the extends and the implements keyword must be used in a single line. <?php class ClassName extends ParentClass implements InterfaceName { //class definition… } ?>If there are multiple interfaces to implement, then you can write the interface names in the new line as shown below: <?php class ClassName extends ParentClass implements InterfaceName1, InterfaceName2, InterfaceName3 { //class definition.. } ?>Example to show how methods are defined in PHP:While defining the methods, the arguments should be written in the same line. Also, you must not put any whitespaces before commas in arguments, and you must put one whitespace after them. <?php class ClassName { public function method($arg1, $arg2) { //definition… } } ?>If there are many number of arguments, then they can be written in newline one after the other: <?php class ClassName { public function method( arg1, arg2, arg3) { //definition… } } ?> When defining methods, you must have either one of public/protected/private and abstract/final. The visibility modes come after the abstract/final keyword, if used. static is the last modifier. <?php class ClassName { abstract public function abstractMethod(); final public static function staticMethod() { //definition… } } ?>Conditional Statements You must put one whitespace before ( You must not put any whitespaces after ( You must not put any whitespaces before ) You must put one whitespace after ) use elseif rather than else if. Example to show the difference between elseif and else if:Interpretation of elseif: <?php if ($condition1) { //… } elseif ($condition2) { //… } else { //… } ?>Interpretation of else if: <?php if ($condition1) { //… } else { if (condition2) { //… } } ?>For the switch statements,  The curly braces must be opened in the same line where the switch statement is written. The case body must be indented once from the case and the case must be indented once from the switch. Use no break when break is not needed. You can also use return instead of break. Example: <?php switch($condition) { case 0: echo ‘Use a break’ ; break; case1: echo ‘If you are not using break; then write no break as a comment’ ; // no break case 2: echo ‘Use return instead of break’ ; return; default: echo ‘Default’; break; } ?>Huge shoutout to Samvada Jain for her contributions to this article. Final Thoughts In a project that is incorporated with various packages, it can be a mess if each individual uses a different coding standards. This is the reason why PSR was designed. In total, there are over 20 PSRs that are designed and each PSR is suggested by members and voted according to an established protocol to act consistently and in line with their agreed upon processes. Our expertise in PHP stems from our focus on Drupal - An enterprise CMS built using PHP. If you are looking to develop a custom module for Drupal or any other Drupal development services, talk to us today!    

In this interview, Michael Anello opens up about his experiences, challenges, and triumphs in Drupal. From teaching engineering to steering DrupalEasy, he shares unfiltered insights into Drupal's evolution, the hurdles beginners face, and his vision for the future. Michael reflects on 2023, offering a genuine look into his professional highs and challenges with a sneak peek into what lies ahead for DrupalEasy. Join us for a straightforward exploration into the heart of Drupal, guided by Michael's authentic perspective.

As we welcome the dawn of a brand-new year, it's the perfect time to reflect on the past and set our sights on the future. New Year's resolutions offer us the chance to positively change our personal and professional lives. Whether it's adopting healthier habits, pursuing new skills, or fostering stronger connections, the start of the year serves as a powerful catalyst for growth and self-improvement.

In the spirit of resolutions, let's focus on personal goals and consider how we can collectively enhance our contributions to the Drupal community. As advocates for open-source collaboration and innovation, we have the opportunity to amplify the reach of Drupal and strengthen its impact. By fostering a culture of inclusivity and diversity within the Drupal community, we can ensure that our collective efforts lead to more robust, accessible, and user-friendly solutions.

In the coming year, let's commit to bringing Drupal to new heights by actively engaging with and reaching out to a broader audience. Embracing diversity and inclusion within the Drupal community enriches our collaborative environment and opens doors to fresh perspectives and ideas. Let's make 2024 a year of growth, unity, and empowerment for ourselves and the Drupal ecosystem.

We're excited to share some intriguing Drupal-related news from last week! Vimal Joseph, Director of MarTech at Zyxware, conversed with Jonathan Carter, the Debian Project Lead (DPL). This insightful dialogue originated during their in-person meeting at the Global DebConf, the Debian Project's annual developer conference, held in Kochi, Kerala, India. The conversation culminated in an engaging email interview, shedding light on Carter's journey within the Debian ecosystem. To read the complete interview, click here. 

In addition, The DropTimes (TDT) contacted the initiative leads and contributors of Distributions and Recipes. Tim Hestenes Lehnen and Jim Birch generously accepted our request. In an email correspondence with Alka Elizabeth, sub-editor of TDT, they shared valuable insights. Dive into the complete article here.

Delve into my latest articles featuring insights from Coby Sher and Pratik Kamble on the transformative API Client initiative. Coby shares his excitement for the project, emphasizing its efficiency for developers, while Pratik highlights the positive impact of the official JavaScript library on data retrieval. Read the full article here.

Also, experience the festive zeal of Specbee's dynamic team in Elma John's holiday reflection. Discover their celebrations and aspirations for the Drupal community in this heartwarming piece. Don't miss out – read the full article here for festive inspiration and community spirit.

Secure your spot at Drupal Mountain Camp 2024 with Early Bird tickets! Act now, as Early Bird pricing ends on January 20, 2024. Drupal Mountain Camp 2024 is gearing up to host an illustrious keynote speaker—Preston So, a distinguished figure in product, design, engineering, and innovation, and Jutta Horstmann, a passionate advocate for feminist sustainability and a leading voice in free software advocacy, is set to be another keynote speakers at Drupal Mountain Camp. 

Secure your spot at the two-day nerd-delicious NERD Summit 2024. Get your tickets and be part of an empowering event where knowledge and collaboration take center stage. MidCamp, a significant Drupal event, extends its speaker submission deadline to January 7, 2024.  Start the year with the Twin Cities Drupal community at the University of Minnesota's Sprint Day on January 12, 2024!

Discover how the User One Time Login module in Drupal revolutionizes user authentication by enabling secure single sign-on links and unique login access, offering enhanced control and flexibility for site administrators. Read about the View Filter Commerce Promotion module, designed to streamline commerce promotion management within Drupal. Klaus Purer, Ivan Tibezh, Juraj Falat, and Andrii Cheredn have been officially recognized as current security release members of the D7Security initiative to bolster Drupal 7 projects' security.

Learn about the recently introduced Bunny Stream module by Borja Vicente, which seamlessly integrates Drupal Media with Bunny.net’s streaming service, offering enhanced video upload and embedding capabilities for Drupal websites. Explore TokenLink, the recently launched Drupal module revolutionizing token integration. Developed by Cosmos, this module offers enhanced flexibility and promises efficient token management for diverse content needs. Get the complete insight here. Learn about the recently revealed Drupalwned script designed to escalate Cross-Site Scripting vulnerabilities to critical levels within the Drupal CMS. 

Due to the compulsion to limit the selection of stories, we can only share this much for now. Wishing you continued success and inspiration in your Drupal journey!

To get timely updates, follow us on LinkedIn, Twitter and Facebook.

Thank you,

Sincerely

Kazima Abbas
Sub-Editor, TheDropTimes

Talking Drupal #431 - Live at NEDCamp

On today’s show we share interviews we conducted with sponsors, speakers and attendees at New England Drupal Camp in November. Seventeen in all.

For show notes visit: www.talkingDrupal.com/431

Topics

Interviews with:

Michael Miles Nick Silverman Matt O’Bryant Ethan Aho Mike Anello Patrick Anderson Brian Perry Aubrey Sambor Brigitte Ayerves Valderas Chris Wells Richard Hood Chris Amato Ivan Stegic Philip Frilling Rod Martin Jacob Rockowitz Whitney Hess

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Martin Anderson-Clutz - mandclu Stephen Cross - StephenCross.com

Drupal Advent Calendar 2023 Retrospective and Thank Yous james Mon, 01/01/2024 - 00:00 Image Body

This December was the second incarnation of the Drupal Advent Calendar project.

This started on a whim in 2022, and while fun, I knew I didn’t want to write it all myself the second year.

So at DrupalCon Lille, I started asking people to get involved in this year’s calendar, initially focusing on people I know. The response was generally positive, with most people eager to take part.

My aim was to have a different person talk about an aspect of Drupal behind each door, and that was more or less how it worked out.

When I thought of asking people to take part, my aim was to cover 24 topics without…

Allowing your content creators to embed images in text fields is a big risk if you don't have the right measures in place to get properly rendered images without jeopardizing your site's performance. We faced this issue first-hand with embedded images due to not using the right configuration and this lead to extremely large images being rendered. In this post I'll go over the techniques I took for addressing those issues and set up a system for image embeds that is solid and performant.

I started by writing a seven-part guide on how to setup responsive images. In this post I'll focus on image embeds. If you followed or read the responsive images guide, you should be able to take advantage of some of the work we did there in this post. The guidelines covered here include:

• Defining requirements
• Image styles
• Media view modes
• Text format configuration

Defining requirements

Before you write the first line of code or set the first drupal configuration for this issue, you need to have a clear understanding of your requirements. Here is a summary of my requirements:

• Only certain user roles can embed images

  This means we need to figure out if the text formats used in our site will allow us to set the restrictions we need. Otherwise we may need to create or edit a text format for our target user roles.

• Users need to be able to choose the image size and aspect ratio when embedding images

  We defined the image sizes and aspect ratios and assigned names that were user-friendly for non-technical users. We came up with name options we think our users will find easy to work with such as:

  • Small square, Small portrait, Small rectangular
  • Medium square, Medium portrait, Medium rectangular, Medium rectangular wide
  • Large square, Large rectangular, Large rectangular wide
  • Extra large square, Extra large rectangular, Extra large rectangular wide

• If no option is selected by users, set a default image size

  For the default option when no selection is made by the user, we decided to use the Medium rectangular option. This has an aspect ratio of 3:2 and it measures about 720x480.

• Existing Media items need to be available for embedding

  This was a tricky one because my original inclination was to create a new Media type so we can isolate all configuration for its view modes and not overpopulate our default Media type. However, this ended up not working for us because when you limit your image embeds to only use a new Media type, you don't get access to any of the media items (images), that have already been uploaded to the Media library using other media types. Ultimately we ended up using Drupal core's Media type, Image, and our dev team had to compromise on having a very busy list of view modes for this media type.

• Images need the ability to be cropped wihin the Media page

  Since most of our images already provide the ability to be cropped at different aspect ratios, using the core Media type in the previous bullet point made this an easy solution.

Image styles

It all starts with image styles. I'm not going to go over how to create image styles, you can read my post Image styles in Drupal. The one thing I am going to repeat however is the importance of creating reusable image styles. Reusable image styles can help you reduce the number of image styles you create while providing the flexibility you need with each use case.

Image styles are key as each of the size options we defined above translate into image styles. So Small square for example, is an image style that is defined as 1:1 (250px). Medium rectangular would be something like 3:2 (720x480), etc. You may be wondering, how do you plan on using fiendly names for your content editors when your image styles names are not very friendly? Great question. Since we are using Drupal's Media, content editors do not interact directly with image styles, they do with Media view modes and this is where we will use more friendly names.

Media view modes

View modes are one of Drupal's powerful features. Being able to display content is different ways with little effort can turn a simple website into a dynamic content hub. The example I always give when someone asks me what view modes are or how do they work is the Amazon website. When you are viewing a product in amazon.com, or most retail websites for that matter, you will notice that the same product or similar ones appear all over the page but in slightly different ways, with different fields or styles. See the page below for an example.

The image above shows many ways in which a product can be displayed. I've numbered each display.

In Drupal, every entity such as content types, media types, blocks, etc., offer the ability to create view modes. For the purpose of image embeds, we will create a Media type view mode for each image style we plan on using. The view modes is what content editors will interact with when choosing an image size or aspect ratio during the image embed process. This is where we will use the user-friendly names we defined earlier. Let's go over how this relationship between view modes and image styles works for image embeds.

Configure view modes for the Image media type

1. In your Drupal site, create an image style for each image size option you wish to provide to users when embedding images.

2. Next, create a Media view mode for each image style (/admin/structure/display-modes/view). Very iimportant: Remember the view mode's label (name) is where we are going to use the friendly name (i.e. Medium rectangular (720x480)). I like to keep the machine name similar to the label so it's easier to debug or identify in code (i.e. medium_rectangular_720x480).

3. Now, let's tie 1 & 2 together:

   • Go to the media type you plan on using for media embeds (/admin/structure/media/manage/image/display). I am using Drupal core's Image media type.
   • Scroll down and expand the Custom display settings fieldset.
   • Check each of the view modes you created in step 2 and click Save.

4. Now click each of the view modes and update the image field to use the respective/matching image style.

Configure the text format

View modes and image styles are all configured. Now let's configure the Text format that authorized users will use to embed images.

1. Go to the Text formats and editors page (/admin/config/content/formats)
2. Click Configure next to the text format you plan on using (i.e. Full HTML)
3. Ensure the right user roles are selected
4. Within the Toolbar configuration section, drag the Drupal media button from the Available buttons options to the Active toolbar section. You could probably remove the original insert image button since you won't be using it.
5. Scroll to the Enabled filters section and check the Embed media checkbox
6. Scroll to the Filter settings section and set the following:

   • Default view mode: This is the default display that will be used if content editors don't pick an option when embedding images. Select any of the view modes that represents the image size you want to use as default.

   • Media types selectable in the Media Library: Select the Media type you plan on using. In my case is Image.

   • View modes selectable in the 'Edit media' dialog: Finally, select each of the view modes you created in the previous section. FYI: View modes will be sorted in alpha order by their machine name. In my case I had to prefix some of the machine names with either "a" or "b" so the list of options for the users to choose from would be nicely organized by their label name. See screnshot below.

   • Click Save configuration

Testing your configuration

Now that we've completed all the configuration we should be able to take it for test drive.

• Go to any page where there is a text field with a WYSIWYG editor
• Make sure you are using the right text format by selecting it at the bottom of the text field where you want to embed an image
• Click the Insert media button from the editor's toolbar
• Select or upload the image you'd like to embed
• When the image has been inserted, click on it and you should see several options of actions you can do with the image. Things like align the image, add a caption, link it, and you should also see a selection box listing all the view modes you created.
• After making your selection you should immediately see the image size/aspect ratio change to the one you selected. When you are happy with your selection, click the Save button to save your page.

Important: Depending on your site's configuration, the options for changing your image size may look different than mine. In my case, I am only using Drupal's core modules and this is how the options look for me:

In closing

Putting a system like this for your image embeds will give you the piece of mind that content editors have options to choose how big or small they would like images to be displayed, and from a performance point of view, if your image styles are done properly, you can rest assurred that bloated images will never be rendered because you have put the guard rails in place to avoid this from happening.

I hope you found this article useful and can put these techniques to use in your own Drupal project. Happy New Year! 🎉 🎊 🎆 👋

Discover the Debian Project's evolution and aspirations through an insightful interview with the Debian Project Lead, Jonathan Carter. Learn about the Debian ecosystem's path, objectives, problems, and future ambitions, shining light on Debian's transforming landscape, attracting contributors, DPL's role complexities, Debian's progress, and the project's guiding values. Jonathan's experiences unveil the dynamic world of Debian, shaping the future of this influential open-source project.

From Shopping Carts to Conversions: Why Drupal Commerce Should Be Your Top Choice kanapatrick Sat, 12/30/2023 - 09:39

When it comes to building an e-commerce website, choosing the right platform is crucial for success. With so many options available, it can be overwhelming to decide which one is the best fit for your business. However, if you want a flexible and powerful solution, Drupal Commerce should be at the top of your list.

Explore the best Drupal hosting solutions! Our guide helps you navigate the options, find the perfect match, and optimize your project's performance. Make an informed choice for seamless Drupal hosting.

Recently, I presented an online session for the TechCohear community at Infosys, focusing on the Schema.org Blueprints module. This module developed by Jacob Rockowitz simplifies building structured websites. It's a significant leap for Drupal in managing and distributing structured data.

In Drupal, the default behaviour of entity reference fields allows us to select unpublished content if the content creator has permission to view unpublished content, which can be useful in specific scenarios where we need to establish relationships even with unpublished content. However, in many cases, we want to refer only to published content. The problem arises when we add references during content creation without verifying whether the referenced items are published. This can lead to confusion later when we wonder why the referenced contents are not visible when viewing the content. Here's a step-by-step guide on how to use a Drupal view to filter the values appearing in an entity reference field

Adaptability and swift implementation of feature requests from business owners are important for successful digital ventures. When faced with the challenge of meeting the dynamic demands of the operations team and ever-changing business requirements, relying solely on native implementations can lead to prolonged deployment times and missed opportunities. Learn how we have leveraged no-code, low-code solutions and Drupal to quickly deploy a feature that made a media portal's lead management process efficient.

ICFOSS and Zyxware Technologies organized the 5th season of the "Back-To-Work" program for women, with the topic being "Building digital experiences with Drupal". As part of the event, The Director of Programs at the Drupal Association, Von R. Eaton, gave a presentation covering various aspects of Drupal, Drupal.org, and the Drupal Association, followed by a question and answer session with participants. The questions addressed topics such as the cost of Drupal, the necessary skills to work in the Drupal Association, mentoring opportunities, and payment for freelancers contributing to Drupal.

This article discusses 4 Drupal modules useful for implementing standard features required by public sector websites.

Drupal Earns Digital Public Good Status: Recognized by the UN for Helping Achieve Sustainable Development Goals. Drupal's recognition as a Digital Public Good by the DPGA is a significant achievement that invites more governments and non-profit organisations to explore the benefits of using Drupal.