<h2>The Dominance of WordPress</h2>



WordPress remains the dominant platform with over 40% of all websites on the internet using it compared to Drupal with around 2%. Its intuitive user interface, vast library of plugins and themes and endless amount of online resources make it an attractive choice for beginners and experts alike wanting to get online quick and hassle-free.



Another appealing factor for beginner users with Wordpress is the large amount of cheap &amp; easy hosting options. Nearly all larger hosting companies offer cheap one-click Wordpress site installs and hosting so you can spin up a new Wordpress site in a matter of minutes and start using it for a few dollars per month. While there are Drupal specialised hosts they are more development orientated and as a result cost more and take longer to set up even if you get more resource &amp; power in return.



From a client perspective in my day job we work primarily with Drupal clients and while more and more companies are adopting Drupal or a decoupled Drupal setup company-wide the vast majority of clients and their employees are far more comfortable with and have more experience with Wordpress for the reasons already stated above. This for me is the gap Drupal Starshot is trying to fill without directly trying to take on Wordpress.



<h2>Introducing Drupal Starshot or Drupal CMS</h2>



As a developer I look at Drupal as a framework rather than a CMS, providing me with the building blocks to build as I please without a tonne of functionality and "opinions" I'm never going to need. The core APIs in Drupal are designs to be expanded and customised for whatever need you can think of. This, for me is what actually makes Drupal less beginner-friendly and far more developer-friendly than it perhaps ever planned to be.



In recent years, Drupal has undergone significant improvements in terms of user-friendliness and accessibility. Historically known for its steep learning curve, the release of Drupal 8 marked a turning point for Drupal, making it more intuitive and user-friendly to the end user but also more predictable and sustainable for developers with the adoption of the Symfony framework under the hood.



The introduction of numerous initiatives like Layout Builder, Media Library, a new admin theme, Configuration Management, Auto-updates, Decoupled architecture as standard and more have further improved the user and developer experience making Drupal a more viable option for technical and non-technical users. From a developer perspective and business owner who uses Drupal on a daily basis these initiatives are really exciting to follow and Drupal Starshot on first glance is no different.



Introduced at <a href="https://www.drupal.org/association/blog/drupal-lead-dries-buytaert-announces-the-guiding-star-for-a-new-version-of-the-drupal-cms-23-years" data-type="URL" data-id="https://www.drupal.org/association/blog/drupal-lead-dries-buytaert-announces-the-guiding-star-for-a-new-version-of-the-drupal-cms-23-years" target="_blank" rel="noreferrer noopener">DrupalCon 2024 in Portland</a>, <a href="https://www.drupal.org/starshot" data-type="URL" data-id="https://www.drupal.org/starshot" target="_blank" rel="noreferrer noopener">Drupal Starshot</a> is the latest Drupal initiative to stir up excitement (and likely some concern) within the community. With Dries, the Drupal founder admitting freely that Drupal lacks the beginner-friendliness of some of it's competitors, Drupal CMS or Starshot as it will be known aims to be Drupal's answer to providing beginner-friendly, easy to use CMS out of the box.



From my first look it appears that Drupal Starshot will be like many Drupal distributions of the past; Drupal Core, a handful of useful contrib modules, configured and ready to use and then some specific custom features added on top with, in this context the aim of making Drupal as beginner friendly as possible.



There are numerous Drupal distributions already available on Drupal.org and Github allowing you to download a ready made "recipe" of Drupal angled at a certain type of website (ie. education, commerce, social, intranet, publishing etc). Most of them are the result of Drupal companies working in and learning what certain niches have in common and then sharing their codebases in the spirit of Open Source.



From the Portland announcement, Dries stated Starshot is not a fork of Drupal Core (phhhewww) and in the near future Drupal.org will offer 2 download options:



<ol><li>Drupal CMS (Starshot)</li><li>Drupal Core</li></ol>



