Feed aggregator

Code Karate: Drupal 7 Sweaver Module: Change your theme style with no CSS code

Planet Drupal - Thu, 11/12/2014 - 14:49
Episode Number: 185

The Drupal 7 Sweaver module makes it easy to change the style of your Drupal theme without having to write any CSS code or dig through any template files. The Sweaver module provides a simple to use designer toolbar that sits at the bottom of the page and allows you to instantly change the look of your Drupal theme.

Tags: DrupalDrupal 7Theme DevelopmentDrupal PlanetUI/DesignCSS
Categories: Elsewhere

Code Karate: Smart Paging: How to display a node on multiple pages

Planet Drupal - Thu, 11/12/2014 - 14:18
Episode Number: 184

The Smart Paging module is one of those "nice to have" modules. This module allows the ability to break content on a particular node into multiple pages. It is important to remember though that this doesn't mean you have to create multiple nodes or Drupal pages. This module works off of the same node. Neat!

Tags: DrupalContent TypesDrupal 7Site BuildingDrupal Planet
Categories: Elsewhere

Raphaël Hertzog: Freexian’s fourth report about Debian Long Term Support

Planet Debian - Thu, 11/12/2014 - 12:32

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In November 42.5 work hours have been equally split among 3 paid contributors. Their reports are available:

  • Thorsten Alteholz did his share as usual.
  • Raphaël Hertzog worked 18 hours (catching up the remaining 4 hours of October).
  • Holger Levsen did his share but did not manage to catch up with the backlog of the previous months. As such, those unused work hours have been redispatched among other contributors for the month of December.
New paid contributors

Last month we mentioned the possibility to recruit more paid contributors to better share the work load and this has already happened: Ben Hutchings and Mike Gabriel join the list of paid contributors.

Ben, as a kernel maintainer, will obviously take care of releasing Linux security updates. We are glad to have him on board because backporting kernel fixes really need some skills that nobody else had within the team of paid contributors.

Evolution of the situation

Compared to last month, the number of paid work hours has almost not increased (we are at 45.7 hours per month) but we are in the process of adding a few more sponsors: Roche Diagnostics International AG, Misal-System, Bitfolk LTD. And we are still in contact with a couple of other companies which have announced their willingness to contribute but which are waiting the new fiscal year.

But even with those new sponsors, we still have some way to go to reach our minimal goal of funding the equivalent of a half-time position. So consider asking your company representative to join this project!

In terms of security updates waiting to be handled, the situation looks better than last month: the dla-needed.txt file lists 27 packages awaiting an update (6 less than last month), the list of open vulnerabilities in Squeeze shows about 58 affected packages in total. Like last month, we’re a bit behind in terms of CVE triaging and there are still many packages using SSLv3 where we have no clear plan (in response to the POODLE issues).

The good side is that even though the kernel update spent a large chunk of time to Holger and Raphaël, we still managed to further reduce the backlog of security issues.

Thanks to our sponsors

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Categories: Elsewhere

Steve Kemp: An anniversary and a retirement

Planet Debian - Thu, 11/12/2014 - 11:56

On this day last year I we got married.

This morning my wife cooked me breakfast in bed for the second time in her life, the first being this time last year. In thanks I will cook a three course meal this evening.

 

In unrelated news the BlogSpam service will be retiring the XML/RPC API come 1st January 2015.

This means that any/all plugins which have not been updated to use the JSON API will start to fail.

Fingers crossed nobody will hate me too much..

Categories: Elsewhere

Dirk Eddelbuettel: digest 0.6.6 (and 0.6.5)

Planet Debian - Thu, 11/12/2014 - 02:27

A new release 0.6.6 of the digest package is now on CRAN and in Debian.

This release brings the xxHash non-cryptographic hash function by Yann Collet, thanks to several pull requests by Jim Hester. After the upload of version 0.6.5 we uncovered another lovely non-standardness of Windoze: you cannot format unsigned long long via printf() format strings. Great. Luckily Jim found a quick (and portable) fix via the inttypes.h header, and that went into the 0.6.6 release.

