Update: Oops, this wasn’t the problem at all. It was actually with the Content Permissions module. Forgot the site was using it! Pretty embarrassing

I just went through quite a struggle getting my CCK fields to appear on my Display Suite-managed node. I finally succeeded, though, in the end, and thought I would share the solution.

Don’t worry, there isn’t much to read: just disable and re-enable the Node Displays CCK (nd_cck) module found within in the Node Displays Contributions module.

I initially tried disabling and re-enabling all Display Suite-related modules, but that didn’t work. For some reason, however, disabling and re-enabling that specific one did.

Hope this solves someone’s problem!

(To read my full rant, check out this issue comment and the ones below.)

My goal here is only to share quickly how I actually got this working.

Alright, so you know the part where it says to add the directives:

AddHandler php5-fcgi .php
Action php5-fcgi /fcgi-bin/php5.external

This didn’t work for me no matter what I did. No errors were produced, so I knew that it simply wasn’t executing the Action directive for whatever reason. In checking the Apache 2.2 documentation for Action, I noticed that a MIME type could be given in lieu of an action-type (the php5-fcgi thing). Having exhausted all other options, and knowing that the PHP file was being sent to the browser unprocessed with the MIME type application/x-httpd-php, I decided to add:

Action application/x-httpd-php /fcgi-bin/php5.external

to my configuration. And, much to my shock, it actually worked!

So, if you find yourself as frustrated with setting up Apache + PHP-FPM as I was, I hope this tip may ease your suffering.

find . -name '[^.]*' | xargs perl -pi -e 's/192\.168\.1\.3/192\.168\.0\.3/g'

I adapted it to this for my task of replacing IP addresses. The first set of numbers is the old one (don’t delete the backslashes) and the second set is the new one.

This command assumes all files in the directory are configuration files and do not start with a dot.

Enjoy!

Update: According to a commenter, sed -i 's/thisip/thatip/g' * should also work. I didn’t try that since I thought it wouldn’t work with multiple input files.

Recently, I read the Stanford Tech Commons article on Cloning a Content Type in D7 at https://techcommons.stanford.edu/topics/drupal-7x/cloning-content-type-d7. It proposes a simple but (mostly) effective way  to wind up with cloned content types in Drupal 7. Summarized:

1. Create a content type and set it up as desired.
2. Export the content type and its field to a feature module with the Features module. *** WARNING: DO NOT ENABLE THE FEATURE MODULE YET. ***
3. The existing content type will be the clone, so edit it and change the machine name; this renames it and changes the type of all existing content to the new name.
4. Enable the feature module. Your previous content type is restored (potentially after reverting).

My Experience

I found that things didn’t quite go as advertised with this approach. I couldn’t get the existing content type to be recreated when reverting the feature. I found a workaround; it entailed editing database tables in phpMyAdmin, so it’s not ideal;  however, it does appear to be safe as it is only old data that is deleted. This should be done only if you have enabled the feature module and you cannot revert it, meaning that shows Overridden despite your best efforts.

1. Open phpMyAdmin or your database tool.
2. Browse to the field_config_instance table.
3. Sort by the bundle column and delete all rows corresponding to the content type encapsulated in your feature (not the already-renamed one).
4. Now browse to the node_type table.
5. Edit the row corresponding to the renamed content type, and you should see that its orig_type column still contains, predictably, the original name. Unless you’re sure you need this information, in which case you probably won’t be able to revert the feature module, edit this row and change the value of this column to the same as the type column. In other words, if the new machine-readable name for your content type is income, as it was mine, change the value of this column to income as well.

Try reverting your feature again. The content type will revert successfully, and the fields will remain Overridden. But don’t despair! They will be properly configured when you go and have a look. It’s just that Drupal adds some additional information that for one reason or another will not have been exported to the original feature, or wasn’t in my case. Recreate the feature module and re-export it to make it show Default again.

I hope these third-party errata help someone out.

• Drush Make makefiles for Drupal development versions
• Workaround for inability of Quickstart’s quickstart-create Drush command to create Git-enabled sites

There were two problems that were so counterintuitive, the urge to blog about them came over me. Disclaimer: I admit I’ve never properly read the Feeds documentation; I figured setting up a node importer based off a CSV parser would be pretty easy.

The solution is extremely simple:

When setting up your CSV importer and specifying Source column names, do not use spaces or uppercase letters. This means you need to avoid it in your CSV file as well.

