Adrian Ababei / Oct 30'2017
We think Drupal is the best CMS Okay, we admit it. We love Drupal and have a bias towards it. We do know other CMS' (content management systems) have their benefits and purposes. But this blog post isn't about them. It's about why Drupal is the best. Drupal isn’t for everyone. You do need a dev team to support your website to customize Drupal. And to be more specific, you need one that is well-versed in Drupal specific development Every developer has his or her own personal favorites. After working on Drupal websites for many years, we have grown to love Drupal. So here is our completely biased opinion on why Drupal is the best. 1. Drupal Is Customizable Drupal allows for very high levels of customization. With Drupal, if you think it you can build it. The framework of this CMS platform itself never limits you. With Drupal, it’s easy to customize your site to have app-like features. Websites have become more complex these days with a lot of various functionalities. Working with a flexible system has become important. 2. Some Of The Largest Sites Use It Drupal is a powerful CMS, open-source, that sites like Al Jazeera and The Economist use. Drupal is structured like building blocks, which makes it flexible. The modular architecture makes it ideal to handle scale and continuous integration. Developers get more control over the code from the ground up (i.e. you can build anything). 3. Drupal Is Built For Scalability Drupal’s modular building block system allows for easy scalability. Out of the box, it’s easy to integrate with other applications. This integration is usually needed at an enterprise level. Another feature that makes it scalable is that you only select the modules you need on a per-page basis. This eliminates a lot of excessive and messy code on pages that don’t need every module. Drupal offers a series of articles on how Drupal can be configured for optimal performance and scalability. 4. Drupal Offers Enterprise-Level Security Drupal offers enterprise-level security. High profile organizations like the White House and Nasa use it. The Drupal core code base is very stable and secure. Drupal has a security team comprised of a global group of web security experts. They take security very seriously. Their job is to analyze and report any security vulnerabilities. Because most sites that run on this CMS platform need an expert Drupal developer, the Drupal community is efficient at working together. There are over a million experts to review code and functionality. Any potential issue is quickly identified and dealt with before it becomes a threat. 5. Drupal Is Fast One of the things that differentiate Drupal from other content management systems is that it has built-in caching. In plain English, this allows for content to be delivered quickly. What Drupal also does is allow you to select modules to run a per-page basis. This eliminates unnecessary code that can slow a page down. Not everything needs to be a part of the site-wide template. Keep in mind, there are other factors - not Drupal-specific - that can really slow things down. Things like the size of images, number of images on a page, number of requests to the server a page makes, and the number of modules running on a page. There are helpful (and free) tools out there, like webpagetest.org, that provide lots of tips for helping to speed your Drupal site up. 6. Drupal Is Multilingual Drupal modules come in 90 different languages. You can display your site in multiple languages and allows users to switch languages easily. Here is a resource guide for configuring a multilingual site. 7. Drupal Is Good For SEO If you know anything about search engine optimization, you’ll know that Google is soon-to-be making a big switch to a Mobile-First Index. (It’s a pretty big deal.) Drupal 8 is also supported by a mobile-first philosophy, so it’s ready for the future of SEO. Drupal is very search engine friendly. Here’s a good explanation of what Mobile-First Indexing means. Drupal offers excellent plugins for optimizing content. A couple of favorites are the Metatag module and the XML sitemap module. Drupal provides a limitless platform for you to deliver amazing content. A solid framework – that can functionally do anything - is key to building your presence on search engines. If you are looking for Drupal Web Developers for your next project, please get in touch. We are always happy to start a conversation.
Adrian Ababei / Sep 08'2017
To upgrade or to migrate? To keep supercharging your current Drupal 7 site with new cool features or to get it straight to the next league? A so much more than just another Drupal 7 vs Drupal 8 debate: it's a decision impacting your budget and future-proofing (or not) the enhancements that you're about to implement. In this respect, our web development team in Toronto has done its best to “pile up” the crucial pros and cons for each one of the two paths that you're now challenged to choose from. Think them through, give honest answers to all the strategically chosen questions included in our little “questionnaire” here and you'll find your (own) way of leveling up your website: To Upgrade or to Migrate? And a Few Other Key Questions to Ask Yourself So, here you are: facing the challenge of taking your Drupal 7 website to the next stage of its evolution! But which one is it: the upgrade phase or the migration one? Now here are some preliminary questions to ask yourself right now. It's the answers to these particular questions that will weigh heavily, later on, on your decision-making process: 1. To what extent will this “maneuver” influence my website's stability, lifetime and level of flexibility? An extra boost of flexibility, reflected in the “edit content on-the-go” functionality, or the perspective of ongoing support for many years to come will undoubtedly influence your decision! 2. Will my site's code get easier to maintain? And this is a crucial question to be asking yourself at this phase of the whole decision-making process: how convenient will it be for your Drupal developers to maintain/update your site's code on a long term? 3. How many resources of time do I need to invest? For time sure is money! How long will it take to implement those new enhancements on your website? Does it involve a lengthy training process for your team, as well? 4. How easy will it be for my administrators to manage content on my website? A simplified content editing/publishing process is what will guarantee you an independent editorial team. Empower your editors and your site admins and you'll streamline all non-coding processes on your website! With each question that you'll answer you'll be sketching your company's “specific context”. The one favoring either the upgrade or the migration way for ramping up your Drupal site! Drupal 7 vs Drupal 8: Key Comparison Notes Does its “age” automatically give Drupal 7 an advantage over Drupal 8? No doubt about it! Drupal 7 is now capable to “tempt” you with a heavier load of modules, stable modules and with a longer period of time that the Drupal community has spent constantly improving it. And yet! Drupal 8, although “younger”, is taking advantage of Drupal 7's weaknesses and shortcomings. Basically, it's equipped with all the functionality that its predecessor lacked. Speaking of which, here's what Drupal 8 brings new to the table: top popular modules have been moved to core an advanced, easy to handle configuration management system mobile-friendly backend: jump on the “edit content on-the-go” trend a new era for the “content as a service” movement, thanks to its API approach to content delivery object-oriented code: by using Symfony and Twig Drupal 8 “surprises” you with a more logically structured code (do take into account, though, that your developers will have to be already familiar with object-oriented coding) easier-to-edit content: the very essence of content management one-click code deployment: deploy your code faster and (therefore) as frequently as you have to pre-built multilingual support: you no longer need to leverage a whole “fleet” of modules for supercharging your website with multilingual capabilities ramped up performance and scalability: 2 enhancements you just can't underestimate especially if it's a large-scale, content-packed website that you own (one carrying a heavy ecosystem of third-party technologies “pomping” data into it) easier third-party integration Your Final Decision Depends Greatly On... the number of custom-built elements on your current Drupal site: the more of them, the more complex (lengthy and pricey) moving it over to Drupal 8 will get the goals that you're aiming to achieve via your new enhancements: is it just a new basic feature (just a few hours' work) that you're planning to add or a major enhancement, which would justify the migration process? the “weight” of your Drupal 7 site's load of data: and its complexity, as well whether you have a standalone website or a multi-site: needless to add that you should have all your sites (if it's a “cluster” of sites that you own) running on the same version of Drupal your company's resources of time and money: an upgrade of your current Drupal 7 website won't, indeed, impact your budget to the same extent as a migration process would Upgrade Your Current Drupal 7 Site If... it's mostly custom-built: it features custom modules, custom-made workflows which would take longer to recreate and to adjust to Drupal 8's particularities you need to have your new enhancement(s) up and running on your website in no time it's basic features only that you're planning to upgrade it with you're constrained by a tight budget: a factor which will weigh heavily in the Drupal 7 vs Drupal 8 balance Make the Leap to Drupal 8 If... the specific workflow on your website depends greatly on a streamlined content editing process you need to make code deployments on a regular basis it's complex enhancements that you want to implement your current Drupal 7 website is a low-complexity one the overall success of your upgrade strategy depends on high levels of performance and scalability you value the ongoing support which, well, the Drupal 7's support team will stop offering you at some point So: Drupal 7 vs Drupal 8? Will you stick to the former or level up to the later? Which direction do our “questionnaire's” results point you in?
Adrian Ababei / Aug 30'2017
Consider these 3 real-life scenarios: you need to “populate” a newly developed Drupal website with content you need to migrate content from one Drupal website to its freshly redesigned version you need to quickly “animate” a website wireframe with some demo content for one of your Toronto digital agency's clients The YAML Content module is: a handy tool ensuring a streamlined import/update process a flexible way for you to manage the content that you need to migrate / update … in each one of the 3 above-mentioned use cases! Basically: it helps you outline (mind you don't connect it to the module Outline) it the content to import by leveraging a YAML format it streamlines the whole process helping you define a set of content which can be found in multiple content files on your site it turns content updating/re-importing into a highly flexible, highly dynamic process thanks to the hierarchical way in which you get to visualize it and scan it through (notice the resemblance with the module Outline, which enables you to organize your entities in a hierarchical structure) In other words: the YAML Content module turns the entire defining, structuring and dynamic updating of the content to be imported into an ideally streamlined process! Now let's see why such a module was needed in the first place. What sets it apart from other Drupal tools alike: The Interrelation of Content: Now a Problem Solved With an entire “ecosystem” of Drupal modules ready to take on the role of importing and migrating content, a valid question might be: “Why the YAML Content module?” What obstacle does it help you overcome? What added value does it provide? Now if you've already dealt with content import scenarios, you must have surely “bumped” into the interrelation of content issue, right? It's precisely this “sore point” that this content utility module comes to “heal”! Practically you're enabled to define processing callbacks across the content to be imported and thus to easily insert new data/modify the existing one during the import process itself! And here are some examples of tasks that you get to carry out precisely at the time of import: import/reference managed data files import image files query existing entities There's more! Besides “dynamic processing”, you're granted with almost unlimited flexibility in terms of the type of entities that you get to define during this process. It's thanks to your content's YAML format, which closely parallels the entity and field API architecture, enabling you to apply it to almost any entity type and to support multiple field types: menu links nodes media entities file entities taxonomy terms block content But There's no UI: How Can I Use the YAML Content Module? It's true: the module doesn't provide a user interface! It's been built with back-end utility in mind. In other words: you're triggering and managing the entire content importing process exclusively via some simple Drush commands! Just run this command in Drush: drush –filter=yaml_content … and you'll get the whole list of commands available to you for interacting with the YAML Content module. It will present you both with the commands that you need to use for importing your content files and the ones that you'll need for a “developer usage” of the module (meaning: if you need to delve deeper into the import services). Leverage This Particular Directory Structure to Find The Content to Import And this assumed file structure looks likes this (whether we're talking about a module, a profile or a sub-directory): /content: all.content.yml files that contain the content data to be imported /images: all images referenced /data_files: all file assets using a file callback for loading and which are referenced Wrapping Up Things will never be the same again whenever you need to import content in a Drupal site! enhanced user-friendliness for tracking down the content you wish to import more “order” (thanks to the YAML format) in structuring your target content to be imported, which implicitly leads to a more streamlined import process much more flexibility in managing your content … the YAML Content module provides it with all and thus manages to stand out from the crowd of modules tackling the same content import “issue”. Feel free to take it for a spin next time you need to import/migrate content to a Drupal site!
Adrian Ababei / Aug 21'2017
Does anyone of the following scenarios sound familiar to you? you need to translate a few language strings on your Drupal site due to a certain dialect that the great majority of your site visitors use you simply prefer to see certain messages or labels on your website written slightly differently (let's assume that you prefer the “Add new content” textline to the “Add Content now” default one) you need to go multilingual (on your Drupal site at least) and you have a whole heavy load of language strings to be translated into those target languages What do you do? Which are your options? Which one guarantees you a streamlined translation process? And most importantly: which one makes the perfect fit for your own site-specific scenario? Let us try and answer all your questions by presenting you 3 approaches to language string translation in Drupal: 1. Use the String Override Module Now before we go on with our short step-by-step guide on how to install and to turn this module into your handy translation tool, we feel like pointing out its “limitation”. It makes a more than handy tool mostly for all those small changes that you need to apply to just a few strings on your Drupal site. Therefore, using it for a full-site translation “marathon” is probably not the most inspired choice. This being said, let's break down further with our step-by-step installation and configuration guide: Step 1: Download and Install Your Module You'll find it here: https://goo.gl/aCJGyy you've successfully downloaded it, go to “Modules” > “Add New” > use your “Browse” and search for the file you need to upload > “Install” Next just briefly “scan” the enabled boxes corresponding to your two String Overrides fields there and, if everything looks OK to you, hit the “Save configuration” button! Step 2: Trigger Your Module from the Configuration Menu Now navigate to “Configuration” (you'll find it “neighboring” the “People” and the “Modules” tabs on top of the page) and, unfolding its menu, go to “Translate Interface”. It's the last option listed there (after the “Regional and Language” one). Next just give it a click! Step 3: Now Go Ahead and Replace Your Language String Just enter the exact string that you want to replace/translate on the left side of your screen (in the “Original” section) and its replacement string/its translated version on the right side (in the “Replacement” section). Easy peasy! And where do you add that the module even enables you to streamline things even more: you even get to replace multiple language strings simultaneously just by adding some extra rows. Wrap Up: as already mentioned, the String Overrides module makes a great choice for “small-scale” string translations only. It enables you to track down the strings you need to change and to replace them with the new ones in no time. Yet, when it comes to translating an entire Drupal site, manually overriding every single language string using this module is hardly an effective solution. Such a “challenge” to respond to calls for a more powerful module such as the Locale module. 2. Use the String Translation Module for Handling User-Defined Strings Also known as the i18n_string module (falling under the Internationalization project's “umbrella). Now if the just mentioned Locale module (along with the .po files) enables you to translate hard-coded language strings, the String Translation module empowers you to translate the user-defined ones, too. And here we're referring to taxonomy terms, menu items, field names, which are a bit “trickier” when it comes to translating them, since you can't just rely on Drupal 7 core for that. Also, another important specification that we need to make is that this is an API module! Therefore, it doesn't work as a standalone solution, but rather “supports” other modules from the Internationalization group. And when it comes to the UI that you get to use to translate language strings in Drupal using this particular module, you should know that it's incorporated in the localization system: go to Administer > Site building > Translate interface for translating your user-defined language strings. "And how does it work exactly?" you might legitimately ask yourself. Here's how: it uses the Locale's module standard translation page (the above mentioned UI) for enabling you to translate the user-defined strings that it will have collected but not before you haven't defined your site's default language (and it's not always English) and it does this by grouping strings into “text groups” (you can find these groups of user-defined strings named “Profile”, "Menus” or “Taxonomy”, at admin/build/translate/search, under the "Limit search to:") Notes: do keep in mind that whenever you're translating your user-defined strings, the source strings that will get stored will be displayed in your default language in case the default language on your website is not English, you still get to import/export English translations relying on your localization UI a sort of “warning”: whenever you change the default language on your website you'll need to remember to redefine all your source language strings, too (the user-defined ones, of course) in short: get yourself informed of all the implications deriving from changing your default language, since this goes hand it hand with a never-ending string editing “ordeal”, too all the other translations on your website will be kept “unharmed” yet, as a rule of thumb, you should be changing (if it's necessary) the default language on your site at the very beginning of its development process; later on, once you have your site up and running, changing it back and forth and in several different languages will only lead to... “language string chaos” 3. Use the Strings Overrides in Settings.php to Translate Language Strings in Drupal You'll get to carry out the entire process in the settings.php file and where do you add that you don't even need to download, install and configure any extra module: it all happens in Drupal core. Yet, you should be fully aware that it's not a method for the inexperienced either. We're not going to hide it from you: it does require a certain level of coding “expertise”. Moreover, the same specification that we've made for the String Override module applies to this method, too: it's a tool to be used for small-scale string translations. Not the best choice when you're faced with much larger-scale translations! And now, shall we proceed with our explanations on “how it's done”? 1. Edit your settings.php file and go right up to line 430 (or somewhere 'around” it) 2. Next, uncomment this code (so that you can later on enter your translated strings) 434 # $conf['locale_custom_strings_en'][''] = array( 435 # 'forum' => 'Discussion board', 436 # '@count min' => '@count minutes', 437 # ); Note: in case the default language on your Drupal site is not English, remember to make the due modifications in the array key locale locale_custom_string_en so that it should reflect the actual language on your website! Now let's assume that you're being “dared” to translate a whole lot of language strings on your website.Then you sure need to streamline things a bit, right? For this you can rely on the i18n_string module, the API String Translation Module that we've just put into the spotlight. Just edit your settings.php file by entering this new line of code: $conf['i18n_string_translate_langcode_en'] = TRUE; Or, if you're not that much into “tweaking” code in settings.php you can always rely on the variable_admin module (part of the Variable module). Here's how you get to leverage its functionality to translate language strings in Drupal: first you navigate to admin/config/system/variable next you click on the "Multilingual settings" tab then on the "Enable translation for language" tab set your default language hit the “Save” button And voila! Now you get to translate your language strings! How about you? Have you, by any chance, discovered other more effective ways to translate language strings in Drupal?
Adrian Ababei / Jul 07'2017
Adrian Ababei / Jul 04'2017
Adrian Ababei / Jun 29'2017
Lazy loading (images, in this case) leads to energy preserving, which leads to a significantly improved site performance! Pretty ironic, isn't it? Well, this is precisely the logic on which the Image Lazyloader module in Drupal has been developed! Saving your website's energy goes hand in hand with increasing its page loading times. It goes hand in hand with “sparing” HTTP round-trips and taking some heavy load off the browser's “shoulders”, which otherwise would be “pressured” to relentlessly load thousands of images, even before they would be visible in his/her window browser. Basically what this module does is both unexpectedly simple and impressively smart : it loads images on your Drupal site only when they're in visitors' viewports. In other words: when there's no one opening them up in his/her browser, why bother loading an entire “cargo” of images? Why put an unnecessary pressure onto your site and the browser? And now let us detail to you this “energy-saving” tool that Drupal puts at your disposal and which we encourage you to leverage in the name of a... faster loading website: The Image Lazyloader Module: How Does It Work Exactly? What Makes it a Speed Booster? The whole “mechanism” behind this Drupal module is surprisingly simple, if we come to think of it: it loads images (lots and lots of them) only when they're displayed in a site visitor's browser window. Not before! And this is a “dream come true” especially for web designers, who're constantly dealing with the challenge of optimizing heavy loads of images. As you can surely guess it yourself, the module's an incredibly useful tool precisely for those Drupal website carrying heavy “cargos” of images. For no matter how many they might, how heavy the load is, the Image Lazyloader module's capable to... lazy load them all and therefore to keep your site's performance at optimum parameters. How Do You Use It? How Do You “Exploit” Its Full Potential on Your Drupal Site? Now allow us to give you a few tips and tricks or, better said, a step-by-step guide on how to fully leverage this module on your Drupal site: Step 1: you download (and install, obviously) the module itself along with the Libraries module in the sites/all/modules/contrib; the latter is, in fact, a dependency for 2.x branch Step 2: next you download your echo library and place it in sites/all/libraries Step 3: it's time to enable your Image Lazyloader module now Step 4: don't forget to clear your cache Essentially all these preliminary setups will actually grant you the much-needed freedom to quickly enable and to disable your Lazyloading module any time you want to. Which turns it into such a powerful convenience when you just need to run some tests on your website, for instance. And speaking of “empowerment”, there's an entire array of options to choose from and setups to enable, depending on your site's needs and on your purposes: you have the loader icon letting you know if the images are not (yet) fully loaded you get to set the distance from the viewable screen part and to go for a placeholder image of your choice you're even enabled to select those particular web pages on your Drupal site where there's no need for an image lazy loading process to be performed And voila! These are the answers to your “why” and “how" to use the Image Lazyloader module! Questions deriving, of course, from the main one: “how can I boost my Drupal site's performance?” Feel free to test its image optimization power and to determine how much faster your web pages will then load.
Adrian Ababei / Jun 27'2017
Adrian Ababei / Jun 23'2017