LATEST FROM OUR BLOG

Take your daily dose of (only) relevant news, useful tips and tricks and valuable how to's on using the latest web technologies shaping the digital landscape. We're here to do all the necessary information sifting for you, so you don't have to, to provide you with content that will help you anticipate the emerging trends about to influence the web.

Automatic Updates in Drupal Core? Top Benefits and Main Concerns With Drupal Updating Itself
Just imagine... automatic updates in Drupal core. Such a feature would put an end to all those never-ending debates and ongoing discussions taking place in the Drupal community about the expectations and concerns with implementing such an auto-update system. Moreover, it would be a much-awaited upgrade for all those users who've been looking for (not to say “longing for") ways to automate Drupal core and modules for... years now. Who've been legitimately asking themselves: “Why doesn't Drupal offer an auto-update feature like WordPress?” And how did we get this far? From idea to a steady-growing initiative?   first, it was the need to automate Drupal module and security updates then, the issues queues filled with opinions grounded in skepticism, valid concerns and high hopes started to “pile up” on Drupal.org, then, there was Dries' keynote presentation at Drupalcon Vienna in 2017, raising awareness around the need to re-structure Drupal core in order to support a secure auto-update system … which grew into the current Auto Update Initiative that echoed, recently, at Drupal Europe 2018, during the “Hackers Automate, but the Drupal Community still Downloads Modules from Drupal.org” session   Many concerns and issues have been pointed out. Many questions have been added to the long list. Yet, one thing's for sure: There still is a pressing, ever-growing need for an auto-update feature in Drupal... So, let me try to answer my best to some of your questions regarding this much-awaited addition to Drupal core:   What's in it for you precisely? How will an auto-update pre-built feature benefit you?  Does the user persona profile suit you, too? Is it exclusively low-end websites that such a feature would benefit? Or are enterprise-level, company websites targeted, as well? What are the main concerns about this implementation?   1. The Automatic Updates Initiative: Goal & Main Challenges  Let's shift focus instead and pass in review the inconveniences of manually installing updates in Drupal:   it's time-consuming it's can get risky if you don't know what you're doing it can be an intimidatingly complex process if you have no dedicated Drupal support & maintenance team to rely on it can get quite expensive, especially for a small site or blog owner   See where I'm heading at? This initiative's main objective is to spare Drupal users of all these... inconveniences when it comes to updating and maintaining their websites. Inconveniences that can easily grow into reasons why some might get too discouraged to adopt Drupal in the first place. The goal is to develop an auto-update mechanism for Drupal core conceptually similar to those already implemented on other platforms (e.g. WordPress). And now, let's dig up and expose the key challenges in meeting this goal:   enabling update automation in Drupal core demands a complete re-engineering of the codebase; it calls for a reconstructing of its architecture and code layout in order to support a perfectly secure auto-update system  such an implementation will have a major impact on the development cycle itself, causing unwanted disruption such a built-in auto-update feature could get exploited for distributing and injecting malware into a whole mass of Drupal websites   2. Automatic Updates in Drupal: Basic Implementation Requirements  What would be the ideal context for implementing such a perfectly secure auto-update system?  Well, its implementation would call for:   multiple (up to date) environments released updates to be detected automatically and instantly an update pipeline for quality assurance existing automate tests with full coverage a development team to review any changes applied during the update process    3. How Would These Auto-Updates Benefit You, the Drupal User? Let's see, maybe answering these key questions would help you identify the benefits that you'd reap (if any):   is your Drupal website currently maintained by a professional team? has it been a... breeze for you so far to cope with Drupal 8's release cycle (one new patch each month and a new minor release every 6 months sure claim for a lot of your time)? have you ever got tangled up in Composer's complexities and a whole load of third-party libraries when trying to update your Drupal 8 website? did you run the Drupalgeddon update fast enough? have you been secretly “fancying” about a functionality that would just update Drupal core and modules, by default, right on the live server?   To sum up: having automatic updates in Drupal core would keep your website secured and properly maintained without you having to invest time or money for this.   4. Drupal Updating Itself: Main Concerns And concerns increase exponentially as the need for an update automation in Drupal rises (along with the expectations). Now, let's outline some of the most frequently expressed ones:   there is no control over the update process, no quality assurance pipeline; basically, there's no time schedule system enabling you to test any given update, in a development environment, before pushing it live there's no clearly defined policy on what updates (security updates only, all updates, highly critical updates etc.) should be pushed with Drupal updating itself, rolling back changes wouldn't be possible anymore (or discouragingly difficult) with no GIT for version control again: automatic updates in Drupal could turn into a vulnerability for hackers to exploit for a mass malware attack  there's no clear policy regarding NodeJS, PHP and all the JS libraries in Drupal 8, all carrying their own vulnerabilities, too it's too risky with all those core and module conflicts and bugs that could break through such a feature should be disabled by default; thus, it would be every site owner's decision whether to turn it on or not could this auto-update system cater to all the possible update workflows and specific behaviors out there? Could it meet all the different security requirements?   So, you get the point: no control over the update pipeline and no policy for handling updates are the aspects that concern developers the most.   6. Does It Cater for Both Small & Enterprise-Level Websites' Needs?  There is this shared consensus that implementing automatic updates in Drupal core would:   not meet large company websites' security requirements; that it would not fit their specific update workflows benefit exclusively small, low-end websites that don't benefit from professional maintenance services   Even the team behind the automatic updates initiative have prioritized low-end websites in their roadmap. But, is that really the case? Should this initiative target small websites, with simple needs and writable systems, that rarely update and to overlook enterprise-level websites by default? Or should this much-wanted functionality be adjusted so that it meets the latter's needs, as well?  In this case, the first step would be building an update pipeline that would ensure quality. What do you think?   7. How About Now?"What Are My Options for Automating Updates in Drupal?" In other words: what are the currently available solutions if you want to automate the Drupal module and security updates?    7.1. You Can Use Custom Scripts to Automate Updates … one that's executed by Jerkins or another CI platform.  Note: do bear in mind that properly maintaining a heavy load of scrips and keeping up with all the new libraries, tools, and DevOp changes won't be precisely a “child's play”. Also, with no workflow and no integrated tools, ensuring quality's going to be a challenge to consider.   7.2. You Can Opt for a Drupal Hosting Provider's Built-In Solution “Teaming up” with a Drupal hosting provider that offers you automated updates services, too, is another option at hand. In this respect, solutions for auto-updating, such as those provided by Pantheon or Acquia, could fit your specific requirements.  Note: again, you'll need to consider that these built-in solutions do not integrate with your specific DevOps workflows and tools.   And my monologue on automatic updates in Drupal ends here, but I do hope that it will grow into a discussion/debate in the comments here below: Would you turn it on, if such a feature already existed in Drupal core? Definitely yes No way It depends on whether... ... Read more
RADU SIMILEANU / Sep 28'2018
Media Handling in Drupal 8.6.0: 4 New Features that Will Enhance Your Media Management Experience in Drupal
The media management experience had been one of the well-known sources of frustration for Drupal content editors for a long time. For, let's face it: Drupal's out-of-the-box media support was just... basic. But not anymore: there are new exciting features for media handling in Drupal 8.6.0 that will dramatically change the way you manage your media assets on your Drupal website! Now, let's take a sneak peek at these most-anticipated media handling features that Drupal 8.6.0 comes equipped with:   adding media from a remote source adding various types of media embedding Youtube and Vimeo videos in the content (via URL) easily accessing and reusing the existing media uploading new media types right out of the box   And this is almost... overwhelming: From almost no built-in media support in Drupal, for so many years, to a whole set of modern, powerful media management options now in Drupal 8.6.0. But let's not ramble about this topic anymore and dive right in! Into the pile of new features meant to enhance the whole media management experience in Drupal:   But First: An Update on The Progress of the Media in Drupal 8 Initiative The main goal of this media initiative was to: Add a rich media support to Drupal 8. One that would empower the content editors to easily reuse existing media assets, add new media entities and to overall gain more control (and meta information) over their media. And there are 3 core milestones that we can trace while tracking the progress of this initiative for Drupal 8:   adding the experimental Media module to Drupal 8.4 in late 2017 leveling up this module from experimental to stable phase in Drupal 8.5.0 turning it into the standard way of storing media in Drupal    Moreover, starting with Drupal 8.6.0 a new key module for handling media has been added to core — Media Library — along with a few more exciting options:   quick access to the existing media assets oEmbed support a new media type: remote video content   Quite a “leap” forward, to a great media management experience in Drupal, I would say...   2. Welcome a New Media Type in Drupal 8: Remote Video Let us list the 4 media types that you could add to your site's content up to Drupal 8.6.0:   file image video audio   OK, now it's time you welcomed a new media type to the group: remote video! Basically, as a content editor you're now able to add videos from remote sources, as well — Vimeo and Youtube — via their URLs.   In short: you're no longer constrained to settle for the default media types in Drupal 8. No sir, now you get to create new custom ones mentioning their media sources. Summing up: embedding new media to your website content is nothing but a two-step process: Content-Add Media. 3. Reusing Media Is Now Possible: Media Library One of the much-awaited features for media handling in Drupal 8.6.0 had been reusable media. Well, here it is now: Media Library! It's where you can save and store all your media assets to be further reused whenever needed. Note: do keep in mind that this an experimental module and that you'll also need to enable the Media module first things first. “And how does it work more precisely?”   while in your content edit screen just browse through all the media assets stored in your Media Library select the one you need and simply “inject” it into your page   Note: it's the “Media library” widget, added to the Media field, that enables you to scan through all your media entities straight from the content edit screen. 4. The New “Media” Field: A Quick Way to Embed Media in Your Content Handling media in Drupal 8.6.0 is as simple as... adding a new field — “Media” —  to the content type in question (be it news, blog post, article and so on). Once the new field is added on, just go through the 5 media types available in Drupal 8.6.0 and select the one you need to embed. Next, you can simply integrate it into your content, while in your edit screen, positioning it to your liking.   5. New Media Handling in Drupal 8.6.0: Youtube & Vimeo Embeds A new media management tool that significantly improves the whole content editing experience in Drupal. You're able to embed remote videos from Youtube and Vimeo via URL, thanks to the now added oEmbed media support. “How precisely?” Basically, you simply:   add that new “Media” field to your content type, as previously stated select the “Remote Video” option from the “Media Type” drop-down menu enter your video's URL in the “Video URL” field, while in your “Add Remote Video” screen and click “Save”   And voila: you'll have your remote video integrated into your content! The END! As Steve Burge from OSTraining would say: “Finally we're getting somewhere with media in Drupal!”   What do you think about the new features for media handling in Drupal 8.6.0? What other options and tools are there on your wishlist? To be able to embed remote videos right from the node create page, maybe? Or to have other video platforms, as well, supported in Drupal? ... Read more
Silviu Serdaru / Sep 21'2018
How Do You Restrict Access to Content in Drupal 8? 6 Modules That Will Do the Job for You
We all love Drupal's granular permission and access control system! And yet: its life-saving hierarchy of user roles and permission levels is strictly for creating/editing content. Since Drupal wrongly assumes that all site visitors should be able to visualize all published content, right? But what if this default assumption doesn't suit your specific use case? What if you need to restrict access to content in Drupal 8? … to limit users' access to certain content on your website? So that not all visitors should be able to see all published nodes. In this case, Drupal's typical access control system for creating and editing content is not precisely the functionality that you need. But there's hope! And it comes in the form of 6 Drupal 8 access control modules that enable you to give content access of different levels, ranging from “average” to “more refined”.   But First: An Overview of Drupal's Typical Access Control System  Now, we can't just jump straight to the “more sophisticated” content access solutions in Drupal 8, not until we've understood how its basic access control system works, right? As you can see, in the screenshot here below, the logic behind it is pretty straightforward: while in your admin panel, you need to access the People menu > Permissions and there, you just assign different user types (authenticated, admin or anonymous) with specific sets of permissions (to administer blocks, to post/edit comments, to modify menus on your Drupal site etc.)   As you can see, Drupal's typical access control system is not configured so as to enable you to restrict visitors' access to specific content on your website. Or to limit user access to a more granular level other than the standard “logged in/not logged in user”.   1. Access by Entity   If you're not looking for anything “too fancy”, just a straightforward functionality for controlling access to view/edit/delete content entities, then this module's THE one. And here are 2 of its most common use cases:   you define some access-restricted premium content areas on your Drupal site, for “privileged” user roles only you grant publish/edit permissions to certain groups on your website, having specific predefined user roles   2. Content Access Definitely a go-to module when you need to restrict access to content — to specific content types — in Drupal 8. It enables you to:   set up specific access control roles define custom granular restrictions based on different user permissions (you could, for instance, limit access to certain content on your website for non-authenticated users only...) set up content types with restricted access    Note: do bear in mind that, once you've enabled Content Access, you'll need to rebuild your entire “collection” of access content permissions. The module is going to alter the way they work, that's why. Tip: if you need to control access to content nodes on your Drupal 8 site, this module's built to help you “refine” your restriction; for that you'll just need to define some more detailed permissions in People menu >  Permissions tab.   3. Permissions by Term A lightweight solution to restrict access to content in Drupal 8. One that enables you to set up access-restricted content sections on your website. Now, what makes it stand out from the other 5 modules in my list here is: The refined, taxonomy term-based restrictions that it allows you to create for specific nodes on your Drupal site. You can limit access to these nodes for:   specific user roles certain individual user accounts   How do you set everything up?   first, you enable the module then, on the term edit page, you define a specific role access for each taxonomy term  And there's more to look forward to!  Unlike Organic Groups and Group, the Permissions by Term module comes with very little overhead, in the form of light contributed code. In other words: for the taxonomy terms-based access control that it enables you to set up, it adds a new field to your current content types. That's all!   4. Node View Permissions When it comes to Drupal role-based access control (to content types or nodes) this module's simple, straightforward approach is exactly what you need. Not as “sophisticated” as Content Acess, yet conveniently easy to configure and to maintain. And also, the perfect choice if it's just a basic kind of content type access restriction that you need to set up. Summing up its functionality now, what you should know is that Node View Permissions enables you to define 2 types of... permissions:   “View any content” “View own content”   … for every content type listed on your Drupal site's Permissions page.    5. Group          It enables you, as the site admin, to structure content into... groups. Different group types, with their own hierarchies of group roles:   anonymous member outsider (a logged in user, but not a group member) other group roles that, as an administrator, you'll need to create   Needless to add that with Group you'll restrict access to content in Drupal 8 based precisely on these group roles that you'll set up. Furthermore, it allows you to define:   the most suitable permissions (view/edit/delete) for specific content types the most appropriate group roles   … per group type.  And the best is yet to come: All group types, group roles, group/content relationships are set up as entities. Meaning that they're fully fieldable, exportable, extendable!   6. Taxonomy Access Control Lite It's a restricted access to nodes, based on taxonomy terms, users and roles, that you get to define using this module: A user role-based access control... Note: mind you don't forget that, in order to restrict access to viewing/editing nodes on your Drupal website, you'll first need to reconfigure the existing user permissions. The END!  A bit curious now: which one of these solutions, ranging from straightforwardly simple to most refined, would you go for to restrict access to content in Drupal 8? ... Read more
RADU SIMILEANU / Aug 30'2018
10 Drupal SEO Mistakes You Do Not Want to Make on Your Website: From Least to Most Harmful- Part 2
You've put so much effort into crafting and polishing the content on your Drupal website and it just won't... rank? Why is it that search engines' web crawlers won't index its “juicy” content? Why they won't give your site a big push right to first-position rankings? As it clearly deserves... Could it be because you're making these 10 Drupal SEO mistakes?  Knowingly or just recklessly... And with the first 5 of them already exposed in the first part of this blog post, I'm keeping my promise and here I am now, with 5 more SEO mistakes that you don't want to make on your Drupal website, ranging from:   embarrassing gaffes to faux pas to catastrophes...   1. Underrating Meta Tags: One of (Too) Common, Yet Costly Drupal SEO Mistakes  And let me just say it: forgetting (or choosing not to) to check those 3 on-page ranking factors:   description page title tags   ... is one rookie SEO mistake.  And one costly neglect, too... Why? Because by simply checking your meta tags, making sure that the content entered there:   contains all the relevant keywords is user-friendly and engaging   you hit 2 birds with just one stone:   search engines' crawlers will just know whether specific web pages on your site are relevant for specific search queries or not; whether the keywords that you will have added to your meta elements are precisely those that online visitors use users will get a “teaser” of what the page is about, helping them decide whether it matches their searches and expectations or not   Note: Drupal's got your back with a dedicated Metatag module that you should install even before you “release your website out into the wild".   2. Ignoring the Slow Page Loading Speed  If it takes more than 2 seconds to load... then you'll lose them. Visitors on your Drupal site will lose all interest in accessing that given page. And could you blame them?  Instead, you'd better:   blame yourself for accepting this status quo and refusing (or just postponing or not putting enough effort into it) to optimize your site for high speed rush to address this major UX issue risking to grow into a critical SEO issue   How? By:   compressing all JS and CSS files using a dedicated tool of your choice (and thank God there are plenty of those to choose from!) compressing all overly large pages reducing images, graphics, and videos to reasonable sizes disabling all those Drupal modules that you haven't used in ages (or maybe never...) enabling caching (and luckily there are Drupal cache modules — like Memcache, for instance — that can help you with that) upgrading your server or even moving to a new hosting company optimizing your site's current theme See? Improving your Drupal site's load time is no rocket science and it doesn't require overly complex measures, either. They're no more than... “common sense” techniques. Assess the resources that implementing them would require and... just do it:   the user experience on your Drupal website will improve significantly search engines will “detect” this increase in user satisfaction … which will translate into a higher ranking    3. Overlooking to Redirect From Its HTTP to Its Secure HTTPs Version Migrating your Drupal site to HTTPS is a must these days. Just face it and deal with it or... be ready to face the consequences! Yet, if you overlook to redirect your site to its new HTTPS version, thus sending its visitors out to... nowhere — to error pages — then... it's all but wasted effort and resources. One of those SEO Drupal mistakes with long-term consequences on your website's ranking.   4. Broken Internal Images Leaving broken internal images and missing ALT attributes behind is a clear sign of SEO sloppiness... And now, here's what we would call a “broken image”:   an image that has an invalid file path an image with a misspelled URL   The result(s)?   first, a broken image has an impact on the overall user experience; your site visitor gets discouraged and quits the page in question next, search engines rate your site's content as “of poor quality” and finally, all these lead to an inevitable drop in Google search rankings   5. Underestimating (or Just Ignoring) the Importance of an XML Sitemap for SEO Not generating an XML sitemap of your Drupal site is more than just one of those Drupal SEO mistakes that you should avoid: it's a missed opportunity! A huge one! Here's why:   an XML sitemap would include all the URLs on your website … as well as information (via heading tags) about your site's infrastructure of web pages, for search engine crawlers to use … “alerts” about which pages they should be indexing first an XML sitemap provides an early index of your website all the pages on your website get submitted to the search engine database even before they get indexed in their own database   Note: the sitemap.xml file not only that communicates with and informs search engines about the current content ecosystem on your Drupal site, but will “keep them posted” on any updates of your site's content, as well. So, what an XML sitemap provides is a prioritized, conveniently detailed and easily crawlable map of your Drupal website meant to ease web crawlers' indexing job. And the easier it gets for them to crawl through your site's content, the faster your site's indexing process will be. In short: if the robots.txt file alerts search engines about those pages that they shouldn't crawl into, the sitemap.xml file lets them know what pages they should index first! Tip: discouraged by the thought of manually building your site's sitemap? Well, why should you, when there are Drupal modules built especially for this?   Site map (Drupal 7)       Sitemap (Drupal 8)         Simple XML (Drupal 8)     XML Sitemap     From taxonomy terms, menu links, nodes, useful entities, to custom links, these modules will automatically generate all the entities that you'd need to include in a detailed sitemap of your Drupal site. The END!  Just face it now: you'll inevitably continue to make gaffes influencing your site's SEO, no matter how many precautions you might take... Yet, these10 Drupal SEO mistakes here, ranked from least to most damaging, are the ones that you should strive to avoid at all costs... ... Read more
Adriana Cacoveanu / Aug 27'2018
What Are Some Good Ways to Write Secure Drupal Code? Most Common Vulnerabilities and Secure Coding Practices
With the Drupalgeddon2 "trauma" still “haunting” us all — both Drupal developers and Drupal end-users — we've convinced ourselves that prevention is, indeed, (way) better than recovery. And, after we've put together, here on this blog, a basic security checklist for Drupal websites and revealed to you the 10 post-hack “emergency” steps to take, we've decided to dig a bit deeper. To answer a legitimate question: “What are some good ways to write secure Drupal code?” For, in vain you:   build a “shield” of the best Drupal security modules and plugins around your website enforce a rigid workplace security policy    … if you leave its code vulnerable to various types of cyber attacks, right? But how do I know how unsecured code looks like, to begin with? What are the site configuration gotchas that I should pay attention to? What are the most common vulnerabilities that I risk exposing my Drupal site to? And how can I test it for security issues that might be lurking in its code? But most of all: What top secure coding practices should I and my Drupal development team follow? Now, let's get you some answers:   1. SQL Injection Vulnerabilities: How You Can Fix & Prevent Them  SQL injections sure make one of the most “banal”, nonetheless dreadful types of attacks. Once such vulnerabilities are exploited, the attacker gets access to sensitive data on your Drupal site.   1.1. Prevent SQL Injection Attacks Using The Database Abstraction Layer In other words: the proper use of a database layer makes the best shield against any SQL injection exploit attempts. Now, let's talk... code. For instance, linking together data right into the SQL queries does not stand for a secure coding practice: db_query('SELECT foo FROM {table} t WHERE t.name = '. $_GET['user']); In this case here, this is how you write secure Drupal code: db_query("SELECT foo FROM {table} t WHERE t.name = :name", [':name' => $_GET['user']]); Notice the usage of the proper argument substitution with db_query. The database abstraction layer uses a whole range of named placeholders and works on top of the PHP PDO. Now, as for a scenario requesting a variable number of arguments, you can use either db_select() or an array of arguments: $users = ['joe', 'poe', $_GET['user']]; db_query("SELECT t.s FROM {table} t WHERE t.field IN (:users)", [':users' => $users]); $users = ['joe', 'poe', $_GET['user']]; $result = db_select('table', 't') ->fields('t', ['s']) ->condition('t.field', $users, 'IN') ->execute(); 1.2. Have You Detected an SQL Injection Vulnerability? Here's How You Can Fix It There are some key Drupal security best practices to follow for addressing SQL injection issues:   always stick to the well-known Drupal database API always filter the parameters that you get (be twice as vigilant and cautious about those who can type anything on your Drupal site) always use placeholders: db_query with :placeholder always check the queries in the code: db_like()   Tip: remember to follow these coding practices for addressing and preventing SQL injections on your contrib modules, as well.   2. How to Protect Your Drupal Site Against Cross-Site Scripting (XSS) Attacks We could easily say that XSS attacks “rival” SQL injection attacks in “popularity”: Drupal's highly vulnerable to cross-site scripting. All it takes is some wrong settings — input, comment, full HTML — as you configure your website, to make it vulnerable to this type of attacks: They make a convenient gateway into your website for remote attackers to use to inject HTML or arbitrary web.   2.1. Check Functions to Rely on for Sanitizing the User Input (in Drupal 7) Securing your Drupal 7 site against cross-site scripting attacks always starts with: Identifying the very “source” of that submitted data/text. Now, if the “culprit” is a user-submitted piece of content, depending on its type you have several check functions at hand to use for sanitizing it:   check_url check_plain (for plain text) filter_xss (when dealing with pure HTML) filter_xss_admin (if it's an admin user that entered the “trouble-making” text) check_markup   Note: always remember never to enter the user input as-is into HTML! Tip: a good way to write secure Drupal code is to use t() with % or @ placeholders for putting together translatable, safe strings.   2.3. Cross-Site Scripting In Drupal 8: Twig & 3 Useful Sanitization Methods In Drupal 8, handling cross-site scripting attacks gets significantly easier. Here's why:   you have TWIG, with its autoescaping and “sanitize all” HTML mechanism!!! no SQL queries no access to Drupal APIs   Now, besides Twig, you have 3 more sanitizing methods at hand for fixing cross-site scripting issues in Drupal 8:   HTML: :escape(), for plain text Xss: :filterAdmin(), for admin-submitted content Xss: :filter(), where HTML can be used   2.4. Testing Your Code Against XSS In order to check whether certain user inputs are vulnerable, all you need to do is:   take the “suspicious” user input as a field, as an input HTML enter them both (or just one of them) in your test   Note: feel free to user Behat or another framework of choice to automate the whole process. 2 clear signs that you've detected an XSS vulnerability are:   you get this pop up alert: <script>altert ('xss') </script> or this error message close to the IMG tag: img src="a" onerror="alert ('title')"   3. Use Twig Templates: They Sanitize All Output...  Automatically  Did you know that a lot of the Drupal security issues on your website occur precisely because you've skipped sanitizing the user-submitted content before displaying it? And someone's neglect quickly turns into another one's opportunity... By skipping to clean up that text beforehand, you lend the attacker a “helping hand” with exploiting your own Drupal site. Now, getting back to why using Twig templates is one of the best ways to write secure Drupal code:   they sanitize the user input and output (all HTML, basically) by default; you can write your custom code without worrying about it risking to break up your website you won't run the risk of having safe markup escaped In short: securing your Drupal 8 website is also about having all HTML outputted from Twig templates.   4. How to Write Secure Drupal Code for Finding & Fixing Access Bypass Issues One of Drupal's strongest “selling points” is precisely its granular permission system. Its whole infrastructure of user roles with different levels of permissions assigned to them. Furthermore, there are all kinds of access controls that you can “juggle with”:   Node access system field access Views access control Entity access   In short: you're free to empower users to access different sections/carry out different operations on your Drupal site.   4.1. How You Can Check for Access Bypass Issues How do you know whether there are access bypass flaws on your website, that could be easily exploited? It's easy:   you simply visit some nid/node and other URL on your site  and just run your Behat automated tests   4.2. And How You Can Fix the Identified Access Bypass Issues Do keep in mind that there are quite a few access callbacks to consider:   entity_access user_access for  permissions Squery – addTag ('node_access') Menu definitions (make sure you set those correctly) node_access All you need to do is write automated tests to address any detected problems related to access bypass.   5. 3 Ways Deal With Cross-Site Request Forgery (CSRF) in Drupal  What does it take to write secure Drupal code?  Writing it... strategically, so that it should prevent any possible cross-site request forgery attack... Now, here are 3 ways to safeguard it from such exploits:   sending and properly validating the token using Form API using the built-in csrf_token in Drupal 8   In conclusion: a trio of good practices keeps the CSRF attacks away...   6. 7 Best Contrib Security Modules to Back Up Your Coding With Now, after we've gone through some of the best ways to write secure Drupal code, let's see which are the most reliable contrib security modules to strengthen your site's shield with:   Hacked!       Permission report   Encrypt       Composer Security Checker         Security Review           Paranoia       Text Formats Report   The END! This is how your solid Drupal security “battle plan” could look like. It includes:   some of the most frequent types of attacks and security issues to pay attention to most effective preventive measures vulnerability detecting methods post-attack emergency actions and sanitization mechanisms   What ways to write secure Drupal code would you have added or removed from this list? ... Read more
RADU SIMILEANU / Aug 24'2018
Drupal Project Management: Specific Challenges and Approaches
Let me guess: you're a Drupal developer (temporarily) turned into a... Drupal project manager! Or maybe a PM new to Drupal, facing the challenge of your first Drupal project management assignment? Have I guessed it? Now the questions roaming in your head right now must be:   What Drupal project-specific challenges should I expect? How should I address them? How should I approach the Drupal developers, site builders and themers involved? What questions should I ask them at each phase of the project? And which are the stages of a Drupal project management process more precisely? How do I collect accurate and explicit requirements for my Drupal project?   “Spoiler alert”: managing a Drupal project the right way isn't so much about using the right project management modules and “heavy-lifting” tools. It's about:   understanding the specific challenges that Drupal projects pose understanding the specific phases of the process empowering the people in your team to capitalize on their Drupal expertise within the given time frames and according to your client's objectives   Now, here's an insight into the process of managing a Drupal project. One shaped as a list of predictable challenges and their most suitable solutions:   1. Proper Planning: Get The Whole Team Involved In other words: defining objectives and setting up a final time frame with the client without getting your team, too, involved in the process is like: Throwing spaghetti at a wall and hoping that it would just... stick somehow. They're the Drupal experts, you know... Therefore, getting the Drupal developers, themers and site builders engaged at this stage of the project is no more than... common sense. They're the (only) ones able to:   give you an accurate time estimate for developing and implementing each functionality/feature tell if certain of the requested features can't be delivered identify interdependencies and conditions provide you vital information about the Drupal-specific architecture and the project-specific development process … information on what components to take, whether new contrib modules need to be developed to support certain functionalities etc.   Get your Drupal team involved in the planning and preparation process and strike a balance between their valuable input, the client's objectives, and time frames.   2. Tempted to... Micromanage? Empower Your Team Instead Yet, resisting temptation won't be easy. Especially if you're a former Drupal developer now turned into a Drupal project manager. You'd just die to get your hands dirty with code, wouldn't you? To supervise, closely, how every single line of code is being written. Refrain yourself from that... Instead, do keep your focus on the bigger picture! And, moreover, empower each member of your team to... shine. To excel at what he/she's doing.  That instead of obsessing over details, getting everyone on their nerves and making them doubt their own skills: By focusing on each one of the small steering wheels, you'd just lose sight of the larger mechanism that's a Drupal project.   3. To Tell or Not to Tell: Do Encourage Your Team Members to... Tell Hiding the dirt under the carpet, from the stakeholders' eyes/ears and having members of your team remain silent over certain bottlenecks in the project will only act as 2 “Trojan horses”. They'll lead your Drupal project to... failure. Instead:   dare be honest with the client and inform him/her if you run the risk of a delay  encourage your team to be open with you and with their teammates when they hit sudden challenges, unexpected issues   By:   hiding ignoring “genuinely” underrating   ... issues detected in the development process — instead of getting them “exposed” and dealt with —  you're only sabotaging the Drupal project. And now speaking of encouraging good communication within your team, how about creating a dedicated open forum for them to use? This could be the “place” where they'd share any issues that they will have detected in the project. Or challenges that they face and can't address by themselves.   4. Juggling with Resources, Timeline, and Unforeseen Events I'm not going to lie to you about this one: keeping the balance between staying flexible and being capable to assess risks is not going to be easy... Unplanned issues will strike, new requirements will come to “jeopardize” this balance, unexpected changes will need to be accommodated under the same time frame... Should you keep yourself rigid and inflexible to all changes, sticking to the initial plan? Or should you “assimilate” all the incoming requirements and additions to scope with the risk of a project delay? And that of overburdening your team with unscheduled tasks... Can't help you with a universal answer here, one that would apply to all Drupal project management scenarios. It's you, together with your Drupal team, who should be able to estimate:   the changes' level of complexity the project delay (if it's the case) the chances for these additional tweaks to turn into contractual changes   5. Drupal Project Management Is 90% Good Time Management And it all comes down to: Breaking your Drupal project down into small, manageable tasks.  Tasks that can be easily turned into goals and objectives:   daily objectives weekly objectives and so on...   Efficient Drupal project management, even if we're talking about truly complex ones, is all about making it... manageable. About ensuring that the lists of tasks are logically structured and (most of all) time framed! Needless to add that this strategy acts as a motivation-booster for your team:  Just think about it: with every ticked off task, each team member can visualize the project's progress in... real-time. A progress that he/she, too, will have contributed to. The END! These are the Drupal project-specific challenges that any project manager dealing with this CMS faces, accompanied by their life (reputation)-saving solutions.   ... Read more
Adriana Cacoveanu / Aug 21'2018
Bringing Gutenberg to Drupal: A Modern Admin UI, a Better Editing Experience in Drupal 8
It's a robust, flexible and admin feature-packed CMS, there's no point in denying it. And yet: Drupal (still) lacks a modern UI that would make building rich web content —  such as landing pages — a breeze. But there is hope: the Gutenberg editor has been ported over, promising a better editing experience in Drupal 8. The team behind this daring project? Frontkom, a Norwegian digital services agency that:   refused to just sit and wait (for a year or two) for the in-progress initiative of modernizing Drupal's admin UI to grow into a core solution decided to capitalize on their experience in working with the Gutenberg page builder  … and on this content editor's open source nature, too … to bring it over to Drupal 8   Now, if you're determined to improve the editorial UX on your Drupal site, to “spoil” your editors with a modern, intuitive and flexible admin UI, keep on reading...   1. The Drupal Gutenberg Project: Aiming for a Modern Admin UI in Drupal 8 And by “modern” I do mean the opposite of the Panels & Paragraphs & Layout combo solutions currently available for editing text in Drupal. Solutions that only manage to make the entire workflow... discouragingly complex. Especially if it's rich web content that editors need to create via the Drupal admin UI. And this is precisely the context where the Drupal Gutenberg project was born: Drupal desperately needed/needs a modern, JavaScript-based admin UI. With WordPress 5 users already enjoying this fancy content editor and the Frontkom team's having gained experience in using it, the idea of porting it to Drupal started to form: "Why wouldn't we make it possible for Drupal users, too, to benefit from this content editor?"  And here are some of the original Gutenberg project's features that lead them into thinking that, once ported, the editor would significantly improve the editing experience in Drupal 8:   it's (highly) decoupled it's open-source it's React.js-based  it provides a simplified, smooth and cool functionality-packed admin UI it's Medium and Squarespace's inspired it turns the creation of complex landing pages into a breeze   Page editing in Drupal 8 wasn't going to be the same again! Their initiative turned into a Drupal 8 module —  Gutenberg Editor —  currently still an experimental one.  Curious enough? The first step to satisfy your curiosity is to take a look at their live demo: an interactive glimpse into the Gutenberg text editor implemented in Drupal 8.   2. The New Gutenberg for Drupal: Top Features Improving the Editing Experience in Drupal 8   2.1. All the Page Elements Are... Content Blocks That's right, the team behind this project capitalized on the “everything is a block” Drupal 8 concept when adapting the Gutenberg UI to Drupal. The result? Both the Drupal core blocks and 20+ Gutenberg blocks are available in the resulting admin UI. Basically, a Drupal 8 editor can insert into the web page that he/she's creating any of the core Drupal blocks and of the Gutenberg blocks of choice. Speaking of which, let me point out just a few:   Heading Image gallery Auto embedded social posts Buttons Custom Drupal blocks Layout blocks   Needless to add that you're free to enrich this list with your own custom blocks, too.   2.2. Easy Switch from Visual to Code Editor That's right, the Gutenberg UI enables you/your editors to quickly switch to code editor —  opening up a neat markup —  and to apply any needed tweaks on the output.   2.3. Positioning Content Is Straightforwardly Intuitive Editors get to select precisely where they want to position different types of content on a page. And the very same results that they generate while in the Gutenberg admin UI get instantly reflected on the live web page, as well. And there's more! More great admin features improving editing experience in Drupal. For instance: Full control over font sizes and colors; tweaking them becomes a breeze with the new editor.   2.4. There's a Blocks Search Box And not only that:   using this search box you can track down precisely those content blocks that you need to add to your page but you can access them inline, as well, using “/”.   2.5. Full Control of the Layout Another great thing about the content blocks available in the Gutenberg UI is that: they can have child blocks, too! This way, it'll get unexpectedly easy for your editors to split their used blocks into columns on a grid.   2.6. Auto Embedded Social Posts/Videos And all it takes is pasting their URL.   The Story of a Real Challenge: Making Gutenberg CMS-Agnostic Open source, but not fully CMS-agnostic...  The team behind the Drupal Gutenberg project had to come up with a suitable solution for this challenge. And they did come up with a multi-step solution to make the fancy text editor work in Drupal 8, as well:   first, they created a fork and removed the WordPress specific features they used the Gutenberg editor as a dependency  next, they set up a standalone NPM package then they built the Gutenberg Editor module   In short: a fork of the initial Gutenberg project is still maintained while being used as a dependency of the new Drupal 8 module. Therefore, each time Gutenberg gets an update, the corresponding Drupal module, too, gets a new release. Now, digging deeper into the project's architectural design, we discover 2 elements that the team had to re-write for Drupal:   the URL defining the editor routes (edit page route, new page route, preview page route) the API-request, now configured to “talk to” Drupal (instead of the WordPress API)   How does the new module work?   as a text editor, which can be easily enabled for each content type all it takes is a long text field for it to work: it replaces the node edit UI for that specific content type   Note: the Frontkom team also “promises” us to re-use many of the Drupal-specific stylings for the editor's UI elements in order to add a familiar Drupal feeling to it.   What Next? What's The Project Roadmap Ok, so what we know for sure now, regarding this ambitious initiative turned into a Drupal module is that:   the Drupal Gutenberg module is downloadable, yet still experimental (for developer use only) the team's still working on the project, implementing new features and functionalities aimed at making it feel more... Drupal native the final version will be presented to the eager/intrigued/curious/skeptical Drupal users and developers in the coming months   The END! Can't hide that I'm more than curious what you think about this contrib solution for improving the editing experience in Drupal 8:   Are you looking forward to using it, hoping that this editor would make up for the inconvenience of working with Drupal's current admin UI? Are you skeptical about the perspective of being tied up to a WordPress page builder?   ... Read more
Adriana Cacoveanu / Aug 17'2018
How to Get Gatsby to Work with Drupal: Building a Gatsby Site with a Decoupled Drupal Back-End
Just imagine: putting together the powerful UI creation tools of a static site generator — more of a modern front-end framework rather —  built for high speed, like Gatsby.js, with Drupal 8's content modeling and access system! Putting their powers together into a blazing-fast website! But how to get Gatsby to work with Drupal? How do you build a plugin that fetches data from API-first Drupal? In short: a static, conveniently simple, yet robust Gatsby site powered by a powerful, decoupled Drupal back-end? You've got the questions, we've got the answers... And we've grouped all our answers to your questions regarding “API-first and decoupled Drupal in connection with Gatsby” in a straightforward 4-step tutorial. One on building a high-speed Gatsby website backed by a versatile headless Drupal CMS. Shall we dig in?   1. But What Is Gatsby.js More Precisely? The standard, rather rigid definition would be: “It is a GraphQL-fueled, React-based static site generator.” Now if the words “static site generator” just make you... cringe, here's a more nuanced definition for you: “Gatsby's more of a modern front-end framework —  one pulling together the best parts of GraphQL, React, webpack, react-router — built with the developer experience in mind.” In short: it's a static site that this “more than just a static site generator” helps you build, leveraging its out-of-the-box front-end tools. A website geared to reach fast page loads while pulling data from a decoupled Drupal CMS. And there are 2 basic steps for getting started with Gatsby. You simply write your site's code structure and let Gatsby handle the rest:   turn it into a directory with a single HTML file … along with all your static assets 2. 3 Reasons Why You'd Want to Use Gatsby … instead of Jekyll, your webpack config or create-react-app.   a. Because of the richness of the Gatsby ecosystem With rich documentation at hand and backed by an already large community of starters, you'll get your Gatsby site up and running in no time.   b. Because it leverages GraphQL' power to build its data layer. And this is one of those heavy-weighting reasons for using Gatsby over other competing alternatives: Gatbsy's built to fetch data from... pretty much anywhere — your CMS of choice, Markdown, third-party APIs, Markdown — using “source” plugins. When creating its data layer, it relies on GraphQL, which builds an internal server of all this pulled data. In short: when questioning yourself “how to get Gatsby to work with Drupal”, do keep in mind that in your future Gatsby & decoupled Drupal setup data gets queried from the same place, in the same way, via GraphQL.   c. Because it's built for high speed. And this is one of Gatsby's hardest-to-resist-to advantage: It's just... fast. And that gets reflected in your final Gatsby & decoupled Drupal site while bubbling up to the user experience, as well. Summing up, these are the 3 strongest reasons why you would be tempted to use Gatsby with Drupal CMS.  I'm not going to engage in dynamic sites vs static sites debate now. The internet's already overcrowded with such comparisons. I'll just end this “pledge” on using Gatsby with a non-debatable statement: Since a static site generator pre-generates the pages of your website, scales of performance vs maintenance costs gets unbalanced. And guess which one's going up and which one down!   3. And Why Would Pair Gatsby with Drupal? If there are strong reasons why you should be getting started with Gatsby, why is there any need to consider decoupled Drupal CMS for its back-end? Because static site generators don't “care” much for the authoring experience. Content editors have to get themselves tangled up in Markdown for creating content. True story! And this is where powerful CMSs, such as Drupal, step in, “luring” you with their: WYSIWYG editors content types  content modeling capabilities access workflow capabilities … to make your content team's lives easier! And now your “How to get Gatsby to work with Drupal” dilemma turns into a new legitimate one: How to make your Gatsby website cope with a decoupled Drupal setup without adding the “dread” of a database and web server to the equation? 2 elements that “pave the path” for performance and security issues... Well, this is precisely what this “decoupling Drupal with Gatsby scenario means to avoid: you'll get to host your Drupal CMS in-house … and thus take full advantage of the robustness and versatility of a decoupled Drupal CMS back-end your Gatsby website will fetch data from its Drupal back-end and generate content “the static way” (which translates into “incredibility fast page loads”)   4. How to Get Gatsby to Work with Drupal More Precisely Or simply put: how to pull data/content from Drupal into your Gatsby website? Here's a straightforward tutorial in 4 steps on how to integrate Drupal with Gatsby:   4.1. First, Build Your Drupal Server  Assuming that you have a Drupal 8 website installed, the very first step to take is to:   a. Create a new content type  For this exercise, it's a blog — including all its blog posts — that we'll try to transfer from Drupal to Gatsby. So, we'll name our content type: “Blog”. It will include 3 basic fields: title body image Just navigate to Home>Administration>Structure>Content Types.   b. Turn Drupal into an API Server  And there are 2 key modules that you'll need to install:   jsonapi_extras: for gaining more control over the API (to disable resources, to change the default endpoint, to enhance field output etc.)  jsonapi, which will turn your Drupal website into an API server (one having a default endpoint)   c. Grant Anonymous User Permission to Access the JSON API resource list If you overlook this step, you'll end up with an “Error 406” message, which will just sabotage your whole “decoupling Drupal with Gatsby” mission.   d. Check How Your Drupal API Server Works  You can do this by navigating to http://[your-site]/jsonapi logged in as an Anonymous user. If the page that you'll get displays all the information regarding your API server, then you'll know you're on the right track.   4.2. Then, Create a New Gatsby Site But before you jump to building your new static website, check whether you have npm and node installed on your PC.  How? By entering “npm  -v” and “node  -v” into your terminal. Next, you'll need to install Gatsby's CLI:   npm install --global gatsby-cli Then, just build and get your Gatsby site up and running. Note: by default, it will be accessible at localhost:8000. 4.3. Decouple Drupal with Gatsby: Pulling Data from the API Server   a. Set up the (/blog) page Solving your “How to get Gatsby to work with Drupal”  type of dilemma starts with... the creation of a new page on your Gatsby website. And is as simple as... setting up a new JS file. Note: all your Gatsby pages will get stored under /src/pages. Now here are the basic steps to take:   create the blog.js in /src/pages then add this code: import React from "react" const BlogPage = () => ( <div> <h1>Latest from our bog</h1> </div> ) export default BlogPage    Voila! You've just created a new page at /blog.   b. Pull Content from the Drupal 8 site using GraphQL The “gatsby-source-drupal” plugin, to be more specific. It's this source plugin that will be “in charge” with all the data (images here included) pulling from decoupled Drupal back-end and pushing into your Gatsby site. Note: do keep in mind that, in this case, the JSON API module plays a crucial role. And here's how you install your “power” plugin:   // in your blog.gatsby folder npm install --save gatsby-source-drupal Next, just configure your newly installed plugin:   // In gatsby-config.js plugins: [ ... { resolve: 'gatsby-source-drupal', options: { baseUrl: 'https://goo.gl/Cc5Jd3 apiBase: 'jsonapi', // endpoint of Drupal server }, } ], Tada! Now your site should be functioning properly. If... not quite, here are the causes of the 2 most common error messages that you could get:   “405 error”, check whether the jsonapi_extras module is enabled “ 406 error”, have a closer look at the permission on your Drupal site   c. Configure GraphQL to Pull Specific Pieces of Content from Drupal In other words: to query all the “blog” nodes from Drupal and request specific data from the API server. Another strong reason for using Drupal CMS with Gatsby is that the latter provides an in-browser tool for testing GraphQL queries names, for writing and validating them. You can access it at localhost:[port]/___graphql, whereas in our particular case here at: localhost:8000/___graphql. Now, as you're solving this “How to get Gatsby to work with Drupal” type of puzzle, just try to query all the blog nodes. Next, navigate back to your blog.js file and run this query:   export const query = graphql` query allNodeBlog { allNodeBlog { edges { node { id title body { value format processed summary } } } } } ` Then, update your const BlogPage so that it should display the body, content, and title: const BlogPage = ({data}) => ( <div> <h1>Latest from our blog</h1> { data.allNodeBlog.edges.map(({ node }) => ( <div> <h3>{ node.title }</h3> <div dangerouslySetInnerHTML={{ __html: node.body.value }} /> </div> ))} </div> ) Next, save your file and... “jump for joy” at the sight of the result: All your blog posts, nicely displayed, pulled from Drupal and published on your Gatsby site!   4.4. Finally, Just Go Ahead and Publish Your New Gatsby Site And here you are now, ready to carry out the last task of your “How to get Gatsby to work with Drupal” kind of “mission”.  This final task is no more than a command that will get your Gatsby website running: gatsby build Next, just run through your /public folder to see the “fruits of your work”. At this point, all there's left for you to do is to copy/push content in /public to the server and... deploy your new website using Gatsby with Drupal CMS. The END! This is how you do it: how you use Gatsby.js in a decoupled Drupal setup so you can benefit both from: a modern static site generator's robustness and high performance, built with developer experience in mind  a powerful CMS's content managing capabilities, built with the editorial experience in mind  ... Read more
RADU SIMILEANU / Aug 13'2018
10 Essential Modules to Start Building Your Drupal Site from Scratch: Toolkit Must-Haves
So, you've installed your version of Drupal and you're now ready to actually start building your website. What essential tools should you keep close at hand, as a site builder? Which are those both flexible and powerful must-have modules to start building your Drupal site from scratch? The ones guaranteeing you a website that:   integrates easily with all the most popular third-party services and apps is interactive and visually-appealing, irrespective of the user's device is a safe place for users to hang on, interact with, shop on, network on... is conveniently easy for content managers and admins to handle   Luckily, there are plenty of modules, themes and plugins to overload your toolbox with: Long gone are the code-centric webmaster's “glory days”! Nowadays, as a Drupal site builder, you have a whole array of tools at your disposal to just start building and getting a Drupal site up and running in no time. Sometimes without the need to write a single line of code! But, let's not beat around the bush any longer and have a close look at these 10 essential modules that you'll need for your “Drupal 8 site building” project:   1. Password Policy Definitely a must-have module: Just consider that Drupal accepts ANY user password, be it a... one-letter password! So, in order to set up your own stricter and safer password policy, you need to install this module here. Then, you can easily define:   the minimal (and maximal) no. of characters that any user password on your Drupal site should include the no. of special characters that it has to include specific restrictions Like: "one can't use his/her email address as his/her password"   2. Comment Notify Why should this module, too, be in your essential toolkit of modules to start building your Drupal site with? Because it implements the functionality to get notified — you, the admin or content manager —  as soon as a user posts a comment on the website. Note: you can get “alerts” about both the logged in and the anonymous visitors' comments.   3. Breakpoints, One of the Must-Have Modules to Start Building Your Drupal Site  It goes without saying that one of the Drupal site building best practices is providing it with a responsive web design. And this is precisely what this module here facilitates: Setting the proper media queries, once you've defined your own breakpoints.   4. Simple Hierarchical Select             A module whose functionality bubbles up to the content manager's experience. Whenever he/she will have to make a selection involving both categories and subcategories, this hierarchical type of selection will prove to be more than useful: Practically, once you/they select the “main” option, a new drop-down menu/widget including the subcategories to select from, pops up, as well. Like in the image here below: 5. EU Cookie Compliance And complying with this EU notification is mandatory.  So, this is why EU Cookie Compliance is another one of the essential modules to start building your Drupal site with: It displays the given notification — providing visitors with the option to agree or/and to read more information about your cookie policy —  in the footer of your website.   6. Shield               Any Drupal site building guide would advise you to install a module that shields your website from anonymous users and search engines when running your test environments. And this is what Shield is built for: To screen your site from the rest of the world —  except for you and the logged in users — when you deploy it in a test environment. A more than convenient method, as compared to manually setting up a .htpasswd and then integrating it with .htaccess.   7. Beauty Tips     If you're not just another Drupal site builder, but a user experience-centric one, you must consider also those modules to build your Drupal site with that boost the level of user interactivity. Like Beauty Tips here. It displays balloon-help style tooltips whenever a user hovers over a certain text or page element on your website. Pretty much like Bootstrap tooltip does.   8. Secure Login           Another one of the Drupal site building best practices is to turn it into a safe place for your users to be.  In short: to protect their privacy. And if you're building a website that's available on both HTTP and HTTPS, the Secure Login module comes in handy as it makes sure that:   the user login form all the other fill-in forms that you'll configure for extra security   … get submitted via HTTPS. It locks them down, enforcing secure authenticated session cookies, so that user passwords and other critical user data don't get exposed all over the internet.   9. Menu Target   It's another one of those essential modules to start building your Drupal site with if you're determined to provide the best user experience there. What does it do? It enables particular visitors on your site — those granted permission to edit and to add new menu items — to choose whether they open menu items in new windows or in the current ones.   10. Persistent Login A module that makes up for the “Remember me” feature that's missing from the user login screen in Drupal: It comes to implement this missing option, one independent from the PHP session settings. So, we're not talking about the conventional, too long “PHP session time” here, but about a more secure and user-friendly “Remember me” feature added to the login form. Furthermore, the module enables you to define some extra security policies, too:   the no. of persistent sessions that a Drupal user can enjoy at the same time specific pages where users still have to log in again after how long the logged-in users will need to re-enter their credentials once again   And 2 “Extra” Modules to Consider When Building Your Drupal Site By “extra” I mean that they're not really essential modules to start building your Drupal site with. Yet, they're the first 2 ones to consider right after you've put together your “survival” toolkit as a site builder:   1. Site Settings & Labels     Take this common scenario: You need to display a social network URL on multiples pages on your Drupal site.  What do you do?   you hard coding this single setting in the source you start building a custom Drupal module for handling this variable you install the Site Settings & Labels module and thus display a checkbox to render page elements through a template conditional   The “c” variant's undoubtedly the winner here.  A win-win for you, in fact:   you save the time you'd otherwise have spent coding you improve the user experience on your Drupal site   2. Slick/Slick Views/Slick Media           It's actually a suite of modules to start building your Drupal site with. One “injecting” the needed functionality so that you can easily set up:   carousels slideshows   … on your freshly built website. Note! I won't lie to you: setting up the library dependencies is not exactly a child's play. Yet, once you've succeeded it, configuring the modules in this suite, right in your Drupal admin, is piece of cake. The END! These are the 10 must-have modules to start building your Drupal site from scratch with. Would you have added some more?  Or maybe you wouldn't have included some of the modules listed here, as you don't consider them “essential”? A penny for your thoughts! ... Read more
RADU SIMILEANU / Jul 20'2018