Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 11 hours 16 min ago

Gizra.com: Organic Groups and Message Stack in Drupal 8

8 June 2016 - 2:00pm

Hi geeks! Did the post title get you excited? Great, because Organic Groups (OG) and Message stack are getting closer to being Drupal 8 ready.

I’d like to give an overview about their state, the amazing community effort around them, and also share some of my personal thoughts about contribution to Drupal 8 in general.

Organic Groups

The heroes: @RoySegall, @pfrenssen @damiankloip, @chx et al.

For years Organic Groups has been one of the proven solutions for multi-sites functionality, in the form of one code base, one database, and one dashboard to rule them all. After so many years and seeing so many different implementations, such as Harvard’s OpenScholar, OpenAtrium, and many others, I’m even more confident OG is doing many things right.

Most of OG7’s concepts are being migrated to OG8, but obviously this is also a good time to fix some old mistakes. One of the mistakes was treating users and content (i.e. non-user entities) alike. But, well, you know - they are not. Because when we came to re-think of it, membership really makes sense only for users. For example, if the membership state is active, pending or blocked, that should indeed be applied only to users. So we’ve changed it:

Continue reading…

Categories: Drupal

Axelerant Blog: Migrate To Drupal 8 For Mobile First, Global Ready Features

8 June 2016 - 11:00am

If you or your competitor is moving to migrate to Drupal 8, that’s good for one of you… and potentially really bad for the other.

Somebody is picking up on something big, because Drupal 8 migration is a mark of enterprise-level thought or a sign of aspiring enterprise-level vision. If you or your associates aren’t sold yet, the proof is in D8’s mobile, global features.

You could say accurately that modern Drupal is a preemptive, forward step, a step away from the dangers of a Closed Source, “one size fits all” mentality. See headless Drupal migration stories for even more proof.

Big question: why migrate to Drupal 8?

Well, the sense that mobile incompetence and unchecked global competition are deal breakers? That’s more than a feeling. That’s a fact. Today if your website isn’t responsive and built for growth with features like those of Drupal 8, you’re declining. Let’s get why:

  1. Face it, we need a different kind of responsive.
  2. What makes Drupal 8 mobile first.
  3. You migrate to Drupal 8 for all users.
  4. Migrate to Drupal 8 for your customers.
  5. And migrate for international teams.

Decision makers like you, with a keen sense for growth, will see. Within these features are the traits of an evolving Open Source software for 2016 onward. 

1. Face it, we need a different kind of responsive.

Having a responsive design means having a website that automatically looks good no matter your user device’s viewport size. The way we search the internet has changed. Search technologies and site owners must account for it.

Just last year, Google rolled out a mobile friendly algorithm that led to mobilegeddon. It was labeled a doomsday because of the tremendous boost in search engine results given to responsive websites versus the whack it gave desktop-only sites.

How far does mobile reach?

In the US, one out of every three people owns a smartphone. Worldwide, it’s one out of every five. The number of users browsing on tablets, phablets, and phones will continue to rise—website responsiveness becomes more critical every day.

Responsive websites are made possible with things like CSS media queries. These queries define how page elements should be displayed to users. Its effectiveness can be checked with responsive plugins and extensions from Chrome and Safari. At Axelerant, we created a simple URL mobile friendly website tester that can check your site.

But shouldn’t “desktop” versions come first?

Not anymore. Productive websites from now on should be treating the desktop as secondary. The demand for mobile, responsive themes has never been higher and it continues to rise. The number of users accessing sites from mobile devices only is steadily growing.

Users in the US alone are accessing mobile online media 51% of the time, compared to the 41% using a desktop. These accesses drives the Drupal community to focus on mobile first because we’re passed the 50-50 mark. Having a clear focus on mobile first designs can also improve the efficiency of your desktop website. Your website’s responsiveness has to be taken into account if it’s going to be productive to you and your end users—to inform, deliver services, generate leads, and more.

2. What makes Drupal 8 mobile first.

Drupal 8’s very essence is accessibility because it was made with a mobile first mentality—for users and end-users. When site owners migrate to Drupal 8, they solve the need for an extremely responsive website. It’s an upgrade that isn’t an option anymore.

For Drupalers like us, a Drupal 8 upgrade provides fresh mobile-friendly development for the content management system (CMS) and Open Source software (OSS) industries. In fact, Drupal’s original creator and product lead Dries Buytaert said way back in 2011:

If I were to start Drupal from scratch today, I’d build it for mobile experiences first, and desktop experience second.

Considering all of its modern features, Drupal 8 has been well worth waiting for. Contributors charged forward with a transforming Mobile Initiative to create a first-class mobile platform, spearheaded by the initiative’s lead John Albin Wilkins. The admin interface, themes, tables, and pictures were focused on and today these are incredibly useful:

Drupal’s Admin

As a mobile friendly CMS, Drupal enables on the go administration. Managing content on a mobile device has become painless. The admin layer has been revamped to be simple, straight-forward, and light. Toolbars work horizontal or vertical as needed.

Great Responsive Themes

All built-in themes are responsive. These give you the power to change the way your site looks and feels. Drupal 8’s new theming engine Twig is PHP-based, secure by default, easier to read, and front-end developer friendly.

This new theme flexibility enables the creation of highly attractive, highly functional sites that look great on mobile. The right theme will help power your organization’s branding while providing positive user experiences.

