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.

Get An Insight Into The Page Request Handling Mechanism in Drupal
  If you really want to evolve from a web developer skillful enough to put together a functional “puzzle” out of Drupal's core modules, to one custom-making his new modules, then you need to take a close look at the whole process behind this apparently simple sequence: “you hit an URL, then (as if by magic) the required page instantly gets loaded”.   So, ready to take a sneak peek “behind the curtains”? If yes, then allow us to be your guide!     1. Drupal Separates The Internal Path from the Domain Name   Once the server gets the message, once the URL is sent, Drupal focuses on the internal path and on it only. Therefore, it just “cuts it off” from the URL.   2. Then Drupal Calls Index.php   Take the index.php as some sort of a “control tower” (you can find it in the root directory of the Drupal install), the one that processes all the incoming requests.    Now, let's have a closer look! Index.php is made of 4 lines, each one of them performing a certain function:   define('DRUPAL_ROOT', getcwd(): the very first line that runs once Drupal gets a page request require_once DRUPAL_ROOT . '/includes/bootstrap.inc': its role is that of loading  bootstrap.inc in the includes/subdirectory.bootstrap.inc drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL): it loads pretty much everything: the modules and functions, the needed data into the memory... menu_execute_active_handler(): as the name says it, it's the one actually handling the page request, delivering the final web page to the end user    3. Now Drupal Goes Through the Bootstrap Process   This is where the “major loading” happens: it is now that Drupal loads the libraries, initializes the database, sets the right sessions...    The bootstrap process a self-start one, requiring no input, no intervention from you, the website's “creator”, and yet... you can't possibly not know what happens during this whole process running on its own!   How about going rapidly through all the 8 phases of this highly complex bootstrapping process?   1. DRUPAL_BOOTSTRAP_CONFIGURATION: Drupal calls upon it wherever it encounters php errors or exceptions. If so, then an error handling code is prepared, settings.php gets loaded, configuration gets initialized...   2. DRUPAL_BOOTSTRAP_PAGE_CACHE: it checks whether the IP is blocked or not, whether the cache is enabled or not in order to serve the page from the cache   3. DRUPAL_BOOTSTRAP_DATABASE: it loads the database and checks whether any $databases array has been defined. If no, then it redirects to install.php   4. DRUPAL_BOOTSTRAP_VARIABLES: it loads the variables from the database variables table, then it overwrites the ones defined in settings.php, while loading all the other modules needed during this process      5. DRUPAL_BOOTSTRAP_SESSION: it initializes the session handlers. There are several custom session handlers in Drupal:   _drupal_session_open() and_drupal_session_close(): to open and close a connection _drupal_session_read(): gets the session from the sessions table _drupal_session_write(): checks whether the session has been updated and writes a new one to the databse _drupal_session_destroy(): it deletes cookies and cleans up a specific session _drupal_session_garbage_collection(): it deletes the outdated sessions   6. DRUPAL_BOOTSTRAP_PAGE_HEADER: it practically sets up the HTTP header   7.  DRUPAL_BOOTSTRAP_LANGUAGE: called upon only for multilingual websites, it initializes the right language for the future web page   8. DRUPAL_BOOTSTRAP_FULL: the very final step, where all the modules are enabled and hook_init() is invoked     4. Drupal's Menu System Steps In   From all of Drupal's modules, it's the menu system that “guides” the internal path to a callback function.   PATH... MODULE... MENU SYSTEM... CALLBACK FUNCTION... LOAD CONTENT   5. Finally, It's the Theme System That Styles the Requested Page   Being more than just a theme (since it's a mix of theme functions and templates), the theme system is the one “dictating” the content/ the web page's final look.    CONTENT... THEME SYSTEM (CSS, HTML, JS etc.)... BROWSER   Of course that each process of this whole page request handling mechanism in Drupal requires a lot more in-depth knowledge, but this is pretty much the overall mental scheme that each developer should know for:   1. boosting his self-confidence with powerful knowledge   2. being able to come up with his own future custom modules       ... Read more
Adrian Ababei / Nov 11'2016
Turn DRUSH Into Your Efficiency-Boosting Tool
  All you command-line addicts (and skeptics, too), mouse haters and... spare time-craving developers, crafting your Drupal websites, gather around! It's time you all learned about this "Swiss army knife"-like tool which will make your work life so much simpler, far more refined and... more rewarding from now on: DRUSH!     What is DRUSH?   There are plenty of related definitions out there, but we like these 2 ones best:   "Drush is a command-line shell for Drupal, and it enables you to perform many administrative and website maintenance tasks from the command line instead of having to use the Drupal administrative interface"    "Drush is an important tool for Drupal developers looking to speed up and simplify their workflows"      We envision DRUSH as a "way too valuable" tool to be overlooked if you're aiming at upgrading the old-schoolish, time-consuming (and therefore, less productive) way of managing your work to a: quicker simpler more refined one   … as a DRUPAL web developer/administrator   Discover the most common DRUSH commands   Till you get to the point of actually setting up your own custom DRUSH commands, let us point out to you the main features that DRUSH can (easily) tempt you with:   Clear Cache (cc): it allows you to either choose a specific cache (drush cc) or to quickly clear them all (drush cc all)   Install Drupal: that's right, installing Drupal from scratch is quicker and easier (with just two basic commands) than ever.    Updatedb (updb): why should you "invest" valuable time in running updates using update.php, when you can... "claim" your spare time by simply running any available database updates using this magic formula: drush updatedb?   Feature-update (fu): do a comparison yourself and see how much time it would take you to update a feature in your Drupal website (after you've applied a certain change stored in that particular feature) the old-schoolish way (e.g. exporting the feature manually in the admin interface) compared to... typing this time-saving shortcut here: drush feature-update feature_name   Feature-revert (fr): you'll get even more eager to experiment, to... play with the features available in Drupal when you know that reverting your features to their code versions is as quick and simple as typing drush-feature-revert feature_name   Enable a module: type drush en name_of_module  -y or drush -y en name_of_module    Pm-update (up): drush pm-update allows you to update Drupal themes, modules and core while you're saving priceless free time for your other... non-website development-related activities   Database tasks (sql-dump, sql-cli): save a considerable amount of time and back up your database (while giving your... mouse a rest), by simply using this shortcut in your command-line: sql-dump, then simply restore it using this magic combo: sql-cli.     .... and the list will get longer and longer as you get more and more eager to discover and to learn other productivity-boosting and time-saving shortcuts in DRUSH.   You're more likely to become a DRUSH “groupie” if:         1. You hate... mice   Could you deny that mastering command-line skills is already a far more... elegant way of working, as a developer, compared to “exploiting” your mouse for opening and closing lots and lots pages in Drupal's administrative interface?    Just imagine this highly suggestive scenario here:    You need to install and reinstall (and eventually administer) several Drupal websites. Therefore, you'll get (mentally) ready for the tedious and boringly repetitive steps to come:   Go to drupal.org. Get Started Download Drupal Download the tar.gz.file Install your new Drupal Going back to drupal.org for installing your modules (unzip a bunch of files) etc.   A whole lot of clicking and wandering about Drupal's interface, isn't it?             Now consider work scenario no. 2:   type cd  /var/ww... run drush dl drupal-7.0... cd /var/www/drupal-7.0 and install your new Drupal website: drush site-install –db-url=mysql://root:secret@localhost/drupal... type "y" at the following prompt     … and voila: with a few clicks (relying exclusivity on your good old keyword), you've had your new Drupal site installed and you're ready to... install your second and your third one, too...        2. You work in a large environment where relying on FTP or carrying out tasks administratively is not an option        3. You want to sharpen your command-line skills         4. You're... open to new tools, constantly testing new technologies aimed at boosting  your (and your team's) productivity        5. You just hate trading priceless personal life time for... more efficiency in your professional life     Is installing DRUSH a dread?   Actually, you can benefit from its time-saving features right after you've walked through 7 easy setting up steps:   Pick the directory to place your drush in: cd /usr/local/share Get drush: [sudo] wget https://goo.gl/GwdpKe it: tar xvf drush-6.x-3.3.tar-gz Remove the package: rm drush-6.x-3.3.tar.gz  Change permissions: chmod u+x drush Create a link: In -s /usr/local/share/drush/drush /usr/local/bin/drush Run drush: [sudo]  drush     Still, probably one of the best Drush features is that... it's constantly evolving, constantly improving, so... sky is the limit when it comes to quickly installing/developing and efficiently managing all your Drupal websites (for this is, in fact, the true beauty of Drush: it allows you to manage several sites at once, helping you turn yourself into an... admin guru).      Give it a try, cure your command-line related “phobia” (if any) and unleash your full potential as a Drupal developer! ... Read more
Adrian Ababei / Nov 07'2016
What Are the Must-Have Drupal Development Tools? Top 8
Drupal development is gaining more and more traction on the web development scene and for good reasons – Drupal is a highly robust yet flexible platform which makes it a great choice for web development projects, e commerce websites and other tech related needs. Drupal development requires lots of programming skills and attention to details so we’ve set out to find the best Drupal development tools for you to use and review. Here is our list of 8 essential Drupal development tools:   Drush for Drupal development Drush is one of the most sought after Drupal development tools – it’s considered the command line and scripting interface for Drupal. While it may take some time to get used to it, Drush is an excellent multipurpose tool used to install, maintain and develop Drupal websites. That being said, Drush is a great time saver for Drupal developers and it also helps with building custom modules and themes.   Coder for Drupal development With the Coder module Drupal developers can follow Drupal’s coding standards more closely. This module is composed of two sub-modules, Coder Review and Coder Upgrade.   Coder review allows Drupal developers to verify if a module or part of code is up to Drupal’s coding standards or not – it also allows users to know if anything needs changing. Coder upgrade helps Drupal developers upgrade modules or themes to a new version of Drupal. Coder is currently available for Drupal 6 and 7.   Backup and Migrate in Drupal Backup and Migrate makes database backups much easier to create. Just click the admin interface or run the Drush command to order a backup. This module can be configured to send your backup to Dropbox or Amazon S3.   Masquerade for Drupal development Sometimes Drupal development can be a hassle – you have to become a different user to test something in Drupal. The Masquerade module is the perfect solution for this purpose simply because it allows Drupal developers to switch between users easily. This module is perfect when a user reports a bug and another developer is supposed to replicate the same conditions and fix it.   Drupal Project Lookup Drupal Project Lookup is a Chrome extension that’s very handy for Drupal development – the extension helps users save a lot of time when looking for project pages on drupal.org. All you need to do is type pml and the project name and you’re there!   Dreditor Dreditor helps Drupal developers review patches and comment on different issues on drupal.org. Dreditor’s features include auto-completion when adding comments in drupal.org, templates for commit messages and the patch reviewer button.   Features Turn on configuration in the modules in order to source control and deploy them properly. You shouldn’t make too many changes on the live website but instead you should try to make changes on your local server. But how can you deploy modules on a live website? Simply use Features – this is an incredibly useful module which will help you along with any Drupal development project.   Diff for Drupal development Drupal developers who use Features are most likely using Diff as well. Sometimes features may get overridden and the information from the database may not match with the code – This is a perfect time to use Diff. With the Diff module Drupal developers will see any difference with ease – you’ll also be able to see changes between revisions of different nodes and modules, effectively saving you a lot of time. Considering these aspects, Diff is one of the most important Drupal development tools.   Conclusions These are some of the best Drupal development tools available today – not only do these tools speed up your workflow but you’ll be able to achieve better and greater results as well. ... Read more
Adrian Ababei / Sep 29'2016
New Modules Released to Improve Drupal’s Content Workflow
Drupal recently released a new set of foundational modules which can improve Drupal development and Drupal’s workflow. The modules range from full-site preview, user experience improvements, auditability, multi site content staging, content staging and more. Here’s a few tips and examples on improving your overall drupal development workflow:   When to use these drupal modules Here’s when and why you should use these modules for your drupal development projects. Coss site content staging – You may want to synchronize content from one site to another. The first website can be a staging site where your content editors make certain changes and the second one can be the live production site. Content changes can be previewed on the stage site and then published on the second website. Content branching – If you want to launch a new product you might want to create a new version of your site with a section dedicated to featuring your new product. With this new section you can introduce new menu items, upgrade pages and introduce new pages. Previewing your website – When building a new section on your site, you’ll want to preview it before going live with it – this is content staging on a single site. Offline browse and publish – Sites should be functional even in offline mode and record any forms or changes – when the connection is restored everything can be syncronized. Content recovery – People often delete things they really didn’t want to delete, you should give users the ability to recover any content that has been deleted. Audit logs – Certain companies or organisations may want to have all content revisions to be logged in order to be reviewed. Certain revisions or actions can be linked to specific users, thus making employees accountable for their actions within the content management system.   Drupal development technical details The cases above have some similar traits: Content needs to be synchronized between two spaces – from site to site or from backend to frontend Revision history is kept for all changes Content revision conflicts are tracked These features started off as a single module called Deploy. Nowadays Drupal development makes use of a large number of different modules: Deploy Multiversion Replication Workspace RELAXed Web Services Trash   Multiversion for Drupal development The Multiversion module keeps track of any conflicts in the revision tree, introduces the concept of parent revisions and adds revision support for all content entities built in Drupal, not just block content and nodes.   Replication module for drupal development The replication module is built on top of the multiversion module – it will help users with revision informations in order to determine which revisions are missing for a certain location. This model also allows drupal developer to replicate content between a source and a target location.   Workspace for drupal development This light module allows full site previews and single site content staging. The user interface allows your average drupal developer to create special workspaces and to switch between them as needed.   RELAXed Web Services The RELAXed Web Services module allows cross-website content staging. This is a more extensive REST API for Drupal development with full support for UUIDs, parent revisions, file attachments and translations. These features are essential for content staging.   Deploy module for Drupal development Before the release of Drupal 8, the Deploy module took care of everything related to content staging – top to bottom. After Drupal 8’s release, Deploy was rewritten to provide a user interface on top of the Workspace and Replication modules. This user interface allows your average drupal developer to manage content deployments between different workspaces on a single website or across multiple websites.   Trash module The Trash module is used to restore content related entities marked as deleted. It basically works like a recycle bin, displaying all entities from all supported content types where the default revision is flagged as deleted.   Synchronizing your websites with an API If a Drupal website has RELAXed Web Services installed and enabled, it will behave and look like the REST API from CouchDB. This allows a drupal developer to use CouchDB tools such as PouchDB.   Conclusions All of these great improvements that can boost your drupal development workflow, effectively allowing you to create better products faster. Check them out! ... Read more
Adrian Ababei / Apr 04'2016
What is Drupal?
Drupal is a popular open-source content management system written in PHP. Having been created in the early 2000s by a Belgian student, it now powers some of the most prominent websites on the web (WhiteHouse.gov, Weather.com, etc.). It is often regarded as a competitor of CMSs such as WordPress and Joomla. One of the most important components of the Drupal project is its community of supporters (contributors, developers, evangelists, business owners, etc.). Prominent within this community stands the Drupal Association, responsible for "fostering and supporting the Drupal software project, the community and its growth". A giant leap from its predecessor, the 8th major release of the Drupal project has just hit the shelves. It brought about a serious modernisation of its code, practices and mentality. Many regard this shift as a real move away from the traditional notion of a CMS to more of a Content Management Framework (CMF) that provides a great platform for building complex applications. In this article, I'm going to answer some of the more frequent questions people have about Drupal when starting up for the first time or considering doing so: • Is it right for me? Who is it aimed at? • How can it be installed, and where can I host it? • How can I start working with it as a developer? • What options do I have for extending functionality or styling it? Who Is Drupal Aimed At? Since the beginning of the project, Drupal has evolved from being mainly a tool for building smaller sites to one that can now power enterprise-level platforms. Especially with Drupal 8, site builders and developers can easily scale up from small websites to large platforms with many integrations. For example, the adoption of Composer allows you not only to bring external libraries into a Drupal project, but also to use Drupal as part of a bigger project of applications and libraries. It's safe to say that Drupal is flexible enough to meet the needs of a wide range of projects. When it comes to development, Drupal has always had a relatively closed community—not because people are unfriendly, quite the contrary, but mainly because of the code typically being written in a Drupal way (resulting in what sometimes is referred to as Drupalisms). This has meant a learning curve for any developer starting up, but also less interest from developers of other PHP projects to jump in and contribute. This is no longer the case. Especially with the release of Drupal 8, the community now promotes a new mentality of code reusability and best practice across different open-source projects. Active participation in the PHP Framework Interoperability Group is part of this effort, and using a number of popular Symfony components in Drupal 8 core is a testament to this commitment. With this move, the Drupal community has gotten richer by welcoming many developers from other communities and projects, and it is sure to grow even further. So if you are a Laravel developer, looking at Drupal code will no longer be so daunting. How Can I Install Drupal, and Where Can I Host It? Traditionally, Drupal has had a relatively easy installation process, particularly for people who at least knew their way around a Linux environment. The project simply needs to be dropped into a folder your web server can run (which needs to be using PHP and have a MySQL or MariaDB database). Then pointing your browser to the/install.php file and following the steps takes care of the rest. The most important screen you'll see is the one in which you select a specific database to use. In terms of requirements, the LAMP stack (Linux, Apache, MySQL and PHP) environment has always been a favourite for Drupal to run in. However, it is in no way restricted to it. Solutions exist for installing it straight on Windows or Mac (e.g. using the Acquia Dev Desktop) but also on a Linux system that runs other web servers. The easiest approach, if you go with your own setup, is to use a LAMP server for hosting. For a bit more performance you can replace Apache with Nginx, but you'll then have to take care of some specific configuration that otherwise is handled in the.htaccess file Drupal ships with. However, if you don't want the hassle of maintaining your own hosting server, there are three main providers of specialised Drupal managed hosting: Acquia, Pantheon, and Platform.sh. These also provide a workflow for easy updates and development flow. Past that, you are looking at fully managed hosting with a Drupal development company. How Can I Get Started Developing for It? Developing Drupal websites has typically been the kind of thing you either liked a lot or didn't like at all. This is because when you were first introduced to Drupal, you encountered very many specificities that you didn't see in other projects. So if those tickled your fancy, you loved it forever. With getting off this island in Drupal 8, this is no longer the case as much. You still have plenty of Drupalisms left that you can love or hate, but you now also have external components like Symfony or Guzzle and, most importantly, a more modern way of writing code in general (OOP, design patterns, reusable components, etc.). So your PHP skills from building websites with Zend will come in handy. A good way of getting into Drupal development is to follow some online video courses. There are a couple of resources that are excellent for this purpose, most notably Drupalize.me. If, however, video is not your favourite medium, there are also many written tutorials and guides available to get you started. Since Drupal 8 is brand new, you'll find significantly more learning content for Drupal 7. Nevertheless, the focus in the community has been shifting recently towards Drupal 8, so you can expect more and more of these resources to crop up. And if you have no experience with any version of Drupal, it's best to focus exclusively on Drupal 8 as the changes between the two are big and perhaps you'd be facing unnecessary challenges. How Can I Extend Drupal? The main extension point of a core Drupal installation is its module system. Modules are used to encapsulate bigger chunks of reusable functionality that can/should work on different sites. Aside from the core modules, there are a large number of contributed ones, available for installation. Granted, most are still only for Drupal 6 and 7, but the community is catching up also for the newest version. This problem is also mitigated by the incorporation in Drupal 8 of a few popular contributed modules as well as extending the scope of what core can do out of the box (compared to Drupal 7). Lastly, custom modules (the ones that you write yourself) are the primary way you can add any functionality that you want and that is not available via a contributed module. Installing modules can allow you to plug in various pieces of functionality, but you should not treat this as a green light for adding too many. It's always better to stick to the ones you actually need, and don't be afraid to be critical in this respect. You can also work on finding a good balance between contributed code and the custom oneyou write yourself. Additionally, since we are talking about open-source software, you should always evaluate the modules you install. The following indicators are good examples to pay attention to: number of downloads and usage, commit frequency, maintainer engagement, state of the issue queue. And do keep security in mind as well. It's highly recommended you keep both Drupal core and any contributed modules up to date as this will significantly help you keep your site and server secure (though it doesn't ensure it). What About Styling? The styling layer of a Drupal site is handled (in large part) by its theme. Themes are similar to modules in that they are an extension point, but they have different responsibilities. They contain the styles, front-end libraries and in most cases template files that are used to output data. There has been great progress in Drupal 8 compared to the previous version: the popular Twig engine has been adopted for templating, theming has been limited to Twig template files, debugging and overriding templates has been made much easier, etc. Similar to the advances in back-end development experience (DX), the theming layer has been made more appealing to the non-Drupal crowd. Front-end developers can now easily work with Drupal themes without having to understand the ins and outs of the back end. Drupal core comes with a number of themes that can provide you with examples but also which you can extend from. There are also contributed themes similar to how there are modules. Popular front-end frameworks such as Bootstrap or Zurb Foundation have mature Drupal theme implementations for Drupal 7, which are also readying for Drupal 8. These work very well as base themes but also for quickly scaffolding a website and making it look decent. Paid themes are also available to try out. Usually they are very cheap and quick to set up. The problem with them is that they are worth exactly as much as you pay for them and usually have gaping holes in their flexibility. As a beginner, these themes can seem like a great way to set up a site, and they very well may be. However, as you progress, you'll learn to avoid them and build your own, based on external designs or even plain HTML/CSS/JS templates. Conclusion Drupal is a powerful tool for building websites and platforms of any kind. With each new major release, Drupal has shown a commitment to better itself, become more robust and flexible, and embrace outside communities as well. Source: http://code.tutsplus.com ... Read more
Adrian Ababei / Mar 31'2016
Adding CSS Classes to Blocks in Drupal
The concept of Modular CSS has been around for years. The basic idea is tackling your CSS code in a systematic way through class and file naming conventions. The main goal being improved workflow through organization, readability and reusability. Some of the more recent modular CSS architectures are Object Oriented CSS (OOCSS) and Scalable and Modular Architecture for CSS (SMACSS). I tend to prefer SMACCS as Jonathan Snook has presented it as a set of guidelines rather than rules. He leaves it open for individual style and interpretation as every developer and every project is different. If you want to see a great example of Modular CSS in action, go blow your mind looking at the Twitter Bootstrap Components Library. The creators have done an excellent job abstracting the components in a way that makes them easy to understand and flexible via classes and subclasses. The idea of Modular CSS really appeals to me, especially having worked on large complex sites with multiple front-end developers collaborating together. While Drupal is perfect for these large scale projects, adding your own CSS classes to a Drupal theme ( essential when working with modular CSS ) is often unintuitive, inconsistent and tiresome at best. To remedy this, I've been working on a systematic approach to adding classes to themes that has so far proved extremely useful. In this post we're going to see how we can easily manage classes on one of Drupal's most used components, Blocks, using a preprocess function. Preprocess Functions Preprocess ( and Process ) Functions are the key to taking control of your classes in Drupal. Preprocess functions are called before every theme hook is sent to a theme function and template file (.tpl). In my mind preprocess functions have 2 uses: Altering and adding variables that are available to theme functions and .tpl's. This is how we'll be adding our classes. Sending these variables to an alternate theme function or .tpl via theme hook suggestions. I prefer managing my classes via preprocess functions over template files because I find it way more flexible and concise. I no longer need duplicate template files just to add or remove a single class. Adding Classes to Blocks As is often the case with Drupal, there are a few options out there for adding classes to blocks, including Skinr, Fusion Accelerator and Block Class. All of these offer the power of adding classes through the admin UI which may be right for you and your site administrators. This hasn't been a requirement for most sites I've worked on. Your mileage may vary. I prefer to define my classes directly in the theme where I'm already writing my CSS, everything is already in code and there is no need to export settings from the database. So let's see how we can do this using default core functionality. Looking at the core block.tpl.php file, by default there are 3 elements to which we can add classes during preprocess: the block container itself ($classes), the block title ($title_attributes) and block content ($content_attributes). As of this writing, in order to preprocess the block content classes, you must remove the hard coded class attribute from the template yourself or apply a core patch. Now let's create our preprocess function and start adding some classes. This may look like a lot but it's actually pretty simple. Let's break it down. First off, we create some shortcut variables to save us some typing down the road and make our code more legible. The first variable we create is $block_id which is just a string combining the name of the module creating the block and the block's delta— separated by a dash. This gives us an easy way to target individual blocks when we start adding classes. One thing to note, some blocks, including core custom blocks, use an auto-incremented integer for their delta value. This can present issues if you are moving blocks from dev to staging to production and you're not careful. I recommend using the boxes module to help mitigate this. The next three variables, $classes, $title_classes and $content_classes are references to the arrays that will eventually be rendered into class attributes. To add classes to an element, we just need to add them to its corresponding array. After we have our shortcuts set, we can started adding classes to our blocks. We first start by adding some global classes, .block-title and .block-content, to all block titles and block content containers respectively. You may or may not find this helpful. If you're interested in stripping out all the classes that core and other modules have added to your blocks up to this point, this would be the place to do it. To remove those classes, just reset your variable to an empty array like so $classes = array(); Next, we can start adding our classes on a per block basis. I like to keep a simple print statement handy that prints out the $block_id for all blocks on the page. When styling a new block, I just uncomment this line and copy the id from the browser into my code editor. To target individual blocks, we create a simple switch statement based on the $block_id. For each block we need to style, we write a case and add the corresponding classes there. In the first case we are adding three classes to the System Navigation block, one to the block itself, one to its title element and one to its content wrapper. In the second instance we are actually grouping two cases together so we can add the same classes to multiple blocks. Here we are adding .element-invisible, Drupal's built in class for hiding content in an accessible manner, to the titles of the Main Menu and User Login Blocks. As we add blocks, we add more switch statements. That's all we really need to do to take over our block classes. I've found this alone can be a tremendous boost to productivity while styling a Drupal site. You can get pretty far with blocks alone. However, with modifications to core theme functions and templates, similar to what we did with block.tpl.php above, this technique can be adapted to manage classes on nodes, fields, menus and most other themeable output. I've submitted a session proposal to DrupalCon Munich on this topic called Stay Classy Drupal - Theming with Modular CSS. If you're interested in learning more about taking control of your classes or have run into trouble trying to do so, leave a comment to let the organizers know you're interested in the session. ... Read more
Adrian Ababei / May 06'2015
Automating Remote Administration
This feature has long been a goal for OPTASY; it’s been more challenging than we expected. You see, automation is easy if all sites are built from the same base repository using the same folder structure and implementing the same base modules. Yet OPTASY supports fabulous client sites that, because they leverage the complexity and extensibility of Drupal they are creative sites., each unique, blending modules, custom code and content. A generic one-size-fits-all update process has never worked. In the past, we have manually updated sites using local scripts and patches, but this method was never going to succeed in providing security updates within 24 to 48 hours of a security release. Early on, we decided that well-built automation needs to: Identify and provide security updates released on drupal.org in a timely manner. Implement a clear path of deployment and testing which starts from and, after validating each environment (Dev; Staging, and Production), and then returns to retest production site code to ensure all updated components have been propagated across all environments. Allow for testing independently of ongoing development by the customer. Provide clear and consistent communication to all stakeholders about pending changes. RA Automation has (mostly) arrived! Finally, we are well on our way to achieving exactly those standards, providing automated security updates to RA subscriptions within 48 hours of a security release, to both the core and contributed modules. We expect to reach this goal in the first half of 2015, but the beta functionality is already updating RA subscriptions. With the introduction of automated patch and update deployment, there are minor but meaningful changes going on with some of the features you are familiar with today. RA Environment In order to avoid interrupting ongoing client development, OPTASY provides a free RA environment. For OPTASY Cloud Enterprise (ACE) clients, the RA environment is on a completely separate server to ensure that RA deployment and testing does not overburden customers’ dedicated testing environments. The redundant server allows security updates to be deployed into client environments as soon as they are available and readied for client testing. RA Preferences Last year, client-facing RA preferences were made available in your RA administrative settings. Clients can control RA automation on a per-subscription level. We plan to continue to refine these to work best with the script and the unique needs of clients. Using APIs OPTASY RA has utilized the internal OPTASY Cloud API in order to take advantage of the tools built by our fabulous cloud team. The API allows automation to read RA Preferences as well as other centralized subscription data that is used to create human-readable tickets and monitor progress. Optasy RA also takes advantage of the Zendesk API, and has contributed improvements back to Zendesk. Drush and LiveDev Since automated updates use Drush, it takes advantage of the Cloud Live Development feature. All updates take place on the RA Environment first, then are switched to Live Development for the update and code commits that will be deployed for the particular customer. While drush typically does all updates at once, we ensure that each module update is a discrete git or svn commit. This allows much more efficient troubleshooting down the line, as load order can impact how the whole instance works due to custom code. The additional staging step, in the RA Environment, allows OPTASY to revert a single module update. It also allows customer development teams to cherry-pick the updates that best fit into their ongoing development process. Drush Backend OPTASY has also contributed back to the Drupal community by sponsoring development in Drush, eliminating a problem that interfered with automated updating. RA clients will know that enabling the Update module is essential in order to get security updates. Drush 6 requires this module to access module status information without which Support teams have no way of knowing the status of a site’s modules. Asking clients to enable the module so we could scan always took extra time, often delayed the process. In Drush 7 the Update module unnecessary. The fabulous-to-work-with F.L. Jonathan Araña Cruz developed the code, while Samuel Mortenson tested on it OPTASY servers. The result is the ‘Drush Backend’ which has been committed to the current dev version of Drush 7. This work has streamlined initial versions of our automation, removing a significant amount of code that worked around Update cache issues (pm-enable update, pm-refresh, truncate cache_update, etc.). We reduced the total number of pm-updatecode calls. This also means that enabling the update module is no longer a requirement for RA subscriptions. Automation now and in the future Currently, OPTASY automation requires manual initiation via a queuing system. The OPTASY RA team always initiates the queue when a core security update is released. Otherwise, we initiate a periodic scan. Based on the improvements described here, RA customers can look forward to the following: Daily automated scanning which will create a new branch every two weeks, so as not to flood you with new updates. The ability to approve and automatically initiate all stages in the update process. This means that, unless you need troubleshooting from our team first, you can apply a security update without any required intervention by OPTASY. The ability to specify bug-fix updates that can be included in a security update, or done independently. This will be a feature of RA Premier only. Support for patching via Drush make files. Finally, since Automation is under active development, this is a great time to let us know what features and capabilities you would like! Please feel free to comment below, I look forward to hearing your thoughts. ... Read more
Adrian Ababei / Feb 24'2015
Blog Placeholder
This tutorial covers writing a "Hello World" test for Drupal 7 using the SimpleTest framework that comes with Drupal core. Knowing how to write tests is an important skill, and being able to do so can help to increase the quality of your code, and save you hours of time clicking around your site making sure things still work after making changes.   For example, we've got a feature on our site that allows anyone to embed a copy of any of our free videos into another site. It's a great feature, but to be honest, it's also one that we forget about. It's hidden beneath the "share" link on video pages, and it's not something that any of us do very often. Whenever we make changes to our video player we're diligent about testing them on our site, but often times forget to check the embed codes. Testing them is also a bit of a tedious process because you need to find a free video, find the embed code, copy it into an HTML file on another site, and then test it. As such, we tend to break it from time to time without realizing we've done so until much later.   After having done this a couple of times though, we added test coverage for it. So now, whenever we make changes to any part of the site, one of the things that happens before that change is made live is we subject a copy of the site with the changes applied to a barrage of automated tests. If we break that embed code again (which we have), we'll know about it before it becomes a problem on the live site.   This is just one of the many useful things you can do with automated tests. Keep reading to learn how to write your first test.   After completing this tutorial you should be able to: Create a new PHP class that defines a test Provide Drupal with meta-data about your test Run your test to see if it works Background This tutorial assumes that you are familiar with PHP and basic OOP concepts, and that you've written a Drupal module before and know how to get Drupal to recognize your module and allow it to be enabled. Hello World Start by creating a simple helloworld module directory in sites/all/modules/custom/helloworld/ Add a helloworld.info file with the following contents: name = Hello World description = An example module to demonstrate using SimpleTest core = 7.x Add a helloworld.module file with the following contents: <?php /**  * @file  * Hello World demonstrates the use of SimpleTest for Drupal 7.  */ /**  * Implements hook_menu().  */ function helloworld_menu() {   $items = array();   $items['helloworld'] = array(     'title' => 'Hello World',     'access callback' => TRUE,     'page callback' => 'helloworld_hello_page',     'type' => MENU_NORMAL_ITEM,     'menu' => 'navigation',   );   return $items; } /**  * Page callback for /helloworld.  */ function helloworld_hello_page() {   return t('Hello World. Welcome to Drupal.'); }   In the Administration menu, go to Modules (admin/modules). Enable the Hello World module. In the navigation menu navigate to Hello World (helloworld), where you should now see the text "Hello World: Welcome to Drupal." displayed on the page. This is what we're going to write a test for. Ensuring that when our module is enabled, a user can navigate to the page /helloworld and see this text. Let's get started.   Extending DrupalWebTestCase Any module can optionally contain one or more test cases, and those test cases can either all be in a single file, or spread out among many files. The convention is for files that contain tests to end with the .test extension. And if you've only got one, to name it MYMODULE.test. Start by creating a new file: helloworld/tests/helloworld.test, we will add the code that makes up our test case to this file. All functional tests in Drupal should extend the DrupalWebTestCase class which will provide the utility functions used to drive the test browser, helper functions for interacting with a Drupal application, and all the assertions we will use to perform our actual tests. Add the following to your helloworld.test file: <?php /**  * @file  * Tests for the hello world module.  */ class HelloworldTests extends DrupalWebTestCase { } Add a getInfo() method to your HelloworldTests class. This method returns an array that provides meta-data about our test that the SimpleTest module can use when displaying our test in the UI. This method is required in order for your test to work. /**  * Metadata about our test case.  */ public static function getInfo() {   return array(     // The human readable name of the test case.     'name' => 'Hello World',     // A short description of the tests this case performs.     'description' => 'Tests for the Hello World module.',     // The group that this case belongs too, used for grouping tests together     // in the UI.     'group' => 'Hello World Group',   ); } Add a setUp() method to HelloworldTests. This method is called when the system is preparing the environment for running our tests. It allows us to perform any setup steps required. In this case, we need to ensure that our module is enable during setup so that the page we want to test is available. We can do this by calling the parent classes's setUp() method and passing it an array of modules we want enabled. /**  * Perform any setup tasks for our test case.  */ public function setUp() {  parent::setUp(array('helloworld')); } Add a test*() method to our class. Each test case can have one or more methods whose names are prefixed with the string test. Each of these methods will be automatically called by the SimpleTest test runner, and should contain the various assertions required in order to demonstrate that this test is passing. This example will use the DrupalWebTestCase::drupalGet() method in order to tell the internal browser to navigate to the URL /helloworld. And then use the DrupalWebTestCase::assertText() method to verify that the string, "Hello World ...", exists somewhere in the HTML output of the page the internal browser is currently looking at. public function testHelloWorld() {   // Navigate to /helloworld.   $this->drupalGet('helloworld');   // Verify that the text "Hello World ...", exists on the page.   $this->assertText('Hello World. Welcome to Drupal.', 'The page content is present.'); } Finally, we need to tell Drupal about our new test. Update your helloworld.info file and add the following line so that after clearing the cache the registry will contain a reference to our new HelloworldTests class. files[] = tests/helloworld.test Run your tests Clear the cache so Drupal locates our new test(s). Navigate to Configuration > Performance (admin/config/development/performance) in the Toolbar, and then clicking the "Clear all caches" button. Navigate to Modules (admin/modules) in the Toolbar. Enable the Testing module in the Core section. Navigate to Configuration > Testing (admin/config/development/testing). Select the checkbox for the "Hello World" test to run all tests in this group, or alternately tip the drop down open and choose the individual test case you want to run. Click the "Run tests" button. A new page will open and display a progress bar while your tests run. Once completed, you will be directed to a page with a table that shows the results of your tests. Summary In this tutorial we've written a Hello World test in order to demonstrate some of the fundamental concepts necessary for writing tests for Drupal with SimpleTest. Including, defining our HelloworldTests class in a .test file and making sure Drupal can find it by adding it to our module's .info file. Then providing meta-data about our tests for the SimpleTest UI, and any setup instructions necessary so that the environment in which our tests run is appropriate for our test case. Finally, we wrote a test*() method that used the internal SimpleTest browser to navigate to a page and verify that a string of text is present on that page.   I encourage you to explore SimpleTest through the Testing module in Drupal, and the concept of automated testing further as it provides numerous sanity and time saving benefits. Enjoy. Source: https://goo.gl/MGzNMi ... Read more
Adrian Ababei / Feb 21'2015