Joomla và Drupal

Titles


Cập nhật cho Drupal

posted May 2, 2012, 6:29 AM by admin@ revitviet.vn

1 link duy nhất: http://drupal.org/upgrade

Move Drupal site from local host to webhost

posted Oct 24, 2011, 1:05 AM by magic stone   [ updated Oct 24, 2011, 1:43 AM ]

1. Disable Clean URLs

2. Clean logs and stuff (Administer / Site config / Error Reporting)

3. Make sure the temporary files folder is configured correctly (Administer / Site config / File system)

4. Upload all files to my new webhost via FTP

5. Edit settings.php and insert new Mysql user/pass for the new server

6. Export the data from local server

7. Import on the web server

9. Logon to the new site, enable Clean URLs again and check everything.
    Troubleshooting:
On D7, before moving to drupal to an other location, I disabled "clean url"
But no, it is not possible to re-enable it :
even with javascript disabled, the checkbox doesn't appear, only the button "trun the clean url test".
  Solution:
Solution is simple: to uncomment the .htaccess
line 104 (in D7.7) RewriteBase /

========================
Comments

The problem was that Clean URLs module was enabled. I should have disabled this before copying the database. To solve the problem, on the new site clone site, I typed

www.sitename.com/?q=user/login

This allowed me to log in as the admin.

Then I got the url for the Clean Url module and repeated as above. Thus I now had

www.sitename.com/?q=admin/settings/clean-urls

I was now able to disable Clean Urls and everything is working now!

Disable Clean URLs in database

1) Open phpmyadmin and select your database.
2) Browse on "variable" table and find the name "clean_url"
3) Change the value from s:1:"1"; to s:1:"0";
4) Run the mysql command "DELETE FROM cache;"

Disabling Clean URLs

Add this line to the end of settings.php

<?php
$conf
[ 'clean_url'] = 0;
?>

Cach

Run the mysql command "DELETE FROM cache;".


Adding a related content view in Drupal 7

posted Oct 21, 2011, 5:21 AM by magic stone

The most gracious commenter "nordic material" provided working instructions for performing this task using Views 3 in D7. I just went through the directions and they work perfectly. Below is a recap. Thanks again Nordic Material!

  1. Create view (block)
  2. Add fields (title, a small image, date, whatever you like). Or teasers, what works as well.
  3. "Arguments" is from now on called "Contextual filters", so go there.
  4. Add the filter: "Content: Has taxonomy term ID"
  5. Configuration on this filter: -> When the filter value is NOT in the URL: -> Provide default value -> Type: Taxonomy Term ID from URL -> under that, check the box "Load default filter from node page, that's good for related taxonomy blocks." -> now check the boxes of the taxonomies you want involved here
  6. Now you need to add the second filter in order to exclude the current node from the list. Click [+] button of the contextual filters section.
  7. Select Content: Nid
  8. Set the 'when argument is not present' to 'Provide default argument'
  9. Set the 'Default argument type' to 'Content ID from URL'
  10. Go to "MORE" , and check the "Exclude" box.
  11. Add a block to your view and embed the block on your node pages
  12. Save your view

How to Patch a Drupal Module on Windows

posted Oct 13, 2011, 7:13 AM by magic stone

If you use Drupal on a regular basis, chances are that you will want to apply a patch to a module at some point in time. Perhaps somebody has posted a patch in the issue cue that sounds like it will address a problem you are having. Patching files on windows is simple. Just follow these steps.

1. You will need to download the patch software. You can download the Patch program athttp://gnuwin32.sourceforge.net/packages/patch.htm

2. Run the setup file and install the program using all of the default settings.

3. Get a local copy of the file you wish to patch. Either pull down the file from your web server using an FTP client, or just download the module form the drupal project page.

4. Open up a windows command prompt by going to Start->Run and typing "cmd" and hitting enter.

5. Change directories to the GNU Patch program directory using the command prompt by typing the command "cd C:\Program Files\GnuWin32\bin" (no quotes)

6. Place the file that needs patching inside this same folder. For example, if you wish to patch the file views.module, place this file inside the folder at C:/Program Files/GnuWin32/bin

7. Using the command prompt, type the command "patch < NameOfThePatchFileYouDownloaded --binary" (no quotes). For example, if the patch file you have downloaded is named "edit_form.patch" you would give the command "patch < edit_form.patch --binary" but without the quotes. The --binary can be very important on a windows machine. On MS-Windows, the patchfile must be a text file, i.e. CR-LF must be used as line endings. A file with LF may give the error: "Assertion failed, hunk, file patch.c, line 343," unless the option '--binary' is given.

8. Once the file is patched you may upload it for testing.

Sorry, there have been more than 5 failed login attempts for this account. It is temporarily blocked.

posted Sep 7, 2011, 1:31 AM by magic stone

Drupal 7 prevents brute force attacks on accounts. It does so by refusing login attempts when more than 5 attempts failed. The amount of failed logins is recorded in the table 'flood'. You can either wait before trying to login again or clean the flood table with the procedure below.

If you forgot your password, generate a new password and update the database.

Execute the following query on the Drupal database:

DELETE FROM `flood`;

To execute this query it will be necessary to login to the database. This is typically done through the command line or through a GUI interface such as phpMyAdmin.

From the command line, with drush installed:

drush php-eval 'db_query("DELETE FROM `flood`");'

Thiết kế website động với mã nguồn Drupal 7 – phần 4

posted Sep 4, 2011, 11:46 PM by magic stone

Với tính năng Article trong Add content thì việc viết bài cho website Drupal 7 gặp rất nhiều khó khăn, bởi vì không có các công cụ soạn thảo trong khung Body. Bên cạnh đó, các nội dung trên website Drupal 7 được đối xử như nhau (được xem là một node) không phân biệt chủ đề hay nhóm chuyên mục. Phần này sẽ giới thiệu một số gợi ý về cách tạo thêm thanh công cụ soạn thảo văn bản, tổ chức và phân loại nội dung, …


7. Cài đặt và thiết lập trình soạn thảo TinyMCE
 

            Đầu tiên, bạn cần truy cập vào địa chỉ http://drupal.org/project/wysiwyg để tải về module Wysiwyg. Chức năng của module này là cho người dùng thấy ngay những thay đổi đối với những thao tác mà họ đang thực hiện. Khi trang hiện ra, bạn kéo thanh cuộn của trình duyệt xuống đến mục Download rồi bấm vào liên kết Zip (149,02KB) ở phiên bản 7.x-2.0. Sau đó, bạn tiến hành giải nén và sao chép vào thư mục modules (đường dẫn htdocs/news/sites/all/modules).


Bạn quay trở lại trình duyệt và bấm vào menu Modules trên thanh công cụ quản trị hoặc truy cập vào đường dẫn http://localhost/info/#overlay=admin/modules rồi kéo thanh cuộn đến cuối trang, đánh dấu chọn vào ô trước tên module Wysiwyg, bấm Save Configuration để bắt đầu tiến trình kích hoạt. Bạn có thể bấm vào liên kết check manually để đảm bảo hoàn tất cho quá trình cập nhật.

Sau khi kích hoạt xong, bạn trở xuống module và bấm vào Configure ở cột Operations. Ở trong khung Installation Instructions là danh sách các trình soạn thảo và trạng thái cài đặt của chúng. Danh sách này gồm có CKEditor, FCKeditor, jWYSIWYG, markItUp, NicEdit, openWYSIWYG, TinyMCE, Whizzywig, WYMeditor, YUI editor. Bạn có thể chọn cho mình một trình soạn thảo vừa ý trong danh sách này. Trong mục này, tác giả chọn trình soạn thảo TinyMCE để minh họa cách cài đặt.

            Bạn truy cập vào trang chủ http://tinymce.moxiecode.com của TinyMCE để tải về phiên bản mới nhất. Tại thời điểm của bài viết, bạn có thể tải phiên bản TinyMCE 3.4.2 tại địa chỉ này. Sau khi tải về, bạn tạo thư mục libraries trong thư mục all (htdocs/news/sites/all) và giải nén thư mục tinymce vào thư mục mới vừa tạo.

Bây giờ, bạn vào lại phần cấu hình của module Wysiwyg để tiến hành kích hoạt sử dụng trình soạn thảo TinyMCE  trên các định dạng văn bản (truy cập nhanh qua đường dẫn: http://localhost/info/#overlay=admin/config/content/wysiwyg). Trong cột Input Format có ba định dạng Filtered HTML, Full HTML, Plain Text, bạn bấm chuột vào ô tương ứng ở cột Editor để chọn sử dụng TinyMCE, xong bấm Save.
Để thiết lập các tính năng của TinyMCE, bạn bấm Edit ở cột Operations sau khi đã kích hoạt sử dụng. Bạn giữ mặc định các thiết lập ở mục Basic Setup. Đối với mục Button and Plugins, bạn đánh dấu chọn vào các nút lệnh cần hiển thị trên thanh công cụ soạn thảo văn bản. Chẳng hạn như: Bold, Italic, Underline, Align right, Justify, Copy, Paste, Cut, Image, Link, Font, Font size, Font style, HTML block format, Table, Media,…
Ngoài ra, bạn còn có thể tùy chỉnh về cách hiển thị của các nút lệnh trên thanh công cụ. Ở mục Editor Appearance, bạn chọn vào các trường để thay đổi Toolbar location- vị trí hiển thị thanh công cụ, Button Alignment- canh chỉnh các nút lệnh và đánh dấu chọn vào ô Enable resizing button để kích hoạt tính năng thay đổi kích thước nút lệnh. Khi xong, bạn bấm Save.
Để kiểm tra kết quả cài đặt, bạn bấm Add content rồi chọn Text Format dạng Full HTML ở trang hiện ra. Nếu xuất hiện thanh công cụ bên dưới chữ Body thì bạn đã cài đặt và thiết lập thành công.


8. Tổ chức nội dung và tạo thêm kiểu nội dung mới

            Module Taxonomy là một công cụ mạnh mẽ cho phép người quản trị web tổ chức, phân loại nội dung. Module này đã được tích hợp sẵn vào nhân của Drupal 7 và đã kích hoạt trong quá trình cài đặt. Trước khi sử dụng Taxonomy, bạn cần cài đặt thêm module Taxonomy Menu (module giúp cho việc sử dụng Taxonomy thuận tiện hơn) bằng cách vào địa chỉ http://drupal.org/project/taxonomy_menu, rồi tải về và giải nén vào thư mục modules trong thư mục info/sites/all, kích hoạt sử dụng modules.

Để khai thác tính năng của Taxonomy, bạn bấm vào menu Structure trên thanh công cụ quản trị, rồi bấm Taxonomy trong trang hiện ra.

Đối với Taxonomy, bạn cần quan tâm đến hai đối tượng VocabularyTerm. Có thể hiểu, Vocabulary là nhóm chuyên mục và Term là chuyên mục con thuộc một nhóm chuyên mục nào đó. Ví dụ: bạn cần tạo các nhóm chuyên mục: Phần mềm, Thiết bị số. Các chuyên mục con thuộc Phần mềm là: Văn phòng, Hệ thống, Bảo mật, Đồ họa, Internet; và thuộc Thiết bị số là: Laptop, Desktop, Tablet, Camera. Dạng cây thư mục:

- Phần mềm

            - Văn phòng

            - Hệ thống

            - Bảo mật

            - Đồ họa

            - Internet

- Thiết bị số

            - Laptop

            - Desktop

            - Tablet

            - Camera

            Khi đó, bạn bấm Add vocabulary để tiến hành khai báo nhóm chuyên mục. Trong trang hiện ra, bạn nhập Name- tên nhóm chuyên mục (ví dụ: phanmem), Description- chú thích, chọn Main menu ở mục Menu location, bấm Save. Thực hiện tương tự cho các nhóm chuyên mục còn lại.

Bạn trở lại trang quản lý nhóm chuyên mục (Vocabulary), bấm vào liên kết add terms để tạo chuyên mục con. Tiếp theo, bạn nhập vào các ô Name- tên chuyên mục (ví dụ: Văn phòng), Description- chú thích, URL alias- địa chỉ liên kết ảo do  bạn tự quy định (Drupal cũng tạo một địa chỉ liên kết khác). Riêng đối với mục Relations, bạn chọn chuyên mục chính (root) hoặc chuyên mục con thuộc chuyên mục chính (nếu có) tại ô Parent terms, thứ tự sắp xếp tại ô Weight, bấm Save. Thực hiện tương tự cho toàn bộ các chuyên mục con còn lại.

Khi đã tạo xong các nhóm chuyên mục thì bạn cần phải tạo thêm kiểu nội dung mới tương ứng với các nhóm chuyên mục đó. Bởi vì, kiểu nội dung Article sẽ tạo ra các Tags và không phụ thuộc vào các nhóm chuyên mục đã tạo. Để thực hiện, bạn vào menu Structure, bấm Content types rồi bấm Add content type.
Trong trang Content types, bạn điền các thông tin: Name- tên nội dung (ví dụ: phanmem), Description- chú thích và giữ mặc định các thiết lập bên dưới, rồi bấm Save and add fields. Tiếp theo, ở thẻ Manage Fields có hai trường Title Body được cung cấp sẵn, bạn cần thêm vào các trường mới như tagpm, imagepm. Bạn thực hiện: nhập tagpm vào ô Add new field, thứ tự ở cột Weight, tên trường ở cột Name (ví dụ: tagpm, có dạng field_tagpm), chọn Term reference ở cột Field, chọn Check boxes/ratio buttons ở cột Widget, bấm Save.

Ở thẻ Field settings, bạn chọn nhóm chuyên mục tại mục Vocabulary, bấm Save field settings. Đến thẻ Edit, bạn nhập tên trường vào ô Label (ví dụ: Phần mềm), đánh dấu chọn vào ô Required field, nhập vài gợi ý vào khung Help text. Nếu không muốn khách truy cập website nhìn thấy các chuyên mục ở cuối bài viết thì bạn cần ẩn nó đi, bằng cách trở về khung quản lý Content type, bấm manage display ở kiểu nội dung muốn thay đổi. Ở cột Format của trường Field, bạn chọn Hidden rồi bấm Save.

Bây giờ, bạn có thể kiểm tra sự hiển thị của các chuyên mục ở khung viết bài, bấm Add content rồi chọn kiểu nội dung cần viết bài.

Sau khi đã phân loại nội dung và tạo kiểu nội dung mới, bạn có  thể tạo ra menu để giúp cho khách truy cập định hướng được nội dung trên website.


9. Quản lý bài viết và bình luận

            Tính năng Content giúp cho người quản trị quản lý nội dung trên website (quản lý bài viết, quản lý bình luận). Để sử dụng tính năng này, bạn bấm vào menu Content trên thanh quản trị hệ thống. Thẻ Content cung cấp  ba khung: ở dưới cùng là danh sách các bài viết (gồm có tên, kiểu nội dung, tác giả, tình trạng, cập nhật), khung Show only items where là một bộ lọc giúp tìm kiếm nhanh bài viết (theo hai kiểu lọc: Status- tình trạng bài viết, Type- kiểu nội dung) và khung Updates Options.

Riêng đối với khung Update Options, bạn có thể cập nhật cho hàng loạt bài viết với các nội dung cập nhật như Update URL alias- cập nhật địa chỉ liên kết mới (khi đã cài đặt xong module Pathauto- sẽ được giới thiệu ở phần sau), Publish select ed content- đăng bài viết, Unpublish selected content- không đăng bài viết, Delete selected content- xóa các bài viết đã chọn,…

            Thẻ Comment giúp quản lý nội dung bình luận của các thành viên gửi đến. Nếu người quản trị thiết lập chế độ kiểm duyệt nội dung bình luận đối với thành viên (bỏ tùy chọn Skip comment approval đối với nhóm Authenticated user) thì các ý kiến gửi đến sẽ nằm trong mục Unapproved comments. Để đăng tải các ý kiến bình luận, bạn đánh dấu chọn vào ô phía trước ý kiến và chọn nội dung cập nhật Publish the selected comments, bấm Update.



Nhật kí cho revitviet một drupal site.

posted Sep 4, 2011, 12:04 AM by magic stone   [ updated Sep 4, 2011, 6:09 PM ]

  1. Cài đặt Drupal 7 trên local host.
  2. Cài đặt theme:
    • Fusion theme
    • Mix and Match
  3. Cài đặt các module cần thiết.
    1. Administration menu
      • Để bỏ chọn menu của hệ thống: Modules -> List -> Bỏ chọn mục Toolbar.
    2. Chaos tool suite (ctools)
    3. entity
    4. Views Bulk Operations (VBO)
    5. Superfish (Lưu ý phần installation guide và làm theo từng bước chỉ dẫn trong đó)
    6. CCK
    7. ckeditor
    8. libraries
    9. panels
  4. Thiết lập hệ thống menu.
    • Tạo hệ thống main menu (Structure -> Menus -> Main menu)
    • Gán hệ thống menu đó cho Superfish menu  ( Tham khảo thêm ở đây)

Drupal 7 Tutorial Part 10: Advanced Drupal 7 menu settings, how to create parent child menus, node menu settings.

posted Jun 28, 2011, 12:41 AM by magic stone   [ updated Jun 28, 2011, 12:53 AM ]

Hi Drupalers,

Till now we saw various menu related concepts in Drupal 7. It's time to learn some advanced settings. In this tutorial we are going to learn following concepts.

  • Drupal 7 global menu settings.
  • How to create hierarchy of menu (Parent / child) links.
  • Node Specific menu settings.

Global Menu Settings:

             In drupal 7, special settings are available for menus. Basically using these settings we can change the menus for Main Links & Secondary links in the default theme. Main Links & Secondary links positions are shown in the below screen.


  • Login as administrator, click on Structure link on top black menu, and then menu link. You will see screen like below.
  • Click on settings tab next to list menus tab in above screen to access menus global settings page. Once you click on settings tab, you will see screen like below.
  • As you see in above screen, you can set source for Main links and secondary links section. By default, Main Menu is used for main links section and user menu is used for secondary links sections.
  • You can change the menus for main, secondary links sections using this form.
  • You can pick any menu for main or secondary links sections from all available menus.
  • To see this settings in action let's interchange the menus for these sections. Let's select user menu for Main links and Main menu for Secondary links and click on save configuration button.
  • If you go to home page you will see something like below screen.
  • As you see in above screen, after saving menu settings you can observe main links menu section is showing user menu and secondary links section is showing main menu. So basically using above settings you can configure different menus for main links and secondary links menu placeholders.

How to create hierarichal menu (Parent / child) links ?

  • Till now we created only one level of menus. It's time to create hierarichal menus or menus with parent child links.
  • We are going to add some hierarichal links to the menu we created previously in this tutorial.
  • Access the links of menu links that we created earlier in the above mentioned url.
  • To access the list click on structure link in top menu black navigation bar after logging as admin. Then, click on menus link in the popup. In the menus listing page click on list links link next to Administration shortcuts menu that we created here. You will see page like below.

 

  • Let's now add a menu link called add new block as a child of Blocks listing page link in the above administration shortcuts menu.
  • First let's create the menu link Add new block and link it to admin/structure/block/add .
    Todo this click on Add link + icon in the above screen.
  • Then fill the add link form as show in below image and click on save.
  • Once you click on save new menu link is created for Administration shortcuts menu and now its time to associate parent menu child relationship. Once menu link is saved you will see screen like below.

  • Now move your mouse to + icon infront of Add new block link in above screen, Then click and hold right mouse button and drag the link above user listing below blocks landing page and then without leaving right mouse button again drag the link to right side.
  • Once you drag the link to right of some link the link will become child of above link. Once you do as mentioned above you will see screen exactly  like below.
  • Now click on save configuration button to save the link and order. We created a child link called add new block which has parent blocks landing page.
  • Unfortunately there is a core bug in drupal 7 which prevents rendering parent child relationship in a proper format for custom menus. For more details follow this link. http://drupal.org/node/942782
  • Once above bug is fixed you will see something like in comment # 17 first image in the above link. I will keep you update regarding this.

Node Menu Settings:

  • A menu item link for a node can be directly created from the node edit page using menu settings for node.
  • Node menu settings gives you option to select the menu where that particular node link appears as a menu item.
  • Let's get into the action to test this feature.
  • Goto any node edit page. Let's say node/2/edit page. You will see screen like below if you already created a node.

 

  • You can see a check box in the menu settings tab which gives you option to create a menu link for the node that you are editing.
  • Check this link to see more settings. Once you check this link you will see screen like below.
  • Now leave the title as "Article One". Add description saying "My First Article" and click on save link to create a menu link in the main menu Menu. Once you save the settings you can see menu link appearing in the main menu as shown below.

 

  • So now we created a menu link for node directly from node edit page.

 

Stay tuned with me to learn Drupal 7.

 

Cheers,

AnilSagar.

How to Make Changes to a Drupal Theme

posted Jun 23, 2011, 9:00 PM by admin@ revitviet.vn

In this sub-tutorial I’ll be showing how to locate places in your theme’s files controlling different aspects of a Drupal page, how to experiment interactively with changes, and how to finalize those changes. If you are just starting with my tutorials, and new with Drupal, I suggest you visit the link above, it goes to where I give an overview of Drupal customization.

Step Zero: Having a Theme you are Ready To Modify
This is a step by step tutorial, so you should have Drupal installed, and either a contributed theme downloaded from Drupal.org installed that supports local changes, or you’ve created your own sub-theme that is waiting for base theme overrides to create your final theme. If you are unclear what I’m talking about, check out the previous sub-tutorials in this series.

Step One: Getting Your Tools and Workspace Setup
The best method I’ve found for interactive Drupal theme modification uses the Firefox browser and its Firebug plugin. If you do not already have these tools installed, download and install them now.

Since we’ll be working in Firefox, get it running and loaded with a page of the Drupal site using the theme you are ready to modify.

Depending upon your familiarity with CSS, in another Firefox tab you may want to load http://www.w3schools.com/css/ for quick reference.

Next, you will need a text editor opened with one of two possible files:

  • If you are modifying a theme that supports local changes, you should have your theme’s “local.css” file loaded and ready for editing;
  • If you are working in your own sub-theme, you should have your sub-theme’s overriding CSS file loaded;
  • If you do not fit one of these situations, you should read my description of the choices for Drupal theme modification.

Next, because we will be making changes to aspects of a theme that may be cached by Drupal, in yet another Firefox tab, load up the performance page of the site you are modifying:

 
admin/settings/performance

On the performance settings page, make sure Caching mode is disabled, Block cache is disabled, and may as well disable both Optimize CSS files and Optimize JavaScript files. The last two should not matter, but with them disabled, they are removed from any possible suspicion during bug hunts. Make sure you click the Save configuration button after making any changes to the page, and then return to the bottom of the page and click the Clear cached data button.  I’m pretty sure saving a new configuration will clear the cache, but clearing the cache explicitly can’t hurt.


Firebug Icon
Check the bottom right of your Firefox browser window for the above icon. That icon appears when you have Firebug installed and activated. If you don’t see that, you should visit Firebug’s FAQ, covering installation and general usage. It probably wouldn’t hurt for people new to Firebug to load that page into another Firefox tab for reference.

Step Two: Using Firebug to find a place you want to change
As an example case, we’ll look at a few changes I did to the Garland sub-theme I created for this web site. One of the first changes I wanted over Garland’s default was a different text color for the content of main articles, (the text used to display nodes.) The text color in Garland is not black; it is medium gray. Text in a medium gray yields a softer appearance, where I would like a crisper, stronger appearance. I would like the font to be black.

In order to figure out what to change to accomplish my text color change, click the Firebug icon at the bottom right of the Firefox browser window. That will cause the Firebug icon to become color, as well as a new sub-window to take over the bottom portion of the browser window. Next, click on the highlighted icon shown below:


Activating Firebug's Element Inspector

That icon enables Firebug’s Element Inspector. Now as you move your mouse over the Drupal page, you will see blue rectangles outline each element as your mouse passes over. Additionally, the left and right portions of the Firebug sub-window update:


Using firebug's Element Inspector to examine the text on a page

While using the Element Inspector, the left side of the Firebug sub-window shows the current page’s HTML, with the HTML markup generating the blue outlined element also highlighted in blue. On the right side of the Firebug sub-window is the CSS code controlling the display of the highlighted page element. There is some additional very useful information here, so I’ve identified more key places for you:


Key information given by Firebug's Element Inspector

On the right side of the above Firebug sub-window, outlined in purple are two places where Firebug gives the line number and CSS filename controlling the highlighted page element. This right side is a hierarchical display, with the top CSS element being the “leaf” CSS declaration affecting the selected page element. Each CSS declaration moving down in the right handed side of Firebug’s display is the parent CSS declaration of the CSS element above; together the entire vertical series of CSS declarations is the CSS hierarchy affecting the selected page element.

On the left side of the above Firebug sub-window is outlined in orange where Firebug shows the nesting of CSS and HTML elements for the selected page element. Not to be confused with the hierarchy of the CSS definition, this is the nesting of HTML and CSS on the web page, showing you how the HTML references the CSS used to create the page.

To help illustrate the nesting of the CSS elements, here is what Firebug gives for the above:

 
p < div.help < div.left-corner < div.right-corner < div#squeeze …

This tells you that for the selected page element (in my case, the main text of a Drupal page):

  • The inner most controlling tag is a “p” tag,
  • The next inner most controlling tag is a “div” tag with a class of “help”,
  • The next inner most controlling tag is a “div” tag with a class of “left-corner”,
  • The next inner most controlling tag is a “div” tag with a class of “right-corner”,
  • The next inner most controlling tag is a “div” tag with an id of “squeeze”.

This information is useful to create nested CSS declarations that only affect the CSS used on a specific page. We’ll get to use such information a bit later. At the moment, we’ll focus on a simple change, changing the font color.

Looking back at the right side of the Firebug display, there are two CSS elements controlling a node’s main text: the CSS declarations for the “p” and “body” tags:


Firebug showing the color defined by a CSS declaration

As you move your mouse over the body tag’s color definition, you’ll notice hovering over a color declaration causes a small rectangle filled with the same color to popup as visual reference. Likewise, you can click on any of the CSS commands or parameters and make changes. You can click on a single parameter, and once your edit cursor is beating on that parameter, the up and down keys increment and decrement the parameter – if the parameter is numerical, it adds and subtracts one to the parameter; if the parameter is text, up and down keys move you through a list of possible parameter values. You can also right-mouse-click over a CSS declaration and get more editing options. As you make modifications, the web page updates automatically to show the result of the changes. If you are not in awe over this, you have not been working with technology long. This is so useful, I’m surprised someone has not claimed patent ownership and wrapped this up behind paywalls!

Step Three: Creating Overriding CSS to Change the Theme
Continuing with the goal of changing the font color, we can see from the above that our main content’s font color definition is on line 15 of the file “style.css”. However, in my theme I have no “style.css” file – that file is in my base theme’s directory. It is one of the inherited properties from my sub-theme’s base theme.

When working in a theme that supports local changes, the situation is very similar: the originating definition lies in a file other than the “local.css” file all your changes should be placed.

In order to override the color definition, I used the following:

a) Inside my theme’s “GarlandSub.css”, I entered the following at the bottom of the file:

 
/* making node font black: */ 
body {
  color: rgb(0,0,0);
}

b) Saving the above, I return to the web browser and click the “refresh” button to reload the same web page. Sure enough, the text is now darker!

c) If you are following these steps and the web page refreshes to the same font color as before, revisit the other tirefox tab where I suggested you keep admin/settings/performance loaded, and click the Clear cached data button at the bottom of the page. Now try refreshing the web page again to check if the text color changed.

d) If you are still not seeing the correct text color, try re-enabling Firebug’s Element Inspector and mouse over the element you are trying to change; in my case it is the text in a typical Drupal page.


Firebug showing the new CSS, overriding the previous color declaration in another file

You can see in the above image how my new CSS is working: there is now a new overriding “body” tag being used, from the file “garlandsub.css”, and it defines the text color as all zeros – which is the color black.

If you are not seeing something similar, then your CSS change is not being recognized and picked up…

Before resorting to “drastic measures”, verify the theme you are trying to change is the current default and enabled theme at admin/build/themes. Also verify that you are editing the correct CSS file. Once again, try the browser's refresh button to reload the Drupal page and see if your change is being picked up.

e) If that still is not showing you the changed color, try clearing your web browser’s cache. I hate going to that extreme, because any web site’s I’m logged into gets their session ids cleared, and I need to re-login.

f) No doubt, some of you will still not see the desired CSS change, even after verifying and re-following the steps. There are more steps you can take to track down the cause of your changes not being picked up, but that detours the tutorial into a troubleshooting guide. Expect another tutorial soon covering additional steps. (Hint: try other browsers and the Firebug Lite java script file.)

A quick summary of the key steps involved in modifying one element in a theme's CSS:

First identify the CSS controlling the element you want to change with Firebug’s Element Inspector:


Firebug's Element Inspector icon

Next test the desired change by interactively modifying the selected element’s CSS via Firebug’s display of the selected element’s definition within its CSS hierarchy:


Firebug's interactive editing of a CSS declaration

Then create a new CSS declaration in your overriding CSS file; that file is named “your-theme-name.css” for those working with their own themes or sub-themes, and is named “local.css” for those working with a theme  supporting local changes:


New CSS placed inside the overriding CSS file

And finally, reload the web page containing the modified element(s), with possible cache clearing as necessary to see your intended change.

The above steps work great in cases where the desired change  is universal, such as the color of text used for all nodes. However, the above is the rare case; more often the change needed is not universal, it is specific to one element on one page or one class of elements used in multiple pages, but not for all pages.

For the next example, I will show how the information Firebug provides on the left side of its sub-window can be used to solve the remaining cases not quite as simple as our first example. Keeping the complexity at minimum, the next change I will show is how to place a border around all inline images within nodes.

The first step in this new example is to either create or navigate to a page of my site where I have images both inline within a node’s content, as well as images not in a node’s content, such as in a block. My goal is to modify the display of all images inline to nodes, while leaving all other images alone. Finding such a page, I realize it has three different types of images: those inline in a node, images in blocks, as well as the web site’s logo image up in the page header.

The next step is to enable Firebug’s Element Inspector and take a look at our images:


(click to enlarge) Firebug's Element Inspector looking at the site logo in the page header


(click to enlarge) Firebug's Element Inspector looking at an image in a block

(click to enlarge) Firebug's Element Inspector looking at an image inside a node

Looking at the top left area of each image, where Firebug gives the nesting of CSS and HTML elements for the selected page element, you’ll see each image is described quite differently:

  • Web site logo: the “img#logo” left most tag is telling you the logo is inside an “img” tag with an id of “logo”; looking lower into the blue highlighted HTML, yes – you can see the HTML markup with an “img” tag followed by id=”logo”.
  • Sidebar-right block image: the left most tag is just a plain “img” tag, which is pretty generic. However, looking into the HTML of the page, we can see all sidebar blocks are enclosed within a “sidebar” class, and each block is enclosed within a “div” given a unique id. That can be used to target CSS image declarations specific to all sidebar images, or all sidebar-right images, or just the images inside a specific block. This is very similar to our goal, but we’re after images inside nodes…
  • Node image: the left most tag here is also a plain “img” tag, just like a block. Looking lower, into the HTML of the page I can see the blue highlighted “img” tag enclosed inside a “p” tag, with that “p” tag enclosed inside a “div” tag with the classes “content” and “clear-block”. The next enclosing tag is a “div” with an id set to “node-17” and a class of “node”.