The goal was to transition all existing Drupal 8 themes from “desktop only” to mobile first, and for all to include a useful backend platform. This ties into the push to make Drupal the leading mobile CMS platform.

Flexible Tables

When a user views the page from a narrow device viewport, such as page’s horizontal elements will automatically become vertical, with lesser important columns being removed.

Breakpoints are built into Drupal 8, which keep track of height, width, and resolution. These breakpoints enable a site to respond appropriately to different devices: tables and the likes shrink readily to preserve mobile integrity. So when transitioning from a desktop screen to a mobile one, you’ll see tables adapt seamlessly.

Picture Perfection

With such an emphasis being placed on ease of use for end users and administrators, with a migrate to Drupal 8 images become responsive. Administrators can add large photos to their pages that automatically size themselves appropriately based on the viewer’s device.

The Drupal 8 responsive module that contains breakpoint mapping and an image formatter that efficiently reduces file weight by resizing the image. These features can be used to output responsive images using the HTML5 picture tag.

Responsive image support isn’t just visually convenient, it helps pages with large images load faster. Meaning that pictures worth 1,000 pixels don’t have to make your mobile site slow or awkward.

3. You migrate to Drupal 8 for all users.

You already know that the standards of your website should be up to par with the growing number of relevant on-the-go, global web users. A huge, growing number that has a direct effect on your organization or will soon. Accessible websites existing within the digital space will either experience the positive or negative side of the expanse: one billion users in 2005, two billion in 2010, three billion in 2014, almost three and a half billion in 2015, and counting.

Now if you keep these numbers in mind, consider that the number of smartphone users in the world is expected to be a massive 6.1 billion by 2020. This growth means that in less than five years, 90% of the world will be online and at that point, 70% will be mobile.

You might be tempted to think: “these numbers don’t apply to my organization. Relevant visits to my site aren’t going to increase as these figures grow.” That’s only correct if your website isn’t mobile first and global ready. In fact, if your site isn’t more accessible now than before, you can expect the number of new, relevant visitors (potential customers searching for your services) to drop.

4. Migrate to Drupal 8 for global customers.

Drupal 8 mobile-based global websites are designed to be accessible for international users from other countries and different cultures. With a migrate to Drupal 8, modern organizations looking to target specific even global reaching demographics can succeed.

However, due to rising internationalization and increasing globalization, all forward thinking businesses will eventually need to take up these searchable, accessible, localized websites. Localization is especially true for e-commerce sites, which must be prepared to cater to ever-changing global e-commerce data. If you’re selling a product or a service online, chances are you’ve been made aware of increasing numbers of international visitors. If your organization has the structural capabilities to sell to these demographics, it should.

What’s this about website localization?

This isn’t the opposite of what’s called website internationalization or globalization. Website localization refers to “local” site adaptations, which facilitate particular communicative, cultural, or other demographical requirements that cater to a particular target market. Globalized or internationalized sites enable localization.

Ongoing Drupal 8 initiatives are aimed at improving its localizing interface to suit international users. Likewise, these users can create localized Drupal sites for their audience. What helps make this possible is a sophisticated translation manager in the Drupal core. This system empowers users to utilize the right translations, for example, for each targeted demographic that need to be reached.

5. And migrate to Drupal for international teams.

To be global ready is to be user-friendly on an international scale, and Drupal internationalization accomplishes this. In the late 90’s, over 80% of internet users were native English speakers, by 2010, this dropped to less than 30%.

With Drupal 8’s multilingual capabilities, international site visitors and Drupal 8 site builders alike aren’t met at a half-way mark, but where they’re most comfortable: in their language. Drupal 8’s Configuration Translation enables the translation of essential elements—blocks, toolbars, menus, etc.

With these essential features, Drupal 8 positions itself as the global ready website option. Multilingual feats like translation and transliteration are two pillars of this positioning.

Drupal 8 Translations

Advanced multilingual capabilities of Drupal 8 are hallmarks of this release. Whereas Drupal 7 has regional settings, language support, and usability attention given to interface translation, Drupal 8 brings this into the core. It comes with highly improved language detection abilities that are browser based, meaning it functions to identify preferred languages and present them to users automatically.

There’s 94 languages and counting, one of which that you can assign as a website default for content and configurations. Blocks can also be language dependent. Further, more page elements than ever are now “blocks” in Drupal 8, granting greater translation accessibility.

Even “Transliterations”

There are times when characters need to be romanized for various purposes. Drupal core has addressed this. Now, built-in user interfaces transliterate key language assignments. This transliteration is an advancement from other CMS solutions, enabling efficient romanization of several challenging scripts and types (e.g. Hungarian, Czech, Marathi).

There is a variety of multilingual Drupal 8 sites in production settings of multiple industries that demonstrate Drupal 8 easily makes possible.

Migrate to Drupal 8 for results.

If you migrate to Drupal 8, you’re setting your organization up for the future. The importance of a mobile-friendly and global ready website cannot be overstated. You’ve heard it more than 1,000 times that “content is king.” It’s true, but it has to be accessible first so your targeted content reigns supreme. Your content after a migration to Drupal 8 can become even more SEO friendly, fast, mobile, and manageable.

Great content doesn’t just happen. Content creators and copywriters need to apply their trade strategically more than ever before. And while it’s principally a supportive means for content creation, Drupal 8 will certainly help. In so many ways, Drupal 8 and content marketers were meant for one another.

SEO capabilities: Users have tons of available modules that monitor SEO activity and track analytics. It’s also able to produce automatically customizable meta tags or create title based URL nodes for a website. Awesome tools like Yoast and Goalgorilla can now be incorporated to develop a site’s SEO in all aspects. Drupal 8 also supports RDF and integrates very easily with Google Analytics.

Content Loading: Another way that Drupal 8 supports content has to do with how quickly and readily it loads. Loading speed is a huge factor that will directly affect both the site’s global rank and local rank. Now Google provides insights on a page’s loading speed to help isolate costly hold ups. Drupal 8 has features that help users address page load issues. As an example, Drupal 8 caches all entities and only loads JavaScript when necessary. What this means for a page is that viewed content doesn’t need to be reloaded again, rather it’s quickly loaded from the cache.

When visitors return to a Drupal 8 website, they won’t have to wait for previously viewed content to load up. Updated or new content is presented to visitors while the cache of older unchanged content remains preserved and shown immediately.

Content Visualization For Multiple Devices: See content when editing, as it’ll look when published with a real-time what you see is what you get (WYSIWYG) editor for desktop and mobile devices. Via the WYSIWYG editor, users have the option to choose images and revise content for desktop or mobile versions as needed. By seeing what end users experience—in real time—is a valuable feature for saving time and foreknowing the outcome before publishing.

General Content Management: Drupal 8 offers a simple and flexible CMS. With previous Drupal versions have been seen as too challenging for new users. Drupal 8 changed all that. Now content authoring is easy and reliable performance is guaranteed. Content managers can navigate their site smoothly and use the new on-page editor quickly and with ease.

With mobile, global content taking the center stage on every stage, if you migrate to Drupal 8 your organization can get it right. It’s time to leave the disappointing and the outdated behind so your organization can pursue something greater.

Want to migrate to Drupal 8? Let's talk. jQuery(document).ready(function() { var custom_cta_viewed = false; jQuery(document).scroll(function() { if ( typeof ga !== 'undefined' && typeof isScrolledIntoViewPort !== 'undefined' && jQuery.isFunction( isScrolledIntoViewPort) && isScrolledIntoViewPort('.custom-cta') && custom_cta_viewed == false ) { custom_cta_viewed = true; ga('send', 'event', 'cta', 'view', 'drupal-migration'); } }); });

This article was originally published in October, 2015. It has since been updated.

This article Migrate To Drupal 8 For Mobile First, Global Ready Features by Nathan Roach first appeared on Axelerant - Axelerant: Expert Drupal Development, Support, & Staffing.

Categories: Drupal

Daniel Pocock: Working to pass GSoC

8 June 2016 - 10:11am

GSoC students have officially been coding since 23 May (about 2.5 weeks) and are almost half-way to the mid-summer evaluation (20 - 27 June). Students who haven't completed some meaningful work before that deadline don't receive payment and in such a large program, there is no possibility to give students extensions or let them try and catch up later.

Every project and every student are different, some are still getting to know their environment while others have already done enough to pass the mid-summer evaluation.

I'd like to share a few tips to help students ensure they don't inadvertently fail the mid-summer evaluation

Kill electronic distractions

As a developer of real-time communications projects, many people will find it ironic or hypocritical that this is at the top of my list.

Switch off the mobile phone or put it in silent mode so it doesn't even vibrate. Research has suggested that physically turning it off and putting it out of sight has significant benefits. Disabling the voicemail service can be an effective way of making sure no time is lost listening to a bunch of messages later. Some people may grumble at first but if they respect you, they'll get into the habit of emailing you and waiting for you to respond when you are not working.

Get out a piece of paper and make a list of all the desktop notifications on your computer, whether they are from incoming emails, social media, automatic updates, security alerts or whatever else. Then figure out how to disable them all one-by-one.

Use email to schedule fixed times for meetings with mentors. Some teams/projects also have fixed daily or weekly times for IRC chat. For a development project like GSoC, it is not necessary or productive to be constantly on call for 3 straight months.

Commit every day

Habits are a powerful thing. Successful students have a habit of making at least one commit every day. The "C" in GSoC is for Code and commits are a good way to prove that coding is taking place.

GSoC is not a job, it is like a freelance project. There is no safety-net for students who get sick or have an accident and mentors are not bosses, each student is expected to be their own boss. Although Google has started recommending students work full time, 40 hours per week, it is unlikely any mentors have any way to validate these hours. Mentors can look for a commit log, however, and simply won't be able to pass a student if there isn't code.

There may be one day per week where a student writes a blog or investigates a particularly difficult bug and puts a detailed report in the bug tracker but by the time we reach the second or third week of GSoC, most students are making at least one commit in 3 days out of every 5.

Consider working away from home/family/friends

Can you work without anybody interrupting you for at least five or six hours every day?

Do you feel pressure to help with housework, cooking, siblings or other relatives? Even if there is no pressure to do these things, do you find yourself wandering away from the computer to deal with them anyway?

Do family, friends or housemates engage in social activities, games or other things in close proximity to where you work?

All these things can make a difference between passing and failing.

Maybe these things were tolerable during high school or university. GSoC, however, is a stepping stone into professional life and that means making a conscious decision to shut those things out and focus. Some students have the ability to manage these distractions well, but it is not for everybody. Think about how leading sports stars or musicians find a time and space to be "in the zone" when training or rehearsing, this is where great developers need to be too.

Some students find the right space in a public library or campus computer lab. Some students have been working in hacker spaces or at empty desks in local IT companies. These environments can also provide great networking opportunities.

Managing another summer job concurrently with GSoC

It is no secret that some GSoC students have another job as well. Sometimes the mentor is aware of it, sometimes it has not been disclosed.

The fact is, some students have passed GSoC while doing a summer job or internship concurrently but some have also failed badly in both GSoC and their summer job. Choosing one or the other is the best way to succeed, get the best results and maximize the quality of learning and community interaction. For students in this situation, now it is not too late to make the decision to withdraw from GSoC or the other job.

If doing a summer job concurrently with GSoC is unavoidable, the chance of success can be greatly increased by doing the GSoC work in the mornings, before starting the other job. Some students have found that they actually finish more quickly and produce better work when GSoC is constrained to a period of 4 or 5 hours each morning and their other job is only in the afternoon. On the other hand, if a student doesn't have the motivation or energy to get up and work on GSoC before the other job then this is a strong sign that it is better to withdraw from GSoC now.

Categories: Drupal

ImageX Media: Lions, Tigers, and Bears, Oh My!

8 June 2016 - 9:54am

DrupalCon brings together thousands of people from the Drupal community who use, design for, develop for, and support the platform. It is the heartbeat of the Drupal community, where advancements in the platform are announced, learnings from its users are shared, and where connections that strengthen the community are made. 

Categories: Drupal

DrupalCon News: Frontend fatigue? Share your story

8 June 2016 - 9:27am

Are you fatigued as a Frontender?  You are not alone. Frontend developers are moving in rapid waters all of the time. The explosion of frameworks and tools during the last 3 years was supposed to help us, but a feeling of overwhelmingness can hit easily.

The polyglot frontend-er

Our mother tongue is HTML, CSS, JavaScript, and add SVG to the mix. But to help us in our tasks, we've added Sass/Less, multiple templating languages, Markdown, JavaScript transpilers, testing languages, and what not.

Categories: Drupal

Lullabot: Adventures with eDrive: Accelerated SSD Encryption on Windows

8 June 2016 - 9:01am

As we enter the age of ISO 27001, data security becomes an increasingly important topic. Most of the time, we don’t think of website development as something that needs tight security on our local machines. Drupal websites tend to be public, have a small number of authenticated users, and, in the case of a data disclosure, sensitive data (like API and site keys) can be easily changed. However, think about all of the things you might have on a development computer. Email? Saved passwors that are obscured but not encrypted? Passwordless SSH keys? Login cookies? There are a ton of ways that a lost computer or disk drive can be used to compromise you and your clients.

If you’re a Mac user, FileVault 2 is enabled by default, so you’re likely already running with an encrypted hard drive. It’s easy to check and enable in System Preferences. Linux users usually have an encrypted disk option during install, as shown in the Ubuntu installer. Like both of these operating systems, Windows supports software-driven encryption with BitLocker.

I recently had to purchase a new SSD for my desktop computer, and I ended up with the Samsung 850 EVO. Most new Samsung drives support a new encryption technology called "eDrive".

But wait - don’t most SSDs already have encryption?

The answer is… complicated.

SSDs consist of individual cells, and each cell has a limited number of program/erase (PE) cycles. As cells reach their maximum number of PE cycles, they are replaced by spare cells. In a naive scenario, write activity can be concentrated on a small set of sectors on disk, which could lead to those extra cells being used up prematurely. Once all of the spare blocks are used, the drive is effectively dead (though you might be able to read data off of it). Drives can last longer if they spread writes across the entire disk automatically. You have data to save, that must be randomly distributed across a disk, and then read back together as needed. Another word for that? Encryption! As the poster on Stack Overflow says, it truly is a ridiculous and awesome hack to use encryption this way.

What most SSDs do is they have an encryption key which secures the data, but is in no way accessible to an end user. Some SSDs might let you access this through the ATA password, but there are concerns about that level of security. In general, if you have possession of the drive, you can read the data. The one feature you do get "for free" with this security model is secure erase. You don’t need to overwrite data on a drive anymore to erase it. Instead, simply tell the drive to regenerate its internal encryption key (via the ATA secure erase command), and BAM! the data is effectively gone.

All this means is that if you’re using any sort of software-driven encryption (like OS X’s FileVault, Windows BitLocker, or dm-crypt on Linux), you’re effectively encrypting data twice. It works, but it’s going to be slower than just using the AES chipset your drive is already using.

eDrive is a Microsoft standard based on TCG Opal and IEEE 1667 that gives operating systems access to manage the encryption key on an SSD. This gives you all of the speed benefits of disk-hosted encryption, with the security of software-driven encryption.

Using eDrive on a Windows desktop has a pretty strict set of requirements. Laptops are much more likely to support everything automatically. Unfortunately, this article isn’t going to end in success (which I’ll get to later), but it turns out that removing eDrive is much more complicated than you’d expect. Much of this is documented in parts on various forums, but I’m hoping to collect everything here into a single resource.

