Articles

Building dynamic routes , that are built based on some custom rules (like taxonomy terms, etc) involve the following:

1. Creating a service that is listening to routing.route_alter event;
2. Implementing a class that alters the route collection;

Creating a route alter event listener

Create src/EventSubscriber/RouteSubscriber.php class stub in your module directory. In this file, add the namespace and create a dummy class that extends Drupal\Core\Routing\RouteSubscriberBase.

WSL2 mounts and binds the host drives so these are accessible in guest OS from the /mnt/* location and this type of mount has inferior performance.

Not only the performance is slow in apps, it's slow overall - composer might time out, npm hickups, etc.

So whether your apps are located in those mount points (read from host drives), move them to a location somewhere within the installed WSL distribution, e.g. /var/www.

When creating custom entities using the BaseFieldDefinition::create() method in the respective entity class file, one way or another it is required to define the fields the entity should by default contain along with their settings.

The BaseFieldDefinition::create() method expects the field type argument and settings of this field are set using the underlying methods the BaseFieldDefinition class provides.

Two issues that might arise are where from to get the field type value and how set the default field settings.

Whether composer install is throwing strange errors inside the virtual box vagrant environment, simply append COMPOSER_RUNTIME_ENV=virtualbox

$ COMPOSER_RUNTIME_ENV=virtualbox composer install

Note:  This parameter is available only in version 2 of composer.

For those still running composer 1, use mount --bind approach. The idea is to mount the vendor directory outside the vagrant virtual box shared folders.

Nowadays there's no way to deal with code issues (read: bugs) without using debugging tools. It's long day gone when var_dump-ing was all you need.

Xdebug allows one to observe the bugs in slow motion and pinpoint the issue easily. It also is a helpful tool to reverse engineer code to understand how it works and how it should be used when there is no documentation.

There are a number of solutions on the Internet, however here goes the one that helped in my case.

Make sure that the private key used to ssh to the guest machine has correct line endings. This affects in most cases Windows machines as the key is created using DOS line engings, but must use UNIX line endings.

This is fixed in vagrant 2.4.1. Update your vagrant executable or read below.

The private key we need is located in same directory as the Vagrantfile.

During upgrade from PHP 8.0 to 8.1, the following error appeared:

SQLSTATE[08001]: [Microsoft][ODBC Driver 18 for SQL Server]SSL Provider: [error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:self signed certificate]

Two solutions here...

If you fall into the following message during vagrant up command:

Command: ["startvm", "71626f2d-1b1c-406c-8cab-698ec48b9815", "--type", "headless"]
Stderr: VBoxManage: error: VT-x is disabled in the BIOS for all CPU modes (VERR_VMX_MSR_ALL_VMX_DISABLED)

... then it seems that your device has virtualization disabled in bios settings.

If private network settings are used for Vagrant machine and the following occurs:

Command: ["hostonlyif", "ipconfig", "vboxnet2", "--ip", "10.0.0.1", "--netmask", "255.255.255.0"]
Stderr: VBoxManage: error: Code E_ACCESSDENIED (0x80070005) - Access denied (extended info not available)

It is not an issue with Vagrant itself, but rather with VirtualBox. Seems that latest versions of it restrict certain private network addresses.

Running Symfony based application in vagrant environment most likely would yield in cache issues.

In order to fix this, we need to instruct Symfony framework to place it's cache outside the vagrant synced folder. Luckily, it's easy and supported by the framework itself.

Check on How to Override Symfony's default Directory Structure (Symfony Docs)