Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 7 hours 24 min ago

Agiledrop.com Blog: Keeping control of your project when outsourcing software development

Wed, 12/02/2020 - 10:25

In this article, we discuss the importance and different options of keeping control of your project when outsourcing development.

READ MORE

Lucius Digital: Using Drupal and Bootstrap HTML? An easy snippet for great Toasts instead of boring Drupal messages :)

Wed, 12/02/2020 - 09:47
So we wanted to implement the great Bootstrap Toasts feature in our social productivity Drupal distro OpenLucius. HTML framework Bootstrap provides Toasts out of the box. After some trial and error, the end result seems fairly easy to use for everybody. So here is how:

Promet Source: Visual Impact and Great UX for High-Stakes Objectives

Wed, 12/02/2020 - 00:55
Early in 2020, as COVID-19 began to seize headlines, counties throughout California were on the front lines as “hotspots,” and citizens of Marin County were paying close attention. 

Lullabot: Lullabots Speaking at DrupalCon Europe 2020

Tue, 12/01/2020 - 20:59

DrupalCon Europe is happening December 8-11, helping us close out a challenging 2020. Like DrupalCon Global, this will be a virtual conference.

We're excited to announce the Lullabots who will be presenting.

Specbee: A Brief Guide to Node Package Manager (NPM) in Drupal

Tue, 12/01/2020 - 15:55
A Brief Guide to Node Package Manager (NPM) in Drupal Shruthi Shetty 01 Dec, 2020 Top 10 best practices for designing a perfect UX for your mobile app

Node Package Manager (NPM) is an open-source software library that has over 800,000 code packages. In simple terms, we can say that NPM is a command-line tool that installs, updates, or uninstalls node.js packages of an application.

Installation

Inside the project theme folder, directly run the npm install command. It will install all the packages that are there in the package.json file.
Once done, you can verify the NPM installation by writing the following command in the command prompt. This will show you the version of the NPM.

npm -v

If you have older version of NPM then you can update it to the latest version using this command:

npm install npm -g

We can use NPM in two different modes: Global and Local mode.
Global mode - It performs operations which affects all the Node.js applications on the computer.
Local mode - It performs operations for a particular local directory which affects an application in that directory only.

How to add Dependency into package.json

NPM packages are all defined in one file called package.json. The content inside package.json must be written in JSON format. The two necessary fields in that file are ‘name’ and ‘version’.
The main goal of this is automated dependency and package management. Here, you can specify all your project/application dependencies within the package.json file.

Here “test” is the name of the Project and version number is given as “1.0.0”.

The dependency packages that are required for “test” project are : Bootstrap, gulp and gulp-sass along with their versions.

Run the below command in the terminal to install the node modules inside your project theme folder.  

npm install

Once you run this command, all the dependency modules will get installed.

Inside the node_modules folder you will see the dependency modules that get installed.

Gulp is a task runner. It can do many things. It uses the JavaScript code and helps run front-end tasks for large scale web applications. It also builds system automated tasks like CSS preprocessing, HTML minification, concatenating library files, compiling the SASS files, and more. Here we are using Gulp to convert .scss files into .css.

Inside the gulpfile.js we are going to assign the tasks that can be done by Gulp.

When using functionalities that are not Drupal, we need to import the CSS or JS files with respect to that module as a library in theme_name.libraries.yml. Next, we need to call the library with respect to that particular twig file to see the required changes. 
This way we can use other NPM packages like slick-carousel, responsive tabs etc. to your project using this command:

This way we can use other NPM packages like slick-carousel, responsive tabs etc. to your project using this command:

npm install

Use this command to update the packages:

C:\MyNodeProj> npm update


To uninstall the package, use this command:

C:\>npm uninstall

Node Package Manager is a very useful tool for developers to automate a lot of front-end tasks. It lets you install and play around with tons of third-party libraries to run difficult and time-consuming tasks. In this brief guide we have discussed about NPM installation and the usage of Gulp in Drupal. If you found this blog useful, don’t forget to sign up to our newsletter so you don’t miss out on our latest insights by our Drupal experts.

Drupal Planet Drupal Module Drupal Development Drupal Tutorial Shefali ShettyApr 05, 2017 Subscribe For Our Newsletter And Stay Updated Subscribe

Leave us a Comment

  Shefali ShettyApr 05, 2017 Recent Posts Image A Brief Guide to Node Package Manager (NPM) in Drupal Image How to Migrate to Drupal 8 from a SQL source in 6 Simple Steps Image How to Configure Faceted Search for Drupal 8 (and 9) – An easy step-by-step tutorial Want to extract the maximum out of Drupal? TALK TO US Featured Success Stories

Know more about our technology driven approach to recreate the content management workflow for [24]7.ai

link

Find out how we transformed the digital image of world’s largest healthcare provider, an attribute that defined their global presence in the medical world.

link

Discover how a Drupal powered internal portal encouraged the sellers at Flipkart to obtain the latest insights with respect to a particular domain.

link

ADCI Solutions: Why upgrade PHP: a guide without complicated explanations

Tue, 12/01/2020 - 12:32

PHP 8 is here! But we bet that many of the Drupal websites you’ve been working on haven’t even upgraded to PHP 7.4 yet. Meanwhile, upgraded software is a great deal when it comes to security and performance. 

We've prepared the article with short and clear explanations about the necessity of updates and the update process itself.

Read Why upgrade PHP

 

