سیاره دروپال

Drupal.org - aggregated feeds in category Planet Drupal
Subscribe to خوراک سیاره دروپال
Webinar: How Quicken is Disrupting Digital with Magento and Drupal antonella Fri, 05/12/2017 - 09:00
We're packing our bags and heading south - way south for what is sure to be a weekend jam packed with BBQ, two steppin', and of course all things Drupal. 
Why DevOps is important? How this can be done in Drupal?

Why DevOps is important?
How this can be done in Drupal?
This video will give you a brief idea about the 2 questions..!

heykarthikwithu Fri, 05/12/2017 - 12:31

I recently migrated content from a Drupal 7 site to a new Drupal 8 install using core’s Migrate, Migrate Drupal and Migrate Drupal UI modules. A few months after the initial migration, I decided to enable core Content Moderation for use with one of my migrated content types. No beuno.

Just saving any content for which I had enabled Content Moderation resulted in this tasteless error:

The website encountered an unexpected error. Please try again later.

Clicking over to Recent log messages at /admin/reports/dblog revealed the following exception:

Invalid translation language (und) specified.

It was being thrown from two different places when I attempted to save a node.

The details for each in order were:

Drupal\Core\Entity\EntityStorageException: Invalid translation language (und) specified. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 770 of /Applications/MAMP/htdocs/project/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php). InvalidArgumentException: Invalid translation language (und) specified. in Drupal\Core\Entity\ContentEntityBase->addTranslation() (line 823 of /Applications/MAMP/htdocs/project/core/lib/Drupal/Core/Entity/ContentEntityBase.php).

Several quick searches didn’t turn up anything exactly applicable, but I did find a pretty useful summary of a similar issue that put me on the right track.

Basically, my content migrated from a Drupal 7 site was set with a legacy langcode of und. If I just load a node and output its language attribute using the Devel module’s dpm() function, you can see what’s amiss:

use Drupal\node\Entity\Node;   $node = Node::load(<My NID>); dpm($node->language()->getId()); // returns 'und', which was causing a problem

It’s the language specification of und that was preventing me from saving the content with Content Moderation enabled. Changing the language over to the site default, EN in my case, just took a minute with the following code.

use Drupal\node\Entity\Node;   $node = Node::load(<My NID>); $langcode = \Drupal::languageManager()->getDefaultLanguage()->getId(); $node->set('langcode', $langcode); $node->save(); dpm($node->language()->getId()); // now this returns 'en', which is good!

Now you can see that the language attribute is reflecting an appropriate value, which in my case meant I was able to save the node like normal with Content Moderation enabled. Fixed!

All that remained was doing the same operation for every node in the database. For my project there were only a couple of thousand nodes, so I just used the code below (I ran this at devel/php but you could do it in a module or wherever is easiest).

use Drupal\node\Entity\Node; $langcode = \Drupal::languageManager()->getDefaultLanguage()->getId();   $result = db_query("SELECT nid FROM node WHERE langcode = 'und' LIMIT 100"); foreach ($result as $record) { $node = Node::load($record->nid); $node->set('langcode', $langcode); $node->save(); }

I limited my query to 100 nodes to avoid a timeout, then just executed the code several times until all my nodes were updated. If you have tons of nodes that need updating, you might consider writing a hook_cron or using batch operations.

Warning: The site I was working on wasn't multilingual. The code above sets every node with a language specification of und to the site default, which may not be what you want for a multilingual site.

That’s it! It seems simpler in retrospect but took me awhile to understand what was going on. I also created an issue on Drupal.org so hopefully this bug will get addressed eventually.

Cog is a Drupal 8 base theme created and maintained by the Acquia Professional Service Front-end team.

Many great Drupal base themes already exist, so what does Cog bring to the table?

