Drupal

cloudbanking

New Drupal Modules - 17 September 2017 - 9:48pm

One Platform - All your payments!

Categories: Drupal

PreviousNext: OK Drupal - powering chatbots with Drupal

Planet Drupal - 17 September 2017 - 5:28pm
Share:

Conversational UIs are the next digital frontier.

And as always, Drupal is right there on the frontier, helping you leverage your existing content and data to power more than just web-pages.

Want to see it action - click 'Start chatting' and chat to our Drupal site.

by lee.rowlands / 18 September 2017

Start chatting

So what's going on here?

We're using the Chatbot API module in conjunction with the API AI webook module to respond to intents. We're using API.ai for the natural language parsing and machine learning. And we're using the new Chatbot API entities sub module to push our Drupal entities to API.ai so it is able to identify Drupal entities in its language parsing.

A handful of custom Chatbot API intent plugin to wire up the webhook responses and that's it - as we create content, users and terms on our site - our chatbot automatically knows how to surface them. As we monitor the converstions in the API.ai training area, we can expand on our synonyms and suggestions to increase our matching rates.

So let's consider our team member Eric Goodwin. If I ask the chatbot about Eric, at first it doesn't recognise my question.

Eric isn't recognized as an entity

So I edit Eric's user account and add some synonyms

Adding synonyms to Eric's account

And then after running cron - I can see these show up in API.ai

Synonyms now available in API.ai

So I then ask the bot again 'Who is eric?'

Screenshot showing the default response

But again, nothing shows up. Now I recognise the response 'Sorry, can you say that again' as what our JavaScript shows if the response is empty. But just to be sure - I check the API.ai console to see that it parsed Eric as a staff member.

Intent is matched as Bio and Eric is identified as staff member

So I can see that the Bio Intent was matched and that Eric was correctly identifed as the Staff entity. So why was the response empty? Because I need to complete Eric's bio in his user account. So let's add some text (apologies Eric you can refine this later).

Adding a biography