Drupal core announcements: Feedback needed: Dropping support for Internet Explorer 11 in Drupal 10

Mon, 11/30/2020 - 13:25

We are currently planning for Drupal core to drop support for Internet Explorer 11 in Drupal 10 (scheduled to be released in June 2022). Drupal 9 will be supported until late 2023, which means that sites that want to support Internet Explorer 11 can continue using Drupal 9 until then.

Feedback needed from assistive technology stakeholders

WebAIM's survey of screen reader users shows Internet Explorer 11 usage dropping from 23.3% in October 2017 to 10.9% in September 2019. The next edition of their survey is likely to be released at the end of 2021, but we need to finalize our browser support within the next month in order to develop and release Drupal 10 on schedule.

We need feedback from assistive technology users and accessibility stakeholders. Do you or your users still use Internet Explorer 11 with screen readers? Do their screen readers support browsers other than Internet Explorer 11? How feasible is it to upgrade to a different browser for use with your screen reader? We are requesting feedback until December 18th, 2020.

Why would we drop support for Internet Explorer 11?
  • Microsoft stopped developing Internet Explorer 11 in 2015. For that reason it is significantly behind modern browsers that have continued development. Because more and more libraries are adopting the use of those features, there is a significant cost associated with maintaining Internet Explorer 11. For example, the latest major release of CKEditor has dropped support for Internet Explorer 11, which means that Drupal 10 cannot securely support both CKEditor5 and Internet Explorer 11.

  • Microsoft itself has dropped support for Internet Explorer 11 in many of its services, and the rest will drop support in mid-2021.

  • Usage of Internet Explorer 11 has decreased significantly. Drupal doesn’t collect analytics on browser usage from its end users, so we rely on data provided by other projects such as Wikimedia, WebAIM, and Statcounter. For example, in October 2019, Wikimedia had 4.4% of its traffic using Internet Explorer 11. At the same time this year the number had dropped to 1.4%. We assume that the number of Internet Explorer 11 users will continue decreasing before the release of Drupal 10.

  • Supporting Internet Explorer 11 degrades the experience for everyone. We currently supply all users extra code to make Internet Explorer 11 work. This increases the request size and makes page load time slower for everyone.

  • The additional requirements of Internet Explorer 11 demand additional development time that far exceeds the browser's market share. These efforts come at the expense of new features and bug fixes.

What if I need to support Internet Explorer 11?

Even if Drupal 10 drops support for Internet Explorer 11, you can continue using Drupal 9 until late 2023. We recommend advising your users to move to another browser before that. If you believe your users have specific requirements as to why they cannot move from Internet Explorer 11, post them on the Internet Explorer 11 policy discussion.

Would this affect Drupal 7?

No. Drupal 7 remains compatible with Internet Explorer 11. A separate announcement will be issued if that changes.

Drupal Core News: Feedback needed: Dropping support for Internet Explorer 11 in Drupal 10

Mon, 11/30/2020 - 13:25

We are currently planning for Drupal core to drop support for Internet Explorer 11 in Drupal 10 (scheduled to be released in June 2022). Drupal 9 will be supported until late 2023, which means that sites that want to support Internet Explorer 11 can continue using Drupal 9 until then.

Feedback needed from assistive technology stakeholders

WebAIM's survey of screen reader users shows Internet Explorer 11 usage dropping from 23.3% in October 2017 to 10.9% in September 2019. The next edition of their survey is likely to be released at the end of 2021, but we need to finalize our browser support within the next month in order to develop and release Drupal 10 on schedule.

We need feedback from assistive technology users and accessibility stakeholders. Do you or your users still use Internet Explorer 11 with screen readers? Do their screen readers support browsers other than Internet Explorer 11? How feasible is it to upgrade to a different browser for use with your screen reader? We are requesting feedback until December 18th, 2020.

Why would we drop support for Internet Explorer 11?
  • Microsoft stopped developing Internet Explorer 11 in 2015. For that reason it is significantly behind modern browsers that have continued development. Because more and more libraries are adopting the use of those features, there is a significant cost associated with maintaining Internet Explorer 11. For example, the latest major release of CKEditor has dropped support for Internet Explorer 11, which means that Drupal 10 cannot securely support both CKEditor5 and Internet Explorer 11.

  • Microsoft itself has dropped support for Internet Explorer 11 in many of its services, and the rest will drop support in mid-2021.

  • Usage of Internet Explorer 11 has decreased significantly. Drupal doesn’t collect analytics on browser usage from its end users, so we rely on data provided by other projects such as Wikimedia, WebAIM, and Statcounter. For example, in October 2019, Wikimedia had 4.4% of its traffic using Internet Explorer 11. At the same time this year the number had dropped to 1.4%. We assume that the number of Internet Explorer 11 users will continue decreasing before the release of Drupal 10.

  • Supporting Internet Explorer 11 degrades the experience for everyone. We currently supply all users extra code to make Internet Explorer 11 work. This increases the request size and makes page load time slower for everyone.

  • The additional requirements of Internet Explorer 11 demand additional development time that far exceeds the browser's market share. These efforts come at the expense of new features and bug fixes.

What if I need to support Internet Explorer 11?

Even if Drupal 10 drops support for Internet Explorer 11, you can continue using Drupal 9 until late 2023. We recommend advising your users to move to another browser before that. If you believe your users have specific requirements as to why they cannot move from Internet Explorer 11, post them on the Internet Explorer 11 policy discussion.