Tags: acquia drupal planet
The new version of Drupal Commerce has been rewritten from scratch, learning from what worked well and what was causing problems in Commerce 1.x. In this blog post, we will focus on explaining some of the key differences we have seen so far and how they affect developers and users.
After a long travel to Baltimore, where two of our team members (Commercial and Operations director to be precise) attended DrupalCon Baltimore, we will have a much shorter distance to overcome this time. In fact, we'll be going to the nearest Drupal Camp possible. That's in Zagreb, where our development team will attend Drupal Heart Camp Zagreb. Since we are located in Ljubljana, Slovenia, our nearest destination would be our coast, where there was once a Drupal Camp Alpe-Adria. But since the Camp is not taking place there anymore – we discussed that with one of its organizers Janez Urevc… READ MORE
A Week of Learning & Growth at DrupalCon Baltimore leigh.anderson Wed, 05/10/2017 - 19:40

It’s hard to believe that another DrupalCon has come and gone — it feels like just yesterday when we were mourning the passing of Drupal 6 in New Orleans and unveiling our new branding in Los Angeles. DrupalCon Baltimore was a success for us, and we wanted to share some of our memories from the event.

Our Week at DrupalCon

It was an honor to introduce Dries on Tuesday morning at DrupalCon. We were grateful that we had the opportunity to discuss two projects that are near and dear to our hearts: The Open Y Drupal distribution, and Drupal Global Training Days.

We were also thrilled to have so many visitors drop by our booth. It was great seeing so many old friends and making new ones, and we’d like to say congratulations again to our raffle winners: Mark (pictured below) & Dennis, who won Apple Watches, and Patrick, who won an Amazon Echo.

FFW Session Recordings

We had a great time sharing our knowledge in trainings, sessions, and BOFs. If you didn’t catch the FFW crew in action, you can watch recordings of our sessions here:

  1. Anti-Crash Course: How to Avoid Drupal’s Most Common Pitfalls
  2. Using Drupal to Power the YMCA
  3. Scaling and Sharing: Building Custom Drupal Distributions for Federated Organizations
  4. Less Is More: What Modules, Features or API's Should We Cut From Core?
  5. Docksal: Better than VMs
Farewell, Baltimore; Hello, Vienna!

As always, we stayed for the community. We were heartened to see so many people working together to grow the project, navigate new territory, and have thoughtful conversations about the future of the Drupal software and the community’s governance. We’re looking forward to the continued discussions about the community’s structure and future; if you’d like to participate, you can find future meeting information here.

It was a pleasure to sponsor such a great event. We’re looking forward to seeing who we meet and what great conversations we have across the pond at DrupalCon Vienna this September.

DrupalCon group shot credit to Michael Cannon on Flickr.


In the previous article, Getting Started With Drupal Commerce 2.x (Part - I) we have set up the Drupal commerce module 2.x and build the store. The next step to finish the basic commerce 2.x setup is to create Products.

Let’s have a detailed summary of e-commerce products creation in commerce 2.x.

1. Products :

