Articles

Local actions are UI components being menu shortcuts placed right under the local tasks tabs. These are actually menu items, but rendered as buttons.

Normally, local actions are defined in the YOUR_MODULE_NAME.links.action.yml file. To generate local actions dynamically it is required to implement a deriver class.

Derivative classes enable to register multiple plugin instances programmatically with minor changes. These inherit base logic from the deriving (base) plugin class, hence the name.

Routes normally are defined in the YOUR_MODULE_NAME.routing.yml file and are pre-defined. Building dynamic routes, however, that are built based around some logic (like taxonomy terms, etc) involve the following:

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.