This module is used to show ANY SELECTED theme based on selective routes/paths and render selected theme for that route/path.
Note : if user has permissions to view SELECTED theme then only theme will be accessible.
Ex: If any authenticated user want to view '/abc' route in admin theme and '/xyz' in CUSTOM theme
this module will help to show selected routes/paths in respective selected theme.
Have you ever needed to persist some irregular data relating with a user account? Things like user preferences or settings that are kinda configuration but not really? Storing them as configuration means having to export them, and that’s no option. Storing them in State is an option, but not a good one as you’d have to maintain a State value map with each of your users and who wants to deal with that…
In Drupal 7, if you remember way back when, we had this data column in the user table which meant that we could add to the $user->data array whatever we wanted and it would get serialised and saved in that column (if we saved the user object). So what is the equivalent of this in Drupal 8?
I’m happy to say we have the exact same thing, but of course much more flexible and properly handled. So not exactly the same. But close. We have the user.data service provided by the User module and the users_data table for storage. So how does this work?
First of all, it’s a service. So whenever we need to work with it, we have to get an instance like so:/** @var UserDataInterface $userData */ $userData = \Drupal::service('user.data');
Of course, you should inject it wherever possible.
The resulting object (by default) will be UserData which implements UserDataInterface. And using this object we can store as many pieces of data or information for a given user as we want. Let’s explore this a bit to learn more.
The interface has 3 methods or handling data: get(), set(), delete(). But the power comes in the method arguments. This is how we can store some data for User 1:$userData->set('my_module', 1, 'my_preference', 'this is my preference');
So as you can see, we have 4 arguments:
- The module name we want this piece of data to be findable by
- The user ID
- The name of the piece of data
- The value of the piece of data
This is very flexible. First, we can have module specific data. No more colluding with other modules for storing user preferences. Stay in your lane. Second, we can have multiple pieces of data per user, per module. And third, the value is automatically serialised for us so we are not restricted to simple strings.
Retrieving data can be done like so:$data = $userData->get('my_module', 1, 'my_preference');
This will return exactly this is my preference (in our case). And deserialisation also happens automatically if your data got serialised on input.
Deleting data is just as easy:$userData->delete('my_module', 1, 'my_preference');
Moreover, most of the arguments of the get() and delete() methods are optional. Meaning you can load/delete multiple pieces of data at once. Check out UserDataInterface to see how omitting some arguments can return/delete sets of records rather than individual ones.
And that is pretty much it. And in true Drupal 8 form, there’s nobody stopping you from overriding the service and using your own UserDataInterface implementation that has that little extra something you are missing. So no, you probably don’t have to create that custom table after all.
We have been running containers in production for more than a year now and want to share some of the lessons learnt, by open sourcing our container suite.
This module provides simple Chart.js integration with your Drupal 7 or Drupal 8 (coming soon) site's statistics.
"We wanted it to be this festive Christmas experience," Halo 5 dev Christopher Bloom tells Kotaku. "But you can't do it all the time or you lose the specialness." ...
This module provides integration with Shorthand, an application which describes itself as "beautifully simple storytelling". It connects your Shorthand account with Drupal and allows you to publish your stories on a Drupal website. Create your Shorthand account to get a User ID and API Token (found on the account settings page) which are prerequisite for using this module.
Drupal Modules: The One Percent: Drupal Modules: The One Percent — Alert to Administrator (video tutorial)
Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll take a look at Alert to Administrator, a module which displays an alert every time a user logs in as an administrator.
A Drupal 8 module to provide emergency alerts.Quickstart
Enable this module and configure to set alert title and message, severity, and to turn on block or full page override.
(optional) Add region emergency_alert to your theme and in templates. For example (in theme.info.yml),