Here we should note the main difference of Drupal Commerce 2.x (for Drupal 8) from Drupal Commerce 1.x (for Drupal 7). In Commerce 2.x, we now have such entities as Product and Product Variation. The product replaces product display of Commerce 1.x (node type, which has been linked to the…

This one is dedicated to all my fellow Drupalers. There’s no better exercise for a brain than reading ancient chinese poetry taming Drupal 8. When I’m bored, I turn to Drupal!

Recently I got my Drupal 8 Address module updated and it turned out that from now on street address ...

Read now

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Webform Multifile module to fix an Access Bypass vulnerability.

This module enables you to upload multiple files at once in a Webform, but it didn't sufficiently check access to file deletion URLs.

This vulnerability is mitigated by the fact that an attacker must have a role with the permission to edit all or their own webform submissions.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the Webform Multifile module, we recommend you update immediately.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

After board meetings, I publish a blog post to provide an overview of the meeting along with the board packet, meeting minutes, and a video of the meeting. Since we just had a board meeting at DrupalCon Baltimore, I want to share details about that meeting as well as pull the lens back to give the community more insight into board meetings and our 2017 schedule. I hope this additional information gives better insight into the Drupal Association’s board activities.

Drupal Association Board Meetings

The Drupal Association board has two different meeting types: Executive Session and Board Meeting. They take place throughout the year to create The Drupal Association’s strategic direction, ensure financial health, engage with the community, and more. This post goes into more details about each meeting type.  

Executive Session

The executive session is usually a two-day meeting that includes board members and the executive director. At times, it can also be a shorter virtual meeting. Topics typically include an Executive and Financial update, financial approvals, committee work, and strategic planning for the Association.

There are four executive sessions a year. All meetings are private to create a safe space for brainstorming strategic direction and discussing confidential matters such as the executive director’s performance and compensation. For this reason, meeting minutes are not shared publicly. However, we will let the community know when we are meeting and what is on the agenda.

The 2017 executive session schedule is: 23 & 24 February, 22 & 23 April, 26 June,  23 & 24 September, and 29 November. The February, April, and September sessions are two day meetings while June and November are two hour virtual meetings. As needed, the board may schedule additional executive sessions to handle business that is time sensitive and best done via a meeting.

The 23 & 24 February executive session agenda covered the following:

  • Executive and Financial Update

  • Getting grounded in DrupalCon Europe survey data (Michael Schmid was present since he was part of the task force)

  • Discuss the future of DrupalCon Europe focusing on sustainability and delivering meaningful value

  • Thank you and goodbye to community-elected board member, Addison Berry.

The 23 & 24 April executive session agenda included the following items:

  • Executive and Financial Update

  • Approve Q3 2016 financial statements

  • Welcome Ryan Szrama - new community-elected board member

  • Understanding community governance needs and identifying community governance gaps

  • Meet and greet with Drupal Association staff / Congratulations on upcoming DrupalCon

Board Meetings

The Drupal Association holds four board meetings each year so the community can observe the board proceedings and participate in a Question and Answer session. Typically, board meetings include operational updates from staff, committee updates, and question and answer time for both the board and the community.

On 26 April, 2017, the Drupal Association held its first board meeting of the year. The board materials and meeting minutes can be found here. All board members were in attendance except Annie Miller, Steve Francia, and Donna Benjamin. Also in attendance were myself, Drupal Association Staff, and about 30 community members.

Dries Buytaert kicked off the board meeting and I reviewed the board packet, which included the meeting’s agenda as well as a scorecard for the key operational projects that staff work on. Next, staff gave operational updates. Tim Lehnen, Director of Engineering, gave an update on Project Application Process, Contribution Credits, and the Drupal.org Infrastructure RFP. Next, Carrie Lacina, Director of Revenue, shared an update on the Drupal.org industry pages. This was followed by Rebecca Pilcher, Marketing & Communications Manager, who gave insight into the new DrupalCon branding.

Lastly, I gave an update related to recent community challenges. I explained that a key way to understand the community’s needs and help them talk about a new community governance model is by hosting mediated Community Discussions. Whitney Hess, the mediator, introduced herself to the board and gave a brief update of the themes she heard in the recent Community Discussions onsite at DrupalCon.

The Board had 10 minutes to ask questions which covered topics such as branding and the Drupal.org infrastructure RFP. While the community had 10 minutes to ask questions, the meeting was extended, giving the community 30 minutes to ask questions. Their questions touched on DrupalCon branding and Project Application Process. There were also several questions related to the learnings gained by the recent community challenges.

You can watch the video of the board meeting here as well as read the meeting minutes and board packet. All materials are found here. The next board meeting will take place on 26 June, 2017 at 12:00 EDT/17:00 BST. It will be a virtual meeting via Zoom. You can go here for login information.

The D8 project I'm currently working on used the file-system based workflow for configuration management. As our deployment workflow improved and got slightly more complex, we started to run into issues with file permissions during deployments and wanted to revert back to the database based workflow that is the default for a new D8 installation.

Unfortunately, though there are a lot of resources on the web that explain how to go from the database to the file system approach, I couldn't find anything explaining how to revert back to the database based configuration workflow. All there is, is this kind of information:

You should do this before installing Drupal, as it is complex to revert back to database-based configuration management setup once you switch to file-based.

So I did some digging and came up with this:

Step 1: Backup

Make a backup of your database and your codebase including all configuration files and your settings and services yaml files. The following actions have the potential to break your site. Do everything on a non-production site, preferabbly hosted on your local machine so that recovery is easy.

Step 2: Export your current configuration

Run this drush command to export your configuration:

drush cex syncStep 3: Revert your settings and services

Put the following in your services.yml:

services: config.storage: class: Drupal\Core\Config\CachedStorage arguments: ['@config.storage.active', '@cache.config'] config.storage.active: class: Drupal\Core\Config\DatabaseStorage arguments: ['@database', 'config'] public: false tags: - { name: backend_overridable }

And comment out the config storage setting in your settings.php:

// $settings['bootstrap_config_storage'] = array('Drupal\Core\Config\BootstrapConfigStorageFactory', 'getFileStorage'); Step 4: Clear caches

Clear your caches using these drush commands:

drush ev "drupal_flush_all_caches();" drush cr Step 5: Re-import your configuration

Run this drush commands to import your configuration:

drush cim sync

This step failed for me at first, due to interdependency between different configuration sets. In my case there had been changes to fields that where attached to some custom ECK entities, and the configuration import wanted to import these before the definition of the actual entity. I was able to work around that by moving the conflicting field configuration out of my configuration sync directory, run the import, moved the files back into the sync directory and run the import again. But you might need to tinkle a bit more with that if you have a complex setup.


Running these 5 steps allowed me to move the site back to use the database based configuration workflow. Let's see if that also helps us with our deployment problems.

Category: Drupal Planet8.xTags: configdevsystem
What's keeping us busy this spring

We, at Drop Guard, never stop thinking what else can we do to help Drupalistas around the world to get aboard of the continuous update process ship (as we call it) as soon as possible. More and more threats are being discovered every day, and it's absolutely imperative to stay alerted all around the clock either with help of automation platforms like Drop Guard or doing things your own way.

Drupal Planet Drop Guard features

Drupal 8 introduced an interesting new approach called "experimental modules".

These experimental modules are included in the Drupal core, and have inspired several questions from OSTraining members. What are these experimental modules, and is it safe to use then?

Yes, experimental modules are shipped with the Drupal 8 core, but they are not yet fully supported. Here's the official explanation:

Experimental modules allow core contributors to iterate quickly on functionality that may be supported in an upcoming minor release and receive feedback, without needing to conform to the rigorous requirements for production versions of Drupal core. Like other features, new experimental modules can only be added in minor releases, but unlike other features, they may change between patch releases while they are still experimental.

Learn how to create content via email and have it imported into Drupal using Mail Comment.

The Lowdown on DrupalCon Baltimore brandt Tue, 05/09/2017 - 16:33 Alex Brandt May 10, 2017

Our favorite parts of DrupalCon Baltimore.

In this post we will cover...
  • Our favorite events from DrupalCon

  • Links to Palantir sessions

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

DrupalCon is always a positive experience for the Palantir team, largely because of the Drupal community itself. Our week in Baltimore was filled with engaged conversations, thoughtful sessions, and much appreciated down time with friends we don’t get to see often enough.

DrupalCon by the Numbers
  • Palantiri in attendance: 14
  • Palantiri sessions: 3
  • Client meetings: 7
  • Coffees consumed: at least 2 dozen
  • Newsletter sign-ups: 240
  • Podcasts recorded: 2
  • Late nights: 2 many

“It was a wonderful first DrupalCon experience because of a great community that is so supportive and accepting of newcomers, regardless of their level of Drupal knowledge.” - Annie Schow

Highlights by Day

Monday: We ate all the crabs.
Following the opening reception in the exhibit hall, we ate dinner as a team at Riptide by the Bay In historic Fells Point. An impressive amount of crabs were consumed.

Tuesday: #PMTheMusical!
We witnessed another standing ovation for Joe Allen-Black and Allison Manley and their performance of Project Management: The Musical! There were quite a few crowd favorites, and Joe and Allison were both happy to share their final performance of this presentation in front of an energetic DrupalCon crowd.

Wednesday: Inclusion Initiative
We partnered with another Chicago-based agency, Digital Bridge, to coordinate a Drupal training session for five students local to Baltimore who were unfamiliar with Drupal. We’re looking forward to expanding the program in the future. Keep an eye out for more details on that later this month!

Thursday: #ContentBeforeCode, #DevTeamCollab and Trivia Night
If you missed them at MidCamp, Megh Plunkett, Michelle Jackson, and Bec White did round two of their sessions on Thursday (recordings linked above). Michelle and Bec’s session will also be available via a webinar later this summer, so stay tuned for your chance to sign up in case you missed it at DrupalCon.

Palantir also hosted Trivia Night at Baltimore Soundstage. We’re not sure the wait staff knew what was happening as over 400 people were tasked with answering some fairly obtuse and nerdy questions about this mysterious Drupal thing, but they kept everyone hydrated so we could enjoy the fun. Jeff Eaton killed yet again as the emcee for the evening. 

Friday: Exploring Baltimore
As people shuffled to the airport, a few Palantiri were able to squeeze in a last minute trip to the Baltimore National Aquarium. Thankfully not one Palantir was lost to sharks.

Thanks for a great week Baltimore. We’ll see you next time, DrupalCon!

We want to make your project a success.

Let's Chat.

Talking through the growing pains of using Drupal with Composer dependency management at DrupalCon Baltimore. Drupal gets better when companies, organizations, and individuals build or fix something they need and then share it with the rest of us. Open source technologies become better, stronger, and smarter when others take it upon themselves to make a positive difference contributing their knowledge, time, and energy to it. Acquia is proud to play a part, alongside thousands of others, in making tomorrow’s Drupal better than today’s. One of the people making a difference is Jeff Geerling.

Tags: acquia drupal planetComposerdependency managementdrupalcon

Getting faster page load speeds isn’t just about increasing your Google rankings. It’s about improving customer satisfaction and gaining new revenue. Using tools specific to Drupal along with other universal actions, you can reach your marketing goals faster than ever.

It’s no secret that page loading speed matters to Google rankings. Speed became a ranking factor in 2010 and since that time, developers and marketers have been looking for ways to increase it. Google cares about page speed because the search engine is focused on delivering the best onsite user experience possible. As a result, Google rewards fast-loading websites with better rankings. (The converse is not always true. Slow page loading times will only negatively impact your site rankings if it is very slow.)

As a marketer, your goal really isn’t better Google rankings. You are looking for the result of those rankings—more website visitors, more leads and more revenue. As a marketer, fast page load times aren’t the goal either; but, a means to improve your users’ experiences. Better website interactions can result in greater satisfaction, more conversions, and higher sales.

Faster Page Load Time Results in Greater Revenue

Faster page navigation means that users may see more page views each time they visit your site. Having a fast website means that users can quickly understand your offering and purchase your products.

Studies show that faster page speed results in greater revenue.

  • Both Amazon and Walmart, in separate studies, attribute additional sales revenue from faster page speeds. Their revenue grew by 1% for every 100ms of page speed improvements. For Amazon, slowing down their page load time by just one second could result in a loss in revenue of $1.6 billion. That’s a lot of zeroes for a measly second.
  • Shopzilla increased revenue by 12% and page views by 25% by speeding up their page load time to 1.2 seconds from 6 seconds.
Customer Satisfaction Increases with Faster Page Speed

Faster websites mean happier customers. Particularly, studies have shown that:

  • A one-second delay in page-load time leads to a drop in pageviews (11%), conversions (7%), and customer satisfaction (16%), according to the Aberdeen Group.
  • Econsultancy research found that 47% of consumers expect to wait no longer than two seconds for a web page to load. Additionally, 88% of people who experience a dissatisfying visit due to page load times are less likely to shop from that site and more than a third will tell their friends about the bad experience.
  • According to KISSmetrics, 18% of mobile users will abandon a website if it doesn’t load in less than five seconds. If it takes more than 10 seconds to load, 30% will abandon the site.
Is Your Website Fast Enough?

The evidence shows page speed matters. Is your website fast enough? At a minimum you should aim for under 2 seconds. For e-commerce sites, you should have even faster goals.  Google’s goal is 100ms—faster than the blink of an eye.

It’s quite simple to test your website speed.  You can use Google’s PageSpeed Insights tool and WebPageTest.org to take a benchmark of how your website performs. If your pages load in more than two seconds or if you haven’t met your page loading goals, you should consider taking some of the steps below.

Ways to Increase Your Drupal Website Performance

There are general ways that every website manager can implement to speed up page loading, but there are also specific Drupal tools and modules to know and implement. I’ll address both of these.

1. Keep it simple.

Page speed starts with choosing a design that is clean and fast. By reducing the number of components on your page, and keeping widgets and embedded media to a minimum, you are on the way toward a lightning fast website.

2. Cache your pages.

Drupal 8 enables caching by default for anonymous visitors. That is sufficient for small to medium sized websites with moderate traffic. You can select the maximum age for your page caching based on how quickly your website content changes.

1 day - good for websites that are only updated a couple of times per week. There is no commenting or other interaction on the site. (lead generation brochure site)

1 hour - good for websites that are updated once or twice per day. (ecommerce)

15 minutes- good for frequently updated websites. (news sites)

If you use Drupal 8 Views or Panels, you can get more fine-grained in your cache settings. The caching on each individual block can be customized as well.

3. Optimize your website to work with different devices and browsers.

You can no longer only optimize speed for desktops. With 60% of online traffic coming from mobile devices, a mobile responsive website is critical. All of the things that you do to speed up your website will help, of course. There are also things that you can do specifically to make your website more responsive for mobile devices. You should make sure that your website is optimized to work with popular mobile browsers. One of the most powerful things you can do is to implement the Google AMP module. We talk in detail about it in our article, How Marketers Use Drupal's AMP Module to Improve Google Search Rankings.

4. Compress your images, CSS and Javascript files.

The Advanced CSS/JS Aggregation module aggregates and compresses CSS and Javascript files to make your site run faster. Google loves fast websites and this module speeds things up with little overhead.

Drupal 8 Core has the ability to resize images and serve the right image for any situation. It can scale them, crop them, and much more. Consistent image sizes help reduce the bandwidth required to load a particular web page. This can greatly reduce load time.

5. Use a Content Distribution Network (CDN) with Drupal 8

There are a few third party tools that you can use with Drupal to speed up your website. A CDN stores your website on servers across the globe. CDN companies own data centers on every continent and in every region. Think of it as taking your server cache and making copies of it to servers that are a lot closer to your visitors. If the HTML does not need to be recreated by Drupal, then it is served directly from the CDN, greatly reducing the load times involved.

Example companies include (my personal favorite) CloudFlare, Level3, Amazon, and Akamai. The CDN module for Drupal is located here. There are also service-specific modules for CloudFlare and

6. Choose a host that can offer greater speed

If, after implementing some of the tips above, you are still not meeting your performance goals, you should consider choosing a faster host. When you look for hosting, you’ll find many options. At Volacci, we have experience with several dozen hosting companies that promise Drupal support and high speeds. In order of most capable to least capable (with considerable overlap in performance and cost), here is a list of the types of hosting you may want to consider:

Managed Dedicated Server(s)

A managed dedicated server takes care of all your hosting needs for you. Not only do you get the hardware but you get a team of experts to make sure everything is running as it should. They will keep your software up-to-date and alert you if there are any problems – often after they’ve already been fixed. You can deploy multiple servers in many configurations. For example, a firewall, caching server, database server or multiple http servers could all be part of a larger solution. It’s fast and reliable hosting. Adding multiple servers or getting help designing the perfect configuration for you is part of the service. Blackmesh (my personal favorite) is the Drupal-specific company for this kind of hosting. Also consider Rackspace.

Dedicated Server(s)

A dedicated server provides low latency which means a fast response time for most small to medium-sized sites. Consider that you need to provide technical staff to manage the hardware and software stack. Examples include HostGator and Viawest.

Cloud Hosting

Cloud hosting is scalable. The “cloud” means that there is a data center with lots of dormant servers. As your site’s needs scale up (or down) the servers in the data center respond with more server power. While it may be a panacea for some, latency and cost are critical concerns. Examples include Acquia Cloud, Pantheon, and Platform.sh.

Virtual Private Server (VPS) / Server Slice

A VPS offers a good balance between cost and performance. It’s similar to shared hosting in that you share a single server with other tenants. However, you get a guaranteed amount of performance on that server. Maybe 10% (or more) dedicated to you which preserves your performance. Examples include HotDrupal and Green VPS.

Shared Hosting

Shared hosting is the rookie league of hosting. Your site sits on a server with many other tenants. It’s slow and not scalable but it’s inexpensive. Examples include Bluehost and SiteGround.

Learn More with Drupal 8 SEO

If you would like specific details on how to speed up your Drupal 8 website and optimize it for higher Google rankings, take a look at Drupal 8 SEO. This book is the definitive authority on SEO for Drupal 8 websites. Check it out.

Contact Volacci if you would like our Drupal SEO experts to create a plan and implement best practices that will maximize your website performance and improve Drupal SEO.

Surprising Marketing Benefits of Increased Web Page Loading Speeddrupal 8, drupal websites, Planet Drupal

This is the second part of a series of blog posts about automated testing for Drupal. Its mission is to take you from zero testing experience to confidence in testing your custom Drupal work, from the ground up. Last time, in Testing for the Brave and True: Part Zero we defined exactly what automated testing is and discussed some of the common vocabulary of testing. It also introduced the two primary tools used by the Drupal community to test their work, PHPUnit and Behat.

Why Automated Testing Will Save You Time and Treasure

Now that we know a little about what automated testing is, I'm going to make the case that it can be a net positive to your everyday workflow and actually make you a better programmer.

Everybody Tests

If you came to this blog post with the idea that you've never done any testing or that you've tried to test and didn't succeed, you'd be wrong. Every developer tests their code. Some developers just throw that work away.

Consider what you're doing every time you clear cache and go refresh your browser. You're testing your work. You've made some change to your code and now you're asserting that your work functions as you expect. Perhaps you put a dpm() or kint() in your new code to inspect some part of your code or a variable, or maybe you're using XDebug (if not, I'd encourage you to start) to step through your code. This process is testing.

