During development you regulary have to make changes to your data model. e.g. create new entities or change exitisting ones. To check this changes in use hook_update_N and
Read this change record for update functions for entity schema updates (doc needs update).
multi property field approach
default_value: 'Click here!'
D7 to D8 Migration
If you have some configuration in your modules config/install directory, it didn’t get deleted during module uninstall routine.
drush en -y YOURMODULE will throw an error if you try to reinstall your module. But during development – e.g. custom migrations – you will likely find you in a situation where you have repeatedly to to this. I tried the config_devel module. Sadly without much success.
Luckily since beta3 you can add (change record) enforced dependencies. Since then
drush pmu -y YOURMODULE will uninstall your config item too.
You have to add:
to all of your config files.
drush pmu -y YOURMODULE && drush en -y YOURMODULE will give you a fresh reinstall with all the new config goodness. Not very elegant, but it works.
I’ve tried the better part of the morning to get an custom migration for D8 up and running. I stumbled on the very first step. Migrate Plus doesn’t recognized my migration. After some hairpulling, I came across a blog post by Mike Ryan.
If in 8.0.x you were implementing migrations by providing .yml files in config/install, you’ll need to rename those files from migrate.migration.* to migrate_plus.migration.* (because it is now the contrib migrate_plus module rather than the core migrate module which implements migration configuration entities).
Simple naming issue – aaah, slapping myself, whosh -. Thats why I dislike fileNameMagic. With some explicit config …, well I guess, I would hunt another thing :S
If you need a sophisticated solution including an API the metatag module is for you. An short post about it by Jeffrey McGuire.
If you don’t feel the need of an module and simply want to set some static global metatags, you can do it by implementing the hook_page_attachements. A good example is the system modules implementation.
Actually it is sufficient to google react and flux. You will find enough good sources to read for days.
But this post by Lin Clark on medium is so good, I have to keep it here.
A cartoon guide to Flux
Today I needed to know which JQM version is available in a certain context. Maybe I wasn’t clever enough to use the right search terms. Howsoever, it took far to long to google the answer.
console.log("JQM version: " + $.mobile.version);
Okay, I could have guessed that one. 😉
Good sources for quick overview:
Definition of routes happens in yourmodule.config.yml. The structure of a route definition is documented on d.o., but documentation is incomplete.
Especially I couldn’t find any useful documentaction on how to restrict the route definition to a specific method (in my case GET). The symfony way of using
methods: [GET] doesn’t work. Seems that drupal is using a depreciated way of defining the allowed methods. Symfony’s route.php on github (see setMethods)
The solution as today is to put an _method definition under the requirements section in the yaml file:
Note that you have to use a string, even in case of more than one method. Example: ‘GET|POST’.
Change record on d.o. on upgrading to symfony 3.0 in a subsequent minor release.
See also the upgrade notes from the symonfy team at github. According to these docs, the structure of the routing definitcccion will likely change soon.
To setup other HTTP Methods than GET and POST for your route, you can use symfony’s fake method parameter in the query string. I didn’t test if this actually works on a D8 installation yet.