Planet Drupal

How to exclude the current node from a list view in Drupal 7

This is the instructions corresponds Drupal 7 + views 3.

There is a standard problem, we have the teaser of a random node in the block,
but it would be wrong to deduce the node teaser page on the page of it's full view.
Lets do following in views settings:

1. Click on the "advanced" fieldset.
2. Click on add under "contextual filters". We are going to add new contextual filter.
3. Choose Content:nid.
4. Under "when the filter variable is not available", choose "provide default value".
5. From the drop down menu select "content id from url".
6. Scroll all the way down to the bottom of the window and click on the "More" link.
7. Click "Exclude".
8. And be happy!

Blog tags:

How to add each own 404 page to each section of the site.

Several days ago I have following task:

there is a site with URLs content structure:

section-1/title-1
section-1/title-2
section-1/title-3
...
section-n/title-1
section-n/title-2
...
etc.

Task, to provide the ability of separate 404 page for each section of the site,
that is
section-1/404
...
section-n/404

Of course, we can use Rules API to set complex rules but there is more simple way to solve this problem.

I think arg() function helps us. See http://api.drupal.org/api/drupal/includes%21path.inc/function/arg/6
Without any argument arg() returns the array of the current path components.
If it will be correct node alias arg() returns following array:

[0] = 'node'
[1] = some node id

in the case of wrong path it returns for example:

[0] = 'section-1'
[1] = 'wrong-title'

Let's create simple "section_404" module.

<?php
function section_404_init() {
  $args = arg();
  if($args[0]  != 'node' && $args[0]  != 'admin') // in the case if we are going to use not simple node content but views etc. the condition can be more complex
    drupal_goto($args[0] . '/404');
}
?>

As was indicated in the comment in the code the real condition that you should use on production site should be more complex.

Blog tags:

Start You Own Drupal Distribution with Drush Make. Part 1.

As a rule, we get used to enjoy some limited set of trusted modules, especially if we often have to work on typical projects.

I remember when I started working with Drupal, every time for each new project I collected fresh new versions of my favorite modules on Drupal.org. It was monotonic mannual work and I wast a lot of time before starting new Drupal installation.

But after meeting with Drush Make I was really happy!

I will not tell about the installing this extension of Drupal Shell, yet immediately move on to writing .make file.

First of all we should start with two service lines:
; Core version
; ------------
; Each makefile should begin by declaring the core version of Drupal that all
; projects should be compatible with.
core = 7.x

; API version
; ------------
; Every makefile needs to declare it's Drush Make API version. This version of
; drush make uses API version "2".
api = 2

After that we need to indicate core version that we are going to use. To use the latest Drupal version we should write only following:
projects[drupal][type] = core

We can also type the version of the core that we need. In this case our .make file will be following:
core = 7.x
api = 2
projects[drupal][type] = core
projects[drupal][version] = 7.8

But we can use also PressFlow as core for our distribution. There is no any other way to obtaine PressFlow only to get it from GitHub.
For this porpouse pressflow.make was created:
core = 7.x
api = 2
projects[pressflow][type] = core
projects[pressflow][download][type] = git
projects[pressflow][download][url] = git://github.com/pressflow/7.git

If you have this file you can type:
$ drush make --prepare-install --tar pressflow.make pressflow

And in several minutes have pressflow.tar.gz

Ok, I describe below what each argument of drush make command means.

--prepare-install mean that Drush Make prepare "files" folder and "settings.php" file future installation, I remember I had often had to do it manually :-)

--tar will do archive .tar.gz with your distro.

The following parameters are the name of the our make file and the name of the target archive or folder if we miss --tar parameter.

Let's talk about how to add modules and themes in our distribution. Fairly complete documentation you can be find on http://drupalcode.org/project/drush_make.git/blob_plain/refs/heads/6.x-2.x:/README.txt. But I'm going to provide several examples to cover main part of content of the document.

Lets start with modules. There is a good practice to put all contributed modules in the folder "sites/all/modules/contrib", and put your custom modules into "sites/all/modules/custom". I like Backup&Migrate module so I put it into each my distribution:

projects[backup_migrate][subdir] = "contrib"

In this case Drush Make get recommended version of the module and put it into "sites/all/modules/contrib".
But in some cases there is no recommended version, or if you want to use some selected version, you should input it in the instructions to Drush Make:

For example, if you want to use Defaul Content module, you should indicate the version of the module, because this modul have no recommended version yet:

projects[defaultcontent][subdir] = "contrib"
projects[defaultcontent][version] = "1.0-alpha4"

Also you can get latest version of module directly from GIT:

projects[addthis][subdir] = "contrib"
projects[addthis][download][type] = "git"
projects[addthis][download][url] = "http://git.drupal.org/project/addthis.git"
projects[addthis][download][branch] = "7.x-2.x"

How to add themes?

projects[omega][type] = "theme"

We should touch at list one parameter to include project into distro, so we indicate that Omega is theme, but it is obvious for us.

And finnaly we can include in our distributions third party libraries, for example lets add colorbox to our distribution:

libraries[colorbox][download][type] = "get"
libraries[colorbox][download][url] = "http://colorpowered.com/colorbox/latest"
libraries[colorbox][directory_name] = "colorbox"