Would this affect Drupal 7?

No. Drupal 7 remains compatible with Internet Explorer 11. A separate announcement will be issued if that changes.

Web Omelette: New Drupal module: multi-value form elements

Mon, 11/30/2020 - 10:04

In this short article I want to introduce you to a new module we recently released on Drupal.org, namely Multi-value form element.

This small module provides a form element that allows you to easily define multi-value elements in your custom forms. Much like what field widgets provide with the Add another item Ajax button.

So how does it work? Easy, really. All you have to do is define a form element of the '#type' => 'multivalue' with one or more children, defined like you normally would. So for example:

$form['names'] = [ '#type' => 'multivalue', '#title' => $this->t('Names'), 'name' => [ '#type' => 'textfield', '#title' => $this->t('Name'), ], ];

Would give you this:

And you can also use multiple form element children if you want:

$form['contacts'] = [ '#type' => 'multivalue', '#title' => $this->t('Contacts'), 'name' => [ '#type' => 'textfield', '#title' => $this->t('Name'), ], 'mail' => [ '#type' => 'email', '#title' => $this->t('E-mail'), ], ];

So as you can see, no big deal to use. But all the complex Ajax logic of adding extra values is out of your hands now and can easily build nice forms.

Check out some more examples of how to use this element and what options it has above the Drupal\multivalue_form_element\Element\MultiValue class.

This module is sponsored by the European Commission as part of the OpenEuropa initiative and all the work my colleagues and myself are doing there.

Yusef Blog: Auto Deploy a project with leveraging gitlab CI/CD

Sun, 11/29/2020 - 21:40
A few days ago Github again, prevents access to my personal private project on Github because I visited my home country last year. I decided to move my private repositories from Github to Gitlab. after migrating my project I noticed I haven't work with Gitlab for a long time and during this time it has added a lot of tools. like Bitbucket and Github it server very convenient CI/CD development that developers easily deploy their projects to servers without any cover.

Droptica: Users, Roles and Permissions in Drupal - the Most Important Informations for a Drupal Developer

Fri, 11/27/2020 - 12:57

Drupal is being chosen as a platform for building websites, among other things, due to its flexibility. If you want a system ideally suited to your business model and better than the competition's systems, Drupal will prove to be perfect. One of the areas you can customise in Drupal is the user permissions system. Take a few minutes to learn about the permission management abilities of Drupal.

General information

Drupal allows you to manage access from the admin panel and from the code level. In this post, I will present these two possibilities and the most common examples of their use.

Roles and permissions in the Drupal core

If this is your first time dealing with Drupal and its permission system, you should know that there are three elements used for granting permissions:

  1. User
  2. Role
  3. Permission

When installing Drupal, you create a root administrator account in the system (identifier 1 in the database). It can be compared to the root user in Unix systems. This user has access to all subpages and settings in the system.

You can add more users to the system. These could be, e.g. the editors responsible for creating the content, or the moderators deciding whether to post the added comments.

If you want to assign a permission to a given user, you do it indirectly by assigning a role to them. There is no association between a user and permissions in Drupal. There is a user-role association and a role-permission association.

How to add an editor role and assign the appropriate permissions to it

This is probably the most common issue encountered in Drupal. You need to let users into your system, but you want to limit their rights to the content management only. You do not want to give the rights to change the system configuration or to add new users.

In order to achieve this, follow these steps:

  1. Add a new role on the page "/admin/people/roles/add/".
  2. Assign the selected permissions to the role on the page "/admin/people/permissions/". For the content-related ones, check out the "Node" section. Below you can find more information on the permission list.
  3. Assign the selected user to the new role on the page "/admin/people/".

Then log-in into the account of the selected user and check out whether they have the appropriate permissions. Maybe you need to extend them or take them away. If you are unfamiliar with the Drupal's permission system, such a test with logging-in into the user account is always worth carrying out.

You do not need to know the password to the user account you want to log-in into. You just need to install the module Masquerade. Thanks to it, you can log-in into the account of any user.

Drupal core permissions overview

When entering the page "/admin/people/permissions/" for the first time, one can get a little scared. This is probably the longest configuration page in Drupal.

Let us start with the table header. You will always see the word "PERMISSION" in the first column. In the next cells of the first row, there will be the names of the roles. The more roles you add (you can add them on the page /admin/people/roles/add/), the more of them you will see in this table.

Then, looking at the first column in its entirety, you will see a long list of permissions. The permissions are divided into sections. The sections are the names of modules. The "Node" section mentioned earlier is named so because the permissions in this section are defined in the "node" module (you will find it on your disk in the core/modules/node directory).

Some sections have only one permission, e.g. the "Block" section has the "Administer blocks" permission only. Others have many more of them.

If this is your first time dealing with Drupal permission settings, I suggest that you read the names of all permissions. The names themselves explain what a given permission is for.

Anonymous & Authenticated

There are two system roles in Drupal that cannot be removed:

  1. Anonymous User
  2. Authenticated User

The first of these roles is responsible for all non-logged-in users. For example: if you want to add the ability to view user profiles for all non-logged-in for the "View user information" permission, tick the checkbox in the "Anonymous User" column.

"Authenticated User" is the role assigned to all logged-in users. It is important here to understand the permission inheritance. If you assign a permission to "Authenticated User", then all other roles (except anonymous) will be given this permission immediately.