That’s all! Instead of Body Text, call it body_text. What happens is that by the time Feeds Tamper receives your Feeds field, the data structure it uses to store them contains lowercase (and probably space-free) versions of whatever you had as the Source column names back in your updater. Using my tip ensures that these will be the same, and Feeds Tamper will be happy.

Have fun tampering.

P.S. The Latin in the title hopefully means, “Developer beware.”

How do I get my links to open in a new window or tab in the user’s browser in Drupal 7?

I’ve heard that the target=”_blank” method is once again valid in HTML 5…however, it will still make your HTML fail validation under other specifications. The way around this is to use JavaScript.

Copy and paste this snippet into the appropriate area of your site – usually a JavaScript file in your theme. When you want to make a link open in a new window or tab, instead of target=_blank, add rel=”external”.

(function ($) {
Drupal.behaviors.externalLink = {
attach: function (context, settings) {
$('a[rel="external"]', context).attr("target", "_blank");
}
}
}(jQuery));

The reason this workaround is OK to use is that it does a little something called separating presentation from behavior. In other words, you aren’t relying on the browser to take a particular action because of the HTML itself; you’re telling it what action to take in the JavaScript.

sed -i '[num]d' [filename]

For example, to remove line 1 from ~/.ssh/known_hosts (my exact use case right now), type:

sed -i '1d' ~/.ssh/known_hosts

sed is a neat little tool. I use it to quickly copy and change Apache virtual hosts sometimes as well. I recommend learning a bit about it and its ‘s’ command as well.

P.S. If you don’t use the -i switch, sed will output the result after replacements instead of changing the file. You can pipe (|) this output to other programs or redirect (> or >>) it to a file.

Happy sed…ing.

Basically, it’s the drush sql-cli command, or drush sqlc for short. If you type just that, you will be logged into a database shell. Did you know, however, that you can actually import a database this way, much in the way you would with mysql database < database_file.sql? Swap out the mysql stuff and drop in drush sqlc < database_file.sql – and it works! It grabs the DB information from your settings.php file, and magic happens! This was an awesome find for me, and it’s going to save me a decent amount of time in the future.

NOTE: This might be MySQL-only. If a PostgreSQL user could chime in and let me know if it works for that or any other DBMSes, I’d appreciate it!

I ran into an API change issue yesterday when working on upgrading Fill PDF to be fully Drupal 7-compatible, and just today, someone on IRC ran into the same issue. She suggested that “somebody” write a blog post about it, so I thought I would. I hope it saves some random Internet searcher a few hairs.

Basically, you can no longer use jQuery’s shortcut variable $ in Drupal 7 instead of the full jQuery variable.

What does this mean? In short, code that you used to write like this:

$('#my-awesome-id').attr('title', 'My Awesome Title');

will net you a Javascript error in Drupal 7. There are not one, but two ways around this.

The Ugly Way

Replace $ with jQuery wherever $ is used. For example:

jQuery('#my-awesome-id').attr('title', 'My Awesome Title');

Yuck. Despite that actually being the slightly simpler way…I don’t like it.

The Money Way

This is the money way because it brings back the $. This way is slightly more complex because you have to wrap your JavaScript code inside of a parenthetical inline function. Let’s have a look:

(function($) {
$('#my-awesome-id').attr('title', 'My Awesome Title');
})(jQuery);

This basically makes $ work inside of that wrapper code (between the (function($) { and the })(jQuery). I haven’t yet tried putting it around entire JS files – if you have, let us know in the comments. Does Drupal.behaviors work inside of this wrapper? Update: According to Lê Thanh in the comments, Drupal.behaviors functions properly within the (function($) { … })(jQuery); wrapper. Next question – anyone know if this wrapper has a name? I’m going to call it the jQuery Sandwich ™ until corrected.

For the full story, see: http://drupal.org/node/224333#javascript_compatibility

And speaking of Drupal.behaviors, that has also changed a little bit (and perhaps more if you are doing AHAH/AJAX): http://drupal.org/node/224333#drupal_behaviors

Whether you write jQuery in Drupal 7 the subjectively ugly way or the subjectively money way, you will now at least be able to produce working jQuery code in Drupal 7. Happy coding!

P.S.: For further hair preservation, it is recommended not to look at the size of your browser scrollbar when browsing the “Converting 6.x modules to 7.x” page referenced above.

Update: P.P.S: The jQuery Sandwich is not actually a trademark, or if it is, it’s not mine.