What this means unlike other contrib Drupal distributions is Drupal Starshot will be an officially supported and maintained distribution of Drupal with Drupal core available for downloading separately.



The specifics of Starshot are yet to be known but the wheels are in motion with a lofty goals of it being ready for downloading within 8 months (early 2025) so watch this space. I'll update this post as more specifics are announced.



<h2>Is Drupal too hard for beginners?</h2>



Nearly 20 years ago I first downloaded and installed Drupal on then Windows XP machine with WAMP and as a then beginner within 2 days I concluded it was too complex for me in terms of the learning curve and swiftly starting looking at alternative Open Source options. Spoiling alert: I came back to Drupal a few weeks later and the rest is history!



Would I do the same if I was starting out again now with the progress Drupal has made in lessening it's learning curve? Hard to say, the installer is easier, Composer makes dependency downloading easy, admin theme/UI is slicker and now with Gutenberg a primary page builder option in Drupal as well content creation has got fun but somethings are still lacking and developer orientated: as a beginner you don't care about dependency or config management, nodes and entities just don't make sense and while I dislike that nearly every Wordpress plugin has a better paid version, when you just want to "get the job done" a paid plugin is highly appealing especially when they are generally built solely with the end users goals in mind.



From my developer perspective, Drupal wins hands down every time, it's modular, has great core APIs and is built to naturally be expanded and built upon but from a beginner point of view there's is definitely a lot Drupal Starshot can improve on so it's great to see this idea come to fruition.



<h2>The Growing Overlap Between Drupal and Wordpress?</h2>



While Drupal and WordPress still have distinct advantages and disadvantages, their overlap appears to be growing with Drupal readily trying to become more beginner-friendly with recent initiatives and compliment it's already established developer-friendly image.



Wordpress was built primarily with blogging in mind which in my view allowed it to focus on a more defined target user; generally non-technical bloggers. With blogging, the content is the focus and Wordpress through it's simpler interface, customisation options in the UI and the Block Editor (Gutenberg) allows users to do just that. Drupal on the other hand isn't niche down to a single target audience or need so it naturally makes sense (to me) that it's more of a framework or start point to a large variety of needs and in this lies the challenges of best trying to fit the needs of many.



Although a Wordpress site nowerdays with enough time invested can be built into just about any type of website you can think of, it doesn't mean you should! Professionally, I've worked on large Wordpress sites with millions of pieces of content, exploding postmeta database tables and custom functionality and while the sites "works" in my developer brain I'm often left thinking this is not a sustainable way to build by forcing a tool built for a specific need into doing something it wasn't designed for and that's where a framework like Drupal comes in.



In my view the comparison between Drupal and Wordpress might be an obvious one but it doesn't really make sense, Drupal is a framework and Wordpress a Content Management System (CMS) for blogging, the target audiences and needs are and were very different but as a beginner I would say that Wordpress still has a greater appeal and edge. As a developer or a developer coming to Drupal or Wordpress from other frameworks I think you will likely find Drupal far more appealing with what feels like it's limitless possibilities, clear modular structure and PSR-4 namespacing.



In conclusion, Drupal and Wordpress are overlapping more and more but just how far it will go remains to be seen.

Drupal vs WordPress: Is The Tide Turning with Drupal Starshot?

Drush 11 generate command examples

Before we begin a little disclaimer, unless you are a developer it's best to only use official support releases that state they're compatible with your version of Drupal. That said if you're a developer &amp; you understand the potential risk you can forget this!



<hr class="wp-block-separator is-style-wide"/>



<h2>"The problem" with Composer (in this context)</h2>



Using Composer to maintain your Drupal codebase is really awesome, it strictly ensures you only get code in your codebase that will (in theory) function on your codebase, exactly what we want!



The "problem" occurs when you want to go outside of this and force downloading of code that isn't necessarily compatible with your codebase such as patching a contrib module to bring it up to Drupal 10 compatibility. 



