Feed aggregator

Drupal core announcements: Drupal core security release window on Wednesday, January 21

Drupal News - January 18, 2015 - 9:51pm
Start:  2015-01-21 (All day) America/New_York Online meeting (eg. IRC meeting) Organizers:  David_Rothstein

The monthly security release window for Drupal 6 and Drupal 7 core will take place on Wednesday, January 21.

This does not mean that a Drupal core security release will necessarily take place on that date for either the Drupal 6 or Drupal 7 branches, only that you should prepare to look out for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

There will be no bug fix release on this date; the next window for a Drupal core bug fix release is Wednesday, February 4.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

3C Web Services: Creating a Drag & Drop Sorting Interface for a Drupal View

Drupal News - January 18, 2015 - 12:45pm
How to create a drag and drop sorting interface for a Drupal 7 View.

Danny Englander: Drupal Drush Segmentation Fault 11 Error: Avoiding the Rabbit Hole

Drupal News - January 18, 2015 - 12:02pm

I've been doing a lot lately with Grunt and LibSass within my drupal.org contrib theme, Gratis. Yesterday, I updated my Node modules locally. Shortly thereafter, I started getting a nasty Drush error.

line 1: 48475 Segmentation fault: 11  
/opt/local/bin/php /Users/danny/.composer/vendor/drush/drush/drush.php
--php=/opt/local/bin/php --backend=2
--root=/Users/danny/Sites/Drupal/gratis2/gratis2-site
--uri=http://default pm-updatestatus 2>&1 or sometimes just:

Segmentation fault: 11

Not only that but my local site's admin UI started WSODing. I didn't immediately connect the Node NPM update to the drush error. So I looked in my MacPorts Apache log and saw hundreds of these streaming down every few seconds:

[Sat Jan 17 13:03:56 2015] [notice] child pid 49312 exit signal Segmentation fault (11) No joy

Doing a Google search led me to some varied and vague issues with regard to Apache and MySQL but none of theme really rang true to what I was experiencing. I decided to check some of my other local sites and they all seemed fine; no errors, WSODs, or otherwise. Bizarre! I worked for about an hour, but still no joy, I was headed down a rabbit hole. That being said, I let this rest for a while. I always let a problem to sit for a bit if I can't fix it right away or ask for help. More often than not, I'll come back later and end up fixing it.

The search

I got out for some air and went to downtown San Diego to take some photos. That usually gets my mind off things and is relaxing. Arriving back later in the day, I got back into it and decided to search for drush cache clear segmentation fault theme. Bingo! (and 50 browser tabs later). I don't know why I didn't search for this earlier in the day, I was just searching the pure Apache log error which knows nothing of drush.

Sure enough it's an error related to Node modules (from the node_modules folder) having a .info file. Drush sees that and thinks it's supposed to be part of Drupal. The problem is, in a Drush world, these files are malformed. Thus the errors. Right about now, I was wishing there was some kind of .drushignore file along the same lines as .gitignore.

With this new search, here's the relevant posts I found:

In turn, these led me to the main issue, Themes should not crash when .info file appears inside node_modules

It turns out there is a proposed patch for core to prevent this error. I somehow don't see this getting in anytime soon but there are some workarounds on the Node / Grunt end of things.

Custom script

Here is the fix that I arrived at based on all the suggestions and comments in this last issue. First, we need to write a Node NPM cleanup Bash script. The script will find any .info files and rename them to .inf0 (with a zero). This will not have any negative effects as you don't commit node_modules folder to your repo and the info files are not actually needed for Grunt to run properly. So we'll call our script,npm_post.sh

#!/bin/sh
# npm_post.sh

# This script finds any .info files in the node_modules directory and renames them so they don't
# conflict with drush. package.json runs this on completion of npm install.
# These files, if any are not actually needed to run grunt and compile LIbSass
# See this issue for more info: https://www.drupal.org/node/2329453

find -L ./node_modules -type f -name "*.info" -print0 | while IFS= read -r -d '' FNAME; do
    mv -- "$FNAME" "${FNAME%.info}.inf0"
done

Once you have this in the same folder as your package.json file (in my case the root of my theme), you'll need to call it with a postinstall method from your package.json file.

  "scripts": {
    "postinstall": "sh npm_post.sh"
  },

One caveat here is that you may run into an error that the script won't run. To solve this you can either run sudo npm install --unsafe-perm or alternatively create an .npmrc file with the code:

unsafe-perm = true

and then run sudo npm install as usual.

Conclusion

Running into errors like this is definitely not fun but I learned a lot in the process. I am not sure if this is the best fix in the world but it seems to work fine for my use case. It also shows us to not get tunnel vision when trying to fix a development problem.

Tags 
  • Drupal
  • Grunt
  • Node NPM
  • Drupal Planet

Alexander Mikhailian: Data-mining Drupal users in a screenful of code

Drupal News - January 18, 2015 - 1:53am
Objective

Select like-minded users from a local community website.

Pre-requisites
  1. A Drupal website with the votingapi module enabled and at least a few dozen votes by registered users.
  2. A working installation of the R language.
Exract data

For each user, select all other users that voted on same node and comments:

SELECT v1.uid uid1, v2.uid uid2, u.name name2, v2.entity_id entity_id, v1.value value1, v2.value value2 FROM votingapi_vote v1 JOIN (votingapi_vote v2, users u) ON (v1.uid != v2.uid AND v1.entity_id=v2.entity_id AND v1.entity_type=v2.entity_type AND v2.uid=u.uid) WHERE v1.uid

This produces a table

Syndicate content