While these informal tests can be incredibly valuable, you can't commit them; you can't run them the next day and you cannot run all the tests you've ever written with just one command. Writing automated tests is simply writing code that can do some of that testing for you. It's making those informal tests you already do, explicit and formalized.

Context, context, context

Whenever you write code to do specific things, you make assumptions. Assumptions are the foundation of abstraction and abstraction is the foundation of progress. You can't write code that does anything useful without making assumptions. Especially in Drupal. Entities themselves are an abstraction writ large. But, wrong or hidden assumptions are also the root of most bugs.

Therefore, when we write code, we ought to be very aware of the assumptions we make. We ought to record those assumptions in some way, for future maintainers or simply to help us remember that we made them in the first place. Unfortunately, when we only do informal testing, we bake our wrong assumptions into our code without leaving a record of them. We can't re-assert our assumptions later without digging through code or comments or taking the time to figure out what something was actually supposed to do.

This is the first place where formal tests can be a boon to you, future you, and your successors. The act of writing formal, automated tests by its very nature is recording your assumptions for posterity. When you return to your code an hour, day, week, or year later, all the assumptions you made can be tested again. If you have a strange if/else in your code because of some edge case you discovered when you were doing your initial development, a test can ensure that that code isn't deleted when you're cleaning up or refactoring later (at least without explicitly deleting the test).

