ommadawn.dk stuff - drupal

Views

d7lise — Fri, 30 Nov 2012 14:28:53 +0000

Tags:

computers

drupal

Important, basic points about views:

Using views, you can create a particular look at already existing data, e.g. a list of tags.

The same view can have several displays, meaning the same look can exist in multiple formats, e.g. both as page and feed.
Under Fields we can choose which fields will be shown or used in other ways (like a later comparison).
- Fields, add, remember to use Search and the Filter, it makes it much easier to find the field you need to add to your view
- Configure field
  - Exclude from display, precisely if you don't need to display this field, but need it for some other reason
  - Link this field to the original piece of content will sometimes be displayed, this is a simple shortcut for linking from a field back to the content, this field is from.
  - Rewrite results
    - Output this field as a link, if you want to create other kinds of links
      - Use absolute path, very good for links in rss feeds
- Sort criteria
  - Expose this sort to visitors, to allow them to change it, if you enable this, you will get a filter
When an included field is a (term?) reference, a link to the relevant page will be created automatically or by default (e.g. from term to page of content linked to term). It is also possible to include the linked to content.

If you're used to SQL, this might help you:

If the value for filtering comes from the URL, use Contextual filters:

The view is available as a page, with a path: www.example.com/my-view
I want to get the term ID from the URL, if it's available, and only show content matching that term.
Contextual filters, add
Choose the right field, apply, apply.
A relevant term has tid = 7.
Test www.example.com/my-view/7

If fields are needed from more than one entity, relationships are needed, like this:

I want to create a view showing articles + the name of the author.
Create a view showing articles.
Create a relationship to Content: Author.
Now you can select a new field: User: Name.

Using relationships is like joining tables in SQL.

Want to display your content with a view included? Use Viewfield. Viewfield Tutorial. This applies, when you actually want to link youre content to a view. You can also use Views field view, where you can still use another view a field, without relating it to your content type.

Have a hierachal taxonomy structure? Then of course you want to show it hierachally in your view. Use Views tree.

First, create a new term view using the fields row style. Then:
Add relationship for taxonomy term: parent term
Add field term id (do not use relationship) and exclude it from display
Add field term id with relationship, exclude from display
Add any fields you want to display, like term name, term description, etc...
Change style plugin to Tree (Adjacency model)
Set Main field to Term ID
Set Parent field to Term ID with parent relationship

0, "the fields row style". What is actually meant is "unformatted list of fields".

1, find and relate to the parent term.

2, add field term id.

2, without relationship, excluding from display.

3, again, now with relationship.

5-7, change style (or rather, format).

Features

d7lise — Fri, 30 Nov 2012 08:27:10 +0000

Tags:

drupal

computers

How does a feature figure out, whether it's been updated?

The "normal" state of the feature is the state of e.g. the fields involved. The relevant resource is asked: What is the state? E.g., for a field you'd look at field_config and field_config_instance and see how the field was configured.
The "default" state of the feature is stored in the feature itself. There are functions that will return how things should be configured, e.g. a function implementing hook_field_default_fields.
These 2 requests result in arrays. Bascially the 2 arrays are compared. If they're the same, you know that the feature and the database are in sync.
If the feature and the database aren't in sync, it is decided where the problem lies. Other configurations are checked and compared in order to make the decision.

Configuring fields

d7lise — Tue, 13 Nov 2012 12:10:59 +0000

Tags:

computers

drupal

Custom fields also have custom configuration, and this configuration can be changed through many modules. How is this done?

2 tables keep the relevant information: field_config and field_config_instance
field_config notes, that a field exists, and certain basic and default information about it (one row for every field)
field_config_instance notes, that the field has been related to an entity (one row for every relation)

A look at field_config:

Every field has an id (an integer), a machine name, a type and a relation to a module.

Let's look at the field for tags:

id = 3
name = field_tags
type = taxonomy_term_reference
module = taxonomy

Let's look at field_config_instance too:

Looking at field_tags again is interesting:

articles have tags

Both tables have a very important column called data. This is where most of the actual configuration is stored. We won't look directly at that field a lot, but mostly look at manipulating it instead. First let's look at how the above rows were created in the install profile:

  $field = array(
    'field_name' => 'field_tags',
    'type' => 'taxonomy_term_reference',
    // Set cardinality to unlimited for tagging.
    'cardinality' => FIELD_CARDINALITY_UNLIMITED,
    'settings' => array(
      'allowed_values' => array(
        array(
          'vocabulary' => 'tags',
          'parent' => 0,
        ),
      ),
    ),
  );
  field_create_field($field);