The release also contains an earlier extension for hmac() to also cover crc32 hashes, kindly provided by Suchen Jin.

I also made a number of small internal changes such as

  • switching (compiled) function registration to package load via a the useDynLib() declaration in NAMESPACE,
  • (finally!!) formating code to proper four-space indentation,
  • adding some documentation around Jim's pull request, and
  • adding a few GPL copyright headers.

CRANberries provides the usual summary of changes to the previous version.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: Elsewhere

Dirk Eddelbuettel: RcppRedis 0.1.3

Planet Debian - Thu, 11/12/2014 - 01:59

A very minor bugfix release of RcppRedis is now on CRAN. The zcount function now returns the correct type.

Changes in version 0.1.3 (2014-12-10)
  • Bug fix setting correct return type of zcount

Courtesy of CRANberries, there is also a diffstat report for the most recent release. More information is on the RcppRedis page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: Elsewhere

Metal Toad: Drupal 8 Migrations, part 4: Migrating Nodes from Drupal 7

Planet Drupal - Thu, 11/12/2014 - 01:51
Drupal 8 Migrations, part 4: Migrating Nodes from Drupal 7 December 10th, 2014 Keith Dechant

Drupal 8 provides a flexible, plugin-based architecture for migrating data into a site. In Part 3 of this series, we explored how to migrate taxonomies from a Drupal 7 site. We will now expand on this by migrating basic nodes from a Drupal 7 site into Drupal 8.

The code examples in this post build on the migration module begun in Part 2 of this series. If you are trying this code out yourself, it is recommended to start building your custom migration module according to the examples in that post.

The game plan for migrating nodes

Because Drupal nodes can be of many types and have many different user-defined fields, it is complicated to write a single migration script that can handle all fields for all node types. To keep things simple, we will only migrate the built-in "Article" content type, which has the same default fields in Drupal 7 and Drupal 8.

The eventual plan of the Migrate Drupal core module is to build a dynamic migration path that can migrate the fields for any content type. When this is completed, it will likely supersede some of the code shown in this article.

The migration definition

Starting with the "Migrate Custom" module we created in Part 2, we now add the following configuration file.

modules/migrate_custom/config/install/migrate.migration.custom_article.yml

id: custom_article source: plugin: custom_article destination: plugin: entity:node type: article bundle: article process: nid: nid vid: vid type: type langcode: plugin: static_map bypass: true source: language map: und: en title: title uid: uid status: status created: created changed: changed promote: promote sticky: sticky 'body/format': plugin: static_map bypass: true source: body_format map: 1: plain_text 2: restricted_html 3: full_html 4: full_html 'body/value': body_value 'body/summary': body_summary field_tags: tags field_image: images

Pay attention to the last two fields in the definition, "field_tags" and "field_image." These fields can be configured to accept multiple values. (In the case of "field_image" the out-of-the-box configuration allows only one value, but this is easy to change using the Admin UI.) We account for these in the migration by providing only a single property name here. In our source plugin below, we will set these properties to be arrays, thus allowing as many values as exist in our source data.

What's more, "field_image", like the body, is a compound field, in this case consisting of a file ID, ALT text, width, and height. We could specify those values in the definition, but that would limit us to importing only one image. Instead, we will use an associative array in our source plugin to populate all the components of the compound field.

The source plugin

Similar to our Users source plugin in Part 2 of this series, our Blog source definition needs to implement both the query() and processRow() methods. We will do this in the following file:

modules/migrate_custom/src/Plugin/migrate/source/Article.php

<?php   /** * @file * Contains \Drupal\migrate_custom\Plugin\migrate\source\Article. */   namespace Drupal\migrate_custom\Plugin\migrate\source;   use Drupal\migrate\Plugin\SourceEntityInterface; use Drupal\migrate\Row; use Drupal\migrate_drupal\Plugin\migrate\source\DrupalSqlBase;   /** * Drupal 7 Blog node source plugin * * @MigrateSource( * id = "custom_article" * ) */ class Article extends DrupalSqlBase implements SourceEntityInterface {   /** * {@inheritdoc} */ public function query() { // this queries the built-in metadata, but not the body, tags, or images. $query = $this->select('node', 'n') ->condition('n.type', 'article') ->fields('n', array( 'nid', 'vid', 'type', 'language', 'title', 'uid', 'status', 'created', 'changed', 'promote', 'sticky', )); $query->orderBy('nid'); return $query; }   /** * {@inheritdoc} */ public function fields() { $fields = $this->baseFields(); $fields['body/format'] = $this->t('Format of body'); $fields['body/value'] = $this->t('Full text of body'); $fields['body/summary'] = $this->t('Summary of body'); return $fields; }   /** * {@inheritdoc} */ public function prepareRow(Row $row) { $nid = $row->getSourceProperty('nid');   // body (compound field with value, summary, and format) $result = $this->getDatabase()->query(' SELECT fld.body_value, fld.body_summary, fld.body_format FROM {field_data_body} fld WHERE fld.entity_id = :nid ', array(':nid' => $nid)); foreach ($result as $record) { $row->setSourceProperty('body_value', $record->body_value ); $row->setSourceProperty('body_summary', $record->body_summary ); $row->setSourceProperty('body_format', $record->body_format ); }   // taxonomy term IDs // (here we use MySQL's GROUP_CONCAT() function to merge all values into one row.) $result = $this->getDatabase()->query(' SELECT GROUP_CONCAT(fld.field_tags_tid) as tids FROM {field_data_field_tags} fld WHERE fld.entity_id = :nid ', array(':nid' => $nid)); foreach ($result as $record) { if (!is_null($record->tids)) { $row->setSourceProperty('tags', explode(',', $record->tids) ); } }   // images $result = $this->getDatabase()->query(' SELECT fld.field_image_fid, fld.field_image_alt, fld.field_image_title, fld.field_image_width, fld.field_image_height FROM {field_data_field_image} fld WHERE fld.entity_id = :nid ', array(':nid' => $nid)); // Create an associative array for each row in the result. The keys // here match the last part of the column name in the field table. $images = []; foreach ($result as $record) { $images[] = [ 'target_id' => $record->field_files_fid, 'alt' => $record->field_image_alt, 'title' => $record->field_image_title, 'width' => $record->field_image_width, 'height' => $record->field_image_height, ]; } $row->setSourceProperty('images', $images);   return parent::prepareRow($row); }   /** * {@inheritdoc} */ public function getIds() { $ids['nid']['type'] = 'integer'; $ids['nid']['alias'] = 'n'; return $ids; }   /** * {@inheritdoc} */ public function bundleMigrationRequired() { return FALSE; }   /** * {@inheritdoc} */ public function entityTypeId() { return 'node'; }   /** * Returns the user base fields to be migrated. * * @return array * Associative array having field name as key and description as value. */ protected function baseFields() { $fields = array( 'nid' => $this->t('Node ID'), 'vid' => $this->t('Version ID'), 'type' => $this->t('Type'), 'title' => $this->t('Title'), 'format' => $this->t('Format'), 'teaser' => $this->t('Teaser'), 'uid' => $this->t('Authored by (uid)'), 'created' => $this->t('Created timestamp'), 'changed' => $this->t('Modified timestamp'), 'status' => $this->t('Published'), 'promote' => $this->t('Promoted to front page'), 'sticky' => $this->t('Sticky at top of lists'), 'language' => $this->t('Language (fr, en, ...)'), ); return $fields; }   } Running the migration

We need to add a new line to the end of our manifest.yml file:

- custom_article

Remember to reinstall the module to load the new migration configuration. See Part 3 of this series for more information.

As we did with our user migration, we now run the migration using Drush.

drush migrate-manifest manifest.yml --legacy-db-url=mysql://{dbuser}:{dbpass}@localhost/{dbname}

Next steps

This migration only handles a single content type, and only the fields that are configured in an out-of-the-box Drupal site. To practice what you have learned here, try adding some custom fields to the content types, then add them to the migration definition and source plugin. For more practice, try writing a custom migration for a different content type, like the Basic Page, or a custom content type from your site.

Categories: Elsewhere

Metal Toad: Drupal 8 Migrations, part 3: Migrating Taxonomies from Drupal 7

Planet Drupal - Thu, 11/12/2014 - 01:38
Drupal 8 Migrations, part 3: Migrating Taxonomies from Drupal 7 December 10th, 2014 Keith Dechant

Drupal 8 provides a flexible, plugin-based architecture for migrating data into a site. In Part 2 of this series, we explored how to migrate users from a Drupal 7 site. We will now expand on this by migrating Taxonomy vocabularies and terms from a Drupal 7 site into Drupal 8.

This article continues our work from Part 2. The code examples pick up where that post left off. If you are trying this code out yourself, it is recommended to start building your custom migration module according to the examples in that post.

Migrating Taxonomy Vocabularies

The Migrate Drupal module (in Drupal 8 core) already contains a migration definition and source plugins to migrate taxonomy data from Drupal 6 to Drupal 8. All we need to do is to adapt the existing code to work with Drupal 7.

The migration definition:

Starting with the "Migrate Custom" module we created in Part 2, we now add the following configuration file.

modules/migrate_custom/config/install/migrate.migration.custom_taxonomy_vocabulary.yml

id: custom_taxonomy_vocabulary label: Drupal 7 taxonomy vocabularies migration_groups: - Drupal 7 source: plugin: custom_taxonomy_vocabulary process: vid: - plugin: machine_name source: machine_name - plugin: dedupe_entity entity_type: taxonomy_vocabulary field: vid length: 32 label: name name: name description: description hierarchy: hierarchy module: module weight: weight destination: plugin: entity:taxonomy_vocabulary

Here we have examples of a few plugins not seen in the previous post:

  • machine_name converts the string into a valid machine name.
  • dedupe_entity prevents machine name conflicts, which would cause imported data to overwrite existing data. For example, a machine name "foo" would be renamed to "foo_2" if name "foo" already existed.

The source plugin

To define the source of our vocabulary data, we create a new file modules/migrate_custom/src/Plugin/migrate/source/Vocabulary.php with the following contents:

<?php   /** * @file * Contains \Drupal\migrate_custom\Plugin\migrate\source\Vocabulary. */   namespace Drupal\migrate_custom\Plugin\migrate\source;   use Drupal\migrate\Row; use Drupal\migrate_drupal\Plugin\migrate\source\DrupalSqlBase;   /** * Drupal 7 vocabularies source from database. * * @MigrateSource( * id = "custom_taxonomy_vocabulary", * source_provider = "taxonomy" * ) */ class Vocabulary extends DrupalSqlBase {   /** * {@inheritdoc} */ public function query() { $query = $this->select('taxonomy_vocabulary', 'v') ->fields('v', array( 'vid', 'name', 'description', 'hierarchy', 'module', 'weight', 'machine_name' )); return $query; }   /** * {@inheritdoc} */ public function fields() { return array( 'vid' => $this->t('The vocabulary ID.'), 'name' => $this->t('The name of the vocabulary.'), 'description' => $this->t('The description of the vocabulary.'), 'help' => $this->t('Help text to display for the vocabulary.'), 'relations' => $this->t('Whether or not related terms are enabled within the vocabulary. (0 = disabled, 1 = enabled)'), 'hierarchy' => $this->t('The type of hierarchy allowed within the vocabulary. (0 = disabled, 1 = single, 2 = multiple)'), 'weight' => $this->t('The weight of the vocabulary in relation to other vocabularies.'), 'parents' => $this->t("The Drupal term IDs of the term's parents."), 'node_types' => $this->t('The names of the node types the vocabulary may be used with.'), ); }   /** * {@inheritdoc} */ public function getIds() { $ids['vid']['type'] = 'integer'; return $ids; }   }

Note: this file was adapted from the Drupal 6 version in Drupal 8 core. For the original file, see core/modules/migrate_drupal/src/Plugin/migrate/source/d6/Vocabulary.php

The structure of this file is similar to the User source plugin in the previous article. However, because all the data we need is stored in the `taxonomy_vocabulary` table in the source database, we do not need to define the prepareRow() method.

Migrating Taxonomy Terms

We can use a second migration definition to migrate our taxonomy terms. Create the following file:

modules/migrate_custom/config/install/migrate.migration.custom_taxonomy_term.yml

id: custom_taxonomy_term label: Drupal 7 taxonomy terms migration_groups: - Drupal 7 source: plugin: custom_taxonomy_term process: tid: tid vid: plugin: migration migration: custom_taxonomy_vocabulary source: vid name: name description: description weight: weight parent: - plugin: skip_process_on_empty source: parent - plugin: migration migration: custom_taxonomy_term changed: timestamp destination: plugin: entity:taxonomy_term migration_dependencies: required: - custom_taxonomy_vocabulary

In this migration, we make use of the migration process plugin for two of our properties, the vocabulary ID and the parent term ID. This preserves these references in case the referenced entity's ID or machine name changed during the import.

Some machine names and/or IDs will likely change when running your import. This is to be expected, especially because Drupal 8 stores taxonomy vocabularies in the 'config' table, where they are accessed by their machine names instead of by the numeric IDs used in Drupal 7. Fortunately for us, the Migrate module records a map of the old and new IDs in the database. We can then use the migration source plugin to easily look up the old ID or machine name.

The source plugin

To define the source of our term data, we create a new file modules/migrate_custom/src/Plugin/migrate/source/Term.php with the following contents:

<?php   /** * @file * Contains \Drupal\migrate_custom\Plugin\migrate\source\Term. */   namespace Drupal\migrate_custom\Plugin\migrate\source;   use Drupal\migrate\Row; use Drupal\migrate_drupal\Plugin\migrate\source\DrupalSqlBase;   /** * Drupal 7 taxonomy terms source from database. * * @todo Support term_relation, term_synonym table if possible. * * @MigrateSource( * id = "custom_taxonomy_term", * source_provider = "taxonomy" * ) */ class Term extends DrupalSqlBase {   /** * {@inheritdoc} */ public function query() { $query = $this->select('taxonomy_term_data', 'td') ->fields('td', array('tid', 'vid', 'name', 'description', 'weight', 'format')) ->distinct(); return $query; }   /** * {@inheritdoc} */ public function fields() { return array( 'tid' => $this->t('The term ID.'), 'vid' => $this->t('Existing term VID'), 'name' => $this->t('The name of the term.'), 'description' => $this->t('The term description.'), 'weight' => $this->t('Weight'), 'parent' => $this->t("The Drupal term IDs of the term's parents."), ); }   /** * {@inheritdoc} */ public function prepareRow(Row $row) { // Find parents for this row. $parents = $this->select('taxonomy_term_hierarchy', 'th') ->fields('th', array('parent', 'tid')) ->condition('tid', $row->getSourceProperty('tid')) ->execute() ->fetchCol(); $row->setSourceProperty('parent', $parents); return parent::prepareRow($row); }   /** * {@inheritdoc} */ public function getIds() { $ids['tid']['type'] = 'integer'; return $ids; }   } Reloading the configuration

Remember that migrations are configuration entities. To reload the configuration, we need to uninstall and reinstall our module. Here's a handy Drush command to do this:

drush pm-uninstall migrate_custom -y && drush en migrate_custom

Running the migration

We need to add some new lines to our manifest.yml file:

# A D7 user and taxonomy migration, with dependencies. - custom_user - custom_taxonomy_vocabulary - custom_taxonomy_term

As we did with our user migration, we now run the migration using Drush.

drush migrate-manifest manifest.yml --legacy-db-url=mysql://{dbuser}:{dbpass}@localhost/{dbname}

When including multiple migrations in a single manifest, be aware that drush migrate-manifest doesn't always run them in the order you specified. If, for example, your taxonomy migrations are being run before your user migration, and your taxonomy terms end up missing their UIDs, you might need to create two separate manifest files, to give yourself better control over the order.

Next post: Migrating Nodes from Drupal 7.

Categories: Elsewhere

PreviousNext: Automated style guides with KSS-node

Planet Drupal - Wed, 10/12/2014 - 22:47

During PreviousNext’s weekly developers meeting I recently gave a lightning talk about how to use kss-node to auto-generate a website style guide. If you’ve even tangentially followed front-end development, you’ll find that this is yet-another blog post describing “project A implementing technology B with hip, new language/framework C.”

But kss-node is really cool and useful, especially if you understand how it fits into the larger picture of the new web development process. Fortunately, my previous post provides that big picture, so if you’d like to understand how Agile is turning web development inside-out and how style-guide-driven development is the new website development workflow, please go read that first. Then head back here for the screencast to get you started with kss-node.

Categories: Elsewhere

Gregor Herrmann: GDAC 2014/10

Planet Debian - Wed, 10/12/2014 - 22:28

debian has a bigger role than "just" providing a free operating system to our users (& derivatives), it's also an important player in the free software world at large. a recent indication of this is the composition of the FSF's High Priority Projects Committee: if I'm counting correctly, there are two active & one former DDs listed as members; oh, & the contact person is yet another DD :) – great to see many debianistas active all around!

this posting is part of GDAC (gregoa's debian advent calendar), a project to show the bright side of debian & why it's fun for me to contribute.

Categories: Elsewhere

Blue Drop Awards: We're Looking for Guest Bloggers!

Planet Drupal - Wed, 10/12/2014 - 21:20

Do you have a unique way of using Drupal? Can you offer helpful tips about Drupal or even have creative solutions to those nagging problems associated with Drupal? Then we would like to offer you a free platform on which to share your voice.

We are looking for people who would like to be featured on the Blue Drop Awards' website discussing the issues and topics surrounding the Drupal platform.

Are you more into doing than telling? Create a video or podcast that offers helpful tips or information relevant to the Drupal community.

Not into creating content but still want to help? We still need volunteers to help manage the blog or newsletters.

If you're interested, please contact erik@bluedropawards.org.

Categories: Elsewhere

Clint Adams: In Uganda, a popular marbles game is called dool.

Planet Debian - Wed, 10/12/2014 - 21:13

Sophie stood before me. “I'm leaving with that guy,” she gestured.

“Yes, I thought that would happen,” I chuckled.

She hugged me. The guy, whose name we managed to never utter, did not hug me, though he usually does. They went home together.

That was the last time I saw Sophie.

The rest of us sat down, finished our drinks, and split up. I went with Sophie's ex-girlfriend and the guy who sometimes serves as her ironic beard.

They smoked their disgusting light cigarettes, the kind with very little tobacco but lots of horrible chemicals that make me cough and hopefully fail to give me lung cancer, because watching someone else die of that was excruciating enough.

So we get to our next destination and there is a Peruvian girl sitting on a stool and shopping for shoes on her phone. I am fascinated. Phone app developers had told me that people actually did this but I thought it was just wishful thinking on their part.

The Peruvian girl, who is named something that sounds like it was uttered accidentally by Tommy Gnosis, complains to Sophie's ex-girlfriend that some guy keeps harassing her. We instinctively form a human barrier to shield her from this alleged transgressor, who, it turns out, is the pompous drug dealer with whom Sophie's ex-girlfriend is just about to conduct business.

“I'll be right back,” she says. “Hit on her.”

“What‽ Why‽” I shout after her. There is no response.

Sophie's ex-girlfriend and the drug dealer return from the darkness, having swapped possessions.

The drug dealer is a blowhard and proceeds to regale us with stories so little interest to me that I can't even remember what they were about, but as drug dealers are wont to do, he abuses the power of his possession to maintain the delusion that people would tolerate his presence even if he didn't have illegal commodities to sell them.

When the beard and Sophie's ex-girlfriend go out for a smoke break, I went home.

Categories: Elsewhere

Chris Lamb: Starting IPython automatically from zsh

Planet Debian - Wed, 10/12/2014 - 19:07

Instead of a calculator, I tend to use IPython for those quotidian bits of "mental" arithmetic:

In [1]: 17 * 22.2 Out [1]: 377.4

However, I often forget to actually start IPython, resulting in me running the following in my shell:

$ 17 * 22 zsh: command not found: 17

Whilst I could learn do this maths within Zsh itself, I would prefer to dump myself into IPython instead — being able to use "_" and Python modules generally is just too useful.

After following this pattern too many times, I put together the following snippet that will detect whether I have prematurely attempted a calculation inside zsh and pretend that I ran it in IPython all along:

zmodload zsh/pcre math_regex='^[\d\.\s\+\*\/\-]+$' function math_precmd() { if [ "${?}" = 0 ] then return fi if [ -z "${math_command}" ] then return fi if whence -- "$math_command" 2>&1 >/dev/null then return fi if [ "${math_command}" -pcre-match "${math_regex}" ] then echo ipython -i -c "_=${math_command}; print _" fi } function math_preexec() { typeset -g math_command="${1}" } typeset -ga precmd_functions typeset -ga preexec_functions precmd_functions+=math_precmd preexec_functions+=math_preexec

For example:

lamby@seriouscat:~% 17 * 22.2 zsh: command not found: 17 377.4 In [1]: _ + 1 Out [1]: 378.4

(Canonical version from my zshrc.d)

Categories: Elsewhere

Acquia: A Symfony Shop Embraces Drupal 8 & Gets Down to Business

Planet Drupal - Wed, 10/12/2014 - 18:42
Language Undefined

Chris Jolly, CTO Ontraq Europe, and his company have a strong technical background, going back to "old school" (pre-internet) IT. Their main focus until now has been eCommerce, Symfony, and solving hard problems like legacy-system integrations. Now, thanks to its use of Symfony framework components, they've started using Drupal 8 as their content management technology of choice! Chris and I talked at DrupalCon Amsterdam about getting there and what they're up to now.

Categories: Elsewhere

Drupal Watchdog: Migrate Overview

Planet Drupal - Wed, 10/12/2014 - 18:16
Article


Two years into the development of Drupal 8, Dries Buytaert announced that Drupal 8.0 might ship without an upgrade path.

This unorthodox decision was made to support substantial improvements in Drupal’s major version upgrade process by introducing a robust new sub-system based on the popular contributed modules Migrate and Migrate D2D. The sub-system includes the Migrate module, which provides the basic framework and API, and the Migrate Drupal module, which provides the upgrade paths and framework to enable other Drupal-to-Drupal use cases in contrib.

The substantial wins with this new approach include the ability to move directly from Drupal 6 to Drupal 8 – as well as the possibility of providing more fine-grained control over the process – and the option of continuous content migration.

The migration team is working extraordinarily hard to be ready by the time that D8 is ready for beta. As of March 31, Migrate API has been committed to core. The last blocking issues for Migrate Drupal were resolved during the DevDays sprint, and the team will begin submitting patches for the D6 to D8 migration path to the core queue any day now.

A Drupal 6 to Drupal 8 upgrade without Migrate

Without the new API, an abbreviated move from Drupal 6 to Drupal 8 would have looked something like:

  1. Backup your database
  2. Update core and contrib to the latest version of 6
  3. Disable all contributed modules and switch to the core theme
  4. Delete the D6 code and replace it with D7 core code
  5. Run update.php
  6. Download the D7 contributed modules
  7. Enable the contrib modules
  8. Run update.php
  9. Repeat to upgrade from D7 to D8

For Drush users, the 'drush up' command would vastly simplify this, but two full upgrades — from 6 to 7, then 7 to 8 — would still have been required, inevitably losing data in each step.

Categories: Elsewhere

Annertech: Scalable & Sustainable Media Management for Drupal Websites

Planet Drupal - Wed, 10/12/2014 - 18:08
Scalable & Sustainable Media Management for Drupal Websites

*/ /*-->*/

Categories: Elsewhere

SitePoint PHP Drupal: 7 CRM Options Compatible with Drupal

Planet Drupal - Wed, 10/12/2014 - 18:00

I love Drupal and end up undertaking most of my programming projects with it. I have been using it for so long that I find it far easier to push out projects with Drupal than with anything else, despite it’s infamous learning curve.

Whether you want to call Drupal a CMS (Content Management System), a CMF (Content Management Framework) or a CMSomething, the ‘C’ always stands for Content. Content is where Drupal shines and is what it’s designed for.

When an organisation is at a stage and mindset that they also want to manage their contacts and interactions effectively they will often need tools designed specifically for that function. These are generally referred to as a CRM, which stands for Client Relationship Manager or Constituent Relationship Manager, depending on the sector (For-Profit or Not-for-Profit respectively). CRMs are big business, with many free and paid options available, all with their own advantages and disadvantages.

Often these interactions that people have with your organisation will include things such as registering for an event, making a donation, becoming a member, expressing interest in a product or receiving a newsletter. This all sounds quite simple, but often representing a business rule in the digital realm is very difficult as everyone thinks ‘their way’ is ‘the only way’ and that surely every off-the-shelf system should represent them out of the box.

Continue reading %7 CRM Options Compatible with Drupal%

Categories: Elsewhere

Code Drop: Drupal Security Tips for Developers

Planet Drupal - Wed, 10/12/2014 - 05:30

I’ve recently been reviewing a few security related patches and it soon became apparent that many developers make the same mistakes over and over in regards to best practices for security in Drupal. So below, a very short post on the common mistakes and solutions.

Correct usage of t()

Use the right placeholder for t(). You should be using "% and @" which are both escaped to protect against Cross Site Scripting vulnerabilities. Whenever you use "!" as a placeholder, double check the content has already been escaped.

Escaping Output in #markup

If you’re providing a custom field, widget and formatter you need to make sure that any content coming from the admin is correctly escaped. For example, you’re implementing hook_field_formatter_view() and doing something like:

Categories: Elsewhere

Drupal governance announcements: DrupalSouth - Early Bird tix almost sold out!

Planet Drupal - Wed, 10/12/2014 - 02:26

There are only a few early bird tickets left. So if you want one, grab it now.

https://melbourne2015.drupal.org.au/conference/tickets

Categories: Elsewhere

Dirk Eddelbuettel: Wilco!!

Planet Debian - Wed, 10/12/2014 - 01:47

With a bit of luck due to a collegue having a spare ticket, I managed to make it to an awesome Wilco show at The Riviera in Uptown.

This concert was part of a set a six shows. Tweedy and the band were fast, and loose, and wonderful, and totally beloved by the home crowd. An truly outstanding show, and a great evening.

Also: I should get out more often. Last blog entry about Wilco was from 2005. Ouch.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator