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.

What Is the Best Magento 2 Product Reviews Extension? Top 5
Let's just say that the default product review system in Magento 2 is... well... not 100% satisfactory for you. It does have its limitations; there might be some particular product reviewing and rating features that it can't provide you with. So, you start looking for an extension to compensate for this... inconvenience. But which one to go with? What is the most suitable Magento 2 product reviews extension for your own eCommerce store's needs? And it takes just a brief scanning of the large “pile” of Magento 2 extensions to start experiencing choice overload: How do you know which one's the best for your eStore? Which one suits your own idea of an “ideal” reviews system? But what if we narrowed them down to 5 choices only? The 5 best Magento 2 review extensions to start your searches with:   But First: The “Ideal” Magento 2 Reviews System —  Main Characteristics What features should the reviews system on your eStore have to meet all your expectations? Let me guess:   reviews should be accompanied by the customers' real names, photos and maybe even a link to their social media accounts, as well customers should be able to rate products on a “pros & cons” scale the reviews section should be easily noticeable on page the reviews system should empower you with the proper tools to use for encouraging customers to insert informative, relevant reviews only … needless to add that the UI of the add review screen should be highly intuitive the reviews should show product photos, as well the reviews system would enable you, the admin, to easily sort product reviews by relevance/helpfulness   The Default Magento Product Reviews Feature: How Does It Work? Before we delve right into the mini pile of Magento 2 product reviews extensions that I've prepared for you here, let's see: How does the default reviews functionality work in Magento 2? On the user's side, he/she writes down his review in the text description field popping up once he's rated the product from 1 to 5. Whereas on the admin's side, you get to configure those ratings at Stores > Attributes > Rating, right in your Magento 2 admin dashboard.                                        Images: Potatocommerce.com   The Advanced Review for Magento 2 Extension  You cannot run your evaluation of the best rated Magento 2 product reviews extensions and skip this module here. Why? Here are the top reasons for considering it:   it provides a detailed product reviews system, with pros and cons it makes it possible for the published reviews to be rated as helpful/unhelpful … and to be shared across social media networks, as well it features review captcha and report reviews, helping you minimize the risk of fraud and spam it boosts the product reviews system with custom rating values (quality, price and so on)   The Import/Export Product Reviews Extension  A handy Magento 2 extension if you're “juggling with” multiple online stores. Basically, it enables you to import/export product reviews from one eStore to another via CSV file.  Note: while importing them, you, the admin, get to set their status using the CSV file The extension's most valuable features:   it makes it possible for reviews to get transferred along with their titles and descriptions via CSV file it supports a multi-store environment it empowers you, the admin to approve/disapprove the submitted reviews   Magento 2 Review Booster: The Best Magento 2 Product Reviews Extension?  Another product reviews and rating extension for Magento 2 that you shouldn't overlook while determining your best option. And here are some of its main functionalities:    pros and cons  reviewing the written feedback's helpfulness uploading images to product reviews the possibility to “lure” customers with different discounts/coupons for reviewing the products they buy review reminders adding comments to product reviews sorting product reviews by rating   The Magento 2 Product Reviews Extension  Another extension that has the potential to get you closer to that “ideal” Magento 2 reviews system of yours. Here's how precisely:   it enables customers to upload images of the product review form (no registration required) it's ideally easy to install & manage you get to integrate the product review functionality through a widget you, the admin, get to review the uploaded images' widths & heights   The Magento 2 Review Reminder Extension   Now, could you imagine the reviews system on your Magento 2 website without a powerful review reminder type of tool plugged in? I didn't think so... They make such handy tools to help you encourage customers, via email reminders, to post reviews for the products they've bought. Now, here are the key features of this specific tool here, an essential Magento 2 product reviews extension:   targeting specific groups of customers that you'd send your email reminders to sending automated reminder emails using coupons to entice customers to share their first product reviews and even choosing its template cleaning log records automatically, after a specific no. of days setting up the right time for sending the first reminder email   The END! These are the 5 best Magento 2 review extensions to add to your shortlist and start your “research” with.    feature-rich powerful easy to set up and customize on your side easy to use on your customers' side   … each module, taken separately, injects those product reviews functionalities into your store to help you enhance the built-in reviews system that the platform provides you with. ... Read more
Silviu Serdaru / Sep 13'2018
Designing for a Global Audience? 5 Things to Consider for Making Your Website Internationally Friendly
Designing for a global audience should be straightforward simple, right? You'd just translate the written content on your current website into all the different languages of your target audiences and you're good to go... Well, not even close. Closer maybe, but definitely not close.  For, as the Globalization & Localization Association (GALA) says it, far more accurately than I could: “The aim of localization is to give a product the look and feel of having been created specifically for a target market, no matter their language, culture, or location.” And proper localization (or contextualization, if you prefer) is precisely what you should aim for when trying to reach a global audience. Now, making your website internationally-friendly is subject to a lot of considerations; translating the written content into different languages is but one of the many steps to take. Let me point out to you just 5 of the essential ones to keep in mind:   1. Can Your Current Web Hosting Solution Handle That Amount of Traffic? Let's take this hypothetical (yet not impossible) scenario: You've been selling custom-designed stationary in Canada for a while now. Your eCommerce website's server is in Vancouver. Still, your Canadian customers just don't seem so “mesmerized” with your hand-crafted products as you expected them to be. So, what do you do? You go global! You start selling your stationary in... South Korea, as well, and online orders start to ramp up.  But your web hosting provider doesn't have servers in Asia, as well, to back you up with, and so the page loading speed on your website gets close to... lousy. There are scripts, files, images to be loaded and to all these all too common heavy-weighing factors, now you add the distance factor, as well...  Your server just can't handle it... In this hypothetical case here, you have 3 viable solutions at hand:   you supercharge your website with a CDN for high speed you replace your current provider with another one that can provide you web hosting globally you upgrade your current hosting plan, opting for one that can handle higher volumes of traffic   It's up to you how you'll equip your website to cope with the expected larger-than-normal amount of traffic.   2. Is the Used Imagery Culturally Relevant for Your International Audiences? And yes, when designing for a global audience you need to consider this aspect, as well: Will all the international audiences that you're targeting resonate with the images displayed on your website? Do these images convey the same message, irrespective of culture, location, spoken language...? Are there any culture-specific meanings or symbols that you might have overlooked? Make sure they're not “packed with” references that a global audience wouldn't understand. Or risk misinterpreting... And, above all: Take your research seriously when you're planning to reach global audience; ensure your site's imagery can't get interpreted as offensive in some of the cultures that you're targeting.   3. What Do Your Chosen Colors Symbolize in Different Cultures? Make sure that you base your color choice on an in-depth research on the color symbolism in different cultures. And not solely on aesthetic aspects. In this respect, the examples of colors having both positive and negative connotations, depending on the cultural area, are numerous: Take white, for instance, a color that means both cleanliness, innocence or/and... death (in China). Choose your color palette wisely and do not leave the selection up to your designers entirely. Designing for a global audience is no more than a compromise, after all: You trade visually-striking design for a globally-relevant one. One that's both... global and local.   4. Remember to Use Hreflang Tags when Designing for a Global Audience  Why bother?  Well, you could take the hreflang tags as some kind of “traffic signs” indicating to  the search engines:   that the content on your website has been translated into multiple languages precisely which version of that content they should deliver to your site's visitors, depending on their location   As for how you can add them to your site's content, the Moz team has a more than “enlightening” blog post on the topic of hreflang tags, so I'm not going to get into details here. Now, let's move on to the last point on my list of aspects to pay attention to when designing for a global audience:   5. Is Your Website Optimized for Globally Accepted Keywords? And “globally accepted” sure doesn't come down to: Showing the translated version of each one of your target keywords each time it shows up. Now, let's take this common example: What if you're optimizing one of your site's pages for the keyword “dinner recipes”, but in some parts of the USA the equivalent “supper” is more frequently used? Then, you'll need to:   do your own research on all the possible keyword variations  account for them when doing keyword optimization on your website's pages   Et voila: these are just 5 of the essential aspects to consider when designing for a global audience. As you can see, translating the words on your website is just the very base of the “pyramid” of techniques to apply for avoiding common gaffes when you go global. That if you want to do it the right, of course... Photo by Kyle Glenn on Unsplash. ... Read more
Adriana Cacoveanu / Sep 11'2018
Should I Use Docker in Production Environment? Is It Safe? 
“Should I use Docker in production?”  Are you "torn” between: Docker's superpower as a container platform and all the security concerns related to the Docker model? “Seduced” by the names of all those giant companies — Twitter, Google, Amazon, eBay, Netflix —  who're already using Docker containers in production? Yet, still skeptical and hesitant to run them in production environment considering all the signaled data management issues?                     Now, instead of letting this question turn into a “haunting” dilemma, you'd better dug for some answers. Find out:   whether Docker is right for your own unique project, as well how a container infrastructure works (compared to a traditional environment)  what it takes to use Docker in production which are the common misconceptions and issues with Docker in production   And, most of all: based on your own use case, should you be running Docker in production environment or not?   1. The One Question to Ask Yourself: “What Will I Do with Docker in Production?” Before asking yourself:  “Should I be using Docker in production? How safe is it?” … you'd better answer one critical question: “What will I do with Docker in production?” And toying with the thought of using Docker containers does require a reevaluation of your system's whole infrastructure. From the ground up:   How will you monitor Docker containers in production? How will things be deployed? How will backups be performed? What about updates? How will they be handled?   Also, while giving yourself some realistic and straightforward answers to all these questions, try to consider different attack vectors, as well:   What services will your Docker containers get access to? Are you able to restrict their access to the host system? And what kind of “privileges” will they get?      So many things to clarify before you can ask yourself: “Should I use Docker in production?”    2. Container Infrastructure vs Traditional Environments How does a Docker container infrastructure work? It's critical that you fully understand what sets it apart from a traditional environment before you can assess whether it's safe for production usage in your project or not. Unlike traditional environments, where a sysadmin would normally run upgrades and restart services, in container infrastructures, containers are read-only, immutable... elements. In other words: security upgrades won't happen inside your Docker containers; for these upgrades to run, you'll need to redeploy newly upgraded versions of your containers. Note: since developers can push containers to your platform, you should define and enforce custom policies to limit the no. of privileges assigned to each one of the containers in your infrastructure.   3. 2 Most Common Misconceptions about Using Docker in Production Since it hit the systems scene (2002) and quickly “stole the show”, Docker's generated a lot of misconceptions. And probably the most common one (that all the other ones stem from) is that: "Docker's ridiculously easy to use; it's a “one size fits all projects/use cases/infrastructures...” type of technology." Well, not quite... Now, let's “bust some Docker-related myths” once and for all:   3.1. Running Docker in Multi-Host Production Environments Is (So) Simple It's almost grown into a universal truth that: Using Docker even in a multi-host production environment is... nothing but a child's play. It is technically possible, indeed, yet, it's far from simple! Before running Docker in a multi-host network —  in a robust and safe way, I mean —  you need to consider and to put in place the proper management of a whole lot of variables:   orchestrating container deploys with no downtime at all managing container logs ensuring that the private image repository's 100% secure managing container logs properly handling all container deploy roll-backs   And the list is almost a never-ending one... See? Sure, big companies manage to use Docker in multi-host production environments and to successfully handle all the above variables, yet the process's anything but trivial.   3.2. It's OK to Blindly Jump into Docker, No Matter The Infrastructure Tempted to go from “Should I use Docker in production?” to “I should/can definitely use it straight away!”? And this is yet another misconception that has grown out of the general idea that using Docker requires zero preparations; zero planning and evaluation of your current infrastructure. That it's conveniently easy to use and it fits all use cases. Wrong!  You need to take a whole lot of aspects into account before using Docker in production: It requires a robust, stable foundation/infrastructure! In other words, if your current system does not have:   an automated system setup  a fully secured least-privilege type of access automated deploys easy-to-be-restored and 100% secure database backups and more   ... you should reconsider using Docker in production ASAP. Or at least postpone your plan till you've filled in all those cracks in your systems' infrastructure...   4. Choosing the Right Path From Test Environment to Production Environment The very first step to take for “leveling up” from running Docker in your test environment to using it in production is: choosing the right path. This can be either:   predetermined by your own project's particularities (project-specific constraints such as a specific cloud service or datacenter)  DIY a rented cloud service a pre-made platform   Choose your path wisely!   5. 3 Key Aspects to Take into Account For a Smooth Production Usage of Docker   5.1. The Docker Engine: Tweaking Its Default Settings Is a Must As I've been trying to stress out here: Running Docker in production does require certain preparations and considerations. For instance, once you install the Docker engine to your distribution of choice (Ubuntu or Red Hat or... another one), you shouldn't stick to its default settings. They're not suitable for production usage! Therefore, it will require some tweaking so that your Docker engine can handle the load once in production environment. Moreover, your engine will be in charge of running the containers and nothing more. When it comes to:   cleaning up containers … volumes … logs   … these are all your configuration's responsibility. And 2 more words of caution/pieces of advice:   keep in mind to check the graph driver (go for Overlay2 if it's the latest version of kernel that you're using) keep both your Docker engine and the kernel safely up-to-date    5.2. A Well-Built CI/CD Pipeline Can Save Your Life And it's just partly an exaggeration... For once you run your Docker containers in production and you need to handle a complex infrastructure of services, having a reliable pipeline in place can do wonders. In short: if you don't automate the process of moving your containers across all the 3 stages of production — build phase, test phase, deployment phase — you'll go nuts... Tip: remember to script everything; also, to version control each and every script and configuration.   5.3. Security: Handle It Properly, Right from the Testing Environment In other words: no matter how tempted you might be to overlook this aspect once you finally have Docker running properly in production, don't underrate the security issue. Moreover, you should give it due consideration right from the testing environment... Once you deploy your Docker containers in production environment, be 101% cautious and vigilant to detect any network vulnerabilities threatening your data.   6. “Should I Use Docker in Production?” Is It Safe? Is It Efficient? Back to our initial question: “Is it safe to run Docker in production environment?” My answer to you is: It is, as long as you take into account all the above-mentioned technical aspects and variables and as long as you adopt the best practices for using Docker in production. Meaning:   applying updates running your CI tests automating... everything closely monitoring your Docker containers once in production using the available tools running only current versions running only one process per container  “supercharging” your orchestration tool with all the appropriate security measures (Kubernetes, Swarm, Titus, DCOS etc.)  etc.   In short: Docker is only as safe as its users' implemented safety measures. Technically, it can be used in production.  When it comes to safety, Docker's come a (really) long way since its early days.  With:   a whole set of best practices in place appropriate powerful tools to use for securing it ... Docker's once glaring security flaws (e.g. less isolation of containers as compared to virtual machines) now seem like a bad memory from its old “experimenty” stage. Yet, to your “Should I use Docker in production?” type of question I can only answer: “You should, if you don't do it blindly and you commit yourself to following the best practices”   7. In Conclusion... If I was to sum up, into a “shortlist of commandments”, all the recommendations, words of caution, clarifications, and explanations here-above, it would go something like this:   don't jump blindly into Docker; take your time to think through all the involved aspects keep in mind that it's far more unlikely for an attacker to exploit an insecure Docker container in your system than to... tap into social engineering for getting his hands on the password Docker's an extremely powerful tool, so running it on top of an unstable infrastructure is pretty much like driving a sports car on a pothole-riddled road ... Read more
RADU SIMILEANU / Aug 31'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
10 Drupal SEO Mistakes You Do Not Want to Make on Your Website: From Least to Most Harmful- Part 1
You have made, are currently making and will continue to make various Drupal SEO mistakes. From those easy to overlook gaffes to (truly) dumb neglects, to critical mistakes severely impacting your site's ranking...  Just face it and... fix it!  And what better way of becoming aware of their impact on your site than by... getting them exposed, right? By bringing them into the spotlight... Therefore, here are the 10 SEO mistakes you really don't want to make on your website: the “culprits” for your site's poor ranking. Take note of them, assess their occurrence/risks for your Drupal site's SEO and strive to avoid them:   1. Overlooking or Misusing Header Tags Do it for the crawlers or do it for your site visitors. For whichever reason you decide to structure the content on your web pages using H1, H2, H3 tags, Google will take note of your efforts... And it all comes down to setting up an SEO-valuable hierarchy on each page on your Drupal site. One that:   crawlers will painlessly scan through, which translates your website getting indexed more quickly users will find conveniently “readable”, which bubbles up to the overall user experience   Note: one of the worst SEO gaffes that you could make —  one that would confuse the crawlers and intrigue the site users — would be to use multiple H1 tags on the very same page.  It's one of those silly, yet harmful rookie Drupal SEO mistakes that you don't want to make!   2. Duplicate Content: It's Literally Killing Your SEO Now, speaking of running the risk to confuse the crawlers in your Drupal site, duplicate content makes the "ultimate source of confusion” for search engines. And how does this show on your site's SEO?  Basically, since the crawler can't identify the right page to show for a specific query, it either:   "refuses" to rank any of them or applies specific algorithms to recognize the "suitable" page for that search query   Needless to add that the second decision is discouragingly time-consuming, while the first is simply... disastrous for your site's ranking. "But how did I end up with duplicate content on my website in the first place?" you might ask yourself. Here are 3 of the most common causes:   HTTP vs HTTPS  URL variants WWW and non-www pages   Now, since an identified and acknowledged mistake is already a half-solved one, here's how you can get it fixed:   just set up a 301 redirect from that web page's primary URL to the new one set up a rel=canonical attribute on the old URL, one that would let search engines know that they should handle the new URL as a duplicate of the original one   Note: It goes without saying that all metric records and all the links that search engines will have monitored on these two duplicate pages will then be automatically attributed to the original URL.   3. Optimizing for the Wrong Keywords And this sure is one of the most frequent Drupal SEO mistakes, that goes back to: Not investing enough resources (of time mostly) in a proper keyword research strategy. And no, trying to rank for the prime keywords isn't a foolproof action plan! The result(s)?   you end up targeting all the wrong keywords you optimize your site's content for all the wrong terms, that your target audience isn't actually searching for   Wasted efforts for putting together non-targeted (or not properly targeted) content... Instead, invest time in identifying and then ranking for the right search terms. For yes, it will take longer to carry out a proper keyword process and for your site to start ranking for those keywords. But it won't be wasted time...   4. Having Pages with Duplicate Title Tags on Your Drupal Site Here's another way of confusing crawlers even more: Faced with two separate web pages having the same <title> tags, search engines won't know which one of them stands for a specific search query. And their confusion only risks to lead to your Drupal site's getting banned... Moreover, it's not just search engines that will get discouraged by the duplicate titles, but site visitors, too. They won't know which is the “right” page to access. “OK, but how can I get it fixed?”   you install and turn the Metatag module on you craft and give each page on your Drupal site a unique title    5. Ignoring Robots.txt: One of the Common Drupal SEO Mistakes Now, before answering your otherwise valid question: “Why do I even need Robots.txt file on my Drupal website?” … we'd better see what this protocol brings, right? Take it as a standard that websites use to communicate with crawlers and web robots “in charge” with indexing their content. It's this file that points out what web pages should be crawled and indexed and which ones should be skipped. Now, if it's a blog that you own, ignoring this protocol isn't one of the biggest Drupal SEO mistakes that you could do. But if it's a larger Drupal site, with a heavy infrastructure of web pages, that you're trying to optimize, then having Robots.txt file makes all the difference... Tip: do consider installing the Robots.txt module for streamlining the efforts of making your site “crawling-friendly”. END of Part 1! Stay tuned for I'll be back with 5 more Drupal SEO mistakes — ranking from seemingly harmless to critical — that you definitely don't want to make on your website. ... Read more
Adriana Cacoveanu / Aug 24'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
3 Essential Steps to Convert Your Website to a Progressive Web App
Thinking to convert your website to a progressive web app? And why shouldn't you? Since the benefits are obvious:   you “end up” with a website behaving like a native web app … one that works offline (and “offline” is the new black these days, right?), having its own home-screen icon  improved user experience: not only that your site goes mobile, but users don't even need to get your site-turned-into-an-app downloaded from an app store and then installed on their devices   Furthermore: Putting together a PWA out of a regular website (or blog) is unexpectedly easy! Basically, any site/blog can be turned into a progressive web app... No need to let yourself discouraged by terms such as:   service workers web app manifest (or “manifest.json)   … for the whole process is actually far less complex than it sounds. Here, see for yourself: go through the 3 essential steps it takes to convert your website to a progressive web app:   But First: All You Need to Know About PWAS— Benefits & Common Misconceptions A succinct and clear enough definition of progressive web apps would be: A PWA is a website that behaves like a native mobile app once visited on a mobile device. Whereas a more detailed and comprehensive one would go something like this: A PWA is a sum of modern web capabilities (and basic mobile capabilities) that enable users to save it on their own mobile devices (thus enjoying a native app-like experience) and access it offline, too. And now, without getting into the old “native mobile app vs PWAs” debate, let me point out to you some of progressive web apps' most “luring” benefits:   as compared to native apps, the setup process, on users' end, is significantly simplified: PWAs get instantly installed on their home screens, with no need to visit an app store for that they can get accessed offline, as well, via the home screen icon (a huge step forward from responsive web design) installation is conveniently lightweight: a few hundred KB essential files get cached locally (needless to say that this makes them faster than the standard web apps) they feature modern web capabilities: push notifications, cameras, GPS updates are run automatically, with no user interaction not only that they work offline, too, but once the network connection is restored, they synchronize the data    And now, before we virtually convert your website to a progressive web app, let's go, briefly, through some of the most common misconceptions about PWAs:   a. A progressive web app is literally an... “application”. Not necessarily: A progressive web app can be a blog, an online shop, a collection of... dog memes, you name it. Do not take the term “application” too literally when referring to PWAs. It's more of a concept, a code optimization technique which, once leveraged, "turbocharges” your app-like website or blog to deliver content faster.   b. Progressive Web Apps Are Developed Specifically for iOS or Android. On the contrary! Probably one of PWAs' “hardest to resist to” advantage is that: They're platform-independent. So, you don't need to:   develop separate codebases comply with platform-specific submission guidelines   c. Your Site Has to Be a JS-Based Single Page One So You Can Turn it Into a PWA. Nothing of that sort! If you're currently running... something on the web (be it a set of static HTML files), then you can easily make a PWA out of it!  And now, let's go straight to the 3-step set up process of a PWA out of your regular website:   Step 1: Go HTTPS to Convert Your Website to a Progressive Web App There's no way around it: the HTTPs protocol is the ONLY way to go when it comes to progressive web apps! All data exchanges need to be served on a secure domain: over an HTTPs connection! And how do you switch from HTTP to HTTPs? You get yourself an SSL certificate from a trusted authority. Now, there are 2 ways to get hold of it:   if your site runs on your own server (or at least you have root access to your server), consider setting up the LetsEncrypt certificate. if your website runs on a shared hosting, then both the process and the cost of your SSL certificate (for yes, there will be a monthly or an annual fee) depends greatly on your provider.   Step 2: Create a Web App Manifest  “But what is a web app manifest?”, you might ask yourself. A JSON text file that contains all the meta data of your PWA: description, scope, start_url, name, images, display, short_name... It's this information that will let browsers know how precisely they should display your app once saved as a home-screen icon. Now, before I go ahead and share a working example with you — one including the must-have entries of any web app manifest — I should also highlight that: A link to this JSON text file should be placed in the <head> of all your PWA's pages: <link rel="manifest" href="/manifest.json"> That, of course, after you've:   entered all the information about your PWA copied the manifest.json created a new “manifest.json” file in the root directory of your site and pasted it there  It should be served with:   Content-Type: application/json HTTP header or a Content-Type: application/manifest+json   And here's a “sample” piece of code: { "name": "My PWA Sample App", "short_name" : "PWA", "start_url": "index.html?utm_source=homescreen", "scope" : "./", "icons": [ { "src": "./android-chrome-192x192.png", "sizes": "192x192", "type": "image/png" }, { "src": "./android-chrome-512x512.png", "sizes": "512x512", "type": "image/png" } ], "theme_color": "#ffee00", "background_color": "#ffee00", "display": "standalone" } Once the “Manifest” section of the Chrome's Development Tools Application tab has validated your JSON file, it will generate an “Add to home screen” link to be accessed on all desktop devices. Tip: as you convert your website to a progressive web app you don't necessarily need to configure the manifest.json file yourself — with all its different images sizes, meta tags etc. Instead, if you want to make it quick, you can just make a 500x500 sized image of your PWA and then rely on Real Favicon Generator to create all the needed icon sizes and a manifest file for you! And this is just one of the generators you could use!   Step 3: Set Up Your Service Worker This is where the “true power” of your PWA lies: A service worker is a JavaScript file, placed in your app's root, that plays the role of a “middleman” between the browser and the host. The one which, once installed in the supported browsers, intercepts and responds to the network request in different ways. Note: in most cases, it's for caching all the static files, so that our PWAs can function offline, too, that we use service workers. Now that we've seen what a service worker is, here's how you create one as you convert your website to a progressive web app:   a. You get it registered first things first. For this, just run this code in the JS file on your site: if ('serviceWorker' in navigator) { // register service worker navigator.serviceWorker.register('/service-worker.js'); } Practically, it will check whether the browser does support Service Workers and, if it does, it registers your Service Worker file. Note: NEVER call this file, inside your website, like this: <script src="./service-worker.js"></script> b. If you do not need your PWA to work offline, too, just set up an empty /service-worker.js file. Users will just be notified to install it on their devices!   c. Once you've registered your Service Worker, generate your Service Worker file, too. For this, just run this command in your terminal: $ npm install --global sw-precache Next, go ahead and run it on your website directory: $ sw-precache Et voila! You will have generated a service-worker.js including the service worker contents.   Test It Out! At this stage of the "convert your website to a progressive web app" process, you should:   check whether your service worker got properly registered and installed on Chrome run a performance audit on your PWA, using Chrome's Lighthouse Extension   For the first operation, go through these 3 basic steps here:   press F12 to open your Chrome Dev Tools click on the “Application” tab next, on the sidebar, select “Service Workers”    Then, check whether your service worker has been properly activated and is running normally: Just tick the “Offline” checkbox and try reloading. Does your PWA-site still display its content, even when there's no internet connection? Now let's run an audit using Chrome's dedicated testing tool, Lighthouse:   press F12 again to visualize the Chrome Dev Tools select the “Audits” tab then select “Perform an audit” check all the suggested checkboxes and finally, run the audit    And here's how the generated report would look like: The END! This is how you convert your website to a progressive web app in 3 steps:   enabling HTTPS configuring your web app manifest creating your service worker   See? Any website can be turned into a PWA and you don't need to be a senior developer to do it. ... Read more
Silviu Serdaru / Jul 24'2018