Running standard <code>composer require PROJECT</code> commands won't work if the module you want to patch doesn't have <code>Works with Drupal: * || <meta charset="utf-8">^10</code> on a release on it's project page, this is Composer doing it's job like you normally want it to do:



<h3>An example of "The problem"</h3>



On this <a rel="noreferrer noopener" href="https://eplfixturestoday.com" data-type="URL" data-id="https://eplfixturestoday.com" target="_blank">given personal project</a> I use the feeds module (which I love!!) to gather JSON data into football fixtures &amp; stats, I'm in the process of upgrading to Drupal 10 and I needed to install the <a rel="noreferrer noopener" href="https://www.drupal.org/project/feeds_http_auth_fetcher" data-type="URL" data-id="https://www.drupal.org/project/feeds_http_auth_fetcher" target="_blank">Feeds HTTP Auth Fetcher module</a> in order to make authenticated API calls to get JSON data. 



The module had a stable release so I gladly went into Terminal and ran <code>ddev composer require 'drupal/feeds_http_auth_fetcher:^1.0'</code> only to find:



<pre class="wp-block-code"><code>Could not find a matching version of package drupal/feeds_http_auth_fetcher. Check the package spelling, your version constraint and that the package is available in a 
 stability which matches your minimum-stability (stable). </code></pre>



Back to the module page and I saw my mistake, there's no Drupal 10 compatible release!!! Just Drupal 8 &amp; 9........



<figure class="wp-block-image size-wide"><img src="/img/blog/patching-drupal-contrib-modules-drupal-10-compatibility-composer-92c8e68da51c3695555b981051b12ac8.png" alt="Drupal 10 compatibility on a Drupal module project" class="wp-image-256" data-entity-type="file" data-entity-uuid="4f5560f3-5067-4528-b55a-a1176f4fa327" data-image-style="original"/><figcaption>Drupal 10 compatibility on a Drupal module project</figcaption></figure>



So over to the modules issue queue I went and searched for the standard automated Drupal 10 compatibility issue which is normally title "<a rel="noreferrer noopener" href="https://www.drupal.org/project/feeds_http_auth_fetcher/issues/3297180" data-type="URL" data-id="https://www.drupal.org/project/feeds_http_auth_fetcher/issues/3297180" target="_blank">Automated Drupal 10 compatibility fixes</a>", bingo! The automated bots had done their job and the module could be easily brought up to Drupal 10 compatibility with one simple patch (a single line), time to get around "the problem".



You can use this same approach on all contrib modules &amp; themes just be aware not all modules will have automated patches available and not all the patches will be as simple as the one in this example!



<hr class="wp-block-separator is-style-wide"/>



<h2>Make Composer download a module from source </h2>



As the heading above suggests the way we get around "The problem" is by downloading the modules source code directly from it's source (ie. git) rather than from it's official package, this means we bypass Composers version checking and checkout the source code regardless of whether Composer thinks it's compatible or not.



To do this it's relatively simple. Open up your composer.json file and find the line <code>"repositories":</code> (this is where <a href="https://getcomposer.org/doc/05-repositories.md" data-type="URL" data-id="https://getcomposer.org/doc/05-repositories.md" target="_blank" rel="noreferrer noopener">Composer looks for information about the code you download</a>) and then manually add information about the Feeds HTTP Auth Fetcher modules source code so we can download it.



<pre class="wp-block-code"><code> {
 "type": "package",
 "package": {
 "name": "drupal-gitlab/feeds_http_auth_fetcher",
 "version": "1.0.3",
 "type": "drupal-module",
 "source": {
 "url": "https://git.drupalcode.org/project/feeds_http_auth_fetcher.git",
 "type": "git",
 "reference": "1.0.x"
 }
 }
 }</code></pre>



The most important bits are:



<ul><li><code>"name": "drupal-gitlab/feeds_http_auth_fetcher"</code> - you can define whatever you want but you'll need to remember this so I use the pattern <code>drupal-gitlab/MODULENAME</code> (<a rel="noreferrer noopener" href="https://about.gitlab.com/blog/2018/08/16/drupal-moves-to-gitlab/" data-type="URL" data-id="https://about.gitlab.com/blog/2018/08/16/drupal-moves-to-gitlab/" target="_blank">GitLab being where Drupal.org code is stored</a>)</li><li><code>"type": "drupal-module"</code> - tells Composer what type of code this is and if you use "<code>installer-paths</code>" that'll determine where the code is downloaded to, if it was a theme for example you'd use <code>drupal-theme</code></li><li>"source" - this is where the source code actually is, for Drupal modules &amp; themes they live on GibLab as "git" repositories. The URL pattern is always <code>https://git.drupalcode.org/project/MODULENAME.git</code>. "<code>reference</code>" should be the branch or commit hash you want, for this module there was only a <code>1.0.x</code> branch.</li><li><code>"version"</code> - my understanding is this allows you to define a given version of the code when you use <code>composer require</code> in my example it seemed to what with whatever I wrote here.</li></ul>



To test this we can now run the following which should now download the module from it's git source:



<pre class="wp-block-code"><code>ddev composer require drupal-gitlab/feeds_http_auth_fetcher</code></pre>



And look for the following in your Composer output:



<pre class="wp-block-code"><code>- Installing drupal-gitlab/feeds_http_auth_fetcher (1.0.3): Cloning 8.x-1.x</code></pre>



<figure class="wp-block-image size-wide"><img src="/img/blog/patching-drupal-contrib-modules-drupal-10-compatibility-composer-52b7b0da7f39010cd49cb2bafb644310.png" alt="feeds_http_auth_fetcher downloaded locally" class="wp-image-257" data-entity-type="file" data-entity-uuid="2dffe157-0132-4978-b0f1-f3569bb4bcff" data-image-style="original"/><figcaption><meta charset="utf-8">feeds_http_auth_fetcher downloaded locally</figcaption></figure>



<hr class="wp-block-separator is-style-wide"/>



<h2>Now to patch the module</h2>



First thing we need if you haven't already got it is a Composer plugin called "<a href="https://github.com/cweagans/composer-patches" data-type="URL" data-id="https://github.com/cweagans/composer-patches" target="_blank" rel="noreferrer noopener">composer-patches</a>", follow the instructions there to install it on your Composer Drupal project.



Over to the <meta charset="utf-8"><a rel="noreferrer noopener" href="https://www.drupal.org/project/feeds_http_auth_fetcher/issues/3297180" data-type="URL" data-id="https://www.drupal.org/project/feeds_http_auth_fetcher/issues/3297180" target="_blank">Automated Drupal 10 compatibility fixes</a> issue and grab the remote URL of the patch we want: https://www.drupal.org/files/issues/2022-07-18/feeds_http_auth_fetcher.1.0.x-dev.rector.patch 



Now we add the patch information to the "extras" -&gt; "patches", this is a simple format:



<pre class="wp-block-code"><code>"extras": {
 "patches": {
 "PACKAGENAME-1": {
 "DESCRIPTION-OF-PATCH": "PATH-TO-PATCH-FILE-(LOCAL-OR-REMOTE)"
 },
<meta charset="utf-8"> "PACKAGENAME-2": {
 "DESCRIPTION-OF-PATCH": "PATH-TO-PATCH-FILE-(LOCAL-OR-REMOTE)"
 }
 }
}</code></pre>



And for our example this became:



<pre class="wp-block-code"><code><meta charset="utf-8">"extras": {
 "patches": {
 "drupal-gitlab/feeds_http_auth_fetcher": {
 "Automated Drupal 10 compatibility fixes": "https://www.drupal.org/files/issues/2022-07-18/feeds_http_auth_fetcher.1.0.x-dev.rector.patch"
 }
 }
}</code></pre>



