May 30 2018
May 30

The new GDPR laws are here, hurrah!

Having a number of developers handling databases from a number of client sites could easily be a nightmare, but we at ComputerMinds spent quite some time thinking about how to get and keep everybody safe and squeaky clean on the personal data front.

Here's a quick run-down of the key things to be aware of - and a pretty poster to help you keep it all in mind :)

Remove personal data from your system

  1. Review all databases on your computer, making sure to consider also those .sql dump files still sat in your downloads directory or your Recycle bin/trash.
  2. If there are databases that you need to keep on your system, then you must sanitize them by encrypting, anonymizing or removing personal data.
  3. Review all testing / UAT environments and ensure they're running off sanitized databases where possible.

Stay clean by using sanitized databases

Set up some _drush_sql_sync_sanitize() hooks to deal with personal data stored on your site. Then either have your Jenkins server use it to provide sanitized dumps, or ensure that your developers use it to sanitize databases immediately after importing.

When setting up your hook, make sure to consider things like:

  • User table - clear out email addresses, usernames etc.
  • Custom fields on users - names, telephone numbers etc. that you've added.
  • Webform / contact form submissions - make sure that your Webform / contact form data gets cleared out. Webform 7.12 and above has these hooks included, but it's good to double-check.
  • Commerce order table - you'll need to remove personal data from the commerce orders.
  • Commerce profile tables - make sure that the personal data in the profiles gets anonymized or removed.
  • Commerce payment gateway callback tables - these will have detailed payment transaction data, and absolutely must be cleared out.
  • URL aliases & redirects - by default Drupal sets up aliases for users' usernames, so you'll need to review those tables.
  • Comments - these usually have name, email and website fields that will need clearing out. But their body content may also have personal data in too, so you might be better off just binning the lot.
  • Watchdog / logging tables - these take up lots of space, so you probably don't want to export them off the live site anyway, but think seriously about the personal data inside if you do decide you want to import them elsewhere. Truncate recommended.
  • Cache tables - these can be huge, so you probably don't want to export them off the live site anyway, but think seriously about the personal data inside if you do decide you want to import them elsewhere. Truncate recommended.

This is certainly not a complete list, but we can't tell you what custom fun you've implemented on your site - so its' down to you to go check your tables!

Stay vigilant

  • Ensure future development environments and UAT/test environments are built using sanitized databases.
  • If you receive user data via email, immediately delete the email and attachments and reprimand the sender!
  • Talk to your clients about changes that need to be made to their sites.

The "GDPR and You" poster for developers, by ComputerMindsPDF download link below!

Jan 12 2016
Jan 12

The preview functionality in action - everything works nicely inside our iFrame.It's a well known fact that a large proportion of sites turn off the node preview button. It just doesn't work well. Your unsaved changes don't show and the admin theme is used in place of your site theme - not helpful.

The default Drupal node preview.

Workflows like that provided by Workbench Moderation give previews that work nicely, but that involves a lot of complexity with revisions and workflow. It really changes the way you (and your nodes, for that matter) work. For the sites out there that don't have something like Workbench Moderation in place, this usually means that there is no accurate preview functionality. End of.

So, when a couple of weeks ago the marketing team for Coventry Motofest asked if we could make the page preview work, we were surprised to find that we'd NOT turned off node preview for pages!

Rather than shy away, we took some time to see what we could do. What we've ended up with is a really neat working preview (complete with unsaved changes), that shows in the actual site theme (not the admin theme) and even can show at different (admin defined) viewport sizes. There are still some tweaks that could be made, but for a first go with *no additional custom code required* (just a cheeky patch - details coming) it's pretty darn good!

How it works

The mainstay of the functionality - the preview - is provided by [Page Preview]( It's a recent addition to the Drupal world and is still in Alpha, but a quick review of the code doesn't raise any alarms. It essentially provides an iFrame, which, complete with changes, shows the node perfectly in your site theme. Amazing.

One thing better than seeing your node, though, is seeing your node as it will be seen by your site visitors. With almost all sites now embracing mobile-first and responsive methodologies in their design practices, it would be really helpful to be able to preview the node at a variety of sizes. Cue Responsive Theme Preview!

Responsive Theme Preview is actually a D8 module with a D7 backport. With all its snazzy complexities we couldn't get its preview to work as we'd like. *However* we were able to take some of the best bits and integrate them with Page Preview. RTP has a nice little UI for creating, managing and selecting viewport sizes for use in the preview, and a neat set of buttons for choosing the viewport size whilst previewing. If you use the D8 Navbar you'll get an even nicer UI via the navbar. We made a patch for Page Preview which pulls these tools into place.

What you get is this - a beautiful node preview, complete with breakpoint buttons :)

Your turn - how to do it

So to summarise: Install pagepreview, with THIS PATCH. Install responsive_preview.  Done.

You can then customise the breakpoints via your new admin page at /admin/config/content/responsive-preview.

Oh, and you'll probably need to  turn preview back on  ;) We'd almost forgotten how - go to /admin/structure/types/manage/ and for each content type hit Edit > Submission form settings > Preview before submitting > Optional / Required. If you've disabled via custom code, then we'll leave that to you.


Looking forward, it would be really nice to also have a little grabber, so you can just take your mouse and manually resize the preview to any width you'd like. Then, you could see how your content shows at any width. Watch this space... or if you've a spare moment then beat us to it!The preview functionality in action - everything works nicely inside our iFrame.

Jun 02 2015
Jun 02

We've done a fair bit of reading around lately, thinking through different ideals on content construction. There's a fine balance to be struck between atomic units of content, vs. an enormous amorphous blob of formatted HTML, and articles like this by Wim Leers and sessions like this provide great food for thought.

ComputerMinds recently sponsored the site for Coventry Motofest, and I was lucky enough to be part of the team. We've done a few sites lately with our bespoke block-based system, but we wanted this site to be a bit simpler. Different content types would still be needed, as well as control for content sizing at different breakpoints, but we wanted more simplicity throughout - our block system can get a bit fiddly at times. We decided to take a foray with the Paragraphs module, and what an adventure it's been!

What's a Paragraph?

The Paragraphs module works on the principle of breaking content into different chunks, named paragraphs. Paragraphs don't have to be your conventional text paragraphs as you would normally know them, however - they can be text, images, slideshows, tabs… anything you want! This means that putting pages together is as simple as clicking the button for the new paragraph type you want, and then putting in your text / images / options.

Paragraphs are essentially field collections, which makes them a fairly familiar platform to work with. You create different Paragraph Bundles (types of paragraph), which can be individually templated, and add exactly the fields you need. Once you've added a Paragraphs field to your content type(s), you can then define which Paragraph Bundles can be used on that content type.

Paragraphs in action

We created paragraphs for media (text and images), maps, partner ads, views, social media, events and Webforms, and these power all the content on the site. Take a look at the site - each chunk of content is a paragraph.


I've highlighted some here - There are two media paragraphs (orange, blue), a paragraph that shows items from a view (red) and a MailChimp signup form paragraph.

Paragraphs go Mobile

You can't develop a site in 2015 and not think very carefully about how it works on mobile. Following our mobile-first strategy, we needed to be able to choose how wide the paragraphs were to be at different viewport breakpoints. We added a field on each paragraph bundle, which defines sizing instructions for the paragraph to be passed through the theme layer.

Our defaults provided full-width paragraphs at the 'mobile' breakpoint upwards - but more complex defaults are possible. With this field in action, we're able to define widths of 1/4, 1/3, 1/2, 2/3, 3/4 and full-width, enabling some really nice layouts.

It's even possible to target content at a particular breakpoint - over the MotoFest weekend, we were able to add content to the home page which targeted only mobile users. By adding a map to the home page, we made the site just a little bit quicker and easier for mobile viewers - just what you need during a city-wide event with 100,000 people in attendance!


Making the editorial role easier

One of our goals was to keep the editorial role as simple as possible - if somebody just wants to change some text, that should be really really easy. A great way to enable fast edits is to have an 'Edit' contextual link on each paragraph, which means you don't need to return to the rather large node edit form. Instead, you get an edit page just for that paragraph. James Williams made a patch which made this possible, and hopefully this'll make its way into a future module update.


Because they're rectangular and have grey in between, we've called our paragraphs Bricks

The ultimate standard in editorial ease would be same-page editing. We had a quick play with QuickEdit, but it only works with basic fields at the moment and it looks like a fair bit of work to make it play nicely with Paragraphs right now.

What we love about Paragraphs

Paragraphs makes content creation really nice. You can add lots of different chunks of content to a page, lay them out how you want to, reorder and reposition them, and easily update the template files to get everything exactly how you want to. Changing the look and feel of a page takes just a few quick changes.

This fits in nicely with this site's model, where different pages have radically different content, and the size of the site doesn't make it worth restricting control of layout and formatting. Our editors can make style and formatting choices, and that works well for this scenario.

We've enjoyed this first adventure with Paragraphs, and have had fun trying out different layouts and formats. Even better, it'll be easy enough to copy this functionality on future sites (we're already porting some of these elements to a number of our clients' sites, and they love it too) and continue developing it.


Nathan is a recent Masters of Computer Science graduate from the University of Warwick, and has lots of little chunks of experience in a variety of languages and arenas. He is currently the main developer for our automated testing ambitions.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web