The Setup
  • An SSD supporting eDrive and "ready" for eDrive
  • Windows 10, or Windows 8 Professional
  • A UEFI 2.3.1 or higher motherboard, without any CSMs (Compatibility Support Modules) enabled, supporting EFI_STORAGE_SECURITY_COMMAND_PROTOCOL
  • A UEFI installation of Windows
  • (optionally) a TPM to store encryption keys
  • No additional disk drivers like Intel’s Rapid Storage Tools for software RAID support
  • An additional USB key to run secure erases, or an alternate boot disk
  • If you need to disable eDrive entirely, an alternate Windows boot disk or computer

I’m running Windows 10 Professional. While Windows 10 Home supports BitLocker, it forces encryption keys to be stored with your Microsoft account in the cloud. Honestly for most individuals I think that’s better than no encryption, but I’d rather have solid backup strategies than give others access to my encryption keys.

Determining motherboard compatibility can be very difficult. I have a Gigabyte GA-Z68A-D3-B3, which was upgraded to support UEFI with a firmware update. However, there was no way for me to determine what version of UEFI it used, or a way to determine if EFI_STORAGE_SECURITY_COMMAND_PROTOCOL was supported. The best I can suggest at this point is to try it with a bare Windows installation, and if BitLocker doesn’t detect eDrive support revert back to a standard configuration.

The Install

Samsung disk drives do not ship with eDrive enabled out of the box. That means you need to connect the drive and install Samsung’s Magician software to turn it on before you install Windows to the drive. You can do this from another Windows install, or install bare Windows on the drive knowing it will be erased. Install the Magician software, and set eDrive to "Ready to enable" under “Data Security”.

After eDrive is enabled, you must run a secure erase on the disk. Magician can create a USB or CD drive to boot with, or you can use any other computer. If you get warnings about the drive being "frozen", don’t ignore them! It’s OK to pull the power on the running drive. If you skip the secure erase step, eDrive will not be enabled properly.

Once the disk has been erased, remove the USB key and reboot with your Windows install disk. You must remove the second secure erase USB key, or Window’s boot loader will fail (#facepalm). Make sure that you boot with UEFI and not BIOS if your system supports both booting methods. Install Windows like normal. When you get to the drive step, it shouldn’t show any partitions. If it does, you know secure erase didn’t work.

After Windows is installed, install Magician again, and look at the security settings. It should show eDrive as "Enabled". If not, something went wrong and you should secure erase and reinstall again. However, it’s important to note that “Enabled” here does not mean secure. Anyone with physical access to your drive can still read data on it unless you turn on BitLocker in the next step.

Turning on BitLocker

Open up the BitLocker control panel. If you get an error about TPM not being available, you can enable encryption without a TPM by following this How-To Geek article. As an aside, I wonder if there are any motherboards without a TPM that have the proper UEFI support for hardware BitLocker. If not, the presence of a TPM (and SecureBoot) might be an easy way to check compatibility without multiple Windows installs.

Work your way through the BitLocker wizard. The make or break moment is after storing your recovery key. If you’re shown the following screen, you know that your computer isn’t able to support eDrive.

You can still go ahead with software encryption, but you will lose access to certain ATA features like secure erase unless you disable eDrive. If you don’t see this screen, go ahead and turn on BitLocker. It will be enabled instantly, since all it has to do is encrypt the eDrive key with your passphrase or USB key instead of rewriting all data on disk.

Turning off eDrive

Did you see that warning earlier about being unable to turn off eDrive? Samsung in particular hasn’t publically released a tool to disable eDrive. To disable eDrive, you need physical access to the drive so you can use the PSID printed on the label. You are supposed to use a manufacturer supplied tool and enter this number, and it will disable eDrive and erase any data. I can’t see any reason to limit access to these tools, given you need physical access to the disk. There’s also a Free Software implementation of these standards, so it’s not like the API is hidden. The Samsung PSID Revert tool is out there thanks to a Lenovo customer support leak (hah!), but I can’t link to it here. Samsung won’t provide the tool directly, and require drives to be RMA’ed instead.

For this, I’m going to use open-source Self Encrypting Drive tools. I had to manually download the 2010 and 2015 VC++ redistributables for it to work. You can actually run it from within a running system, which leads to hilarious Windows-crashing results.

C:\Users\andre\msed> msed --scan C:\Users\andre\msed> msed --yesIreallywanttoERASEALLmydatausingthePSID <YOURPSID> \\.\PhysicalDrive?

At this stage, your drive is in the "Ready" state and still has eDrive enabled. If you install Windows now, eDrive will be re-enabled automatically. Instead, use another Windows installation with Magician to disable eDrive. You can now install Windows as if you’ve never used eDrive in the first place.

Quick Benchmarks

After all this, I decided to run with software encryption anyways, just like I do on my MacBook with FileVault. On an i5-2500K, 8GB of RAM, with the aforementioned Samsung 850 EVO:

Before Turning On BitLocker After BitLocker After Enabling RAPID in Magician

RAPID is a Samsung provided disk filter that aggressively caches disk accesses to RAM, at the cost of increased risk of data loss during a crash or power failure.

As you can see, enabling RAPID (6+ GB a second!) more than makes up for the slight IO performance hit with BitLocker. There’s a possible CPU performance impact using BitLocker as well, but in practice with Intel’s AES crypto extensions I haven’t seen much of an impact on CPU use.

A common question about BitLocker performance is if there is any sort of impact on the TRIM command used to maintain SSD performance. Since BitLocker runs at the operating system level, as long as you are using NTFS TRIM commands are properly passed through to the drive.

In Closing

I think it’s fair to say that if you want robust and fast SSD encryption on Windows, it’s easiest to buy a system pre-built with support for it. In a build-your-own scenario, you still need at least two Windows installations to configure eDrive. Luckily Windows 10 installs are pretty quick (10-20 minutes on my machine), but it’s still more effort than it should be. It’s a shame MacBooks don’t have support for any of this yet. Linux support is functional for basic use, with a new release coming out as I write. Otherwise, falling back to software encryption like regular BitLocker or FileVault 2 is certainly the best solution today.

Header photo is a Ford Anglia Race Car, photographed by Kieran White

Categories: Drupal

Acquia Developer Center Blog: Drupal 8 Module of the Week: Workbench Moderation

8 June 2016 - 6:29am

Each day, between migrations and new projects, more and more features are becoming available for Drupal 8, the Drupal community’s latest major release. In this series, the Acquia Developer Center is profiling some prominent, useful, and interesting projects--modules, themes, distros, and more--available for Drupal 8. This week: Workbench Moderation.

Tags: acquia drupal planetworkbenchmoderationstate changeworkflow
Categories: Drupal

Cheppers blog: Exploring Behat Ep. 2: Behat Scenario Selectors

8 June 2016 - 1:57am

In our previous post on the topic, we used output formatters to determine how Behat displays test results. Now we continue with exploring our possibilities on what tests to run together with Behat’s scenario selectors.

Categories: Drupal

Virtuoso Performance: wordpress_migrate now has a Drupal 8 release

7 June 2016 - 9:04pm
wordpress_migrate now has a Drupal 8 release

So, last week the next arena for me to work on came up as XML/JSON source plugins (see my companion piece for more on that). My intention had been to hold off tackling wordpress_migrate until "nailing down" the XML parser plugin it depends on, but I decided that at least trying to prototype a WordPress migration would be a good test of the XML plugin. The initial attempt was promising enough that I kept going... and going - we've now got a (very) basic D8 dev release!

The UI

The user interface works generally as it did under Drupal 7 - upload the XML file on the first page of a wizard, configure taxonomies, then content, then review. It's important to note that this UI is for configuring the WordPress migration process - it creates the migrations, which you can then run using migrate_tools.

To begin, visit the migration dashboard at /admin/structure/migrate:

Clicking "Add import from WordPress" starts the wizard, where you can upload your XML file:

Clicking Next provides options for handling authors:

Next you can select which Drupal vocabularies (if any) to use for your WordPress tags and categories:

Then, choose the Drupal content types to use for WordPress posts and pages:

You may omit either one (actually, you could omit both if all you wanted to import were authors, tags and/or vocabularies!). Following that, for each content type you selected you can choose the Drupal text format to use for the body content:

In the review step, you can choose the machine name of the migration group containing your WordPress migrations, and also a prefix added to each generated migration's original machine name (if you were to import multiple WordPress blogs into your site, choosing distinct values here will keep them straight).

When you click Finish, you are brought to the migration dashboard for your new group:

Soon, you should be able to run your migration from this dashboard - for now, you'll need to use drush (which, really, you should use anyway for running migrations).

The drush command

Speaking of drush, you can configure your migrations through drush instead of stepping through the UI. Most of these options should be self-evident - do drush help wordpress-migrate-configure for more information.

drush wordpress-migrate-generate private://wordpress/nimportable.wordpress.2016-06-02.xml --group-id=test --prefix=my_ --tag-vocabulary=tags --category-vocabulary=wordpress_categories --page-type=page --page-text-format=restricted_html --post-type=article --post-text-format=full_html

Using drush for configuration has some advantages:

  1. If you're testing the import process, particularly tweaking the settings, it's much quicker to reissue the command line (possibly with minor edits) than to step through the UI.
  2. Scriptability!
  3. If your WordPress site is large, uploading the XML through the UI may run into file upload limits or timeout issues - alternatively, you can copy the XML file directly to your server and configure the migration to point to where you put it.
Ctools Wizard

This was my first time using the Ctools wizard API, and it's really easy to create step-by-step UIs - even dynamic ones (where not all the steps are determined up-front). Basically:

  1. Set up two routes in example.routing.yml, one for the landing page of your wizard, and one to reflect the specific steps (containing a {step} token).
  2. Create a class extending FormWizardBase.
  3. Implement getRouteName(), returning the step route from above.
  4. The key - implement getOperations() to tell the wizard what your steps are (and their form classes):

  public function getOperations($cached_values) {
    $steps = [
      'source_select' => [
        'form' => 'Drupal\wordpress_migrate_ui\Form\SourceSelectForm',
        'title' => $this->t('Data source'),
      ],
      'authors' => [
        'form' => 'Drupal\wordpress_migrate_ui\Form\AuthorForm',
        'title' => $this->t('Authors'),
      ],
      'vocabulary_select' => [
        'form' => 'Drupal\wordpress_migrate_ui\Form\VocabularySelectForm',
        'title' => $this->t('Vocabularies'),
      ],
      'content_select' => [
        'form' => 'Drupal\wordpress_migrate_ui\Form\ContentSelectForm',
        'title' => $this->t('Content'),
      ],
    ];
    // Dynamically add the content migration(s) that have been configured by
    // ContentSelectForm.
    if (!empty($cached_values['post']['type'])) {
      $steps += [
        'blog_post' => [
          'form' => 'Drupal\wordpress_migrate_ui\Form\ContentTypeForm',
          'title' => $this->t('Posts'),
          'values' => ['wordpress_content_type' => 'post'],
        ],
      ];
    }
    if (!empty($cached_values['page']['type'])) {
      $steps += [
        'page' => [
          'form' => 'Drupal\wordpress_migrate_ui\Form\ContentTypeForm',
          'title' => $this->t('Pages'),
          'values' => ['wordpress_content_type' => 'page'],
        ],
      ];
    }
    $steps += [
      'review' => [
        'form' => 'Drupal\wordpress_migrate_ui\Form\ReviewForm',
        'title' => $this->t('Review'),
        'values' => ['wordpress_content_type' => ''],
      ],
    ];
    return $steps;
  }

Particularly note how the content-type-specific steps are added based on configuration set in the content_select step, and how they use the same form class with an argument passed to reflect the different content types they're handling.

Your form classes should look pretty much like any other form classes, with one exception - you need to put the user's choices where the wizard can find them. For example, in the VocabularySelectForm class:

  public function submitForm(array &$form, FormStateInterface $form_state) {
    $cached_values = $form_state->getTemporaryValue('wizard');
    $cached_values['tag_vocabulary'] = $form_state->getValue('tag_vocabulary');
    $cached_values['category_vocabulary'] = $form_state->getValue('category_vocabulary');
    $form_state->setTemporaryValue('wizard', $cached_values);
  }

Next steps

Now, don't get too excited - wordpress_migrate is very basic at the moment, and doesn't yet support importing files or comments. I had a couple of people asking how they could help move this forward, which was difficult when there was nothing there yet - now that we have the foundation in place, it'll be much easier for people to pick off one little (or big;) bit to work on. Having spent more time than I intended on this last week, I need to catch up in other areas so won't be putting much more time into wordpress_migrate immediately, but I'm hoping I can come back to it in a couple of weeks to find a few community patches to review and commit.

mikeryan Tue, 06/07/2016 - 23:04 Tags
Categories: Drupal

Virtuoso Performance: Drupal 8 plugins for XML and JSON migrations

7 June 2016 - 9:03pm
Drupal 8 plugins for XML and JSON migrations

I put some work in last week on implementing wordpress_migrate for Drupal 8 (read more in the companion piece). So, this seems a good point to talk about the source plugin work that's based on, supporting XML and JSON sources in migrate_plus

History and status of the XML and JSON plugins

Last year Mike Baynton produced a basic D8 version of wordpress_migrate, accompanied by an XML source plugin. Meanwhile, Karen Stevenson implemented a JSON source plugin for Drupal 8. The two source plugins had distinct APIs, and differing configuration settings, but when you think about it they really only differ in the parsing of the data - they are both file-oriented (may be read via HTTP or from a local filesystem) unlike SQL, both require a means to specify how to select an item ("row") from within the data, and a means to specify how to select fields from within an item. I felt there should be some way to share at least a common interface between the two, if not much of the implementation.

So, in migrate_plus I have implemented an Url source plugin (please weigh in with suggestions for a better name!) which (ideally) separates the retrieval of the data (using a fetcher plugin) from parsing of the data (using a parser plugin). There are currently XML and JSON parser plugins (based on Mike Baynton's and Karen Stevenson's original work), along with an HTTP fetcher plugin. All of the former migrate_source_xml functionality is in migrate_plus now, so that module should be considered deprecated. Not everything from migrate_source_json is yet in migrate_plus - for example, the ability to specify HTTP headers for authentication, which in the new architecture should be part of the HTTP fetcher and thus available for both XML and JSON sources. Since no new work is going into migrate_source_json at this point, the best way forward for JSON migration support is to contribute to beefing up the migrate_plus version of this support.

Using the Url source plugin with the XML parser plugin

The migrate_example_advanced submodule of migrate_plus contains simple examples of both XML and JSON migrations from web services. Here, though, we'll look at at a more complex real-world example - migration from a WordPress XML export.

The outermost element of a WordPress export is <rss> - within that is a <channel> element, which contains all the exported content - authors, tags and categories, and content items (posts, pages, and attachments). Here's an example of how tags are represented:

<rss>
  <channel>
    ...
    <wp:tag>
      <wp:term_id>6859470</wp:term_id>
      <wp:tag_slug>a-new-tag</wp:tag_slug>
      <wp:tag_name><![CDATA[A New Tag]]></wp:tag_name>
    </wp:tag>
    <wp:tag>
      <wp:term_id>18</wp:term_id>
      <wp:tag_slug>music</wp:tag_slug>
      <wp:tag_name><![CDATA[Music]]></wp:tag_name>
    </wp:tag>
    ...
  </channel>
</rss>

The source plugin configuration to retrieve this data looks like the following (with comments added for annotation). The configuration for a JSON source would be nearly identical.

source:
  # Specifies the migrate_plus url source plugin.
  plugin: url
  # Specifies the http fetcher plugin. Note that the XML parser does not actually use this,
  # see below.
  data_fetcher_plugin: http
  # Specifies the xml parser plugin.
  data_parser_plugin: xml
  # One or more URLs from which to fetch the source data (only one for a WordPress export).
  # Note that in the actual wordpress_migrate module, this is not builtin to the wordpress_tags.yml
  # file, but rather saved to the migration_group containing the full set of WP migrations
  # from which it is merged into the source configuration.
  urls: private://wordpress/nimportable.wordpress.2016-06-03.xml
  # For XML, item_selector is the xpath used to select our source items (tags in this case).
  # For JSON, this would be an integer depth at which importable items are found.
  item_selector: /rss/channel/wp:tag
  # For each source field, we specify a selector (xpath relative to the item retrieved above),
  # the field name which will be used to access the field in the process configuration,
  # and a label to document the meaning of the field in front-ends. For JSON, the selector
  # will be simply the key for the value within the selected item.
  fields:
    -
      name: term_id
      label: WordPress term ID
      selector: wp:term_id
    -
      name: tag_slug
      label: Analogous to a machine name
      selector: wp:tag_slug
    -
      name: tag_name
      label: 'Human name of term'
      selector: wp:tag_name
  # Under ids, we specify which of the source fields retrieved above (tag_slug in this case)
  # represent our unique identifier for the item, and the schema type for that field. Note
  # that we use tag_slug here instead of term_id because posts reference terms using their
  # slugs.
  ids:
    tag_slug:
      type: string

Once you've fully specified the source in your .yml file (no PHP needed!), you simply map the retrieved source fields normally:

process:
  # In wordpress_migrate, the vid mapping is generated dynamically by the configuration process.
  vid:
    plugin: default_value
    default_value: tags
  # tag_name was populated via the source plugin configuration above from wp:tag_name.
  name: tag_name

Above we pointed out that the XML parser plugin does not actually use the fetcher plugin. In an ideal world, we would always separate fetching from parsing - however, in the real world, we're making use of existing APIs which do not support that separation. In this case, we are using PHP's XMLReader class in our parser - unlike other PHP XML APIs, this does not read and parse the entire XML source into memory, thus is essential for dealing with potentially very large XML files (I've seen WordPress exports upwards of 200MB). This class processes the source incrementally, and completely manages both fetching and parsing, so as consumers of that class we are unable to make that separation. There is an issue in the queue to add a separate XML parser that would use SimpleXML - this will be more flexible (providing the ability to use file-wide xpaths, rather than just item-specific ones), and also will permit separating the fetcher.  

Much more to do!

What we have in migrate_plus today is (almost) sufficient for WordPress imports, but there's still a ways to go. The way fetchers and parsers interact could use some thought; we need to move logically HTTP-specific stuff out of the general fetcher base class, etc. Your help would be much appreciated - particularly with JSON sources, since I don't have handy real-world test data for that case.

mikeryan Tue, 06/07/2016 - 23:03 Tags
Categories: Drupal

Gizra.com: Drupal 8: Migrate Nodes with Attachments Easily

7 June 2016 - 9:00pm

Drupal-8-manina is at its highest. Modules are being ported, blog posts are being written, and new sites are being coded, so we in Gizra decided to join the party.

We started with a simple site that will replace an existing static site. But we needed to migrate node attachments, and we just couldn’t find an existing solution. Well, it was time to reach out to the community

Any example of #Drupal 8 migration of files/ images out there? (including copy from source into public:// )

— Amitai Burstein (@amitaibu) April 8, 2016

A few minutes after the tweet was published, we received a great hint from the fine folks at Evoloving Web. They were already migrating files into Drupal 8 from Drupal 7, and were kind enough to blog post about it.

However, we were still missing another piece of the puzzle, as we also wanted to migrate files from an outside directory directly into Drupal. I gave my good friend @jsacksick a poke (it’s easy, as he sits right in front of me), and he gave me the answer on a silver platter.

Post has a happy end - we were able to migrate files and attach to a node!

Continue reading…

Categories: Drupal

DrupalEasy: DrupalEasy Podcast 178 - Rifftrax - Erik Peterson

7 June 2016 - 7:40pm

Direct .mp3 file download.

Rifftrax is the movie commentary web product from former members of Mystery Science Theatre 3000 (powered by Drupal). Erik Peterson (torgospizza) is the Lead web architect, art “director”, sometimes-writer (marketing and social media copy) for the site. Mike and Ryan interview Erik about the cultural phenomenon which is also a verb (to "MiSTy" a film is to watch it while riffing).

Interview

Erik is a Contributor to Drupal Commerce and Ubercart before it. He is also a Co-maintainer of Commerce Stripe and creator of Commerce Cart Link.

DrupalEasy News Three Stories Sponsors Picks of the Week Upcoming Events Follow us on Twitter Five Questions (answers only)
  1. Photography such as this Raven photo
  2. PHPStorm 10 (EAP)
  3. Giraffe @ SD Zoo
  4. Manage a team, teach for passion. Play music in my spare time. (What’s that?)
  5. Matt Glaman He’s well-versed in pretty much everything, and wrote a D8 cookbook.
Intro Music

MST3K Theme Song, California Lady (Gravy)

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Categories: Drupal

Pages