In short, you make your assumptions explicit. This reduces the cognitive burden of "getting back up to speed" whenever you need to come back to some piece of code.


This is where I first really fell in love with testing. Having formal tests for the code I was working with gave me confidence as I made changes. That can sound strange to someone who's never tested before. It sounded strange to me, too.

The confidence I'm talking about is not the confidence I have in my abilities (Lord knows I could learn a little more about being humble), it's my confidence in the codebase itself and the relative safety I have when I incorporate a change.

If you've ever been in an old, large, legacy codebase, you might recognize that feeling of mild anxiety when you've made a change and there's just no feasible way to know if you've broken something else in some obscure place of "the beast". The only thing you can do is click around and cross your fingers. This is where a well-tested codebase can create real confidence. Having a suite of automated tests means I can isolate my changes and then run all the tests ever written for that codebase and ensure that my changes haven't broken something, somewhere.

Better tests, better code

If you've been interested in the art of programming itself (and I think you must be to be reading this), then you might have heard of the SOLID design principles. Or, at least, things like "write small functions" and "do one thing and one thing well." Maybe you've heard about "dependency injection," "separation of concerns," or "encapsulation." All these words are names for the concepts that, when applied to the way we write code, make the likelihood of our code being robust, flexible, extensible, and maintainable (all good things, right?) go up.

The art and practice of testing itself can help you apply all of these concepts to your code. If you recall the term "unit testing" from the last post in this series, I said, "[unit] tests isolate very small bits of functionality." The process of identifying the one small thing that your code achieves in order to test it, helps you apply the Single Responsibility Principle. Put another way, when your tests become large and unwieldy, they're saying to you, "this code does too much and it should be refactored."

When you're testing code that has dependencies on other code or configuration, like access to the database, another service, or some credentials, it can become difficult to write useful tests. For example, if you're writing code that runs an entity query and you'd like to test how the code works when there are no results, five results or 500 results, you would have a hard time doing so with a real entity query and database connection. This is where "inversion of dependencies" or "dependency injection" come into play. Instead of running an entity query and doing processing on the results all in one function or within a single class, pass the entity query or its results into the function, method or class. This allows you to test the function with fake results, which you can then set up in your test (we'll go over the methods for doing exactly that in a later part of this series).

That inability to test code with implicit dependencies is a good thing™—it forces you to do dependency injection, whereas it's simply a ritual that you have to practice without tests (I should note, the reason inversion of dependencies is a good thing™ is because it makes your code modular and helps ensure it only "does one thing well").

What's next?

I hope I've made a convincing case that writing automated tests for Drupal can save you time and treasure. In the next part of this series, we're going to begin our descent into the art of testing itself. We'll go over writing our first unit test and getting it running on the command line. Until then, feel free to comment or tweet @gabesullice if you've got questions!

آخرین ارسال ها

محتواهای محبوب

درباره ما

اینجا دروپال یعنی همه چیز. در مورد دروپال صحبت میکنیم. ماژول هامون رو به اشتراک میزاریم در مورد قالب دروپال ، فروشگاه دروپال، دروپال فارسی و تاریخ شمسی دروپال صحبت میکنیم و هرچیزی که در مورد طراحی سایت با دروپال میدونیم به هم انتقال میدیم. دروپالیون یک سایت شخصی نیست. ما دست همه کسانی که برای پیشرفت دروپال تلاش میکنند رو میفشاریم و با آغوش باز اونها رو در این سایت میپذیریم.

تماس با ما

با ما تماس بگیرید.