I have been using the Drupal dependency injection system for a while now, even giving talks and writing articles on the subject. As the release of Drupal 10 is just around the corner I have been thinking more about how to override dependencies to plugin classes.

I wanted to share a trick to overriding dependency injection that will make your life easier. The Drupal codebase itself does not use this trick, but it seems that many contributed modules have started to use this trick to create plugin classes.

In this article I will go through how to add dependency injection to Drupal classes in two different patterns.

The first pattern will create problems and will require quite a bit more typing and repeating of code. The second pattern is much easier to use and will make life easier going forward.

An Example Block

The following block of code shows a very basic Drupal Block class that doesn’t do anything. This will be the basis of the rest of this article.

<?php namespace DrupalmymodulePluginBlock;

use DrupalCoreBlockBlockBase;

/**
 * Provides a 'TEST' block.
 *
 * @Block(
 *  id = "mymodule_block",
 *  label = "A testing block",
 *  admin_label = @Translation("A testing block"),
 * )
 */
class TestBlock extends BlockBase {

  /**
   * {@inheritdoc}
   */
  public function build() {
    $build = [];

    return $build;
  }

}

What I am going to do with this block is inject a service to perform route matching. In Drupal there are a couple of services to do this, but I will be using the current_route_match service to look for the service.

Read more.

Every desktop computer or mobile device comes with some form of “app
store”. There is F-Droid for Android. Debian has “software repositories”
at its core. Then there are the really big, proprietary ones: Apple App
Store and Google Play. These have millions of apps, while Debian has tens
of thousands, and F-Droid around 4,000. This statistic is commonly
mentioned when the big app stores promote themselves. When comparing by
this number, F-Droid is a tiny little blip. But really, how many apps do
you need in your app store?

Every software collection is fundamentally an act of curation. Only useful
software is included. Malicious software is filtered out. Software deemed
illegal in your jurisdiction is blocked. Any software that does not meet
the standards or terms of service is removed. In the cases of
community-curated distros like Debian or F-Droid, the contributors curate by
choosing which apps are worth their attention. There is no major end-user
software distribution that does not curate. Ideally, it is software that is
useful to you, the user. Sadly, that is often not true. Think of the
companies that prioritize surveillance
capitalism:
they include software designed to capture your attention so they can sell to
advertisers. Or some companies promise privacy protections from apps, but
then exempt their own
software
from the privacy protections.

From the point of the user, the ideal app store would contain exactly what
the user wants, and not one thing more. Nobody has millions of apps
installed on their device. All those extra apps just get in the way of
finding what is important. Even worse, in the big app stores, its not just
noise, it is
malware
or companies trying to rope you into something. They are trying to be the
flashiest thing so people click the “buy” button. Or worse, they are trying
to
addict
you so that they can sell your data to advertisers.

F-Droid is organized around different principles: user choice,
decentralization, and community-controlled curation. This means F-Droid
gives you selected apps by default without bans or censorship. When you
install the F-Droid app, it automatically connects to the collection on
f-droid.org that is maintained by this community. F-Droid also makes it
easy for anyone to publish their own repository, with their own curation
rules. Repomaker is a easy web app
for publishing, and the fdroidserver command line tools that power
f-droid.org are available for power users.

Organizing this way makes a lot of hard questions go away. Children,
hackers, religious people, grandparents, activists, bachelors, and adult
film actors; we all use calendars, read the news, need help navigating, play
games. Over the years, a rough consensus has formed within the f-droid.org
community that our collection should be curated this way. This turns out to
be quite similar to other free software communities, like Debian. This blog
post aims to make this more explicit to our users.

Every society has accepted ways to communicate about offensive things. If
f-droid.org is the one source of software, then our curation would be
censorship, since we would be preventing speech. As supporters of free
software and privacy, we also want nothing to do with censorship. That’s
where decentralization comes in. Decentralization means people can choose
who they trust in a fine-grained way, not all or nothing. We have put a lot
of work into making it easy for anyone to make their own app repos, and
those repos can follow any rules that its creators want. Since F-Droid
repos are a form of user-controlled subscription, it is not the place for
F-Droid contributors to decide. Which apps or repos an F-Droid user
includes in their own devices is entirely up to them.

One common complaint about decentralized systems is that they work badly.
That is not true for the Android app ecosystem, and software distribution in
general. Software repositories are usually not monolithic, the big mobile
app stores are really the exception. Windows allows many sources. GNOME
Software has one seamless
experience based on apt, dnf, Flatpak, Snapcraft, etc. as software
sources. In the Chinese app store
market
five to ten commonly used app stores, and yet even the largest has less than
a majority market share. Most Chinese people have more than one app store
on their phone, so there is no monolith there, whereas “outside of China,
Apple and Google control more than 95 percent of the app store market
share”. Ecosystems with
multiple app sources work, and governments around the world believe that
monopoly
forces
are
what
keeps
Google
Play
and
Apple
App
Store
dominant. Even Apple’s famous strictly walled garden can coexist with
AltStore, AppFair, and
Cydia. This clearly demonstrates that the only
barrier to breaking down the app monoliths are the policies of monopolist
companies.

The point remains: for the vast majority of Apple iOS and Google Play device
users, when the store removes or restricts an app it is essentially
censorship. Using alternatives requires a high level of technical skill.
Google Play devices at least allow third party app stores, albeit with a
much lower level of integration than Google Play itself. Not only does
F-Droid offer truly open app distribution, the F-Droid model offers an
improved user experience: many decentralized app repositories can be managed
in a single F-Droid client app. So there is the ease of use provided by a
unified user experience, but it is not locked to a single provider. Only
when there is a free, open, decentralized ecosystem can everyone decide for
themselves what apps they want while also choosing which apps they do not
want to see. The freedom to get apps will always be in tension with the
things that people want to keep out of their life. Decentralization is the
only solution, and F-Droid is built from the ground up to enable it.