Now I ask the bot again (note I've not reloaded or anything, this is all in real time).

A working response!

And just like that, the bot can answer questions about Eric.

What's next?

Well API.ai provides integrations with Google Assistant and Facebook messenger, so we plan to roll out those too. In our early testing we can use this to power an Actions on Google app with the flick of a switch in API.ai. Our next step is to expand on the intents to provide rich content tailored to those platforms instead of just plain-text that is required for chatbot and voice responses.

Credits

Thanks go to @gambry for the Chatbot API module and for being open to the feature addition to allow Drupal to push entities to the remote services.

And credit to the amazing Rikki Bochow for building the JavaScript and front-end components to incorporate this into our site so seamlessly.

Further Reading Tagged Chatbots, Conversational UI, Drupal 8

Posted by lee.rowlands
Senior Drupal Developer

Dated 18 September 2017

Add new comment
Categories: Drupal

WordPress Migration (from DB)

New Drupal Modules - 17 September 2017 - 3:06am
Categories: Drupal

Price

New Drupal Modules - 16 September 2017 - 6:22am

Price field with different tweaks.
Started as a decoupling commerce_price from commerce.
The work is in progress...

Categories: Drupal

Status report

New Drupal Modules - 16 September 2017 - 5:06am

Checks the status of third-party services.

Categories: Drupal

Dave Hall Consulting: Trying Drupal

Planet Drupal - 16 September 2017 - 3:34am

While preparing for my DrupalCamp Belgium keynote presentation I looked at how easy it is to get started with various CMS platforms. For my talk I used Contentful, a hosted content as a service CMS platform and contrasted that to the "Try Drupal" experience. Below is the walk through of both.

Let's start with Contentful. I start off by visiting their website.

In the top right corner is a blue button encouraging me to "try for free". I hit the link and I'm presented with a sign up form. I can even use Google or GitHub for authentication if I want.

While my example site is being installed I am presented with an overview of what I can do once it is finished. It takes around 30 seconds for the site to be installed.

My site is installed and I'm given some guidance about what to do next. There is even an onboarding tour in the bottom right corner that is waving at me.

Overall this took around a minute and required very little thought. I never once found myself thinking come on hurry up.

Now let's see what it is like to try Drupal. I land on d.o. I see a big prominent "Try Drupal" button, so I click that.

I am presented with 3 options. I am not sure why I'm being presented options to "Build on Drupal 8 for Free" or to "Get Started Risk-Free", I just want to try Drupal, so I go with Pantheon.

Like with Contentful I'm asked to create an account. Again I have the option of using Google for the sign up or completing a form. This form has more fields than contentful.

I've created my account and I am expecting to be dropped into a demo Drupal site. Instead I am presented with a dashboard. The most prominent call to action is importing a site. I decide to create a new site.

I have to now think of a name for my site. This is already feeling like a lot of work just to try Drupal. If I was a busy manager I would have probably given up by this point.

When I submit the form I must surely be going to see a Drupal site. No, sorry. I am given the choice of installing WordPress, yes WordPress, Drupal 8 or Drupal 7. Despite being very confused I go with Drupal 8.

Now my site is deploying. While this happens there is a bunch of items that update above the progress bar. They're all a bit nerdy, but at least I know something is happening. Why is my only option to visit my dashboard again? I want to try Drupal.

I land on the dashboard. Now I'm really confused. This all looks pretty geeky. I want to try Drupal not deal with code, connection modes and the like. If I stick around I might eventually click "Visit Development site", which doesn't really feel like trying Drupal.

Now I'm asked to select a language. OK so Drupal supports multiple languages, that nice. Let's select English so I can finally get to try Drupal.

Next I need to chose an installation profile. What is an installation profile? Which one is best for me?

Now I need to create an account. About 10 minutes I already created an account. Why do I need to create another one? I also named my site earlier in the process.

Finally I am dropped into a Drupal 8 site. There is nothing to guide me on what to do next.

I am left with a sense that setting up Contentful is super easy and Drupal is a lot of work. For most people wanting to try Drupal they would have abandonned someway through the process. I would love to see the conversion stats for the try Drupal service. It must miniscule.

It is worth noting that Pantheon has the best user experience of the 3 companies. The process with 1&1 just dumps me at a hosting sign up page. How does that let me try Drupal?

Acquia drops onto a page where you select your role, then you're presented with some marketing stuff and a form to request a demo. That is unless you're running an ad blocker, then when you select your role you get an Ajax error.

The Try Drupal program generates revenue for the Drupal Association. This money helps fund development of the project. I'm well aware that the DA needs money. At the same time I wonder if it is worth it. For many people this is the first experience they have using Drupal.

The previous attempt to have simplytest.me added to the try Drupal page ultimately failed due to the financial implications. While this is disappointing I don't think simplytest.me is necessarily the answer either.

There needs to be some minimum standards for the Try Drupal page. One of the key item is the number of clicks to get from d.o to a working demo site. Without this the "Try Drupal" page will drive people away from the project, which isn't the intention.

If you're at DrupalCon Vienna and want to discuss this and other ways to improve the marketing of Drupal, please attend the marketing sprints.

AttachmentSize try-contentful-1.png342.82 KB try-contentful-2.png214.5 KB try-contentful-3.png583.02 KB try-contentful-5.png826.13 KB try-drupal-1.png1.19 MB try-drupal-2.png455.11 KB try-drupal-3.png330.45 KB try-drupal-4.png239.5 KB try-drupal-5.png203.46 KB try-drupal-6.png332.93 KB try-drupal-7.png196.75 KB try-drupal-8.png333.46 KB try-drupal-9.png1.74 MB try-drupal-10.png1.77 MB try-drupal-11.png1.12 MB try-drupal-12.png1.1 MB try-drupal-13.png216.49 KB
Categories: Drupal

Ddate Block

New Drupal Modules - 16 September 2017 - 2:58am

Dddate block provides configurable blocks displaying a Discordian date.

Categories: Drupal

Drutopia Landing Page

New Drupal Modules - 15 September 2017 - 4:55pm

A base feature providing a landing page content type and related configuration.

Development is on GitLab and mirrored here.

Categories: Drupal

Better Local Tasks

New Drupal Modules - 15 September 2017 - 2:36pm

Drupal's 'local tasks' tab array doesn't always look great. It can also interfere with the theme when administering content.

This module just adds a bit of polish to the local task tabs, by fixed positioning it and adding some icons, and hover animation.

Categories: Drupal

Flexible Layout

New Drupal Modules - 15 September 2017 - 1:59pm

Provides a dynamic regions for layout discovery that can be output in rows and columns.

Categories: Drupal

Joachim's blog: Brief update on Drupal Code Builder

Planet Drupal - 15 September 2017 - 1:31pm

I've completely revamped the Drush commands for Drupal Code Builder:

  • First, they're now in their own project on Github
  • Second, I've rewritten them completely for Drush 9, completely interactive.
  • Third, they are now geared towards adding to existing modules, rather than generating a module as a single shot. That approach made sense in the days of Drupal 6 when it was just hook implementations, but I increasingly find I want to add a plugin, a service, a form, to a module I've already started.

The downside is that installing these is rather tricky at the moment due to some current limitations in Drush 9 beta; see details in the project README, which has full instructions for workarounds.

Now that's out of the way, I'm pushing on with some new generators for the Drupal Code Builder library itself. On my list is:

  • plugin types (as in the plugin manager service, base class and interface, and declaration for Plugins module)
  • entity type
  • entity type handlers
  • your suggestions in the issue queue...

And of course more unit tests and refactoring of the codebase.

Categories: Drupal

Aten Design Group: Mastering Drupal 8’s Libraries API

Planet Drupal - 15 September 2017 - 9:56am

If you ever had to overwrite a module’s css file or a core javascript library in Drupal 7, you likely remember the experience. And not because it was a glorious encounter that left you teary-eyed at the sheer beauty of its ease and simplicity.

Along with Drupal 8 came the Libraries API and a whole new way of adding CSS and JS assets and managing libraries. In true Drupal 8 fashion, the new system uses YAML files to grant developers flexibility and control over their CSS and JS assets. This gives you the ability to overwrite core libraries, add libraries directly to templates, specify dependencies and more.

There are many pros to this approach. The most important improvement being that you can add these assets conditionally. The FOAD technique and other hackish ways to overwrite core CSS files or javascript libraries are long gone. This is extraordinarily good news!

However, the simplicity of the drupal_add_js() and drupal_add_css() functions have also disappeared, and now you have to navigate a potentially overwhelming and confusing nest of yml’s just to add some custom CSS or javascript to a page. (No, you can’t just add css via the theme’s .info file). In this post, I’ll guide you through the new Libraries API in Drupal 8 so you can nimbly place assets like you’ve always dreamed.

Prerequisites

If you haven’t yet experienced the glory that is the yml file, you’ll want to get familiar. Read this great introduction to YAML then come back to this post.

Creating Libraries

First step is to create your libraries.yml file at your-theme-name.libraries.yml or your-module-name.libraries.yml.

Here’s an example of how you define a Drupal 8 library.

A few things to note:

  • The path to CSS and JS files are relative to the theme or module directory that contains the libraries.yml file. We’ll cover that in more depth shortly.
  • The dependencies, in this case jQuery, are any other library your library depends on. They will automatically be attached wherever you attach your library and will load before yours.
  • Multiple libraries can be defined in one libraries.yml file, so each library in the file must have a unique name. However the libraries will be namespaced as mytheme/mylibrary or mymodule/mylibrary so a libraries.yml file in your theme and libraries.yml file in your module can contain libraries with the same name.
  • The css files are organized according to the SMACSS categories. This gives some control over the order of which assets are added to your page. The css files will be added according to their category. So any css file in the theme category will be added last, regardless of whether or not it comes from the base theme or the active child theme. Javascript files are not organized by SMACSS category.

Now that you know the library basics, it’s time to up the ante.

Properties

You can add additional properties inside the curly braces that allow you to define where the javascript is included, additional ordering of files, browser properties and more. We won’t cover all the possibilities just now, but here are some examples

Attaching Libraries

The simplest way to attach libraries globally is through the your-theme-name.info.yml file. Instead of adding stylesheets and scripts ala Drupal 7, you now attach libraries like so:

Global is great and all, but perhaps the coolest libraries upgrade in Drupal 8 is the ability to attach libraries via twig templates. For example, if you have a search form block, you can define the css and js for the block, add it to a library, and add that library to the search form block twig template. Those assets specific to the search form block will only be included when the block is rendered.

And yes, you can also attach libraries with our ol’ pal php.

Extending and Overriding Libraries

Another boon is the ability to extend and override libraries. These extensions and overrides take place in the your-theme-name.info.yml file.

As you might expect, libraries-extend respects the conditions of the library is being extended. Maybe you have a forum module that comes with css and js out-of-the-box. If you want to tweak the styling, you can extend the forum modules library, and add your own css file.

For overrides, you can remove or override a specific file or an entire library.

Final Considerations

Before we wrap up, I'll send you on your way with a couple final considerations and gotcha's that you need to be aware of.

  • The Libraries API Module is still relevant in Drupal 8, and should be used to handle external libraries that don't ship with drupal or a module or theme. It also allows libraries to be used by multiple modules or sites.
  • If a file is already linked to within a library it won't get added a second time.
  • Module CSS files are grouped before theme CSS files, so a module's css file will always be loaded before a theme's css file.
  • Refer to the Drupal 8 Theming Guide for more info.

Thanks for reading. Now go forth and use your asset placing powers for good, not evil.

Categories: Drupal

DrupalCon News: Novice Contributor Sprints at DrupalCon Vienna

Planet Drupal - 15 September 2017 - 9:47am
Everyone is welcome (including you!)

With just about two weeks to go until DrupalCon Vienna we are anticipating an amazing week of learning and collaborating ahead! There will be code sprints all week, but Friday is our dedicated sprint day when anyone and everyone can come contribute to Drupal core and participate together in guided sprints.

Categories: Drupal

Don't blame open-source software for poor security practices

Dries Buytaert - 15 September 2017 - 7:28am

Last week, Equifax, one of the largest American credit agencies, was hit by a cyberattack that may have compromised the personal data of nearly 143 million people, including name, address, social security numbers, birth dates and more. The forfeited information reveals everything required to steal someone's identity or to take out a loan in someone else's name. Considering that the current US population is 321 million, this cyberattack is now considered to be one of the largest and most intrusive breaches in US history.

It's Equifax that is to blame, not open-source

As Equifax began to examine how the breach occurred, many unsubstantiated reports and theories surfaced in an attempt to pinpoint the vulnerability. One such theory targeted Apache Struts as the software responsible for the breach. Because Apache Struts is an open-source framework used for developing Java applications, this resulted in some unwarranted open-source shaming.

Yesterday, Equifax confirmed that the security breach was due to an Apache Struts vulnerability. However, here is what is important; it wasn't because Apache Struts is open-source or because open-source is less secure. Equifax was hacked because the firm failed to patch a well-known Apache Struts flaw that was disclosed months earlier in March. Running an old, insecure version of software — open-source or proprietary — can and will jeopardize the security of any site. It's Equifax that is to blame, not open-source.

The importance of keeping software up-to-date

The Equifax breach is a good reminder of why organizations need to remain vigilant about properly maintaining and updating their software, especially when security vulnerabilities have been disclosed. In an ideal world, software would update itself the moment a security patch is released. WordPress, for example, offers automatic updates in an effort to promote better security, and to streamline the update experience overall. It would be interesting to consider automatic security updates for Drupal (just for patch releases, not for minor or major releases).

In absence of automatic updates, I would encourage users to work with PaaS companies that keep not only your infrastructure secure, but also your Drupal application code. Too many organizations underestimate the effort and expertise it takes to do it themselves.

At Acquia, we provide customers with automatic security patching of both the infrastructure and Drupal code. We monitor our customers' sites for intrusion attempts, DDoS attacks, and other suspicious activity. If you prefer to do the security patching yourself, we offer continuous integration or continuous delivery tools that enable you to get security patches into production in minutes rather than weeks or months. We take pride in assisting our customers to keep their sites current with the latest patches and upgrades; it's good for our customers and helps dispel the myth that open-source software is more susceptible to security breaches.

Categories: Drupal

Dries Buytaert: Don't blame open-source software for poor security practices

Planet Drupal - 15 September 2017 - 7:28am

Last week, Equifax, one of the largest American credit agencies, was hit by a cyber attack that may have compromised the personal data of nearly 143 million people, including name, address, social security numbers, birthdates and more. The forfeited information reveals everything required to steal someone's identity or to take out a loan on someone else's name. Considering that the current US population is 321 million, this cyberattack is now considered to be one of the largest and most intrusive breaches in US history.

It's Equifax that is to blame, not open-source

As Equifax began to examine how the breach occurred, many unsubstantiated reports and theories surfaced in an attempt to pinpoint the vulnerability. One such theory targeted Apache Struts as the software responsible for the breach. Because Apache Struts is an open-source framework used for developing Java applications, this resulted in some unwarranted open source shaming.

Yesterday, Equifax confirmed that the security breach was due to an Apache Struts vulnerability. However, here is what is important; it wasn't because Apache Struts is open-source or because open-source is less secure. Equifax was hacked because the firm failed to patch a well-know Apache Struts flaw that was disclosed months earlier in March. Running an old, insecure version of software — open-source or proprietary — can and will jeopardize the security of any site. It's Equifax that is to blame, not open-source.

The importance of keeping software up-to-date

The Equifax breach is a good reminder of why organizations need to remain vigilant about properly maintaining and updating their software, especially when security vulnerabilities have been disclosed. In an ideal world, software would update itself the moment a security patch is released. Wordpress, for example, offers automatic updates in an effort to promote better security, and to streamline the update experience overall. It would be interesting to consider automatic security updates for Drupal (just for patch releases, not for minor or major releases).

In absence of automatic updates, I would encourage users to work with PaaS companies that keep not only your infrastructure secure, but also your Drupal application code. Too many organizations underestimate the effort and expertise it takes to do it themselves.

At Acquia, we provide customers with automatic security patching of both the infrastructure and Drupal code. We monitor our customers sites for intrusion attempts, DDoS attacks, and other suspicious activity. If you prefer to do the security patching yourself, we offer continuous integration or continuous delivery tools that enable you to get security patches into production in minutes rather than weeks or months. We take pride in assisting our customers to keep their sites current with the latest patches and upgrades; it's good for our customers and helps dispel the myth that open-source software is more susceptible to security breaches.

Categories: Drupal

Don't blame open-source software for poor security practices

Dries Buytaert - 15 September 2017 - 7:28am

Last week, Equifax, one of the largest American credit agencies, was hit by a cyber attack that may have compromised the personal data of nearly 143 million people, including name, address, social security numbers, birthdates and more. The forfeited information reveals everything required to steal someone's identity or to take out a loan on someone else's name. Considering that the current US population is 321 million, this cyberattack is now considered to be one of the largest and most intrusive breaches in US history.

It's Equifax that is to blame, not open-source

A security breach of this scale warrants serious concern. As Equifax began to examine how the breach occurred, many unsubstantiated reports and theories surfaced in an attempt to pinpoint the vulnerability. One such theory targeted Apache Struts as the software responsible for the the breach. Because Apache Struts is an open-source framework used for developing Java applications, this resulted in some unwarranted open source shaming.

Yesterday, Equifax confirmed that the security breach was due to an Apache Struts vulnerability. However, here is what is important; it wasn't because Apache Struts is open-source or because open-source is less secure. Equifax was hacked because the firm failed to patch a well-know Apache Struts flaw that was disclosed months earlier in March. Running an old, insecure version of software — open-source or proprietary — can and will jeopardize the security of any site. It's Equifax that is to blame, not open-source.

The importance of keeping software up-to-date

The Equifax breach is a good reminder of why organizations need to remain vigilant about properly maintaining and updating their software, especially when security vulnerabilities have been disclosed. In an ideal world, software would update itself the moment a security patch is released. Wordpress, for example, offers automatic updates in an effort to promote better security, and to streamline the update experience overall. It would be interesting to consider automatic security updates for Drupal (just for patch releases, not for minor or major releases).

In absence of automatic updates, I would encourage users to work with PaaS companies that keep not only your infrastructure secure, but also your Drupal application code. Too many organizations underestimate the effort and expertise it takes to do it themselves.

At Acquia, we provide customers with automatic security patching of both the infrastructure and Drupal code. We monitor our customers sites for intrusion attempts, DDoS attacks, and other suspicious activity. If you prefer to do the security patching yourself, we offer continuous integration or continuous delivery tools that enable you to get security patches into production in minutes rather than weeks or months. We take pride in assisting our customers to keep their sites current with the latest patches and upgrades; it’s good for our customers and helps dispel the myth that open-source software is more susceptible to security breaches.

Categories: Drupal

CiviCRM Blog: CiviCon UK Sponsor post: Registrations in seconds, logins without passwords

Planet Drupal - 15 September 2017 - 5:39am

A big thank you to all our CiviCON UK Sponsors. Here's a special post from Gold Sponsor Yoti:

Doing things differently: Registrations in seconds, logins without passwords and minimising data.

Over the last 15 years I’ve probably been responsible for around 50 or so websites or microsites that in some way or another have tried to gather people’s data.  Either to enter into an event, join a forum or buy something.  And like most other marketeers I’ve been obsessed by two things.  Funnels and Data. i.e how easily are people signing up and how much do I now know about my customers.  I’ve always known that by asking people for more information there was a danger people would drop out of my acquisition funnel but we marketeers are hungry for data. We want it all and we want it now.

I’ve now come to realise that less is more.  I still want the customers, and loads of them, but I want them to join me on their terms. If I ask people less about themselves I’m more likely to get an answer. 

I always try to liken marketing situations with personal situations.  When you first meet someone in a bar you don’t tend to ask them everything about themselves in the first sentence.  You might introduce yourself and ask them their name.  And perhaps ask them where they’re from.  You certainly wouldn’t ask their address or birthday.  If you did, you can be fairly sure they’d either not tell you or they’d give you a fake one and then avoid you for the rest of the night.  So why do we do it in business?  

So we can send them emails they’ll never read?  Send them mail that’ll clog up their recycling bin. Profiling our user base?  Most businesses can’t afford this kind of wastage.  We can’t afford to be sending emails that damage our brand by clogging up people’s inboxes or sending people mail that costs us thousands of pounds.  And just how much effective user profiling can be done if the data they are giving us isn't actually real in the first place?

I want to suggest a revolutionary new idea.  Why not just ask for less, just their first name? Or maybe, not even ask them anything at all. Imagine if you could give them access to a secure user profile on your website even though you didn't even have a name or email address for them.  And they could return to that profile whenever they want to tell you a bit more about themselves. Imagine if you could give them a special key to your world.

A special key?  What like a password?  Surely not...No, not like a password.  Just let them use their phone and their biometrics.  Let them then build their trust with you by adding more details when they want to.  When they need to.  Let them feel special by showing them all the awesome stuff they can now see that nobody else can, and then when you need their address to send them something they've bought you can ask for it.  You could even give them the option of giving you their phone number or email so you can tell them when you’ve got something new and cool to sell. Or you could just say ‘come and stop by whenever you fancy. You’ve got the keys and you can’t lose them so come and have a browse whenever you fancy it.’

It feels a little scary doesn't it? Having anonymous customers that are in control of what information they give you and when.  But there's also all sorts of other interesting stuff it means you could do. You can create chat forums where people just prove they are from a certain city but otherwise remain anonymous.  You could build web forums for children that only allowed people under a certain age or over another age to register.

However, I know there are plenty of us who do actually need all the data up front, just because that’s how business works and it may take a while for my utopian customer-centric world to exist.  And plenty of businesses need to be absolutely sure they have the right name and address to eliminate fraud that’s costing us billions of pounds every year.

But these businesses still want to get people signed up quickly and they’re still scared about getting their data hacked.  And a lot of businesses do end up giving their customers passwords, which their customers usually forget.

We created Yoti to try and let people and businesses do all of the above. We want to encourage businesses to ask for less, but give you the confidence people are who they claim to be.  We want to make it frictionless for you to sign up new verified customers. We don't want anyone to ever hate your website just because they forgot their password.

Yoti is an easy to use digital identity app for consumers and secure digital identity attribute exchange platform for organisations. Our phones help us connect, make payments and board planes, it’s time that they helped us prove our identity.

People create their Yoti by downloading our free app, prove they’re a real person and match their selfie to their passport or driving licence photo. In less than 5 minutes, out pops their verified digital identity that they control for life. Yoti uses AES 256 encryption to store and share user data in such a way that only they have access to their personal details. Yoti cannot see or access any personal information once the accounts have been verified.

Once people have Yoti they can then prove any element of their identity in seconds to businesses and organisations that accept Yoti.  They simply scan a QR code if they are on a desktop, or press ‘Use Yoti’ if on their mobile.  They’ll then be told what information is being requested and they allow the information to be shared.  Registered in seconds.  They can then log back in using their Yoti. No password is required meaning they’ll never forget them and the business need never worry about whether or not they chose a secure password.  

We are building an ecosystem of places where people can use Yoti in their everyday life. They will use Yoti to prove their age at the supermarket self checkout, apply for jobs online, sign up to new web services, prove their age on nights out instead of having to carry their passport.

We’re in our ‘pre-launch’ phase at the moment (we launch in November) but people seem interested.  Over 65,000 people have installed the app already and some great businesses and organisations like Reed, Worldpay and NSPCC are already working with Yoti.

To make it as easy as possible for businesses and organisations to use Yoti we've developed a number of SDKs in seven different coding languages and plugins for Wordpress and Drupal 7, with Joomla and Drupal 8 in development right now.

If you'd like to find out more about Yoti please visit www.yoti.com

ArchitectureCiviConDrupal
Categories: Drupal

Error & Exception Mailer

New Drupal Modules - 15 September 2017 - 5:33am

A simple Drupal module to handle error reporting on site wide exceptions.

Administrators are emailed when an exception or fatal error occurs.

Categories: Drupal

aleksip.net: More thoughts on the Drupal upgrade model and Drupal 8.4

Planet Drupal - 15 September 2017 - 5:22am
As I experienced some issues upgrading to Drupal 8.3, I thought I should be more prepared this time, and tried out the Release Candidate version of Drupal 8.4.
Categories: Drupal

Valuebound: How to use Features module in Drupal 8 to bundle functionality in reusable module

Planet Drupal - 15 September 2017 - 5:01am

Features Module has played a significant role in deploying site configuration for Drupal 7. If you’ve ever build a site in Drupal 7, then possibly you have worked with the Features Module. However, CMI in Drupal 8 solved a lot of problems that we faced with Features in Drupal 7. In this blog, we will discuss - Why do we need Features Module in Drupal 8? What is the use of it? We will also attempt to export photo gallery feature.

Let’s take a use-case where you are working on a media and publishing company project and your client wants a feature of ‘…

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal