Importing a price in Drupal 8 for Drupal Commerce 2.x

Posted on: 2016-04-20 14:21:04

Just a quick note that if you're importing a Commerce price:

  • you must set the currency_code.

  • what was commerce_price in DC 1.x / Drupal 7 is now just price.

  • the number can be a decimal now.

    'price/number': SomeFieldName 'price/currency_code': plugin: default_value default_value: 'USD'

Note that you can also set up a constant in the migration definition and use the constant value:

  plugin: d6_ubercart_product_variation
    currency: USD
  'price/number': SomeFieldName
  'price/currency_code': 'constants/currency'

It is worth mentioning that this fails silently right now. That is, if you don't provide the currency code, the migration will continue but you just won't have a value.

Update 2017-11-20: Vimokkhadipa told me that price/amount in the example above should actually be price/number. Since I haven't done any migration work in a while I'm taking his word for it and noting the update. Thanks Vimokkhadipa!

Continue reading...

You can chain callbacks in a Drupal 8 migration

Posted on: 2016-04-20 09:08:53

If you're wanting to do some advanced processing (e.g. lowercasing a word and then capitalizing the first letter) you can chain the two callbacks to get the desired effect:

      plugin: callback
      source: MyVar
        - '\\Drupal\\Component\\Utility\\Unicode'
        - 'strtolower'
      plugin: callback
        - '\\Drupal\\Component\\Utility\\Unicode'
        - 'ucfirst'

The two transformations will take place one after the other. The first one will execute and pass in the value straight from the source (e.g. 'SOMEVAR'). The next one will get the result (e.g. 'somevar') and then the the final value will be ('Somevar').

Continue reading...

Quickly importing new config entities from the command line using Drush

Posted on: 2016-04-18 13:58:03

Drush's cset command is a bit picky, but with a few command line options, we can get it to import a yaml file into our site's config:

drush -y --format=yaml cset config.entity.string '' - < config_file.yml

This will put the entirety of config_file.yml into the configuration entity config.entity.string.

The -y is required because drush will ask you if you want add a new entity (and of course you do!). The "trick" if it even is that, is the '' before the - to read from STDIN.

Continue reading...

Field Tools as a replacement for Features

Posted on: 2016-04-04 12:28:56

One of my new favorite modules recently has been Field Tools. What I love about it is that it presents you with the ability to export all of the fields on a particular bundle (or even just a single field).

Then, you can just use field_create_field or field_create_instance in a little loop.

Take for example (in a module's .install file):

<code lang="php"> function mymodule_install() { $fields = mymodule_get_some_fields();

foreach ($fields as $name => $field) { field_create_field($field['field']); field_create_instance($field['instance']); } }

Then, inside of mymodule_get_some_fields() you just put the output of Field Tool's export:

function mymodule_get_some_fields() {
  $fields = array();
  // Start export.
  $fields['field_name'] = array(
    'field' => array(...),
    'instance' => array(...),
  $fields['another_field_name'] = array(
    'field' => array(...),
    'instance' => array(...),
  // End export.
  return $fields;

See, the magic is that the $fields export includes two sub-arrays: 'field' and 'instance'. That's what then powers the ability to just run it through the foreach above and it create your bases and your instances.

A couple of caveats:

  • You should probably check to see if the field exists before creating it. Otherwise, it'll throw an Exception.
  • It dumps everything in the exports, and so you might need to clean them up a bit by checking to ensure that you're not adding them to extra bundles or something like that.

But for most cases, this is way simpler than using Features and having to bring it in as a dependency.

Continue reading...

A quick note about Drupal Commerce price updaters that use Feeds and Feeds Validation

Posted on: 2016-03-31 14:25:21

Perhaps this may save someone else some time:

If you're wanting to do price updating in Drupal Commerce using Feeds, you'll normally use a field that is guaranteed unique. The Product ID and Product SKU fields (provided by the Commerce Feeds module) give this to you out of the box, but if you're wanting to give a user the ability to match by something else: say, a catalog number or some vendor part number that is an actual field on the product entity itself, you might have already looked at Field Validation to do this.

The general idea goes like this:

  1. Set up field validation so that the field you're wanting to use has the "Unique value" validator.
  2. Now, in Feeds, that field will show as being able to be used as a unique field.

This works for fields that are used on a single entity bundle, but not for fields that are used on multiple entities.

The problem arises when it tries to read the configuration for the bundles out of the field_validation_rule table. It might work if you have it defined for every instance of the field on every bundle, but I haven't tried that.

Make your life easier by just using Feeds Tamper String2ID, and creating a view that does a lookup from whatever field you're wanting to match with to the Product ID. Then, let Commerce Feeds' ProductProcessor do the rest.

Continue reading...

Modifying distribution Makefiles within your own project Makefile on

Posted on: 2016-02-24 09:48:42

As I've written about in the past,'s Makefile build system is pretty sweet. One of the things that confuse me the most, however, is how to make a change to a distribution (such as adding a patch) without making things even more complicated.

Hat tip to Tavi Toporjinschi for writing the original example this is based off of.

Let's say for a moment that you want to add a patch to a module included in a distribution. If you're just starting out, you could actually just override the module and add it to sites/default/modules by including it within your existing file like so:

projects[commerce_paypal][version] = \"2.3\"
projects[commerce_paypal][patch][2082691] = \"\"

However, if you're wanting to change a module that you've already been using, you'll want to modify the distribution directly from within your Makefile.

To do this, start by grabbing a copy of the distribution's git repository (and make sure you're working from the same version that you're using in your Makefile!). Here's instructions for Commerce Kickstart. Once you've done that, open up drupal-org.make which is the main Makefile for Commerce Kickstart.

In this particular instance, what I'd like to do is use the -rc4 version of Commerce Message. So I'll go ahead and make that change by finding the line that says:

projects[commerce_message][version] = 1.0-rc3

It will now read:

projects[commerce_message][version] = 1.0-rc4

Now that I've got my change and I've tested it (which I'm skipping for now), it's time to add it back into my project. To do this, we'll grab a diff of the change:

commerce_kickstart$ git diff > commerce_message_to_rc4.patch

The file commerce_message_to_rc4.patch will look something like this:

diff --git a/drupal-org.make b/drupal-org.make
index 45fef75..b497a53 100644
--- a/drupal-org.make
+++ b/drupal-org.make
@@ -48,7 +48,7 @@ projects[commerce_moneybookers][patch][] = \"
 projects[commerce_paypal][version] = 2.3
 projects[commerce_paypal][patch][2458721] = \"\"
 projects[commerce_backoffice][version] = 1.5
-projects[commerce_message][version] = 1.0-rc3
+projects[commerce_message][version] = 1.0-rc4
 projects[commerce_search_api][version] = 1.4
 projects[commerce_add_to_cart_confirmation][version] = 1.0-rc2
 projects[commerce_kiala][version] = 1.0-rc1

To add this to my project, we'll create a patches/ directory within the project (if it doesn't already exist) and copy that patch into the directory.

commerce_kickstart$ mkdir ~/ commerce_kickstart$ cp commerce_message_to_rc4.patch ~/

Now, we just need to patch the distribution within the Makefile. How do we do that? With a patch, of course! You probably have a line like this in your makefile:

projects[commerce_kickstart][type] = core

This downloads the "core" version of Commerce Kickstart. This is the one that you get when you download directly from Commerce Kickstart's module page or when you download commerce_kickstart-7.x-2.33-core.tar.gz from the releases page.

This will then be replaced with the following:

projects[drupal][type] = core
projects[commerce_kickstart][type] = profile

; Use dev git version with patch.
projects[commerce_kickstart][download][type] = git
projects[commerce_kickstart][download][branch] = 7.x-2.x
projects[commerce_kickstart][patch][] = \"patches/commerce_message_to_rc4.patch\"

And... breaking it down:

projects[drupal][type] = core signals that we're using Drupal core as the base install. Then, we're installing commerce_kickstart as a profile on top of that (projects[commerce_kickstart][type] = profile). When installing the profile, we specify git as the download type and the branch (7.x-2.x) that we are working on so that we get the correct version of the code that we worked on up above (which include's its Makefile). Finally, projects[commerce_kickstart][patch][] = \"patches/commerce_message_to_rc4.patch\" patches the distribution so that it downloads the -rc4 version of Commerce Message.

Now, build the project, if everything is correct, as the build goes by, you'll see the correct module being downloaded:

 >> commerce_authnet-7.x-1.1 downloaded.                             [ok]
 >> commerce_message-7.x-1.0-rc4 downloaded.                         [ok]
 >> commerce_physical cloned from                                    [ok]

And there we go. Now, push it up to your repository, and you're all set!

Continue reading...

Acquia Dev Desktop and the Drupal 7 test runner

Posted on: 2015-11-15 14:01:47

Recently, I tried to run some tests locally and the test runner kept silently failing. Ultimately, it was just giving up during bootstrap. The problem was eventually traced to Acquia's frustrating modification of the settings.php file; it only loads when $_SERVER['DEVDESKTOP_DRUPAL_SETTINGS_DIR'] is defined.

So in order to make it run, you'll need to:

  1. Define DEVDESKTOP_DRUPAL_SETTINGS_DIR in your CLI environment or:
  2. Modify to populate that value in $_SERVER before bootstrapping Drupal:
$_SERVER['HTTP_USER_AGENT'] = 'Drupal command line'; $_SERVER['DEVDESKTOP_DRUPAL_SETTINGS_DIR'] = '/Users/myusername/.acquia/DevDesktop/DrupalSettings';

Then the test runner will actually do something useful.

Continue reading...

Technological pendulums

Posted on: 2015-11-09 06:53:47

I believe the future of technology is very much a return to simplicity that it seems like every generation or two we end up harkening back to. Modernity, for all of its marvels, feels like it is teetering on collapse. Personally, I see this in all over our society which can't seem to make up it's mind on what it wants. And if modern society could be defined by anything at this time, it'd be by a form of self-opposing delusion. People want security guaranteed by the government and also personal privacy. People want full personal autonomy to live their life as they see fit yet and yet feel obliged to force other's hands using the government when they find it hard to do so. We want the government to be a club for our cause yet so many forget the truth source and purpose of that government.

As it is with society, so also with technology with which society is so intertwined. We want blazing fast, ubiquitous, uninterrupted service but we want it delivered to us without any of the hard work which is required to build and maintain those services. And when a company like AT&T, Time Warner, or Grande Communications provides those services, someone will inevitably complain and emphatically declare what they want and why they are right and why they, the customer, is always right. I suppose we do truly live in an age of consumerism—where the customer is always right. And guess what? We are all customers now.

The pendulum has swung away from the BBSes of old: where groups of individuals combined their efforts to create autonomous, distributed, and personal networks of systems that were capable of transferring email across the world before the internet was in every home, so now it beckons to swing back the other direction. Yes, the pendulum is now seemingly at the very opposite of end of its swing. Where we are now is in an age of consumer demanded centralization: give me one store, one medium, one device that does everything. If it stops working or breaks, I'll throw it away and find another. And if I want it to continue to work, I'll pay exorbitant sums so that someone else can take care of it.

And what do we get for this? Little (if any) privacy. Being at the whim of masked men who wield digital armies and can take down your business for seemingly any reason.

Continue reading...

All code (and coding) is moral

Posted on: 2015-10-19 09:53:02

So I was reading through some blogs this weekend and came across an article about VW on the Clean Code blog. It's a short post and I suppose if you wanted a summary blurb, it would be this:

I think that argument is even more asinine than Michael Horn's. They knew. And if they didn't know, they should have known. They had a responsibility to know.

All too often, we tend to separate the code we write from what it does. In writing open-source Drupal modules, it might be very easy to try to say that there is a certain neutrality about what we do. Take for instance, one of my lowly modules Permission Report. All this module does it take existing information and display it to the user. It doesn't modify any values. And you could say that what it doesn't isn't good or bad—that it's morally neutral.

However, if something were wrong with my program, people would say something. If it were hiding certain roles or providing bad information, it could be an innocent mistake or it could be something malicious. But it would be flawed. The code itself would be bad. And we are no longer in neutral territory. If the code doesn't get changed, the code will be marked as such and it will eventually be replaced or forgotten by the community.

My point is, we don't do this for code that is "morally neutral." All code has some moral capacity in it. This parallels tangible objects such as cars, knives, and baseball bats which have a particular purpose but can be wielded in negligent or malicious ways. Likewise, open source code projects that have modules can be likewise wielded in ways that might align with or otherwise diverge from what we as individuals consider to be good, right, or true.

Now, for a module in a particular open source project that does a particular purpose: sending emails or handling a transaction, it could be used in a project that ultimately disagrees with our own worldview. However, the module itself with it's general quality, tests, and other functionality might be considered morally good, but the resulting use of it might be considered likewise to be morally wrong. But the point is that we didn't write the resulting use, we wrote the intended use and someone else wrote the final moral component. That doesn't change the fact that what we wrote was morally good, just that someone took something good and misused it. There is a difference between creating something good and having it's usage corrupted by circumstances and crafting the corrupting circumstances.

Circling back to the VW article, I'd like to make two points, then:

  1. As a programmer, we have a right—perhaps even a responsibility—to understand what the purpose is for what we are building. I think this is clear from what the author is saying. I would agree with this statement.
  2. Therefore, as a programmer, we have a right to decline work which we personally disagree with. While not stated explicitly, if the argument is that a programmer can and should be held responsible for code they wrote, then they should have the ability to decline to do so on the basis of legal or personal moral dissonance.

Programming, then, is a moral activity and should be treated as such by all who engage in it. Are we ready for this discussion?

Continue reading...

Recreate Drupal's users table from url_alias table

Posted on: 2015-08-19 22:36:38

So I needed to recreate a truncated users table to stop the Drupal admin from barfing all over the admin... the url_alias table has the UID and the user names in it... so why not?

INSERT INTO users SELECT REPLACE(source, 'user/', '') AS uid, REPLACE(alias, 'users/', '') AS name, SHA1('nothing') AS pass, CONCAT(REPLACE(alias, 'users/', ''), '@no.none') AS mail, '' AS theme, '' AS signature, 'filtered_html' AS signature_format, -- make sure this is okay 0 AS created, 0 AS access, 0 AS login, 1 AS status, NULL AS timezone, 'en' AS language, 0 AS picture, CONCAT(REPLACE(alias, 'users/', ''), '@no.none') AS initial_size, NULL AS data FROM url_alias WHERE source LIKE "user/%" -- Only grab users AND source != "user/1" -- But not user 1

I didn't need the emails to be anything useful.

Continue reading...