Over in Terminal run <code>ddev composer install</code> and if everything works you'll see lines similar to this in your Composer output:



<pre class="wp-block-code"><code> - Installing drupal-gitlab/feeds_http_auth_fetcher (1.0.3): Cloning 1.0.x from cache
 - Applying patches for drupal-gitlab/feeds_http_auth_fetcher
 https://www.drupal.org/files/issues/2022-07-18/feeds_http_auth_fetcher.1.0.x-dev.rector.patch (Automated Drupal 10 compatibility fixes)</code></pre>



And that's it, your module should now show as Drupal 10 compatible and can be installed:



<figure class="wp-block-image size-wide"><img src="/img/blog/patching-drupal-contrib-modules-drupal-10-compatibility-composer-d8610b9653521afb2b9b40a0edc9c766.png" alt="Module is now available to install" class="wp-image-259" data-entity-type="file" data-entity-uuid="d966a2f2-54a8-4eca-82f6-8804522a1750" data-image-style="original"/><figcaption>Module is now available to install</figcaption></figure>

Patching Drupal contrib modules for Drupal 10 compatibility with Composer

Upgrading to Drupal 10 and PHP 8

All the projects I've been working with are well maintained Composer based Drupal projects which definitely makes the setup a bit easier! 



<hr class="wp-block-separator"/>



<h2 class="h-underline">Installing <meta charset="utf-8">PHPCompatibility</h2>



To do the actual compatibility testing I'm going to be using the <a rel="noreferrer noopener" href="https://github.com/PHPCompatibility/PHPCompatibility" data-type="URL" data-id="https://github.com/PHPCompatibility/PHPCompatibility" target="_blank">PHPCompatibility</a> bundle and as I mentioned because I'm using Composer it's pretty straightforward to install. There are probably other ways to audit your Drupal projects PHP compatibility but I liked how easy PHPCompatibility fits into a Composer based projects so decided to test it out.



Here's how to install <meta charset="utf-8">PHPCompatibility in your Drupal Composer projects:



1) Go to your project root directory (where <code>composer.json</code> is)



2) Run <code>composer require phpcompatibility/php-compatibility --dev</code> or <code>ddev composer require phpcompatibility/php-compatibility --dev</code> if you're <a rel="noreferrer noopener" href="https://tomswebstuff.com/node/73" data-type="URL" data-id="https://tomswebstuff.com/node/73" target="_blank">using DDEV for your local Drupal development</a> 



3) Now we need to set some PHPCompatibility settings so it knows where it's installed. For that we'll use "scripts" part of our <code>composer.json</code> file. Under "post-install-cmd" &amp; "post-update-cmd" add: <meta charset="utf-8"><code>"\"vendor/bin/phpcs\" --config-set installed_paths vendor/phpcompatibility/php-compatibility"</code>



<pre class="wp-block-code"><code> "scripts": {
 "post-install-cmd": &#91;
 "\"vendor/bin/phpcs\" --config-set installed_paths vendor/phpcompatibility/php-compatibility"
 ],
 "post-update-cmd": &#91;
 "\"vendor/bin/phpcs\" --config-set installed_paths vendor/phpcompatibility/php-compatibility"
 ] 
 },</code></pre>



4) Next from command line run <code>composer install</code> (the official <meta charset="utf-8">PHPCompatibility documentation says it should be <code>composer update --lock</code> but for me I got a load of errors). 



PHPCompatibility should now be installed within the project as a vendor. 



If you're not using Composer you'll need to <a rel="noreferrer noopener" href="https://github.com/PHPCompatibility/PHPCompatibility#installation-via-a-git-check-out-to-an-arbitrary-directory-method-2" data-type="URL" data-id="https://github.com/PHPCompatibility/PHPCompatibility#installation-via-a-git-check-out-to-an-arbitrary-directory-method-2" target="_blank">install PHPCompatibility via git instead</a>.



<hr class="wp-block-separator"/>



<h2 class="h-underline">Run <meta charset="utf-8">PHPCompatibility on your Drupal project</h2>



The PHPCompatibility binary should now be present in <code>/vendor/bin/phpcs</code>, to double check you can run <code>vendor/bin/phpcs --help</code> and you should see the help text like in the screenshot below:



If you don't get the help text then check the output from step #2 above, you may have got an error without noticing.



So assuming all is well with <meta charset="utf-8">PHPCompatibility you can now start to audit your Drupal project &amp; check it's PHP 8.x compatibility. My projects were running Drupal core 9.4.8 with all contrib modules running on their latest version so I decided to skip auditing core &amp; contrib modules (for now) and focus just on custom modules &amp; themes to start with.



Here's the command to audit your PHP 8.0 compatibility:



<pre class="wp-block-code"><code>vendor/bin/phpcs -p SOURCE_CODE_LOCATION --standard=PHPCompatibility --runtime-set testVersion PHP_VERSION--extensions=FILE-EXTENSIONS-TO-CHECK --report-file=REPORT-FILENAME</code></pre>



<code>SOURCE_CORE</code> = the location of the source code to run the audit on Examples: <code>.</code> for the current directory/whole projects, <code>./web/modules/custo</code>m for custom modules or <code>./web/themes/custom</code> for custom themes



<code>PHP_VERSION</code> = The PHP version you want to check your projects compatibility against ie. 8.0



<meta charset="utf-8"><code>FILE-EXTENSIONS-TO-CHECK</code> = The types of files your audit should check, any file that contains PHP basically. For modules this might be <code>php,module,install,inc</code> &amp; for themes <code>php,install,inc,theme</code>



<meta charset="utf-8"><code>REPORT-FILENAME</code> = The location &amp; name of the file to output the results of the audit to. ie. <code>./themes-php8.0-test.txt</code> or <code>./audits/modules-php8.0-test.txt</code>



And the real life commands I used to check my custom modules &amp; themes were:



Modules: <code>vendor/bin/phpcs -p ./web/modules/custom --standard=PHPCompatibility --runtime-set testVersion 8.0 --extensions=php,module,install,inc --report-file=./audits/modules-php8-compatibility.txt</code>



Themes: <code>vendor/bin/phpcs -p ./web/themes/custom --standard=PHPCompatibility --runtime-set testVersion 8.0 --extensions=php,install,inc,theme --report-file=./audits/themes-php8-compatibility.txt</code>



The results being 2 audit .txt files in my sites /audits directory telling me about all errors &amp; warnings related to PHP 8.0 compatibility. From there you can work your way through &amp; fix any issues and then run the audits again. 



For me, all projects were already running Drupal 9.4.8 and PHP 7.4 so I actually got very few warnings but it was reassuring to know that the code was going to run on PHP 8 without issue. 



<hr class="wp-block-separator"/>



<h2 class="h-underline">Don't forget to test for real!!</h2>



The last part of any compatibility testing is actually testing in real life ie. Fire up the website on the PHP version you will be running &amp; use/test the site. 



Fortunately, as I now use <meta charset="utf-8"><a rel="noreferrer noopener" href="https://tomswebstuff.com/node/73" data-type="URL" data-id="https://tomswebstuff.com/node/73" target="_blank">DDEV for all my local Drupal development</a> this was simply a case of changing 1 line in <code>/.ddev/config.yaml</code> from <code>php_version: "7.4"</code> to <code>php_version: "8.0"</code> and then running <code>ddev start</code> to restart the container :)



From there I checked the Status page at /admin/reports/status and then browsed the sites key pages and then reviewed the database logs at /admin/reports/dblog. If things looked good I could then flag the site as ready for further testing knowing that the PHP 8 compatibility was in good shape!







And that's it for this quick but hopefully useful post on PHP 8 Drupal Compatibility testing, thanks for reading!!

Projects

Blog