Now we have all the information we need. We want to change how images are displayed for all nodes, and we just saw that Drupal places nodes inside divs with their id set to “node-number” and with a class of “node”. Loading up a few other nodes to verify, yes – Drupal always puts nodes inside divs with a unique-to-that-node id and a class of “node”.

Going back to our overriding CSS file, I create the following new declaration at the bottom of my GarlandSub.css file:

 
/* giving images inside node content a gray border: */
.node img {
    border: 1px solid #CECECE;
    padding: 3px; 
}

The portion of the declaration outside the curly brackets is saying: for all “img” tags inside elements with a class of “node”, use the CSS inside the curly brackets (in addition to any other CSS not overridden by these declarations.) The CSS inside the curly brackets is saying: for this element, use a 1 pixel, solid border with a color of #CECECE, and wrap that border around the element with 3 pixels of padding.

Saving my overriding CSS file, I reload the page… and there I see a nice border around my image, and the image in my block is unaltered, as well as my site logo image is unaltered. Navigating around the site to confirm, yes, this change is isolated to every inline image within a node, while all other images on the pages are unaltered.

As you can see, this is a very direct method of finding the controlling CSS of any page element. Once you have chosen the CSS change or addition, rather than making changes to the originating CSS, we add our changes to an overriding CSS file. Using this workflow, we ensure we can pickup future bug and security fixes for our theme or base theme.

Here is a final example demonstrating how to target a single block with a CSS modification. You probably noticed I have an Amazon ad for my favorite Drupal book in the right sidebar. Beneath the ad is some endorsement text I wrote, which I would like to have displayed with less space than normal between the lines. Remembering from the above examination of images inside a sidebar, I noticed each block receives a unique id; that unique id is what I will use to target my Amazon book ad.

With Firebug’s Element Inspector, I highlight my endorsement beneath the Amazon ad and look for the unique id defining my block:


Firebug's Elment Inspector showing the id & class used for a block

As shown above, the div id of the block is “block-block-1”. Since I’m creating a new CSS declaration, I just add this to my overriding CSS file:

 
#block-block-1 {
   line-height: 1.1em;
}

I added the above first with a value of “0.2em”; meaning use a line height equal to 20% of normal. That made my endorsement text appear all scrunched up on top of itself. With Firebug’s Element Inspector I am able to select that bad text and interactively find the line-height setting that looks most pleasing. Copying and saving the final value to my overriding CSS file, the modification is complete.

To facilitate targeting page elements, Drupal generates all elements in the following manner:

  • Class names are general, such as block, sidebar, sidebar-left, sidebar-right, and node
  • Div ids are specific, such as block-block-2, and node-23

This structuring of the tags on a Drupal page provides great control when modifying a theme. Additionally, the Views and Panels modules continue this naming pattern, enabling pages created by Views and Panels to enjoy easy theme modifications.

Optional Step Four: using additional modules supporting theme development
Of course, this only scratches the surface of the theme development techniques available in a Drupal environment. Several Drupal modules support advanced controls for theming, such as:

  • Theme Editor module: provides user interfaces for editing of CSS, “.info”, and template files within a Drupal site; great for people working with remotely hosted Drupal installations.
  • Skinr module: enables a theme to define a set of reusable and modular CSS styles, and make those styles available in Drupal's user interface.
  • Block Theme module: enables an admin to define template files for standard block templates and provides a selection box on the block configure form so the admin can select a template file to use as opposed to having to override the templates by block ID.
  • Themer module: provides controls to dynamically create customized body classes and more.
  • Theme Developer module: provides support for people writing their own template files by showing the template used to generate an element, plus additional features.

The above is just a sample of what is available. As you can see the more advanced theming options also provide support for template development and debugging. (A template file is a mixed PHP and HTML file, used by Drupal to generate the final HTML of a region.) I rarely have the need to modify template files, primarily because I’m more of a “coder” than a “themer”. However, understanding them is invaluable, and knowing when you need to operate at the template level can be essential for competent Drupal development.

We’ve covered a lot of information in this tutorial. If you are new to Firebug, I suggest you work with it for a while first, before you investigate the additional theming support modules I describe above. This concludes the "comprehensive" section of this tutorial on modifying a Drupal theme. Over time I will be adding super-brief tutorials covering useful CSS snippets, such as my first snippet covering how to remove the "homepage" field from the anonymous comment form. If you are interested in learning about the module development, PHP and Java Script side of Drupal, you may want to see my tutorials starting with how to insert and use PHP in your site's content.

If you have any questions or suggestions for how I can improve the above, please write a comment. Constructive comments will be followed as much as possible.

How to Decide Between Using Taxonomy Terms and a CCK Field to Classify Content on a Drupal Site

posted Jun 23, 2011, 9:51 AM by admin@ revitviet.vn   [ updated Jun 23, 2011, 10:00 AM ]

I often have a hard time deciding whether to use a CCK field or the taxonomy module when building Drupal sites. At Drupalcon, I was glad to see that I am not alone in my confusion. At the Drupalcon Drupal Taxonomy Revisted session, I finally started to understand the use case for each.

Here’s a table I put together to help me quickly decide whether to use taxonomy or CCK in the future.

Question Which to Use? Rationale
Do you have a lot of terms or attributes? As the size of your vocabulary or field option list grows, taxonomy becomes a better choice CCK stores its values as text while taxonomy stores values with an ID. This makes lookups over a large data set more efficient for taxonomy.
Are you using a hierarchy? Taxonomy Taxonomy is designed to handle multiple levels of hierarchy, which a CCK field is not
Are you listing attributes? For example, listing the color options of a car. CCK CCK makes more sense if you have created a content type and are adding attributes to it using CCK fields. For example, I could have a car node type and color would be a CCK field
Does your piece of content exist in the real world on its own? Taxonomy Taxonomy terms are designed to map to real-world objects in a way that CCK fields are not. For example, if I have a taxonomy of US States, each state exists whether or not I have assigned content to it.
Will you re-use your term or attribute in multiple ways within your site or re-organize them? Taxonomy If you have a classification such as US States that you plan to use in multiple node types, then taxonomy makes more sense. It is easier to add new terms to taxonomies over time than to individual CCK fields.
Are you using CCK or taxonomy to list critical information on your site? What is the cost of losing the data if you upgrade to a future major Drupal version? Taxonomy Taxonomy is more futureproof because each term has its own unique id, and, it can be moved between vocabularies. Taxonomy is also a Drupal core module and there will almost certainly be an easy upgrade path from Drupal 6 taxonomy to Drupal 7 taxonomy.

An Example: Classifying Topic Areas

Using this criteria, making the decisions I was stuck on in an earlier blog post becomes a lot easier.

Question Response Decision
Do you have a lot of terms or attributes? Yes, we have at least 200 terms and that number is likely to grow dramatically over the next few years. Taxonomy
Are you using a hierarchy? Yes, we have at least 3 levels of hierarchy. Taxonomy
Are you listing attributes? For example, listing the color options of a car. No, we are listing topics that span multiple content types. Taxonomy
Does your piece of content exist in the real world on its own? Somewhat. Greenhouse Gas Inventories exist in the real-world, as does the “Climate.” The category “Campus Operations” is more of a grey area Probably Taxonomy
Will you re-use your term or attribute in multiple ways within your site or re-organize them? Yes, we plan to classify many different node types with the same terms Taxonomy
Are you using CCK or taxonomy to list critical information on your site? What is the cost of losing the data if you upgrade to a future major Drupal version? It would be painful to lose all of our classification information but I don’t think that it would destroy us as an organization. CCK or Taxonomy

After evaluating which to use with my new handy chart, it’s clear the taxonomy makes more sense for classifying our topical areas.

1-10 of 28