Recently I wrote on how I replaced my MacBook Pro with a PC and still being productive when developing on several Drupal environments.While Pop_OS! is a wonderful Linux distro, I decided to give Windows a try. The primary reasons were the usual: hardware. The drivers are optimized to work on Windows and some small features that are nice-to-have only work on this controversial OS: Login with an infrared camera (Windows Hello), a solid workspace with several monitors (maybe this is the most important reason), better Dolby sound from the speakers and battery optimizations. Nothing critical really, but things that improve the experience.

What means to have a productive development environment?

This:

1. Bash command line.
2. Fast docker environment (without unison, I've had enough problems with it already).
3. Working git
4. Be able to launch several development environments, fast, from command line, and use custom domain names to access them and its related services.
5. A good editor, like Sublime Text or Visual Studio Code. (I know, I don't use PHP Storm and don't want to).

Since I had tried WSL before (and failed), I decided to get rid of it and move directly to install a VM.

An Ubuntu server checks first three items in the above list, but the next two can get messy. Sharing source code files with the Windows host as a Samba share defeats the purpose because its bad performance, symlinks weirdness, among other things. Sharing it using sshfs could be an option, but then how could I control docker?

Editor

The solution came on a recent iteration on Visual Studio Code: Remote code extensions, specifically, Remote Coding via SSH. This extension allowed me to open remote directories through SSH and work with them. This is not like running Dreamweaver to edit files on a server (remember?). It works splitting the editor in two pieces, a client (the UI) and a server, where the indexing and language processing extensions run. The result is a very responsive editor, while working remotely with all the extensions I would normally use. Even the integrated terminal in the editor opens automatically a bash prompt in the server, a really useful feature.

This remote feature in Visual Studio Code gives me the full Linux experience right from the editor.

However, I normally access docker websites using custom URLs, a pretty common practice. If using docksal, for example: super-awesome-client.docksal, db.super-awesome-client.docksal, etc., you get the idea. I needed to find a way to re-route custom URLs to my VM.

Networking

On a Mac or on Linux this would work out of the box after installing docksal (or lando or whatever docker wrapper you use). I wanted this to work the same way:

• I didn't want to configure each custom website manually
• This had to work on new sites created with docksal
• Should work on any network

To achieve this transparent routing, I needed a static IP for the VM, so I could always reference it if I was at home, at a coffee shop, or in an airport. I'm using Hyper-v, so I created a NAT using the instructions below:

Windows 10: How to setup NAT network for Hyper-V guests?

Then in the VM, configured the static IP address using netplan, created file /etc/netplan/01-netcfg.yaml (I used the same IP address as the guide to create the NAT above).

network:
    ethernets:
        eth0:
            dhcp4: no
            dhcp6: no
            addresses: [192.168.200.11/24]
            gateway4: 192.168.200.1
            nameservers:
                addresses: [8.8.8.8]

After enabling the ssh server in the VM, and configuring my ssh keys I was able to jump into the server from Windows very quickly, or even configure ConEmu or the new Windows Terminal to automatically connect to ssh.

To access the web servers running in docker containers created with docksal, I installed a DNS proxy: Acrylic DNS Proxy, and used this hosts configuration:

192.168.200.11 *.docksal

Visual Studio Code Configuration

In Visual Studio Code I installed the Remote Development extensions for SSH. The configuration was straight forward and worked really well (the extension guides you until you are successfully connected to a SSH server).

Huge Drupal projects were indexed really fast and the performance when browsing them was like working on Linux. Debugging worked out of the box (this thanks to Docksal configs, but still, using docker-compose shouldn't be a problem).

The only downside I've found is that I can't commit, push or pull using the editor, which is not a big deal since I can use the integrated terminal. From the documentation:

If you clone a Git repository using SSH and your SSH key has a passphrase, VS Code's pull and sync features may hang when running remotely. Either use an SSH key without a passphrase, clone using HTTPS, or run git push from the command line to work around the issue.

I ended up creating an SSH key for my repos without a passphrase.

Recap

Working on PHP natively on Windows it is still impossible, but using a VM and Visual Studio Code with Remote Code extensions works very well, with the price of more memory usage, but memory is cheap now, and that is one of the reasons I left Apple in the first place: to have an upgradable development computer.

One unexpected bonus is that I can recover from suspend and the VM will load up with all services that were running, something that in Linux didn't happen; I had to to run fin up or docker-compose up again after the laptop woke.

Aside: WSL2

The Windows Subsystem for Linux v2 is about to be released, which uses a custom Linux Kernel in a very lightweight VM (it is already in Windows Internals fast ring, but expected to reach public release until 2020).

In theory, it has all the same good points of this setup with a VM, and seems so be a great setup for a future development environment because of these:

• The VM file system can be accessed directly from Windows using a p9 file system (that alone is awesome).
• The performance is very close to native one.
• Shared memory and processor cores.
• Much tighter integration, it is possible to run windows programs from within the VM.

This technology can really change the development experience on Windows, lets see if it is up to the expectations when it is released (because I won't subscribe to the fast ring in my main development computer).

Stranger things

While setting the environment I found an error that didn't allow me to clone big repos or to push changes. It turned out to be a bug in my WiFi drivers. So if you find the error below and have an Intel WiFi card, update your drivers.

$ git clone git@somrerepo-bla-bla.git
Cloning into 'somedir'...
error: RPC failed; curl 56 GnuTLS recv error (-12): A TLS fatal alert has been received.
fatal: The remote end hung up unexpectedly

A common request I’ve received lately when building sites in Drupal is to make the background of the page title configurable to allow the user upload and change it.

Of course, this could be solved with a new block type with two fields, one for the image and one for the title. But then we would need to add the block for each page where we want to show the title.

How does Drupal handle page titles? Looking in the block admin page, I found that actually it is a block. Well, we need the same functionality of that block in our new one.

So looking for the class that contains the block machine name page_title_block I found Drupal\Core\Block\Plugin\Block\PageTitleBlock which implements TitleBlockPluginInterface. This is all the interface:

    interface TitleBlockPluginInterface extends BlockPluginInterface {

      /**
       * Sets the title.
       *
       * @param string|array $title
       *   The page title: either a string for plain titles or a render array for
       *   formatted titles.
       */
      public function setTitle($title);

    }

Searching what uses that interface, I found that BlockPageVariant uses it to assign it a title:

    foreach ($this->blockRepository->getVisibleBlocksPerRegion($cacheable_metadata_list) as $region => $blocks) {
          /** @var $blocks \Drupal\block\BlockInterface[] */
          foreach ($blocks as $key => $block) {
            $block_plugin = $block->getPlugin();
            if ($block_plugin instanceof MainContentBlockPluginInterface) {
              $block_plugin->setMainContent($this->mainContent);
              $main_content_block_displayed = TRUE;
            }
            elseif ($block_plugin instanceof TitleBlockPluginInterface) {
              $block_plugin->setTitle($this->title);
            }
      //...

This means that if I create a custom block that implements TitleBlockPluginInterface I will get the page title automatically (thanks to BlockPageVariant)? Apparently, yes.

Lets start writing the custom block extending PageTitleBlock to use the title field implementation:

    /**
     * @Block(
     *   id = "my_image_title_block",
     *   admin_label = "Image title block"
     * )
     */
    class ImageTitleBlock extends PageTitleBlock {

      /**
       * The image field.
       *
       * @var mixed
       */
      protected $image;

      public function defaultConfiguration() {
        return [
          'image' => [
            'value' => '',
          ],
          'label_display' => FALSE,
        ] + parent::defaultConfiguration();
      }

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

        if (isset($this->configuration['image'])
          && !empty($this->configuration['image'])) {

          $image_field = $this->configuration['image'];
          $image_uri = File::load($image_field[0]);

          $build['image'] = [
            'uri' => ImageStyle::load('title_bar')->buildUrl($image_uri->getFileUri()),
          ];
        } else {
          $build['image']['#markup'] = '[' . t('Picture') . ']';
        }


        return $build + parent::build();
      }

      /**
       * {@inheritdoc}
       */
      public function blockForm($form, FormStateInterface $form_state) {

        $form['image'] = array(
          '#type' => 'managed_file',
          '#upload_location' => 'public://images/',
          '#title' => $this->t('Image'),
          '#description' => $this->t("Background image"),
          '#default_value' => $this->configuration['image'],
          '#upload_validators' => array(
            'file_validate_extensions' => array('gif png jpg jpeg'),
            'file_validate_size' => array(25600000),
          ),
          '#states' => array(
            'visible' => array(
              ':input[name="image_type"]' => array('value' => t('Upload New Image')),
            )
          )
        );

        return $form;
      }

      public function validateConfigurationForm(array &$form, FormStateInterface $form_state) {
        if (!$form_state->getValue('image')) {
          $form_state->setError($form['image'], $this->t('Select an image'));
        }
      }

      /**
       * {@inheritdoc}
       */
      public function blockSubmit($form, FormStateInterface $form_state) {
        /* Fetch the array of the file stored temporarily in database */
        $image = $form_state->getValue('image');

        $this->configuration['image'] = $image;

        /* Load the object of the file by it's fid */
        $file = \Drupal\file\Entity\File::load($image[0]);

        /* Set the status flag permanent of the file object */
        $file->setPermanent();

        /* Save the file in database */
        $file->save();
      }
    }

After clearing Drupal cache, you will find your new shiny block waiting for you in the Add block list. The build method returns the processed image URL (using titlebar_ style) instead of the render array for an image so we can use it later.

Let’s create titlebar_ image style and configure it accordingly (in my case, resize and crop to a predefined size will do).

Then, update your theme to make sure that image url shows in a style attribute, or a data-* if you’re using javascript to load the image.

block—image-title-block.html.twig

    <div{{ attributes.setAttribute('style',
        'background: #787c8a url(' ~ content.image.uri ~ ') no-repeat center;') }}>
      {{ title_prefix }}
      {% if label %}
        <h2{{ title_attributes }}>{{ label }}</h2>
      {% endif %}
      {{ title_suffix }}
      {% block content %}
        {{ content }}
      {% endblock %}
    </div>
    ...

Lets test it!

Last time I tried to create from scratch a Drupal instance that used a Solr server wasn’t as easy as I expected. Maybe command line tools for installing modules have spoiled me and I just expected that running something like drupal module:install solr would configure everything for me.

Here is how I made it work, but please consider I’m not a Solr expert. If you know a better way to do this please let me know.

Setup Drupal

Let’s suppose we want to create a blog that uses a Solr for searching its contents.

First, to create a basic Drupal install we can use a recently released project from WeKnow to quickly create a Drupal instance using Docker. Follow the README file keeping the default .env values so we can install Drupal using this command:

$ docker-compose exec —user=82 php drupal site:install standard —db-host=mariadb —db-name=drupal —db-user=drupal —db-pass=drupal —quiet

Don’t forget to add the hosts entry, as mentioned in the README file, or use a proxy like hotel. The objective is to use a custom domain name that the web server can identify (if we use localhost and in the .env file we used HOST_NAME=drupal.vm the web server won’t serve the request).

You can verify it is working if you see a fresh Drupal install when you visit http://drupal.develop.

Install Solr

Let’s install Solr now. We will need some config files found in the module to setup our Solr core, so lets download it inside the container:

$ docker-compose exec --user=82 php composer req drupal/search_api_solr

We will create a sample core named *blog*. Copy the files located at web/modules/contrib/search_api_solr/solr-conf/5.x/ to env/solr/blog/conf/ and create this file in env/solr/blog/core.properties (you will need to create the env dir):

env/solr/blog/core.properties

    name=blog
    config=solrconfig.xml
    schema=schema.xml
    dataDir=/var/lib/solr/books

Update docker-compose.yml to include the solr container and config its port and a way to access it using traefik (using http://solr.drupal.develop if using the defaults in .env):

docker-compose.yml

    services:
      # ...
      solr:
        image: solr:5.5
        labels:
          - 'traefik.backend=solr'
          - 'traefik.port=8983'
          - 'traefik.frontend.rule=Host:solr.${HOST_NAME}'
        volumes:
          - ./env/solr/blog:/opt/solr/server/solr/blog
          - solrdata:/var/lib/solr

    volumes:
      mysqldata:
        driver: "local"
      solrdata:
        driver: "local"

Don’t forget to add the solr.drupal.develop to your hosts file).

After running docker-compose up -d (and adding to your hosts file the entry for solr.drupal.development) you will see this error in solr:

This happened because the user and the uid has to match with the user the solr process runs as in the solr container. To fix this we have to create another container that fixes the perms where the core will write the index.

We will use just-containers/base-alpine image, which has utilities to do this (s6).

Add the docker file to update fix the perms and update docker-compose to use this new container:

./dockerfiles/solr_data/Dockerfile

    FROM just-containers/base-alpine
    VOLUME ["/var/lib/solr"]
    ADD root /

./dockerfiles/solr_data/root/etc/fixattrs.d

    /var/lib/solr false solr,8983 0755

And update the docker-compose.yml to include this image:

    services:
      solr:
        image: solr:5.5
        labels:
          - 'traefik.backend=solr'
          - 'traefik.port=8983'
          - 'traefik.frontend.rule=Host:solr.${HOST_NAME}'

        # add the volumes from the new container
        volumes_from:
          - solr_data
        # the core configs
        volumes:
          - ./env/solr/blog:/opt/solr/server/solr/books

      # added container to fix perms
      solr_data:
        build: ./dockerfiles/solr_data
        volumes:
          - real_solr_data:/var/lib/solr

    volumes:
      mysqldata:
        driver: "local"
      real_solr_data:
        driver: "local"

Now if you run docker-compose up -d and you visit the Solr page you should see your errors fixed.

Configure Solr

Now that we have the server running, lets configure Drupal so we can use it as a search engine. Fortunately, most of the hard work is solved by enabling search_api_solr_default module.

    $ docker-compose exec --user=82 php drupal moi search_api_solr_defaults

Go to the Search API configs (/admin/config/search/search-api) and you will see a new Solr server entry, although with errors because it is missing the server name and the core it will use.

Click edit and set the host (ie. the solr container name, solr) and the core we created before (blog):

Click save and you should be able to to see all green when you go back to the Search API config page. You can now start using your solar server for searching.

The defaults module contains a sample search page to easily get you started in /solr-search/content. It is implemented as a View.

References

You might find this links useful:

• Outrigger examples
• Try Drupal

Permalink: Setup Solr and Drupal using Docker