The array called settings feeds the column called data. This is what data contains afterwards (I've shortened it a little):

a:6:{s:8:"settings";a:1:{s:14:"allowed_values";a:1:{i:0;a:2:{s:10:"vocabulary";s:4:"tags";s:6:"parent";i:0;}}}...}

Let's format that a bit:

a:6:{
  s:8:"settings";
  a:1:{
    s:14:"allowed_values";
    a:1:{
      i:0;
      a:2:{
        s:10:"vocabulary";
        s:4:"tags";
        s:6:"parent";
        i:0;
      }
    }
  }
  ...
}

Hopefully you can see the similarity between the 2 formats.

a = array
s = string
i = integer
i:0 = this integer has the value 0
s:8:"settings" = this string is 8 characters long and has the value settings

Assume I want to add some configuration to the term reference, how do I do that?

load the configuration for our field
- $field = field_info_field('field_tags');
update the configuration by adding the new configuration (which will be an array structured like allowed_values above*)
- $new_configuration = array( NEW CONFIGURATION );
- $field['settings'] += $new_configuration;
save the configuration
- field_update_field($field);

* Details about my new configuration:

    $new_configuration = array(
      'new_conf' => array(
        array(
          'newstate' => 'something',
        ),
      ),
    );

In case I want to do something a little more complicated, for a lot of fields, this might be the place to begin; it does the same but in a way that's easier to modify.

load the configuration for all fields
- $fields = field_read_fields();
narrow it down to looking only at the configuration for tags
- foreach ($fields as $field_name => $field) { if ($field_name == 'field_tags') { STUFFBELOW } }
update the configuration by adding the new configuration (which will be an array structured like allowed_values above)
- $new_configuration = array( NEW CONFIGURATION );
- $field['settings'] += $new_configuration;
save the configuration
- field_update_field($field);

Granting access

d7lise — Tue, 30 Oct 2012 12:00:30 +0000

Tags:

computers

drupal

Apart from the permissions system in Drupal, it is possible to implement a system based on grants. This relates nodes to realms (based on role, term references or other attributes related to users), granting (or denying) access. In the table node_access rows consist of 6 values, (nid, gid, realm, grant_view, grant_update, grant_delete).

E.g. (3, 5, 'superusers', 1, 1, 1).

If the user is trying to access node 3,
if the user is related to the realm superusers
with grant id 5,
then the user can view, update and delete the node.

E.g. (7, 4, 'mice', 1, 0, 0).

If the user is trying to access node 7,
if the user is related to the realm mice
with grant id 4,
then the user can view the node.

How exactly realms and grant ids are used, depends on the module using it.

http://api.drupal.org/api/drupal/modules!node!node.api.php/function/hook_node_grants/7

An example: The ABT module

I create a taxonomy, or use the existing taxonomy tags.
I create a content type, with a term reference to this taxonomy.
While saving this field, I will be asked further details about this field.

Likewise, I add a field to the user profile, a term reference to the same taxonomy.

I create some content in my new content type, and add a tag.

I create a new user, and add the same tag.
Now node_access looks like this:

The new table abt_map will now look like this:

How did ABT do it?

there's more info in abt_map
the gid in this case is the same as the tid / term id for the term in question ("testterm")
the realm is named after the module (abt) and the field (field_termref)

What about a hierachy?

Example: term "Europe" is above term "Denmark"
user is related to "Europe"
node is related to "Denmark"
then the user has access to the node
(the other way around doesn't work, as it probably shouldn't)

What about a combination of tags?

content (jeans) and users are tagged with languages and brands
specific pair of jeans: German Calvin Klein
if user is tagges with either "German" or "Calvin Klein", there is access

An example: The Taxonomy Access Control module

I use the taxonomy called tags.
I create a content type, with a field referencing this taxonomy.
I create content with a term for this reference ("version1.0").
I create a role called "mayversion1.0".
I configure Taxonomy Access Control:
- Authenticated users get a new row, based on the term, with deny in all 3 columns.
- mayversion1.0 users get a new row, based on the term, with allow in all 3 columns.
- (When 2 different roles say allow and deny, allow wins.)
I create a new user. It is related to the role mayversion1.0.
This new user can access my content.

How did TAC do it?

there's more info in taxonomy_access_default:

and taxonomy_access_term:

the gid in this case is the same as the rid / role id for the role in question:

the realm is named by TAC, "taxonomy_access_role"
role 1 = admin, role 2 = authenticated user, role 4 = mayversion1.0
node 3 = my content
vocabulary 0 = tags

What about a hierachy?

Example: term "Europe" is about term "Denmark", and were so when TAC was configured
role is related to "Europe"
node is related to "Denmark"
then the user has access to the node

The module Workbench Access does not use node_access. Also, it only controls create/edit rights, not view rights. Video.

Note:

Term access only exists in a development version.
Content access only exists in beta.
Nodeaccess only exists in a development version.
Taxonomy access control lite only exists in an "other" version.
Access control kit only exists in a development version.
Menu access is only for drupal 6.
Taxonomy Access Control is minimally maintained.

Basic Drupal module building

d7lise — Fri, 14 Sep 2012 15:22:27 +0000

Tags:

computers

drupal

Learned from

http://buildamodule.com/video/drupal-7-development-core-concepts-welcome-to-module-building-our-module-recreated-in-2-minutes-and-next-steps

cd sites/all/modules
mkdir <modulename>
cd <modulename>
edit <modulename>.info
- name
- description
- package
- core
- files[]
edit <modulename>.module
- edit function <modulename>_menu() (creates URL)
- add “$items['<modulename>-<something>']”
- add “page callback = '<modulename>_<something>' “
- edit function <modulename>_<something>()
- return content to be shown on screen
enable module
go to <drupalsite>/<modulename>-<something>

Learned from

http://buildamodule.com/video/drupal-7-development-core-concepts-how-to-build-module-scaffolding-setting-up-the-module-file-structure etc.

http://buildamodule.com/video/drupal-7-development-core-concepts-how-hooks-work-and-how-to-use-them-what-hooks-are-and-a-demo-of-our-final-module etc.

edit <modulename>.info
- ; $Id$
- configure = admin/config/<modulename>
- dependencies[] = <some_other_module>
edit <modulename>.module
- // $Id:$
- Info about file
  - /**
  - * @file
  - * <text>
  - */
- Info about functions
  - /**
  - * Implements hook_menu().
  - */
- Content in <modulename>_menu()
  - $items['admin/config/<modulename>']
  - 'page arguments' => array('<modulename>-<stuff>')
  - <modulename>-<stuff>()
edit README.txt

Example:

example.info:

; $Id$

name = example
description = Example module
core = 7.x

example.module:

<?php
function example_menu(){
$items['example'] = array(
    'title'            => t('Example module'),
    'page callback'    => 'example_output',
    'access arguments' => array('access content'),
);

return $items;
}

/*
* Display output
*/
function example_output() {
return 'This is an example';
}

Other cool stuff

example.admin.inc: contains code needed for administration and configuration, is not needed on every page load.
white screen of death: tail /var/log/apache2/error.log (or something similar)
where is the tmp directory? check admin/config/media/file-system (d7)
when defining a page / menu item, a lot of times you don't define "access callback", so "user_access" will be called by default

This module is not perfect for me, what do I do?

The changes are very specific to us: Find the right hook, and create an extra module using that.
The changes are generic: Patch the module and upload the patch to drupal.org
I have a lot of time on my hands, and this module is important to me: Become a maintainer.
75% functionality needs to be added, and I don't care about maintenance of the 25% already there: Make a copy of the module.

Choices:

for menu types: menu.inc (Constants)
for user access modes: user permissions
if function 1 exists, function 1_2 will be searched for automatically:

Drupal

d7lise — Wed, 08 Aug 2012 12:40:19 +0000

Tags:

computers

drupal

Windows:

Ubuntu:

Getting Started with Drupal 7 Tutorials

Setting Up a Wiki in Drupal 7

Before updating module or core:

How can I backup my database or table?
Backup root directory (e.g. with Filezilla)

Updating core:

Update Drupal Core
Remember sites and modules.

The manual way:

cd sites/all/modules
# backup old module
tar cvf DATE.tar MODULE
(find PATH to new version of module on drupal.org)
# get new module
wget PATH
through site:
# backup database
- Configuration / System / Backup and Migrate / Do backup
# go into maintenance mode
- Configuration / Development / Maintenance mode / Switch on
# move old module away
mv MODULE MODULE.tmp
# unpack new module
tar xzvf MODULE-NEW.tar.gz
through site:
# do update related to new module
- Configuration / Development / Maintenance mode / Update script
# leave maintenance mode
- Configuration / Development / Maintenance mode / Switch off
check that everything is running
# delete the temporary file
rm MODULE-NEW.tar
# delete old module
rm -r MODULE.tmp
# move the backup away
mv DATE.tar ~/backup

Multi-site functionality:

(Place copies of default in the folder below MAIN drupal, not any other sites, that may be located differently.)

REST server:

How to create test_endpoint

CKEditor for Drupal 7 Installation Process

Install CK Editor in Drupal 7

How to delete all unpublished comments?

* Basic Drupal module building

* Configuring fields

* Features

* Granting access