Example: You have the "Editor" role in the system. You assign the "View user information" permission to the "Authenticated User" role. Everyone with the "Editor" role will also be given the permission because they are also considered to be logged-in users.

Moreover, keep in mind that if you select any permission for the Anonymous role (e.g. "View user information" again), but do not select it for the "Authenticated User", the logged-in users will not be able to access the selected section ("View user information" – they will not have access to user profiles).

Worth remembering
  • In Drupal, you can add an unlimited number of roles.
  • The list of permissions is defined by modules in modulename.permissions.yml files (more on this can be found further in the text). 
  • The "Authenticated" and "Anonymous" roles are separate – if you select something for "Anonymous" only, the logged-in users will not be given this permission.
  • To test permissions, it is good to use the Masquerade module.
Own permissions in the code

Sometimes there is a need to define your own permissions, e.g. to administration pages defined by new modules or to modify access to the pages defined by the Drupal core.

How to define a permission

You just need to add the modulename.permissions.yml file in the new module (or in the existing one, if you already have your own modules created). If you do not know how to create your own modules, I encourage you to visit the website.

The permission file is a file in the YML format. A simple example can be found in the Popup Message module, right here.

Being defined in the file is a unique name for the permission (e.g. "popup message administration"), and then – the names being displayed on the page "/admin/people/permissions/". You can provide a title in the "title" parameter and additionally – a more detailed description in the "description" parameter.

This is enough to define new permissions. After creating the file and clearing the cache, you will see the new permissions on the "/admin/people/permissions/" page.

How to use a permission

Most often, permissions are being used when defining routing. Take a look at the file.

In the "requirements" section, you can add the "permission" parameter. In this way, you can define the users (or rather roles) with what permission can display the page defined in routing.

The second method is to check out the permissions in your code. User object in Drupal has the "hasPermission" method. In this way, you can check out whether a given user has the selected permission.

// Get the current user $user = \Drupal::currentUser(); // Check for permission if ($user->hasPermission('display popup message')) { // Do something. }

It is worth to take a look at the hasPermission method here. As you can see, the user ID is being checked there. If the id equals 1, the user gets access without further checking if they have selected roles.

How to check whether the user has a role

Drupal also offers a ready-made method to check whether a given user has a role with a specific name. Provided below is an example of how you can do it in the code.

// Get the current user $user = \Drupal::currentUser(); // Check for permission if ($user->hasRole('editor')) { // Do something. }

Additionally, there are also methods related to the Authenticated and Anonymous roles:

  • $user-> isAuthenticated();
  • $user-> isAnonymous();
How to check permissions for operations on an entity

In the application code, you can also check the permissions to operate on selected entities (e.g. Node or User). You can perform certain operations, e.g. depending on whether the user has the right to edit a given entity or to display an entity.

Entities in Drupal have the method access($operation = 'view', AccountInterface $account = NULL, $return_as_object = FALSE). A simple example of use is provided below:

$nid = 545; $node = \Drupal\node\Entity\Node::load($nid); $user = \Drupal::currentUser(); if ($node->access('edit', $user)) { // Do something } Defining content permissions

Drupal allows you to manage access to display and edit at the level of a single entry (node). This topic was thoroughly described in our other blog post. Grzegorz Pietrzak described it in the article Drupal Node grants.

Ready-made modules for Drupal related to permissions

There are already many ready-made modules extending the capabilities of the Drupal core. You should check them out before you start writing your own permission-related modules.

Below is a list of a few selected modules that are worth checking out and testing:

Also, check the page and take a look at other modules. Maybe some of them you will find useful.

Summary

Drupal is a very flexible system. Just looking at the possibilities regarding permissions, you can see the multitude of configuration possibilities. If you are building a large website with many editor levels or an internal application (e.g. an intranet system) where the users must have limited permissions, Drupal will do the job very well.

If you need support from Drupal specialists on permissions or other issues, use the services of our Drupal developers.

Sooper Drupal Themes: Evaluate our Drupal layout builder now with our new and improved demo site!

Fri, 11/27/2020 - 10:39

We just launched a new free demo on try.dxpr.com that lets you test drive the DXPR Drupal experience. Thanks to our 60+ new demo pages you will be guided to explore the many exciting elements and features that are offered in our DXPR Builder and DXPR Builder Enterprise modules for Drupal 9.

The new demo takes it to the next level: our demo site is based on Acquia Lightning and shows you the extent of Drupal integration of our front-end layout building application. Learn how our state-of-the-art visual authoring experience seamlessly integrates with Drupal’s multilingual features, workflow processes, and views.

Take me to the free demo New minor release for DXPR Builder

Today we release a new minor version update for both our Drupal 7 and Drupal 9 branches of DXPR Builder. Most notably we now have improved native support for media entities in DXPR Builder.

Whether you are on Acquia Lightning or a completely custom Drupal 9 platform, if you upload or re-use images in the DXPR Builder editor our software will automatically detect if your site supports media entities or just file entities, and create media entities when this is supported.

What's next? Bootstrap 4 support!

The DXPR team is working hard to bring our products up to date with Bootstrap 4. This is a large migration for us since our Drupal layout builder is based on and built around Bootstrap 3.

We aim to have a release out that takes full advantage of Bootstrap 4's new features. We will also be able to improve the layout building experience by taking advantage of CSS flexbox technology, which is fully supported in Bootstrap 4.

Security advisories: Drupal core - Critical - Arbitrary PHP code execution - SA-CORE-2020-013

Thu, 11/26/2020 - 00:57
Project: Drupal coreDate: 2020-November-25Security risk: Critical 18∕25 AC:Complex/A:User/CI:All/II:All/E:Exploit/TD:UncommonVulnerability: Arbitrary PHP code executionCVE IDs: CVE-2020-28949CVE-2020-28948Description: 

The Drupal project uses the PEAR Archive_Tar library. The PEAR Archive_Tar library has released a security update that impacts Drupal. For more information please see:

Multiple vulnerabilities are possible if Drupal is configured to allow .tar, .tar.gz, .bz2 or .tlz file uploads and processes them.

To mitigate this issue, prevent untrusted users from uploading .tar, .tar.gz, .bz2 or .tlz files.

This is a different issue than SA-CORE-2019-12, similar configuration changes may mitigate the problem until you are able to patch.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage.

According to the regular security release window schedule, November 25th would not typically be a core security window. However, this release is necessary because there are known exploits for one of core's dependencies and some configurations of Drupal are vulnerable.

Reported By: Fixed By: 

drunomics: Nuxt.js - The frontend framework for decoupled Drupal with Custom Elements

Wed, 11/25/2020 - 21:53

In my first blog post, I introduced the Custom Elements module: A solution for soft-decoupled Drupal! Following that, I want to put more emphasize on the frontend side of the stack in this blog post:

Selecting a frontend framework

With the backend producing custom elements markup, we need a frontend framework that is able to work with that. While there are many frameworks that play nice with custom elements, we want to pick a well-established solution with a large user base. That way, it's more likely that the framework stays relevant and well maintained on the long term. Also, finding more integrated libraries, learning materials or developers knowing the framework becomes much easier.

According to The State of JavaScript 2019: Front End Frameworks the top 3 frameworks developers have used are React, Vue.js and Angular:

  • Angular has been not liked much by developers that used it and won't be used again by the majority of them (see survey). Besides that, it's provided as a whole MVC framework with lots of things potentially not needed here. So not the best fit.

  • React has a very strong user base, but does not play that well with custom elements. While there are solutions like react-slot, they are not as common and well maintained. Finally, personally I don't like the "Everything is Javascript" approach so much.

  • Vue.js on the other hand, comes with template parsing built-in that is able to render custom elements data easily. Like React, it utilizes a virtual DOM and is well adopted and continuously growing. Finally, the Vue.js single file components are following a template based, web-standard oriented approach.

  • Since web components build upon custom elements, they seem to be the perfect fit. However, they are not, since they are not well adopted and server-side rendering web components is not a well solved issue (yet?).

Vue.js

Thus, Vue.js turns out to be the ideal candidate for our decoupled Drupal stack built upon custom elements. Moreover, I like it for the following:

  • It's approachable and easy to use. It has great documentation and sticks to web standard oriented notations.

  • It comes with a set of incrementable adoptable companion libraries for further needs, like routing or state management.

  • It's fast! It only weighs 20kB gzipped and scores well in rendering benchmarks.

  • Just like Drupal, it's a community backed open-source project, not depending on a single large corporation. Check out the Vue.js team and its sponsors.

Nuxt.js

Once one decides for Vue.js, one quickly stumbles over Nuxt.js - the intuitive Vue framework. It comes with a set of useful conventions - inspirated by Next.js - that make it very easy and enjoyable to get started with development. It provides all necessary setup for Javascript transpilation, CSS processing and improves performance by handling route-based automatic code-spliting or link prefetching. Thankfully, it's following Vue.js principles, thus it emphasizes the ease of use and provides great documentation.

Finally, it's built upon a powerful, modular architecture and allows providing features as re-usable Nuxt.js modules - what makes it a great addition to Drupal. While the number of modules is nowhere comparable to Drupal, there are many useful modules available, like PWA generation, Google Analytics or Tag manager integration, or the usual frontend/CSS framework integrations with Bootstrap, Material UI or Tailwind CSS. Check out the module directory at modules.nuxtjs.org for more.

Nuxt.js deployment options

One of the nice features of Nuxt.js is that it's really easy to deploy your project using various ways, all from the same code-base - just by a different deployment configuration. The options are:

  • Static generation
    Generate a static site and leverage the Jamstack approach for dynamic functionality and content previews.

  • Server Side Rendering
    Render the markup using a Node.js server or Serverless functions.

  • Single Page Application

    Just serve a pre-built Javascript application to users and let the user's browser take over rendering.

That way, one can choose the best suiting deployment target per project. Small sites without a large number of pages could be very easily statically generated and benefit from fast, cheap and secure hosting; e.g. via providers like Netlify, Amazon S3 or Github pages. If SEO is not required, running as a Single Page application does away the need for re-building after content changes and allows for highly dynamic, user-specific content and app-like UIs.

More demanding projects, requiring SEO and having a large number of content, can use server side rendering with any Node.js compatible hosting provider like Platform.sh or Heroku. Alternative options would be specialized hosting providers like Vercel, AWS amplify or deploying via the Serverless framework to various serverless cloud providers.

The frontproxy approach

Finally, I'd like to mention we also developed a custom, more advanced approach that becomes possible with custom elements markup: The lupus-frontproxy is a small PHP-based script that serves content as custom element markup combined with a pre-generated app shell (site header and footer). That way, large, content-heavy sites can easily run without a node.js server driving the frontend, while still providing decent SEO based upon the custom element markup delivered (Google just ignores custom elements and indexes the contained markup). However, with the rise of easy and affordable hosting options for server side rendering, such a custom built, uncommon solution seems unnecessary and not really worth the efforts.

Summing up

Nuxt.js is a great framework that makes it really easy to build a Vue.js based frontend application that renders the custom elements markup provided by the Drupal backend. Since each custom element is mapped to a Vue.js component, it's the perfect fit for building up component-based frontends, while keeping the editorial controls in the backend.

Thanks to its flexible deployments options, we can leverage static generation for smaller sites and use server-side rendering for larger, more content-heavy sites.

Following up

Since there are so many details more to talk about, I'll be following up with further blog posts in the coming weeks, covering the following topics:

  • Authentication & related architecture variants. Custom Elements markup & json formats.

  • A developer introduction: Creating components, adding Custom Element processors, the relationship to Drupal's render API, Custom routes and optimizing cache metadata.

  • Handling blocks & layout builder, content previews, forms, caching & performance optimizations.

Finally, I'm going to talk more about this stack at the Drupalcon Europe 2020 in my session "Custom Elements: An alternate Render API for decoupled Drupal" at December 08 - 09:15 - so mark your calendars!

 

 

 

 

Amazee Labs: DrupalCon Europe 2020 – Here We Come!

Wed, 11/25/2020 - 21:12
DrupalCon Europe 2020 is just around the corner and we’re super excited to attend, speak and contribute to this year's virtual event for all things Drupal.

OpenSense Labs: Mistakes to avoid on your drupal website

Wed, 11/25/2020 - 08:50
Mistakes to avoid on your drupal website Gurpreet Kaur Wed, 11/25/2020 - 13:20

Building websites that are completely mistake proof is often considered to be a massive undertaking, which many-many times is not properly executed. Since there are so many parameters to fulfil and so many corners to oversee, mistakes tend to happen. You may not even realise that you have done something wrong in the development process, it could be much much later when you actually undergo a website audit that you come across the mistake that has been made.

Drupal websites are equally prone to mistakes. Despite the CMS being one of the best, there are still occurrences when things go wrong and the impact is felt on the engagement, conversions and consequently, the sales.

To not let that happen, I have compiled a list of mistakes that you need to steer clear of when building or working on a Drupal website. These are errors and oversights that many developers and content authors have experienced first-hand and you can certainly try to learn from their mistakes.

So here are the most common mistakes witnessed on Drupal websites.


Where can you go wrong with the content? 

A good website is often considered to be the one with outstanding content, since that is what keeps the audience engaged and leads to conversion. Therefore, content is crucial for a website, both for the front-end and the back-end, so content should be one of the priorities in the website designing process. Due to this fact, there are a number of areas where the developers can go wrong with the content. 

The first common mistake witnesses with the architecture of content is using too many content types that you actually do not use. The unused content types are just going to burden your database and I am certain, you would not want an additional table in your database for three content types that you do not even use. Having content types with no nodes will have the same effect. Performing an inventory will help you get the mistake resolved.

Moving on from the unused to the used, content structures are extremely valuable for your editors who are going to fill them up and if they end up confused, what will be the point of it all? Standardising your content types is going to help you a great deal. 

  • Strike off the content types that are similar to each other, like news and articles;
  • Do not add new fields for every content type;
  • And most importantly, plan a structure prior to it, winging it may not work with your website content.

Content types have an effect on the performance of your website as well. So, if you do not want to drain the performance of your site by adding unnecessary complexity, you would be wise to avoid these mistakes.

What about your display mismanagement?

After content comes its display and Drupal is best in that game. With many different features available for use, Drupal can make your display game strong as well, you capitalise it wisely.

Creating a view for every list is both impractical and a waste of time. Focus on reusing Views as much as possible along with parameter based rendering.

Do you use PHP code in your database? If so, avoid doing that, instead you must write all the codes in the modules or themes itself.

Planning, optimisation and segregation are essentially the building blocks of a great website display. 

  • Planning to render the content types you need;
  • Optimising the Views you already have;
  • And segregating logic from presentation.

These three would have a visible effect on the display architecture.

What aspects of functionality can make your site lag behind?

The functionality of a Drupal site depends on the number of modules used and the way they interact with each other. Your code and how much of it you use is a major contributor in that. 

The most common mistake in this sense is the ignorance of code standards. This becomes more of a problem when there are more than one developers and everyone is using a different type of code. In such a situation, not only would the standard be lost,  but it would also become difficult for a developer to understand the other’s code. Therefore, the adherence to Drupal’s Coding Standards becomes a great help to uniformalise the code and make the functionality a breeze. 

Another obstacle in functionality are unorganised patches. Code modifications and bug fixes mandates the implementation of patches, however, they become a problem whenever there is an update. You can forget all about re-apply the patch or forget to change it in accordance with the new version. This can very well affect the functionality of your website, so organising them is essential. 

Having too many modules, too many roles and too much custom code, despite there being contrib modules for the same is bound to affect the functionality as well. Evaluate and re-evaluate your site for its needs to overcome these functionality hindrances.

Is your performance and scalability not up to the bar?

User Experience is directly proportional to the performance of your website; the more streamlined the performance is, the richer would the UX be. 

Here are three scenarios that can impact your performance in all the wrong ways.

  • The foremost is improper JS/CSS aggregation settings. This is supposed to combine and compress JS and CSS files from the modules in the HTML, leading to lesser load times and higher performance. And you will be saying goodbye to that with the improper aggregation.
  • The next mistake is that of inundating your site with too many modules. Drupal may have numerous modules to offer, but you can’t be using too many of them. Doing so would only slow you down and hamper your security as well. Only keep the modules that you would be using, messing up your code, performance, overheads and security is simply not worth it.
  • A sound cache strategy also goes a long way in performance enhancement. Caching too soon, caching at lower levels and not knowing what and when to cache all contribute in a lowered performance.

Drupal websites can be scaled by millions of users within seconds and that is what makes these sites great. Drupal offers many modules to enhance the performance and scalability, Blazy, Content Delivery Network and Server Scaling, being just a few of them. Not installing these could be deemed as a mistake.

Are you facing possible security breaches?

Security has become one of the major concerns amongst website builders. Therefore, protecting your business from the menace of hackers and all the havoc they can cause is paramount. 

You must have your security measures in place, however, there still may be certain areas where you may have become complacent and that just gives the break the hackers need. 

  • Primarily, you need to keep your website updated, all the core and contrib modules, despite you using or not using them. Updating a module would mean that Drupal’s security protocols are being updated with them and you make yourself secure with that. You cannot have your projects falling behind on various levels of Drupal’s security advisories.
  • Now, you can install the “ Update Manager” module to keep yourself updated. The “Available Updates” will give you a friendly reminder of applying the available security updates.
  • Next on the list of security blunders is not giving the Input Filters in Drupal their due importance. You might have configured the full HTML Input Format to every user or you might have completely disabled the HTML filtering. Both of these instances can give malicious code to enter your website and you know what happens then.
  • Continuing on similar lines, many sites also configure their servers improperly leading to unwanted access to them. On some occasions, servers are seen displaying their version numbers, which is like giving an open invitation to hackers. Server configuration and permissions should be a priority for every site builder.
  • It is also important to ensure that all the users accessing your site by logging into it are the ones you want. By implementing a password policy, removing old users and updating staff roles, you will be taking a step towards better security.
  • User roles are quite important in running a website, however, they can become overused quite quickly too, which not only slows down your website, but if they are misconfigured, it can lead to major security breaches.

Drupal has proven to be one of the best CMSs in terms of its security measures, it has you covered from every corner, but only if you let it. From granting secure access to providing granular user access control along with database encryption and preventing malicious data entry, Drupal will keep your site protected, provided you let it.

Have you made any infrastructural oversights?

The infrastructure of your website is decided by the stacks you have, which includes the server, database and the software layers like Varnish. Going into development with a firm plan for your infrastructure is the only way to go, an oversight in this area can be quite damaging. 

The common mistakes in this area are;

  • The size of the website’s stack is extremely large or extremely small.
  • Not preparing for growth by consistently checking the logs for error and the identification of the weaklings.
  • Having an ideal sized server, but not configuring it properly, which can make the traffic forego Varnish.
  • Allowing remote connections to the server can make the website more vulnerable.

Misconfiguration can be avoided by simply using the right tools for it. MySQLTuner is one amongst many, its performance suggestions help in improving the infrastructure as well.

Are you following your maintenance goals?

Maintenance of a website starts after the development is done and continues for the entirety of the life of the website. Considering this fact, you have to be very diligent with the maintenance process as making the wrong moves can be brutal.

Here are some of these wrong moves.

  • Not following Drupal updates is a more common mistake than you would think. By doing this, you are going to be hampering security and making your site vulnerable to Drupalgeddon attacks.
  • On the contrary, there are also times when we update the modules, but we forget to remove the older versions. This too happens a lot of the time and can cause many problems.
  • It is not just the modules that need to be updated, the development environment should also be up-to-date and friendly for testing.
  • Then there is the code, which is not using the Version Control System like Git, even the deployment of files should come directly from there. Also, using it, but not leaving messages for other developers related to the changes made can lead to chaos. It is, thereby important to always keep the VCS repository clean.

The crucial aspects of maintenance is time and consistency. When you do it timely, only then would it become a worthy practice. The review and assessment of your architecture in timely intervals along with all the logs, be it Apache or Drupal is a great headstart for the maintenance process.

Are you universally accessible?

Websites today need to transcend the parameters that used to confine them and their audience in the past. The sites and applications need to be built on a foundation that would make them fit for each and every user. Drupal has worked for the same, it aims to make websites accessible to all, including people with disabilities, by making itself an all-accessible tool. 

Web accessibility has become of the essence today, and persons with disabilities are at the core of it. Websites need to be designed keeping in mind their needs, be it a broken hand or a temporary sight loss. It isn't just me who believes this, World Wide Web Consortium’s guidelines agree with me as well. W3C two sets of guidelines are ardently followed by Drupal and your website should do the same, thus, support and foster inclusion. 

Despite its importance, many developers tend to overlook the accessibility features and that is where they go so very wrong. 

  • Not focusing on balanced contrast levels that can work under sunlight;
  • Not incorporating a form validation error verbiage to aid the visually impaired; 
  • Not using buttons over CTAs.

These may seem like minor errors to you, but they can go a long way in making your Drupal site accessible to everyone.

Is your site SEO friendly?

Being SEO friendly is almost as important as building a website. Search engines bring in big numbers of traffic, so optimising them is crucial; yet we tend to forget to fine-tune the SEO details and focus on all the other aspects. At the end of the day, a website is an online business and business cannot survive without its clients and being SEO friendly is the way to go. Going wrong in this area can be extremely detrimental.

Look at the following aspects of a website and see how many you are and aren’t doing. 

Are your URLs user friendly?
Are your images small in size, with filled out alt texts?
Are you making your paragraphs short to make the text easy to scan through?
Are you using robots.txt for pages that you do not want crawled?
Are you creating an XML roadmap to help Google easily understand the structure of your website?
Are you researching your keywords?
Are you adding internal links to make your less popular pages gain attention through the more popular ones?

A positive answer to all of these means that your SEO game is strong and a contrary answer would let you know your mistakes.

To avoid the contrary from happening, Drupal provides a number of modules to help you capitalise on the SEO front. The SEO checklist module is a proof of that as it helps you by ensuring that you are following through on the latest SEO practices. Then there are the modules that aid your URL precision, like Redirect, Pathauo and Easy Breadcrumbs.From easing the process tags to helping in communication with search engines to providing the essentials for editing, Drupal has all the right SEO modules in its corner and not using these would be a colossal mistake on your part. Read our blog, The Ultimate Drupal SEO Guide 2020, to know more about these. 

Can being multilingual pose a problem for you? 

Today, languages that are regionally spoken have started getting more prominence than ever before, especially in the international community. A french website would not be successful in India, if it is in French, not many people speak that language, so it would have to be in a locally accepted language. Being multilingual also opens the doors for many mistakes to occur. 

  • Using the same URL for all of your multilingual websites; 
  • Not giving the user a chance to avoid a redirect to the international website;
  • Using an automated translator, instead of actually hiring content authors fluent in the language;
  • Foregoing to translate the imbedded parts of the site like meta tags and descriptions;
  • Not focusing on the foreign market trends and the keywords appropriate to it;
  • And lastly, not writing the content in accordance with the local language and dialects. You can’t be calling ice lollies popsicles sticks in India.

You have to be totally attuned with the language of the region that you have followed for the multilingual project to work.

Is having a multisite presence worth it?

Depending on your business and its needs, having multiple sites can be a good solution for you. However, managing then can become a bit of a hassle and often lead to big blunders. 

Some examples of such blunders are;

  • Traffic is one of the major concerns here. Running multiple sites means you have one codebase and many sites on it, so if one is inundated with traffic, all of them could slow down as a result.
  • A mistake in the syntax of one site could mean a mistake in the syntax of all.
  • Updates become a headache as well. For Drupal sites, you have to run an update.php in order to update the site and doing that on multiple sites is going to bring on the headache.
  • And finally, if you do not use Aegir, you are going to regret going multisite.
Is your Decoupled Drupal approach the right one?

Drupal offers an impressive front-end technology to make your presentation layer as good as you want, yet it does not include all the front end technologies there are on the market. Taking advantage of JavaScript and Static Site Generator would mean to decouple Drupal and separating the front-end from it. Even if you want to take on decoupling, it may not want to take on. The decoupled Drupal can bring more drawbacks then. 

  • If you wish to capitalise Drupal’s in-built features, Decoupling would be a mistake, since you would end up parting with them.
  • If your front-end requirements and Drupal’s front-end capabilities are aligned, taking on Decoupling would only be an unnecessary effort on your part.
  • If you do not have either the budget or resources to tap into the hottest technologies, then even if you want them it is not going to be fruitful.
  • If you are only publishing content at one place, you would have no need for decoupling.

For a detailed explanation, read our blog, When to Move From Monolithic to Decoupled Drupal Architecture.

Finally, what about web hosting, are you doing it the right way?

Web hosting services that provide your website its own space on the internet are pretty common. There are far too many web hosts to count, yet the decision to choose one is not easy at all, since there are too many considerations to keep in mind. 

Some of the common mistakes to avoid which signing on a web host are;

  • Testing web hosts is not uncommon, it is the right way to know whether they are valuable. However, testing on your website that is primarily bringing in the traffic could be unwise, especially if you are using a free service. Therefore, not registering with a different party can be colossal.
  • Another mistake is trusting too easily without knowing the host for too long. Therefore, not partnering with one that has a long trial could be a mistake. The longer the trial period on offer is, the more reliable the host is going to be.
  • Taking on a web host is a huge commitment, so you have to be sure that you are in the good. Not doing your due diligence before the commitment is not the right way, comparing the pricing and features along with checking if they have blacklisted IPs.
  • Not tracking your hosting uptime and speed can also be a problem. Also not checking what guarantees for uptime are provided by the hosts for the same would not be wise. If there is a lapse between the guaranteed and actual uptime, keeping a track would give you the opportunity to ask for compensation.
  • Lastly, you cannot afford to not have a backup of your site and that too regularly. You will only have the recent version of your files and assets, if you back them up.
The Bottom Line 

Every aspect of your website is important, consequently, you have to be mindful of them all. If you are not, mistakes will happen and they will cost you your site’s performance, its security and your potential customers and sales. In order to keep that from happening, you have to avoid all of the aforementioned mistakes and ensure that your website is impeccably built and maintained on all platforms. 

blog banner blog image Drupal drupal security Website Performance Optimisation Web Accessibility drupal seo Multilingual Site Decoupled Drupal Blog Type Articles Is it a good read ? On