Because of the database abstraction layer that was added in Drupal 7, it is fairly convenient to use a variety of database servers for the backend of your Drupal software. While the term "database abstraction layer" does sound rather sophisticated, and the code involved is certainly not insignificant, in layman's terms what this system does is provide a way for a Drupal developer and Drupal modules to work with its database without generally having to be concerned with what type of database it is.
Urls are an extremely important part of your website. They define the structure of your site and allow search engines to index your content. Because of this, it is critical to keep urls pointing to the same content when you migrate your website to Drupal 8.
For this post, I will assume you are familiar with creating custom migrations in Drupal 8. If you are new to migrations or need more information on creating custom migrations, please see the Migrate API documentation on drupal.org.
Drupal 8 ships with the ability to migrate content from older versions of Drupal or from any other systems. When you set up a custom migration you may need to modify incoming data before it is saved to Drupal. Today, I’ll show you how to create your own process plugin for mapping incoming content.
Monday - May 9
This year for DrupalCon 2016 we traveled down to The Big Easy (New Orleans, LA). We packed up the kids and drove from Colorado through Texas, staying just ahead of the thunderstorms and tornadoes. We arrived in New Orleans with plenty of time check in to our hotel.
Monday afternoon was spent setting up our new booth and attending the opening night reception in the exhibit hall. This year we were exhibiting as Drupal Site Support by Monarch Digital.
Are you attending Drupalcon 2016 in New Orleans? Do you need help with your Drupal website? If so, be sure to find me at the Monarch Digital/Drupal Site Support booth in the exhibit hall for some free (as in beer) Drupal help! I’ll be wearing the red t-shirt that says “Free Drupal Help”.
It is undoubtedly difficult for any project being operated by and contributed to by thousands of people, in an uncentralized manner, to keep pushing that project at a rate such that it is always at the front-end of the curve of innovation. At companies like Apple, a singular, unwavering, and incredibly inspired vision put forth by a leader like Steve Jobs helped keep a steadily growing company at the front of its competition despite no longer being just a tiny group of innovators working in a garage.
Here at Monarch Digital, we have had a number of paid interns. Most didn't know much of anything about Drupal when they first started working with us. All were enthusiastic and smart, and we liked them all, but ultimately we didn't hire a single one (so far).
Reflecting on this I wonder, was that outcome something to do with us as an organization? Was it because of them, or even Drupal itself? In reality, it was probably to some degree all of those things combined.
The EU's recent decision stating that Europe's data-transfer pact with the US violates privacy does not immediately impact companies outside of the 4,500 large internet companies that move and store personal data. (Wall Street Journal article discussing this) However, there is some cause to be concerned if you manage a Drupal site that has personal data on European citizens.
The switch statement is a common control structure in programming languages. You will have undoubtedly seen a few if you spend any time working with Drupal modules or themes. Switch statements love to hangout with a theme’s template.php file in preprocess hooks. Consider, if you will, the following:
By default Drupal sends an email as soon as you make a call to drupal_mail(). For relatively small sites this may never be a problem. However, if you run a large site with many users, then you need to develop a stratagy for controling how much mail gets sent at a given time.