Foggy Perspective

packagist.drupal-composer.org file could not be downloaded

caschbre — Fri, 22 Jan 2016 05:44:38 +0000

I'm excited to be starting a new Drupal 8 project. I get to try new and shiny things. Only this time I'm breaking things along the way as I figure out what some of our new processes will be with Drupal 8.

Part of what I've been looking into is how to go about providing local environments to team members, building out the code-base, etc. With Drupal 7 I was pretty comfortable using .make files, install profiles and distributions. I wanted to give Drupal Composer a try. There are several other articles that discuss Drupal Composer and more specifically Drupal Project (Composer template for Drupal projects). I'll leave it up to you to read through those other articles.

I wanted to keep this short and sweet and point out an issue I ran into and what the work-around is in case anyone else runs into similar issues.

While running "composer install" I started to get the following error.

[Composer\Downloader\TransportException]

The "https://packagist.drupal-composer.org/p/provider-archived%241a0102814c28..." file could not be downloaded (HTTP/1.1 404 Not Found)

A good couple of hours was spent trying to track down what I may have done to break the process. I went to https://packagist.drupal-composer.org and at first inspection the site looked up. Then I started browsing for packages and noticed that when trying to view a package the server was returning a 500 error. This was the likely culprit of the 404 issue I was receiving.

Now that I know it's most likely not an issue with my composer.json file, my next task was figuring out how to work-around packagist.drupal-composer.org being essentially offline. I needed to get some work done.

On the off chance that packagist.drupal-composer.org was just another domain for packagist.org, I modified my composer.json file changing:

"url": "https://packagist.drupal-composer.org"

to:

"url": "https://packagist.org"

Bingo!!!

While I can't use "sudo composer create-project drupal-composer/drupal-project:~8.0 drupal --stability dev --no-interaction" mentioned in the articles linked to above, I was able to simply download the project template and then run "composer install". All of the packages downloaded without issue and things are starting to get back on track.

Hopefully this is just a random server down issue but in case anyone else runs into the same issue, maybe this will be helpful.

Email fields missing feature? Email Confirmation!

caschbre — Thu, 14 Aug 2014 03:50:00 +0000

On previous Drupal projects I've had the requirement to provide some sort of confirmation email to email addresses entered into an Email (module) field. These were typically fields like "Work Email" or "Secondary Email". I had written a few small custom modules to handle these cases but found myself repeating the same thing. I knew that this could be useful as a contrib but never got around to it.

I recently had a requirement to confirm email changes to the user account email (e.g. $user->mail). I went to my goto module for this situation, the Email Confirm module. But this time I decided to dive deeper into what Email Confirm was actually doing... and it looked fairly straight forward. I was hoping that I could possibly extend this module to be used with an Email field, but that ended up not being the case.

So I decided to take the plunge and create the Email Field Confirm module. Boy was I in for a ride...

The Email Confirm module only works with the User entity which happens to have the $user->data property / db table. The module makes use of this to avoid any schema changes and retains the relationship of the new email address to the user account. I had started out down a similar path but came to realize this wasn't going to work for entities other than the User entity. Node entities do not have the data property and I couldn't rely on other entity types to have it. This is the point that I realized this was not going to be a simple module.

Time to really sit down and figure out what this module needed to do.

My goal was to allow for any new email address added to an Email Field to be (optionally) confirmed. A field can be reused on multiple entity types and bundles so I need to allow for configuration at the field instance along with storing any pending email address data down to the specific entity instance (e.g. entity_id). I also noticed that the Email Confirm module would stash the new email address away until it was confirmed so I added that to my list of desired features for Email Field Confirm.

Just tell me what it does already!

Features

At a high level, it met the goals I was after. A confirmation email will be sent to any new email addresses that have not already been confirmed by the same user elsewhere (e.g. another Email field) on the site. A field instance can optionally be configured to save the new email address with the entity or keep the original email address until the new one is confirmed.

This works on both single-value and multi-value Email fields, however there are some limitations with the multi-value field.

With multi-value fields it has proven more difficult to accurately identify what the original email value may be have been. I wasn't able to easily identify if the end user was changing an email address vs. just removing and adding another. It is also easy to re-order the values of a multi-value field so relying on the $delta wasn't helpful.

So with single-value fields we have the capability to retain the original email address until the new email address is confirmed. We also have the option to notify the original email address that a change has been made.

Some other notable features include:

Ability to resend a pending non-expired confirmation email.
Configure if the acting user (e.g. the user adding the email address) or the entity author/owner is responsible for confirming the email address.
Hooks for email confirmation and expiration. This module actually makes use of these to handle updating / revering single value email fields to the new or original value.
Rules integration -- with events similar to the aforementioned hooks.
Permission to bypass email confirmation. (typically for trusted roles.)
Permission to manually confirm any email address. (typically for administrative roles.)
Configurable confirmation and notification emails with token replacement.

Beta Release

There is currently a beta release available for download on the Email Field Confirm project page. It has been pretty stable so far. Besides having more sites use the module and report back and defects or feature requests, I hope to get some automated testing (most likely Behat) in place.

Automatically Change Database Based on the Git Branch

caschbre — Wed, 03 Jul 2013 21:04:48 +0000

While working on some larger enterprise Drupal projects we make extensive use of feature branches. Note: See A Successful Git branching model. When changing branches (e.g. git checkout) we've often run into issues where the code in that branch does not match up well with the database. This often happens if a branch includes a database update, new module, etc. and we aren't ready to merge that into the other feature branches.

We had several workarounds that weren't very efficient.

Manually create a new database per branch and update the settings file every time.
Create database dumps prior to switching branches and import a dump after switching.

Neither option was enjoyable and often led to mistakes so we came up with small solution inside the settings file.

Note: Recommendation is to first create environment specific settings files given that git may not be installed on every environment or we don't want to run the following bit of code.

At the bottom of our settings.[environment].php file we added the following code.

/**
* Acquire the current git branch and populate a variable to render on the
* site.
*/
$path_to_git_head = '/path/to/.git/HEAD';
if ($git_head = file($path_to_git_head, FILE_USE_INCLUDE_PATH)) {
$git_head = $git_head[0];
$git_head_exploded = explode("/", $git_head);
$git_branch = $git_head_exploded[2];
$conf['current_git_branch'] = $git_branch;
}
/**
* If we were able to determine the git branch, try to connect to a
* branch-specific database if possible.
*/
if (!empty($git_branch)) {
$git_branch_db = preg_replace('/[^a-zA-Z0-9_]/', '', $git_branch);
try {
$dbh_test = new PDO('mysql:host=localhost;dbname=' . $databases['default']['default']['database'] . "_$git_branch_db", $databases['default']['default']['username'], $databases['default']['default']['password']);
$databases['default']['default']['database'] .= "_$git_branch_db";
} catch (PDOException $ex) {}
}

What the above code does is attempt to acquire the current branch, and if so, then modify the default database settings established in the settings.[environment].php file.

To help make things more noticeable for the developer, we do render a few variables in our page.tpl.php file.

<?php if ($is_admin): ?>
<div id="environment" class="messages warning">
<strong><?php print variable_get('environment','Undefined'); ?></strong> Environment; <strong><?php print variable_get('current_git_branch','Undefined'); ?></strong> git branch; <strong><?php global $databases; print $databases['default']['default']['database']; ?></strong> database.
</div>
<?php endif; ?>

The above code lists the current environment, git branch, and database which are all set in our settings files.

Foggy Perspective Redesigned

caschbre — Wed, 03 Jul 2013 20:14:27 +0000

This website has finally received some much needed love. It's been over 2 1/2 years since this website was upgraded to Drupal 7. Other Drupal projects have kept me busy and I haven't time until recently to make some changes. I wanted to continue using Drupal as my blogging platform but needed to make it more maintainable. I still wanted to have fun trying out different modules / theming options but I'll try to keep those to a minimum so I don't find myself stuck in the same situation.

Omega8.cc Hosting

In preparation for some larger projects I wanted to give a different development process a run. So as part of the redesign I've moved this blog to Omega8.cc and try out the Aegir platform. It's definitely been a change and I'm still working out the kinks in my process. I'm learning quite a bit along the way. Omega8.cc is a great way to try out Aegir without having to manage the Aegir platform itself. The documentation is a bit scattered throughout various blog posts / articles on the Omega8.cc website but the staff has been pretty responsive to support requests.

Zen Theme

I had previously used the 7.x-2.2 version of the Corolla theme before it became an AdaptiveTheme sub-theme. I wanted to create my own simplified theme that had some responsive capabilities so I chose the widely used Zen theme. Other than learning how Zen Grids does its responsive magic, it's been a pretty easy change. Zen Grids really makes it easy to read / understand how the site will respond and it's constantly improving. Zen itself comes already setup to make the include regions responsive and I only made some very minor changes.

I love the minimalist approach (doesn't assume any design) that Zen takes and I've already started using it as a base theme for some enterprise Drupal projects.

Syntax Highlighting

I post sample code quite a bit and previously would just format it using the Courier New font. I hated that and finally installed the GeSHi Filter module. Hopefully that will make reading code quite a bit easier. I'm also planning to utilize the Gist Input Filter with code snippets I have on Gist. Now all I'm waiting for is Dropbucket to provide a way to embed snippets.

// If you haven't visited Dropbucket yet
// I would definitely check it out.

Disqus Comments

The previous site was using Drupal core comments. Spam was a plague that I got tired of managing and I didn't want to require folks to create their own account simply to comment. So all of the previous comments have been removed and the Disqus module enabled. Hopefully more folks will be inclined to comment given the widespread use of Disqus on other sites and the included ability to login to Disqus using a variety of social sites.

What's Left?

There's still quite a bit I'd like to get to on this site. How the site responds definitely needs some work based on the content / widgets that are used. I need to dive into the Picture + Breakpoints modules a bit more.

I'm also using the core homepage (/node) and Recent Posts block which I'd like to change out. I'm sure there are some theming tweaks I'll be making along the way as well.

Environment Specific settings.php Overrides

caschbre — Thu, 07 Feb 2013 17:04:18 +0000

Throughout a development life-cycle code may move between various environments (e.g. Development -> Integration -> Staging -> Production), however we may not want every environment to have the exact same setup. An example of this might be that on Staging and Production we have CSS / JS aggregation enabled along with caching. On a Development environment we may want both of those disabled. The database connection is also going to be different on each environment.

Some of these configuration settings like the database connection are stored in the sites / default / settings.php file. Aggregation and caching can be configured through the admin UI but they can also be setup in the settings.php file with the $conf variable. The following is a snippet from the settings.php file.

/**
* Database settings:
*/
$databases = array (
'default' =>
array (
    'default' =>
    array (
      'database' => 'local_drupal',
      'username' => 'local_drupal',
      'password' => 'local_drupal',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => false,
    ),
),
);

/**
* CSS/JS aggregated file gzip compression:
*/
$conf['css_gzip_compression'] = FALSE;
$conf['js_gzip_compression'] = FALSE;

gitignore

Each environment has a unique settings.php file to accommodate the different settings. If you use a version control system like git, the settings.php file is typically added to the .gitignore file. This works however you now lose any version control over your settings.php file(s). While not catastrophic, it can be painful if you've heavily modified the settings.php file.

settings.[environment].php

If you want to move your settings.php file(s) into version control we can create a standard settings.php file used across all environments and have that file conditionally include a uniquely named settings.[environment].php file. The trick is how you identify what environment code is being executed on.

We typically have subdomains setup for each environment. For production the URL would be mysite.com and staging it would be staging.mysite.com. We can add a small piece of code to the end of the settings.php file to make this check and then look for a correlating settings.[environment].php file.

Here's the snippet of code that we added to the end of settings.php.

/**
* Override default settings.php with settings.[environment].php.
*
* Get the http host and then start removing pieces to eventually end up with
* an environment identifier. The default environment is 'production'.
*
* Examples:
*   mysite.com = production
*   www.mysite.com = production
*   stage.mysite.com = stage
*   local.mysite.com = local
*   local.mysite = local
*/
$host = $_SERVER['HTTP_HOST'];

$subdomain = str_replace('mysite.com', '', $host);
$subdomain = str_replace('mysite', '', $subdomain);
$subdomain = str_replace('www.', '', $subdomain);

$subfile = (strlen($subdomain) >= 1) ? $subdomain : 'production';
$subfile = trim($subfile, '.');

// Prefix configuration variables with 'pre_' to avoid any clashes.
$conf['pre_environment'] = ucfirst($subfile);
$conf['pre_settings_file'] = '/settings.' . $subfile . '.php';

// Check if the file exists prior to including it.
if (file_exists(dirname(__FILE__) . $conf['pre_settings_file'])) {
include dirname(__FILE__) . $conf['pre_settings_file'];
}

What we're doing here is grabbing the HTTP_HOST and selectively removing parts of it. The remaining piece is then used as the [environment] component of the settings.[enviromment].php file. For example, staging.mysite.com would check to see if settings.staging.php exists, and if so, include it.

We can now include the various settings file(s) in our git repository. One caveat is that each developer would have their own unique settings.local.php file and we don't want those to overwrite each other. So we did add settings.local.php to the .gitignore file and created a sample.settings.local.php file that we add to the repository.

Here's a sample of settings.local.php.

There are definitely other ways to tackle this and hopefully the code samples give you ideas on making your setup more efficient. Good luck!

Positioning the User's Profile Picture on the Manage Display Screen

caschbre — Wed, 21 Nov 2012 18:43:58 +0000

It's been a while since I've had time to share my Drupal experiences with the community. New additions to the family, moving, and a large / length Drupal project have taken up my time. Hopefully things are easing up a bit and I'll be back to sharing.

Have you ever noticed that not all elements rendered on the user account page are visible on the user account -> manage display configuration page?

The project I'm currently working on utilizes panels and in more than one situation we want the ability to insert the user entity as a pane. When we insert the user entity we want to be able to choose a specific view mode that's configured with the fields we want displayed. Let me walk through this in more detail.

Our user account contains the following fields:

First Name
Last Name
Address
Telephone
etc...

When viewing a user's account page, if / how the fields are displayed are controlled through the Administration » Configuration » People » Account settings » Manage Display tab. We can re-order the fields, hide the fields, etc. One user account element that is missing is the User's profile picture.

Note: the screenshot was taken before the additional user account fields were added.

Let's say that you want to hide the profile picture on the user account page or provide new view modes that display / hide the profile picture. Here's how we can easily go about doing that.

Extra Fields: User Picture

I'm assuming that you're familiar with creating a custom module.

In our EXAMPLE.module file we're going to add a single call to hook_field_extra_fields() as follows.

/**
* Implements hook_field_extra_fields()
*/
function EXAMPLE_field_extra_fields() {
$extra = array();
$extra['user']['user'] = array(
'display' => array(
'user_picture' => array(
'label' => t('User Picture from Core'),
'weight' => -5,
'description' => t('This can be anything. I have not seen where this is rendered.'),
),
),
);
return $extra;
}

Ok, so what did we do there?

hook_field_extra_fields() let's us add pseudo-fields to the entity. We could have provided a form option as well, but in this situation we're only concerned with the display of an existing element.
$extra['user']['user'] is the User bundle of the User entity, both provided by Drupal core.
'display' says that we're dealing with the display (manage display).
'user_picture' is the identifier for the actual User Picture uploaded on the user account page
'label' is the text that is shown on the Manage Display tab. Depending on how the element is themed, it's possible this would show up on the rendered user account page
'weight' is the default / initial weight of the element compared to the other elements. This value will change as you re-order elements on the manage display screen.

Save the module, clear your caches, and refresh your manage display configuration screen and you should see "User Picture from Core" as an element you can re-order.

You can also hide the picture from rendering on the user account page. While that's probably not something most will do, let's see how this might be useful with other view modes.

View Mode: Author Bio

If you're not familiar with view modes, you probably just aren't recognizing the term. If you look at a node's manage display screen you'll notice 'Default' and 'Teaser'.

Here are some other blog posts that describe view modes.

The user account only comes with one view mode by default. Back to my original situation, I will be inserting the user entity as a pane in a panel but I don't want to display all of the fields that typically render on the user account page. So what we're going to do is create a new view mode for the user entity.

Back to our EXAMPLE.module we're going to add a single function hook_entity_info_alter().

/**
* Implements hook_entity_info_alter()
*/
function EXAMPLE_entity_info_alter(&$entity_info) {
$entity_info['user']['view_modes'] += array(
'author_bio' => array(
'label' => t('Author Bio'),
'custom settings' => TRUE,
),
);
}

Ok, let's look at what's going on.

$entity_info is passed in by reference so we're directly altering this variable.
$entity_info['user']['view_modes'] += is adding to the existing view modes for the user entity.
'author_bio' is the machine name for the new view mode.
'label' is the text displayed on the Manage Display screen for the new view mode.
'custom settings' is the default setting to say whether we want to configure the fields differently from the default view mode. This value can be changed on a per-bundle bases.

Save the module, clear your caches, and refresh the manage display page and you should see a new View Mode. It will most likely have all of the fields setup the same as the default view mode.

I'm now able to display the user profile picture and first / last name fields. When I insert the user entity as a pane and choose the 'Author Bio' view mode, it will render only those fields in the order I've set them. I can now use CSS to position them accordingly.

Fun at DrupalCamp Asheville

caschbre — Thu, 18 Aug 2011 21:42:28 +0000

This past weekend I had the pleasure of attending DrupalCamp Asheville. It was a great time to see some old faces and meet some new ones. For me these events are less about the sessions and more about the other Drupaleers I get to meet in person.

Addison Berry opened up the day as the keynote speaker. She touched on some of the very reasons why I use Drupal and attend these events... the Community. With the number of folks new to Drupal that attended this camp, her message was right on point. I hope it rung a tone with them.

My favorite session of the day was Building a responsive theme in Drupal with Omega and Drush presented by JP of Redfin Solutions. Not only was the topic of interest, but JP has a great presentation style. I'd highly recommend attending any session he's putting on. After attending this session and watching the Omega theme progress, I'm going to have to switch this blog over to that theme. I figure I gotta provide my ten viewers the ability to view my blog on their mobile device. :-)

During each session there were free books to be handed out. There weren't enough for every attendee so JP had a little humming contest. One participant had to hum the tune of a song while the other participant had to guess the title of the song. I wasn't quick enough to catch the whole contest, but I was able to capture part of it on my phone. Unfortunately the microphone on the phone couldn't pick up the humming loud enough over the laughter of the group. Below is a minute long video of the contest on youtube.

Overall the event was great, especially given it was only the second year for Asheville. I think there is / was a survey coming out I need to complete. But for those putting together other events, here is one comment that hopefully will be useful.

Explain what a BoF is. I remember my first camp and I had no clue. Use the opening session to let folks know what they are and where the sign-up sheets are.

Can't wait until DrupalCamp Atlanta!!!

Theming Custom Entities

caschbre — Thu, 04 Aug 2011 16:59:10 +0000

Entities are a new and exciting concept in Drupal 7 and a few modules are starting to make use of them. A co-worker (Scott) of mine has recently jumped on the Drupal bandwagon. He's been reading up on the Drupal development books and creating custom modules. A new module that he was working on created a new entity type. Great! Not a problem, the Drupal books and online docs provided pretty detailed steps. We ran into a wall however when we attempted to theme it. The documentation was lacking at this point and looking over contrib modules that created entities didn't provide any entity theming examples.

Scott started digging through the code and eventually figured out how to accomplish custom entity theming. Even better, he contributed his findings to the Drupal online documentation. Win Win!

You can learn more about the solution he found on his blog post. Just don't give him too hard of a time about his blog running on Wordpress. :-)

Note: I closed comments on my blog post here... head on over to Scott's to leave any feedback.

Get a jumpstart on #drupal development with #quickstart

caschbre — Fri, 20 May 2011 14:25:03 +0000

I work quite often with Drupal doing various tasks like setting up temporary sites to test out new modules, develop custom modules, and demo Drupal's capabilities to clients and co-workers. For years I've done this on Windows-based machines. I've found over time that I spend quite a bit of time doing tasks that I have very little interest in, just to get to a point where I can enjoy working with Drupal. Some of these tasks include:

Creating databases
Setting up database users
Configuring DNS / host files
Configuring virtual hosts
Manually downloading drupal core, modules, themes
Running the drupal install (yes I like to start with fresh installs for some things)

Windows isn't the easiest to develop on when working with Drupal. I want to mimic the *AMP stack as close as possible and stay clear of IIS. I tried several options to reduce those tasks.

I've tried both WampServer (WAMP) and XAMPP. While both allow me to use apache, mysql, and php, they still leave most of the minutiae (I always wanted to use that word) left up to me to deal with.

I also gave the Acquia stack (Dev Desktop) a run for a short while. Dev Desktop handled most of the apache / mysql setup and actually did a great job of importing existing sites to test upgrades, patches, new modules, etc. I was still left manually handling dealing with modules and themes, but I could live with this. It got me closer to getting into the weeds of what I enjoyed. Where the Dev Desktop eventually failed me however was during development. I use Komodo IDE 6 for development and debugging and I prefer to have code intelligence (i.e. autocomplete) for PHP and Drupal functions. I've been unable to get Komodo (or Eclipse) to recognize the existence of PHP from the Acquia Stack.

So I made the trip back to WAMP / XAMPP and figured I would see if I can add Drush into the mix to try and alleviate some of the mundane tasks. Unfortunately Drush on Windows still has quite a few issues and isn't the most reliable. At times it ended up causing more issues and I had to spend time correcting them or starting over.

I was contemplating dual booting Ubuntu but quickly turned that idea out. I didn't want to deal with rebooting each time to switch environments and didn't need to put my wife through figuring out what to do if I left Ubuntu left open.

Luckily I came across a recent project a few months ago that changed everything.

Quickstart

From the project page: "A pre-packaged downloadable PHP Development Environment for Drupal"
The Youtube Channel provides a video demo of Quickstart's capabilities.
Author: Michael Cole
Drupal Group: Quickstart Drupal Development Environment

What's included:

Support for Drupal 7 and Drupal 6
Ubuntu Linux, Apache, MySQL, APC, XDebug, IMAP, UploadProgress
Firefox (with developer plugins) and Chrome
Drush, drush make, and custom drush commands
Install scripts for: Apache Solr, Aegir, Hudson, and Oracle
Netbeans and Eclipse, configured with XDebug
XHProf and Webgrind profilers. Emails logged as files
cvs, subversion, git, bazaar

At a high level, Quickstart provides a Virtualbox (Ubuntu 10.04 guest) appliance of a Drupal development machine with some additional Drush scripts. This has drastically decreased my setup / configuration time spent with Drupal. The Virtualbox installation was a breeze. There were a few steps to make sure Ubuntu and Drush were the latest but then I was quickly on to Drupal fun time!

Quickstart Drush Scripts

Where I think Quickstart excels is with the additional Drush scripts it provides. Taking a look at one of the Quickstart documentation pages we can see an example of one of these scripts.

$ drush quickstart-create all --domain=example1.dev

This command will download the latest core, create the database and db user, configure apache / virtual hosts, DNS, and run the Drupal install with the default profile. Boom! I can now open up my browser to example1.dev and start working with Drupal. When I'm done with this particular temporary solution, we simply use the quickstart-delete Drush command to remove all traces.

We can also create different make files and utilize those with the quickstart-create command. Simply add the --makefile=mymakefile.make parameter.

One thing to note is that the quickstart-create will create a new instance of Drupal in it's own folder, database, etc. Where Quickstart isn't quite up to speed yet is handling multi-site "quick" installs. From the looks of it however, it appears that this is an upcoming feature.

Similar Projects

Drubuntu (see partial feature comparison)
Note: I have not used Drubuntu yet. Quickstart has met my needs and I haven't had the time yet to give Drubuntu a shot.

Comment notification enabled

caschbre — Tue, 11 Jan 2011 17:13:33 +0000

With the recent transition for foggy perspective from posterous to drupal 7 one of the features I lost was the ability for readers to subscribe to comments. The comment notify module has recently released a D7 version so I've installed and enabled that.

Now all I need are readers and commenters. :-)