Category Archives: Drupal

A screen capture of the WWU WebTech BLog

A blog to follow

Hi all,

My colleagues and I have begun a blog about our day-to-day web work with Drupal, HTML/CSS/JS, git, SASS, and content wrangling. I will be writing on that blog as well. Here is my first post.

Currently this is a trial to make sure we can follow through with quality content. Please leave comments and if there is anything you want specific coverage on let us know at the WWU WebTech Blog or here.

In addition, in a continual effort to work towards embracing Responsive Web Design (RWD) I composed this post on a large flat screen TV. My neck is a little sore as it is a bit like sitting in the front row of a movie theater. Perhaps I need to get a Chromecast.


A water bottle sitting on top of a red bag.

PNWDS 2013 – Vancouver

The 2013 Drupal Summit was a great event. This was my third such summit and it was another solid Drupal event. I wanted to list the key ideas I took away from the conference as well as some modules and software that I am unfamiliar with but heard about over the two days.

Key Ideas

  1. Testing is becoming a major part of the Drupal development process.
    • This is awesome! There were fantastic sessions on PHPUnit and several on Behat. It is certainly a positive direction. There is no requirement to write tests but there is tremendous upside if you are creating reusable components, building from an install profile, or have mission critical components. Testing has been around for a long time with SimpleTest and other methodologies. However, there seemed to be a big focus on it at the summit.
    • PHP Unit Testing,Behat & Drupal
  2. Treat your site, service, component, etc… as a product.
    • I really enjoyed this concept. It appeared in several sessions as an underlying theme. The main concept is that whatever you are building, try hard to make it as if it was a standalone product. It should obviously work well, but how is the UI, is there documentation, tests, versions, etc… If we try for the above with each project or anything we are developing the finished piece should be better overall.
    • Enterprise Drupal, Delivering Amazing Support, Reusable Components

Modules and other software

ckeditor 4.1 & 4.2 sets inline styles for image width and height – One fix

ckeditor in their migration to the ACF system in 4.1 has forced by default image width and height into the images as inline styles.

Simply turning off ACF does not solve the problem. The ACF configuration can be set to send width and height to HTML attributes if you use ACF. The issue though is that they do not provide a “whitelist” of all the plugins. Without such a thing certain ckeditor toolbars will not appear, even when enabled in the editor configuration screen. Those issues are covered in the existing ACF issue and the media markup being converted to false issue.

After trying several solutions all to no avail I have resorted to using jQuery to resolve this dilemma.

Drupal.behaviors.imgAttributes = {
 attach: function () {
//First check to see if an image is on the page, if not, do nothing
 if ( $( 'img').length > 0 ) {
 //Loop through each image found and retrieve the width and height.
 //Then remove the width and height from the inline css.
 //Finally write the width and height as attributes to the html img tag.
   var imgWidth = $(this).css( "width");
   var removeWidth = $(this).css( "width", "" );
   var imgHeight = $(this).css( "height" );
   var removeHeight = $(this).css( "height", "");
 $(this).attr("height", imgHeight);
 //The figure wraps our images and if a height is set, it will not wrap
 //around the text, only the image. This is basically height:auto.
   var removeFigureHeight = $(this).css( "height", "");

Certainly this is not an elegant solution. However, modifying the ckeditor library itself seems risky for upgrade compatibility and ACF currently has no way to override the default “automatic” handling of ACF without declaring each and every component we use, which I tried, but couldn’t quite get to work in a satisfactory manner.

There is the following ckeditor bug ticket which has been again closed because ACF does allow you, as stated above, have image with and height be attributes not inline styles. However, getting ACF to work in Drupal with our myriad of other filters makes for a very challenging task.

While I do not feel this is a bug with WYSIWYG it is an annoyance for those using ckeditor and trying to create flexible images.


How-to: Use git to update Drupal when you can’t use Drush


You have code on a production server that does not allow Drush to be running and you do not enjoy the idea of copying over live files. If these sites are already tracking a git repository that is great, simply do a push and pull and you are done. It gets more complicated though if the repositories are woefully out of sync or if they have never had a git repository configured.

Proposed Solution:

The solution I devised allows you to update the site locally, make a nice commit, and then fetch it on the remote server and reset the filesystem to the fetch that was just made. Here are the steps:

  1. Create a git repository within your development site (skip this step if you already have git enabled).
    $git init
  2. Use Drush on your development site to update Drupal core.
    $drush pm-update drupal
  3. Test your site and then add and commit the files you have just updated.
    $git add -u
    $git commit -m"Upgrade to Drupal version x.yz"
  4. Create a remote repository if you do not have one already configured. Once that is created link your development repository to the remote and push your updates.
    $git remote add origin RemoteRepositoryURL
    $git push origin master
  5. Now, go over to your production site and create a git repository like in step 1 above. Next, you will add the remote, fetch the update from that remote, and then reset your file tree to what you just pulled with the following commands.
    $git init
    $git remote add origin RemoteRepositoryURL
    $git fetch --all
    $git reset --hard origin/master
  6. That last command will rebuild the file system based on repository and from now on you can do normal push and pulls. Make sure to run update.php to get your database in sync with the new Drupal release.


I know the above is quite unorthodox. You also need to be careful as it will only rebuild the files you are tracking. I do not normally advocate for tracking entire Drupal installs but if you are in a situation as detailed above, it may be one of the few ways to have a sane update mechanism. For working with remotes I find the git-scm reference pages very handy.