The code will be putted into "sites/all/libraries/colorbox" folder.

I think this information will be enough to start you own experiments. I'm going to create the second part of the tutorial. Waiting the updates in my Blog.

Thanks!

Blog tags:

How to transfer the content type settings by Features?

In the post How to Create Content Type in Drupal 7 Programmatically I told about creating content type with using .install file.

But more often during development, we are dealing with a situation where some type of content is created in the admin to set up a specific field. These settings are made on staging while production site lived his own life, filled with new content and users. Obviously, it would be inexcusable mistake to overwrite production DB by staging ones.

On the other hand, we can transfer all the settings manually, but it takes a long time, moreover, there is no guarantee that we do not forget anything.

A simple solution to this issue is to use Features module.

Lets we have the type of content portfolio (admin/structure/types/manage/portfolio/fields):

We should be sure that module Features exitsts and enabled.

Lets go Administration » Structure » Features
and click "Create Feature" tab.

We should input "Name" and "Description" of our new feature. Also you can see "Version" and "URL of update XML", do not pay attention on them. Just now we are not going to provide our feature to somebody and make some new versions.

Lets go ahead! Take a look on the second fieldset. We should select content type that we would like to export. On the right we can see dependencies.

After we press download the feature will be ready for downloading.
In the current case got portfolio_content_type.tar

If you will take a look on content of this archive you can find module.
Pay attention to the .info file. Module has dependencies:

dependencies[] = "colorbox"
dependencies[] = "features"
dependencies[] = "image"
dependencies[] = "strongarm"

So on the site, where you would like to copy content type, these modules should be enabled.

Copy this module to the other site and you can see it in the list of modules:

But you should not turn on it here. Please, go to Administration » Structure » Features:

You can see the list of all features available. On this cas there is only one Feature.
You can turn on it to click on "Disabled". And new content type with corresponding field settings will appear!

Good! It is more simple way to create content on the site by one click that I told in the topic How to Create Content Type in Drupal 7 Programmatically. But it is feature based method, in the post that I mention content type was created without Features module, it is more native way, more preferable for the Code Driven Development approach.

Blog tags:

How to Create Content Type in Drupal 7 Programmatically

Please, take a look on node_example module (http://drupal.org/project/examples)
There is a good example in this module, but I'm try to stop only on simple content type adding without any fields as extensions.

The code that will be created new content type we should add into .install file.

Lets add hook_install():

<?php
function your_module_name_install() {
  // use get_t() to get the name of our localization function for translation
  // during install, when t() is not available.
  $t = get_t();

  // Define the node type.
  $node_example = array(
    'type' => 'node_example',
    'name' => $t('Example Node'),
    'base' => 'node_content',
    'description' => $t('This is an example node type with a few fields.'),
    'body_label' => $t('Example Description')
  );

  // Complete the node type definition by setting any defaults not explicitly
  // declared above.
  // http://api.drupal.org/api/function/node_type_set_defaults/7
  $content_type = node_type_set_defaults($node_example);
  node_add_body_field($content_type);

  // Save the content type
  node_type_save($content_type);
}
?>

We should not add
node_types_rebuild();
menu_rebuild();
in the code of your_module_name_install() because rebuild will perfome automatically.

According to the rules of good Drupal code, we should to make drupal message and write this event to the log:

<?php
function your_module_name_install() {
  $t = get_t();
  $node_example = array(
    'type' => 'node_example',
    'name' => $t('Example Node'),
    'base' => 'node_content',
    'description' => $t('This is an example node type with a few fields.'),
    'body_label' => $t('Example Description')
  );
  $content_type = node_type_set_defaults($node_example);
  node_add_body_field($content_type);
// Check if we create content type or update.
  $status = node_type_save($content_type);
// Replacement rule for the messages.
  $t_args = array('%name' => $content_type->name);
  if ($status == SAVED_UPDATED) { // update case
    drupal_set_message($t('The content type %name has been updated.', $t_args));
  }
  elseif ($status == SAVED_NEW) { // create case
    drupal_set_message($t('The content type %name has been added.', $t_args));
    watchdog('node', 'Added content type %name.', $t_args, WATCHDOG_NOTICE, l($t('view'), 'admin/structure/types'));
  }
}
?>

Ok, and we also should provide hook_uninstall() to remove our content type:

<?php
function your_module_name_uninstall() {
  // Gather all the example content that might have been created while this
  // module was enabled.  Simple selects still use db_query().
  // http://api.drupal.org/api/function/db_query/7
  $sql = 'SELECT nid FROM {node} n WHERE n.type = :type';
  $result = db_query($sql, array(':type' => 'node_example'));
  $nids = array();
  foreach ($result as $row) {
    $nids[] = $row->nid;
  }
  // Delete all the nodes at once
  // http://api.drupal.org/api/function/node_delete_multiple/7
  node_delete_multiple($nids);
  // Delete our content type
  // http://api.drupal.org/api/function/node_type_delete/7
  node_type_delete('node_example');
}
?>

I should mention that if we will not delete all nodes of such content type the function node_type_delete() will not run.

See also How to transfer the content type settings by Features?

Blog tags:

Subscribe to RSS - Planet Drupal