Drupal
/
drupal
mirror of https://git.drupalcode.org/project/drupal.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Issue #1800178 by tim.plunkett: Move the documentation out of code and into the handbook.

8.0.x
Tim Plunkett 2012-10-01 16:16:12 -04:00
parent d4926f0b27
commit 39de66ccc2
118 changed files with 0 additions and 2963 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
D7UPGRADE.txt
View File

@ -1,2 +0,0 @@
Information about upgrading existing views from Drupal 6 to Drupal 7 is located
in the module's advanced help under api upgrading.

19
README.txt
View File

@ -1,19 +0,0 @@
Welcome to Views 3. Please see the advanced help for more information.
If you're having trouble installing this module, please ensure that your
tar program is not flattening the directory tree, truncating filenames
or losing files.
Installing Views:
Place the entirety of this directory in sites/all/modules/views
You must also install the CTools module (http://www.drupal.org/project/ctools) to use Views.
Navigate to administer >> build >> modules. Enable Views and Views UI.
If you're new to Views, try the Simple Views module which can create some
often used Views for you, this might save you some time.
Here you can find many modules extending the functionality of Views:
http://drupal.org/taxonomy/term/89

5
documentation-standards.txt
View File

@ -1,5 +0,0 @@
- If the interface text is *bolded*, it got strong tags.
- If it's a button they need to click, that's *bold* too.
- If the text is not bolded (ex: links to click, options to check), it
got /italicized/.
- If it's user-entered text it got 'single quotes'.

62
help/about.html
View File

@ -1,62 +0,0 @@
The views module allows administrators and site designers to create, manage, and display lists of content. Each list managed by the views module is known as a "view", and the output of a view is known as a "display". Displays are provided in either block or page form, and a single view may have multiple displays. Optional navigation aids, including a system path and menu item, can be set for each page-based display of a view. By default, views may be created that list content (a <em>Node</em> view type), content revisions (a <em>Node revisions</em> view type) or users (a <em>User</em> view type). A view may be restricted to members of specific user roles, and may be added, edited or deleted at the <a href="base_url:admin/structure/views">views administration page</a>.
For more technical users, views can be understood as a user interface to compose SQL-queries and to pull information (Content, Users, etc.) from the database and show it on a screen as desired.
The "building block" design of the views system provides power and flexibility, allowing parameters to be specified only when needed. While an advanced view may use all of available parameters to create complex and highly interactive applications, a simple content listing may specify only a few options. All views rely on a conceptual framework that includes:
<ul>
<li><a href="topic:views/field">Fields</a>, or the individual pieces of data being displayed. Adding the fields <em>Node: Title</em>, <em>Node: Type</em>, and <em>Node: Post date</em> to a node view, for example, includes the title, content type and creation date in the displayed results </li>
<li><a href="topic:views/relationship">Relationships</a>, or information about how data elements relate to one another. If relationship data is available, like that provided by a CCK <em>nodereference</em> field, items from a related node may be included in the view </li>
<li><a href="topic:views/argument">Arguments</a>, or additional parameters that dynamically refine the view results, passed as part of the path. Adding an argument of <em>Node: Type</em> to a node view with a path of "content", for example, dynamically filters the displayed items by content type. In this example (shown with Clean URLs enabled), accessing the view through the path "<em>http://www.example.com/content/page</em>" displays all posts of the type "page", the path "<em>http://www.example.com/content/story</em>" displays all posts of the type "story", and "<em>http://www.example.com/content</em>" displays all posts regardless of type) </li>
<li><a href="topic:views/sort">Sort criteria</a>, which determine the order of items displayed in the view results. Adding the sort criteria <em>Node: Post date</em> (in descending order) to a node <em>view</em>, for example, sorts the displayed posts in descending order by creation date </li>
<li><a href="topic:views/filter">Filters</a>, which limit items displayed in the results. Adding the filter <em>Node: Published</em> (and setting it equal to "Published") to a node view, for example, prevents unpublished items from being displayed</li>
<li><a href="topic:views/display">Displays</a>, which control where the output will be seen. Every view has a default display, which doesn't actually display the view anywhere, but is used to hold the default settings for the view, and is used when the view is called programmatically if another display is not specified. Much more useful to users are the <a href="topic:views/display-page">page</a> display, which gives a view a path and allows it to be the primary content of a page, or the <a href="topic:views/display-block">block</a> display which allows it to appear as secondary content on other pages.</li>
<li><a href="topic:views/header">Header</a>, which allow you to add by default one or more text area above the views output. </li>
<li><a href="topic:views/footer">Footer</a>, which allow you to add by default one or more text area beneath the views output. </li>
<li>The <a href="topic:views/footer">Emtpy Text</a> content will be displayed, when you choose in the Arguments Section "Action to take if argument is not present" the option "Display empty text".</li>
</ul>
Parallels between the components in the Views interface and an sql query:
<table>
<thead>
<tr>
<th>Sql Query</th>
<th>Views Component</th>
<tr>
</thead>
<tr>
<td>SELECT n.title, u.name</td>
<td>fields</td>
</tr>
<tr>
<td>FROM {node} n base table</td>
<td>view type</td>
</tr>
<tr>
<td>INNER JOIN {users} u ON n.uid = u.uid</td>
<td>relationship</td>
</tr>
<tr>
<td>WHERE n.status = 1</td>
<td>filter</td>
</tr>
<tr>
<td>AND u.uid = arg(1)</td>
<td>argument</td>
</tr>
<tr>
<td>ORDER BY n.changed DESC</td>
<td>sort</td>
</tr>
</table>

43
help/advanced-settings.html
View File

@ -1,43 +0,0 @@
In the category <strong>Other</strong> you have different options to set Advanced configurations in your View.
<strong>Machine Name:</strong>
You can change the default machine name of the view.
<strong>Comment: No comment</strong>
You can Use the comment option to write comments for your Views, the comments are only shown in the Views UI. Comment your Display for other Maintainer
<strong>Use AJAX: No</strong>
If set, this view will use an AJAX mechanism for paging, table sorting and exposed filters. This prevents the entire page from refreshing. It is not recommended that you use this if this view is the main content of the page as it will prevent deep linking to specific pages, but it is very useful for side content. Block displays require this setting to be ON if exposed filters are being used.
<strong>Hide attachments in summary: No</strong>
<strong>Use aggregation: No</strong>
All fields that are selected for grouping will be collapsed to one record per distinct value. Other fields which are selected for aggregation will have the function run on them. For example, you can group nodes on title and count the number of nids in order to get a list of duplicate titles.
For more Information how aggregation work see the "Use Aggregation" Help Page
<strong>Query settings: Settings</strong>
Here can you set advanced Settings for the SQL Settings
<ul>
<li><strong>Disable SQL rewriting</strong></li>
<li><strong>Distinct: No</strong></li>
This will make the view display only distinct items. If there are multiple identical items, each will be displayed only once. You can use this to try and remove duplicates from a view, though it does not always work. Note that this can slow queries down, so use it with caution.
<li><strong>Use Slave Server</strong></li>
<li><strong>Query Comment</strong></li>
</ul>
<strong>Field Language: Current user's language</strong>
<strong>Caching: None</strong>
You can choose a "Time-based" Caching if you want. With it you get the option to choose the length of time raw query results should be cached and "The length of time rendered HTML output should be cached."
<strong>Link display: Page</strong>
<strong>CSS class: None</strong>
You can define some own CSS Classes for your View
<strong>Theme: Information</strong>
Clicking on the "Theme: Information" link provides you with a listing of all posiible theming files. The highlighted files are the ones Views is currently using. All other filenames are suggested templates.
For more Information see the <a href="/help/views/analyze-theme" title="Theme Information" >"Theme information"</a> Page

30
help/advanced-style-settings.html
View File

@ -1,30 +0,0 @@
In Views 3 you can set Advanced Style Settings, they help you to insert markup of your own from the Views UI, so that you can fairly easily override the default markup without having to restyle via templates.
<ul>
<li> Customize field HTML</li>
With Customize field HTML you can generate html tags around the field.
<li>Customize label HTML</li>
Here you can generate html tags around the label of a field.
<li>Customize field and label wrapper HTML</li>
Here you can generate html tags around the wrapper of the label and field
</ul>
<a href="path:images/views3-semanticviews.png"><img src="path:images/views3-semanticviews.png" /></a>
Usage example
In a view with a field:
<ol>
<li>Configure the field. (Click on the field.)</li>
<li>In the modal that opens, scroll down to <strong>Style Settings</strong>.</li>
<li>Choose one or more of the three <i>Customize</i> options. This will reveal a dropdown menu where you can choose from one or more HTML tags to use on that field and allow you to add a CSS class specific to that field should you desire.</li>
<li>Decide if you want to keep the Views default classes. Unchecking this box means your markup is *it*.</li>
</ol>
In Views 2 you needed for Style Settings the <a href="http://drupal.org/project/semanticviews">Semantic Views</a> Modul, now the Semantic Views module has been mostly incorporated into Views 3.x. Semantic Views is still around for people who need it, though. For some details on how the original module is different from the Views implementation, please see <a href="http://drupal.org/node/1013876">this issue</a>.

1
help/aggregation.html
View File

@ -1 +0,0 @@
See: <a href="topic:views/group-by">Group by</a>

31
help/alter-exposed-filter.html
View File

@ -1,31 +0,0 @@
Modifying default values of a views exposed form is tricky, because FAPI was not designed to work with GET forms. One consequence is that it often can't tell if textfields (there are others) were submitted or not.
As a consequence, it *always* thinks the value was submitted, even if it was not. To fix that, Views modifies $form_state['input'][$identifier] with the default value if $form_state['input'][$identifier] was not set. In order to modify the default value in an alter, you need to do this:
<pre>
&lt;?php
if (empty($form_state['view']->exposed_input[$identifier])) .
{ $form_state['input'][$identifier] = $default_value; }
?&gt;
</pre>
where $identifier is the particular filter for which you want to change the default value, and $default_value is the new default value you want to set.
If you use a hook_form_FORM_ID_alter or hook_form_alter, you can modify exposed filters on the fly based on information that is external to Views. For example, I modified the exposed filter of a form to set a taxonomy term ID based on the user's GeoIP.
To do this, I used the following function, where geoip_redirect_get_tid() loads the relevant term id based on the user's current ip_address():
<pre>
&lt;?php
function MODULENAME_form_views_exposed_form_alter(&$form, $form_state) {
if(strpos($form['#id'], 'volunteer-directory') !== FALSE) {
$city_tid = geoip_redirect_get_tid();
if(is_numeric($city_tid) && $city_tid != 7660) {
if (empty($form_state['view']->exposed_input['tid'])) {
$form_state['input']['tid'] = $city_tid;
}
}
}
}
?&gt;
</pre>

24
help/analyze-theme.html
View File

@ -1,24 +0,0 @@
<p>Clicking on the "Theme: Information" link provides you with a listing of all posiible theming files. The highlighted files are the ones Views is currently using. All other filenames are suggested templates.</p>
<p>You may use any of the following possible theme files to modify individual parts of your view. In total, there are four parts to theming a view.</p>
<ul>
<li> The <strong>display</strong> theme is usually views-view.tpl.php and it largely controls the decorations around a view; where the header, footer, pager, more link, feed icon, etc, will be placed. </li>
<li> The <strong>style</strong> will control how all of the results of the display are put together. It may be as simple as just displaying all of the rows, or it may be a complex table generator or something in between. </li>
<li> The <strong>row</strong> style controls each individual row; not all styles utilize the row style (notably the table), but most others do.
<li> Finally, <strong>field</strong> themes allow you to override the look and even the data of each individual field, if the style uses fields. The actual template the system will use should be hilighted in <strong>bold</strong>.</li>
</ul>
<div class="help-box" style="text-align:center">
<a href="path:images/style-breakdown-large.png"><img src="path:images/style-breakdown.png" /></a>
<em>A breakdown of View output</em>
</div>
<p>The link to the left of each type will give you information about the default template used for that type. You may cut and paste this and place it in your theme with the appropriate template, or you may copy the base file from the views/theme directory (or, if provided by a module, from the module's directory). <strong>It is important that you clear the theme registry cache every time you add a new template, or the new template will not be picked up.</strong></p>
<p><strong>Important note:</strong> You place your custom template files in your theme directory, <strong>not views/theme</strong>. This is always true of theming with Drupal.
<p>In addition to this tool, the very useful <a href="http://drupal.org/project/devel">devel</a> module contains a tool called the "Theme developer" which does a good job of visually showing you which areas of your site use which themes. Be careful with it, though, as the theme developer causes the Views edit page to break.</p>
<p>Also, this feature will only work properly with Drupal 6.3 and later; prior to Drupal 6.3 <a href="http://drupal.org/node/241570">this patch</a> will be required.</p>

103
help/api-default-views.html
View File

@ -1,103 +0,0 @@
Views can be stored in the database, which is typical of smaller sites and hobby sites. However, Views may also be stored directly in the code as "default" views, (which simply means they're available by default). Modules often come with views that are specific to the module data, but it's also possible -- and <b>highly</b> recommended -- that sites which have separate "development" and "production" sites export their views into default views in a site-specific module. This makes it very easy to transfer views from dev to production without making database changes.
<h3>Creating a module</h3>
First, create a directory in <em>sites/all/modules</em> for your new module. Call it whatever you like, but for this example we will call it <em>mymodule</em>.
In this directory, create a <em>mymodule.module</em> file. It can be empty for now, but it should at least contain an opening PHP tag:
<pre>&lt;?php
</pre>
It should not contain a closing ?&gt; tag, as the closing ?&gt; tag is not required and anything AFTER the closing tag, such as a space or a linefeed, will be displayed directly to the browser and can potentially cause problems.
The .module file will contain functions and drupal hooks. Hooks are specially named functions that Drupal will call in order to get your module's response at certain times while generating pages. The only function you will need for this exercise is the 'views_api' hook that tells Views that this module supports the Views API and what version:
<pre>function mymodule_views_api() {
return array('api' => 2.0);
}
</pre>
For other uses you may well add additional functions.
Second, you need to create a <em>mymodule.info</em> file:
<pre>name = My module
description = My site specific module.
core = 6.x
</pre>
Once you have these two files set up, you should be able to activate your new module at the <em>Administer >> Modules</em> page.
<h3>Exporting your views</h3>
The easiest way to do this is to activate the 'views_export' module, and navigate to <em>Administer >> Structure >> Views >> Tools >> Bulk export</em> Place a check next to each view that you want in your module, type the module name into the text field, and click export. This will create the entire <em>hook_views_default_views()</em> function for you.
You can also export individual views. If you do this, keep in mind that this export does not include the line that adds the exported $view into the larger $views array:
<pre>$views[$view->name] = $view</pre>
To place this into your <em>hook_views_default_views()</em> you will need to place that after the view, and make sure the function returns $views at the end.
<h3>Placing your exported views into your module</h3>
Cut and paste the entire output of the bulk export tool into mymodule.views_default.inc -- and be sure to put a &lt;?php at the top of the file so that the webserver knows that it's PHP code! Then visit the Views tools page and clear the Views cache. Your views should now be listed as <b>Overridden</b> on the view list page. If you <b>revert</b> these views, they will be removed from the database, but will remain in code.
<h3>Theming your views in your module</h3>
You can theme these views in the module and not need to rely on the theme to do this at all; and in fact, the theme can continue to override these just like it ordinarily would, even if your module provides a theme. This is very useful for distributing a module where the view needs to look "just so."
To do this, you need to implement <em>hook_theme()</em> in your module:
<pre>function mymodule_theme($existing) {
return array(
'views_view__viewname__displayid' => array (
'arguments' => array('view' => NULL),
'template' => 'views-view--viewname--displayid',
'base hook' => 'views_view',
'path' => drupal_get_path('module', 'mymodule'),
),
);
}
</pre>
There are a small number of gotchas in doing this that you must be aware of.
<ol>
<li>When referring to a template filename, you always use dashes in the name. i.e, <em>views-view--viewname--displayid.tpl.php</em>. However, when referring to the hook or function names, you use underscores instead of dashes. i.e, <em>views_view</em> and <em>views_view__viewname__displayid</em></li>
<li>The 'arguments' change based upon which of the 3 types you're overriding. There's the 'display', the 'style' and the 'row' style. The above code is assuming the display, which is usually just <em>views_view</em>. Here are the possibilities:
<pre>display: array('view_array' => array(), 'view' => NULL),
style: array('view' => NULL, 'options' => NULL, 'rows' => NULL, 'title' => NULL),
row: array('view' => NULL, 'options' => NULL, 'row' => NULL, 'field_alias' => NULL),
field: array('view' => NULL, 'field' => NULL, 'row' => NULL),
</pre>
Be sure to use the right arguments line or the theme system will not properly translate.
</li>
<li>The 'template' line should never include the extension, so drop the .tpl.php from it.</li>
<li>You need to make sure that the Views preprocess functions get registered. The 'base hook' line in the definition does that, but it can only do it if it comes after the Views registration, which actually happens very late in theme building. 99% of the time, your module will come before Views. You have two choices to deal with this:
<ol>
<li>Set your module's weight to 11 or higher in the database. Views' weight is 10. You can make this happen automatically when the module is first installed by creating a mymodule.install file and using this code:
<pre>function mymodule_install() {
db_query("UPDATE {system} SET weight = 11 WHERE name = 'mymodule'");
}
</pre>
If you use this method, the <em>base hook</em> should be set to the name of the original template being used. i.e, if this is a variate of views-view-list.tpl.php, this should be 'views_view_list'.
</li>
<li>You can also just force it to list the preprocessors without actually having to detect them. This doesn't require modifying your module's weight, which is not always possible, you can insert this code into the array:
<pre> 'preprocess functions' => array(
'template_preprocess',
'template_preprocess_views_view',
'mymodule_preprocess_views_view__viewname_displayid',
),
</pre>
The first one is the global 'template_preprocess' function which all templates utilize. It does some basic things such as setting up $zebra and a few other items. See <a href="http://api.drupal.org/api/function/template_preprocess/6">api.drupal.org</a> for specifics.
The second one is the plugin specific preprocess. Like 'base hook' it should conform to the name used by the original template. i.e, if the original template was <em>views-view-list.tpl.php</em> then that preprocess function would be named <em>template_preprocess_views_view_list</em>.
The third one is your module's preprocess function, if it needs one. In general, you probably will not need one, and you should only attempt to use one if you are reasonably familiar with the concept of preprocess functions and Drupal's theme system in general. See Drupal's theme documentation for more information.
</li>
</ol>
</li>
<li>
If you leave the path blank the template file will be searched for in "./" which is the Drupal install base path.
</li>
</ol>

179
help/api-example.html
View File

@ -1,179 +0,0 @@
For the new table defined by the Node example module to be understood by the views module you need to create a node_example.views.inc file that describes the table and its relationships to the rest of the database. In order for views to know that this file is to be loaded you need to implement hook_views_api. This is done by adding the following function into your node_example.module file
<pre>
&lt;?php
/**
* Implements hook_views_api().
*
* This tells drupal that there is Views integration file named
* module-name.views.inc
*/
function node_example_views_api() {
// Note that you can include 'path' in this array so that your views.inc
// file can be stored in a different location.
return array(
'api' => 2.0
);
}
?&gt;
</pre>
Below is the contents of a simple node_example.views.inc file that allows you to create views that include the new color and quantity information.
<pre>
&lt;?php
/**
* This file is used to tell the views module about the new node_example table.
*
* Database definition:
* @code
* CREATE TABLE node_example (
* vid int(10) unsigned NOT NULL default '0',
* nid int(10) unsigned NOT NULL default '0',
* color varchar(255) NOT NULL default '',
* quantity int(10) unsigned NOT NULL default '0',
* PRIMARY KEY (vid, nid),
* KEY `node_example_nid` (nid)
* )
* @endcode
*/
function node_example_views_data() {
// Basic table information.
// ----------------------------------------------------------------
// node_example table
// New group within Views called 'Example'
// The group will appear in the UI in the dropdown tha allows you
// to narrow down which fields and filters are available.
$data = array();
$data['node_example']['table']['group'] = t('Example');
// Let Views know that our example table joins to the 'node'
// base table. This means it will be available when listing
// nodes and automatically make its fields appear.
//
// We also show up for node revisions.
$data['node_example']['table']['join'] = array(
'node_revisions' => array(
'left_field' => 'vid',
'field' => 'vid',
),
'node' => array(
'left_field' => 'vid',
'field' => 'vid',
),
);
// quantity
$data['node_example']['quantity'] = array(
'title' => t('Quantity'),
'help' => t('Quantity of items.'),
'field' => array(
'id' => 'numeric',
'click sortable' => TRUE,
),
'filter' => array(
'id' => 'numeric',
),
'sort' => array(
'id' => 'standard',
),
);
// Color
$data['node_example']['color'] = array(
'title' => t('Color'),
'help' => t('Color of item.'),
'field' => array(
'id' => 'standard',
'click sortable' => TRUE,
),
'filter' => array(
'id' => 'string',
),
'argument' => array(
'id' => 'string',
),
'sort' => array(
'id' => 'standard',
),
);
return $data;
}
?&gt;
</pre>
Some notes on usage:
Within Views, click on the Add tab. You have a number of type options here. Normally you would select either 'Node' (if you only want to display information on current nodes) or 'Node revision' (if you want to display information on all revisions of the nodes)
With this configuration you always pull out of the database, data for every single node, whether or not it has color and quantity information. To display information on just those nodes that have color and quantity information you can use a filter so that only nodes which don't have a NULL color or a NULL quantity are displayed.
<h3>Type/relationship extension</h3>
When your tables have first class data, you will often need to have own View types and View relationships defined. With the current node_example table this isn't required although I try to justify it below on an efficiency basis. See [[http://groups.drupal.org/node/17236#comment-58980|this discussion]] as to why it isn't justified.
Pulling data out of the database for every node when you only want data for the new Example node type is inefficient. To reduce the initial data extraction to just that relating to the new Example nodes requires that you make the node_example table the base table. This can be done by adding the following code into the node_example.views.inc file just before the 'return $data;'
<pre>
&lt;?php
// **** Begin optional extra for type and relationships ****
// Use node_example as a new base table
// by creating a new views type called 'Node example'
// This allows it to be selected as the 'view type'
// when you initially add a new view.
$data['node_example']['table']['base'] = array(
'field' => 'vid',
'title' => t('Node example'),
'help' => t("Node example type with color and quantity information."),
'weight' => -9,
);
// When using the new 'Node example' type you need to use relationships
// to access fields in other tables.
// Relationship to the 'Node revision' table
$data['node_example']['vid'] = array(
'title' => t('Node revision'),
'help' => t('The particular node revision the color and quantity is attached to'),
'relationship' => array(
'label' => t('Node revision'),
'base' => 'node_revisions',
'base field' => 'vid',
// This allows us to not show this relationship if the base is already
// node_revisions so users won't create circular relationships.
'skip base' => array('node', 'node_revisions'),
),
);
// Relationship to the 'Node' table
$data['node_example']['nid'] = array(
'title' => t('Node'),
'help' => t('The particular node the color and quantity is attached to'),
'relationship' => array(
'label' => t('Node'),
'base' => 'node',
'base field' => 'nid',
// This allows us to not show this relationship if the base is already
// node so users won't create circular relationships.
'skip base' => array('node', 'node_revisions'),
),
);
// **** End optional extra for type and relationships ****
?&gt;
</pre>
The above code adds a new 'Node example' to the view types that can be selected within the Add tab window of views. Selecting this sets the node_example table to be the base table.
If you select 'Node example' as view type, when you initially go into the edit window of views you will find the only fields available are the color and quantity fields. To get fields from other tables you need to add a relationship. Relationships may be found at the top in the same column as the fields.

88
help/api-forms.html
View File

@ -1,88 +0,0 @@
Views allows handlers to output form elements, wrapping them automatically in a form, and handling validation / submission.
The form is multistep by default, allowing other modules to add additional steps, such as confirmation screens.
<h2>Implementation</h2>
A views handler outputs a special placeholder in render(), while the real form with matching structure gets added in views_form().
When the View is being preprocessed for the theme file, all placeholders get replaced with the rendered form elements.
The views handler can also implement views_form_validate() and views_form_submit().
<pre>
function render($values) {
return '&lt;!--form-item-' . $this-&gt;options['id'] . '--' . $this-&gt;view-&gt;row_index . '--&gt;';
}
function form_element_name() {
// Make sure this value is unique for all the view fields
return $this-&gt;options['id'];
}
function form_element_row_id($row_id) {
// You could use values from $this-&gt;view-&gt;result[$row_id]
// to provide complex row ids.
return $row_id;
}
function views_form(&$form, &$form_state) {
// The view is empty, abort.
if (empty($this-&gt;view-&gt;result)) {
return;
}
$field_name = $this-&gt;form_element_name();
$form[$field_name] = array(
'#tree' => TRUE,
);
// At this point, the query has already been run, so we can access the results
foreach ($this-&gt;view-&gt;result as $row_id => $row) {
$form_element_row_id = $this-&gt;form_element_row_id($row_id);
$form[$field_name][$form_element_row_id] = array(
'#type' => 'textfield',
'#title' => t('Your name'),
'#default_value' => '',
);
}
}
// Optional validate function.
function views_form_validate($form, &$form_state) {
$field_name = $this->form_element_name();
foreach ($form_state['values'][$field_name] as $row_id => $value) {
if ($value == 'Drupal') {
form_set_error($field_name . '][' . $row_id, "You can't be named Drupal. That's my name.");
}
}
}
// Optional submit function.
function views_form_submit($form, &$form_state) {
// Do something here
}
</pre>
The form is multistep by default, with one step: 'views_form_views_form'.
A "form_example" module could add a confirmation step by setting:
<pre>
$form_state['step'] = 'form_example_confirmation';
</pre>
in form_example_views_form_submit().
Then, views_form would call form_example_confirmation($form, $form_state, $view, $output) to get that step.
<b>Important:</b> You can fetch the Views object in form_alter and validate / submit hooks from the form state:
<pre>
$view = $form_state['build_info']['args'][0];
</pre>
<h2>Relevant Views functions</h2>
<ul>
<li>template_preprocess_views_view()</li>
<li>views_form()</li>
<li>views_form_views_form()</li>
<li>views_form_views_form_validate()</li>
<li>views_form_views_form_submit()</li>
<li>theme_views_form_views_form()</li>
</ul>
<h2>Hooks</h2>
<ul>
<li>hook_views_form_substitutions()</li>
</ul>

45
help/api-handler-area.html
View File

@ -1,45 +0,0 @@
In Views areas (header, footer, empty-text) are pluggable, this means you can write your own php logic to place whatever you want.
<h3>Requirements</h3>
You should have read <a href="topic:views/api">API</a> and <a href="topic:views/api-tables">Tables API</a> to get a basic knowledge
how to extend views.
<h3>Create your own area handler</h3>
The first step is to tell views: Hey i want to add a new area handler.
Therefore you have to implement hook_views_data and add a new one. For example:
<pre>
function yourmodule_views_data() {
$data['views']['collapsible_area'] = array(
'title' =&gt; t('Collabsible Text area'),
'help' =&gt; t('Provide collabsible markup text for the area.'),
'area' =&gt; array(
'handler' =&gt; 'yourmodule_handler_collapsible_area_text',
),
);
}
</pre>
The second step is to write this handler. Therefore create a file called yourmodule_handler_collapsible_area_text.inc and
add it to the .info file of your module.
Then add content to your area file like this:
<pre>
class yourmodule_handler_collapsible_area_text extends views_handler_area_text {
function render($empty = FALSE) {
// Here you just return a string of your content you want.
if ($render = parent::render($empty)) {
$element = array(
'#type' =&gt; 'fieldset',
'#title' =&gt; t('Title'),
'#value' =&gt; $render,
);
$output = theme('fieldset', $element);
return $output;
}
}
}
</pre>
As on every handler you can add options so you can configure the behavior. If the area isn't shown yet in the views interface, please clear the cache :)

262
help/api-tables.html
View File

@ -1,262 +0,0 @@
Tables are described to Views by implementing hook_views_data(). This should be placed in MODULENAME.views.inc and it will be autoloaded (see <a href="topic:views/api">Views' API</a>). The hook implementation should return an array of table information, keyed by the name of the table. For example, if your module is describing three tables, 'foo', 'bar' and 'baz', your hook will look like this:
<pre> /**
* Implements hook_views_data().
*/
function MODULENAME_views_data() {
$data = array(
'foo' =&gt; array(
// ...info about the table named 'foo'...
),
'bar' =&gt; array(
// ...info about the table named 'bar'...
),
'baz' =&gt; array(
// ...info about the table named 'baz'...
),
);
return $data;
}
</pre>
The key should be the actual database name of the table (not including prefix), but it can be an alias as long as the join information (explained later) contains the real name of the table.
Each item in the array should be a field in the table, with the exception of a special information section called 'table'. Example:
<pre>$data['foo'] = array(
'table' =&gt; array(
// ... info about the table, described later ...
),
'bar' =&gt; array(
// ... info about the field named 'bar', i.e, foo.bar,
),
'baz' =&gt; array(
// ... info about the field named 'baz', i.e, foo.baz,
),
);
</pre>
Once you get down to an array that contains actual data, that piece of the array will often be referred to as the definition.
<h2>The 'table' section</h2>
Each table should have a 'table' section in it, which is used to set default information for the table, such as the group, as well as the very important joins and whether or not this is a base table.
First, there are several items that are actually for fields but can be placed here so that all fields within the table inherit them:
<dl>
<dt>group</dt>
<dd>The name of the group this item will be with. In the UI, this is displayed as Group: Title. For example, "Node: Node ID", "Taxonomy: Term description", etc. It is important to be consistent with groups, because the UI sorts by group, and allows filtering by group to find fields as well.</dd>
<dt>title</dt>
<dd>The actual name of the field; it should be concise and descriptive.</dd>
<dt>help</dt>
<dd>A longer description to help describe what the field is or does. It should try to be only a line or two so as not to clutter the UI.</dd>
</dl>
In general, having 'title' and 'help' at the table level doesn't make a lot of sense, but usually every item in a table is in the same group. Thus it is very common to define the 'group':
<pre>
$data['foo']['table']['group'] = t('Foo');
</pre>
The other items in the 'table' section are described in the following sections.
<h3>'base': Base table</h3>
If your table is a base table -- meaning it can be the primary, central table for a View to use, you can declare it to be a base table. This primarily provides UI information so that it can be selected.
For example:
<pre>
// Advertise this table as a possible base table
$data['node']['table']['base'] = array(
'field' =&gt; 'nid',
'title' =&gt; t('Node'),
'help' =&gt; t("Nodes are a Drupal site's primary content."),
'weight' =&gt; -10,
);
</pre>
The following items are available in the base section:
<dl>
<dt>field</dt>
<dd>The primary key field for this table. For Views to treat any table as a base table, it <b>must</b> have a primary field. For node this is the 'nid', for users this is the 'uid', etc. <strong>Without a single primary key field (i.e. not a composite key), Views will not be able to utilize the table as a base table.</strong> If your table does not have a primary key field, it is not too difficult to just add a serial field to it, usually.</dd>
<dt>title</dt>
<dd>The title of this table in the UI. It should be singular and describe the object that this table contains from the perspective of the user.</dd>
<dt>help</dt>
<dd>A short piece of text to describe what object this table contains.</dd>
<dt>database</dt>
<dd>If this table is held in a different database from your Drupal database, specify it as a string in the exact same format as the settings.php file. This is a special purpose variable that will probably be only used in site specific code, and <b>it must be the same database type as your Drupal database</b>. Also, don't try to join it to any table that isn't in the same database. That'll just create all kinds of silly errors. For example:
<pre>
// In settings.php for your site
// Your drupal (site) database needs to be called 'default'
$db_url['default'] = 'mysqli://user:pass@host/drupal_db';
$db_url['budget'] = 'mysqli://user:pass@host/other_db';
</pre>
Then when you are describing the external database in your base table you would write something like this:
<pre>
$data[$table]['table']['base'] = array(
'field' => 'Primary key',
'title' => t('Field name'),
'help' => t('Field description'),
'database' => 'budget',
'weight' => -10,
);
</pre>
</dd>
</dl>
<h3>'join': Linking your table to existing base tables</h3>
For Views to use your table, it has to either be a base table, or know how to link to an existing base table. Or sometimes both. Views uses this information to create a path to the base table; when the table is added to the query, Views will walk along this path, adding all tables required into the query.
<div class="help-box" style="text-align:center">
<a href="path:images/node-term_node-term_data-large.png"><img src="path:images/node-term_node-term_data.png" /></a>
<em>How taxonomy_term_data joins to node</em>
</div>
In the above example, to use these with 'node' as the base table, both 'taxonomy_term_data' and 'term_node' need to be defined, and they each need a join handler for node:
<pre>
$data['taxonomy_term_data']['table']['join']['node'] = array(
'left_table' =&gt; 'term_node',
'left_field' =&gt; 'tid',
'field' =&gt; 'tid',
);
</pre>
The above can be read as "In order to join to the node table, the taxonomy_term_data table must first link to the term_node table, and they join on the 'tid' field.". When adding this table to the query for a node view, Views will look at this and then look for the term_node table.
<pre>
$data['term_node']['table']['join']['node'] = array(
'left_field' =&gt; 'nid',
'field' =&gt; 'nid',
);
</pre>
Above, the fact that 'left_table' is left out lets us know that term_node links directly to the node table, using the 'nid' field on both sides of the join.
Quite a few more fields are available in this definition:
<dl>
<dt>handler</dt>
<dd>The name of the handler object to use. Defaults to 'Drupal\views\Join'. You may create custom join handlers that may or may not use any of the data below, as they see fit.</dd>
<dt>table</dt>
<dd>Table to join. This is optional, and should only be used if the table being referenced is an alias.</dd>
<dt>field</dt>
<dd>Field to join on. This is required.</dd>
<dt>left_table</dt>
<dd>The next step toward the final destination. If this is the final destination it may be omitted.</dd>
<dt>left_field</dt>
<dd>The field to join to on the left side. This is required.</dd>
<dt>type</dt>
<dd>Either LEFT (default) or INNER.</dd>
<dt>extra</dt>
<dd>Either a string that's directly added, or an array of items. Each item is, itself, an array:
<dl>
<dt>table</dt>
<dd>table should not be set in most cases, as it would be filled with the right table alias. Set it to NULL if you want to use a formular in "field"</dd>
<dt>field</dt>
<dd>Field or formula, therein "%alias" can be used to reference the right table.</dd>
<dt>operator</dt>
<dd>Similar to filters, this is the operator, such as &gt;, &lt;, =, etc. Defaults to = or IN.</dd>
<dt>value</dt>
<dd>Must be set. If an array, operator will be defaulted to IN.</dd>
<dt>numeric</dt>
<dd>If true, the value will not be surrounded in quotes, and %d will be used for its placeholder.</dd>
</dl>
</dd>
<dt>extra type</dt>
<dd> How all the extras will be combined. Either AND or OR. Defaults to AND.</dd>
</dl>
<h2>Describing fields on tables</h2>
Aside from the special table tag, each table can also have an unlimited number of field designations; these correspond roughly to fields on the table, though it is very common to use non-fields to display data that isn't directly in a field, such as data arrived from formulae, or special links related to the object the table is part of.
Each field is described in the view data with an array, keyed to the database name of the field. This array may contain some information fields, plus an entry in each of the five types of items Views has per field: argument, field, filter, relationship, sort. For example:
<pre>
$data['node']['nid'] = array(
'title' =&gt; t('Nid'),
'help' =&gt; t('The node ID of the node.'), // The help that appears on the UI,
// Information for displaying the nid
'field' =&gt; array(
'handler' =&gt; 'views_handler_field_node',
'click sortable' =&gt; TRUE,
),
// Information for accepting a nid as an argument
'argument' =&gt; array(
'handler' =&gt; 'views_handler_argument_node_nid',
'name field' =&gt; 'title', // the field to display in the summary.
'numeric' =&gt; TRUE,
'validate type' =&gt; 'nid',
),
// Information for accepting a nid as a filter
'filter' =&gt; array(
'handler' =&gt; 'views_handler_filter_numeric',
),
// Information for sorting on a nid.
'sort' =&gt; array(
'handler' =&gt; 'views_handler_sort',
),
);
</pre>
The above example describes the 'nid' field on the 'node' table, providing 4 of the 5 handlers. Note that while field is normally expected to be the database name of the field, it doesn't have to be; you can use an alias (which is how you get multiple handlers per field) or something completely made up for items that aren't tied to the database. For example:
<pre>
$data['node']['edit_node'] = array(
'field' =&gt; array(
'title' =&gt; t('Edit link'),
'help' =&gt; t('Provide a simple link to edit the node.'),
'handler' =&gt; 'views_handler_field_node_link_edit',
),
);
</pre>
The above handler definition an edit link to a node, but this isn't a field in and of itself. For aliased fields, here is another example:
<pre>
$data['users']['uid_current'] = array(
'real field' =&gt; 'uid',
'title' =&gt; t('Current'),
'help' =&gt; t('Filter the view to the currently logged in user.'),
'filter' =&gt; array(
'handler' =&gt; 'views_handler_filter_user_current',
),
);
</pre>
The above definition provides an alternate filter handler on the uid field for the current user.
The following items are allowed in the field definition:
<dl>
<dt>group, title, help</dt>
<dd>As above, these fields are for the UI. If placed here, any of these fields will override a setting on the base table.</dd>
<dt>real field</dt>
<dd>If this field is an alias, the "real field" may be placed here, and the handler will never know the difference.</dd>
<dt>field</dt>
<dd>A handler definition for the "Field" section, which is a field that may be displayed in a view. The definition is an array; the contents of the array are completely up to the handler, other than the 'handler' definition. If omitted, handler will default to 'views_handler_field'.</dd>
<dt>filter</dt>
<dd>A handler definition for the "Filters" section, which will be used to apply WHERE clauses to the view. The definition is an array; the contents of the array are completely up to the handler, other than the 'handler' definition. If omitted, handler will default to 'views_handler_filter'.</dd>
<dt>sort</dt>
<dd>A handler definition for the "Sort criteria" section, which will be used to add an ORDER BY clause to the view. The definition is an array; the contents of the array are completely up to the handler, other than the 'handler' definition. If omitted, handler will default to 'views_handler_sort'.</dd>
<dt>relationship</dt>
<dd>A handler definition for the "Field" section, which is a way to bring in new or alternative base tables in the view. The definition is an array; the contents of the array are completely up to the handler, other than the 'handler' definition. If omitted, handler will default to 'views_handler_relationship'. All relationships need the 'base' to be set. The basic relationship handler also requires 'base field' to be set. 'base' and 'base field' represent the "right" half of the join that will use this field as the left side.</dd>
<dt>argument</dt>
<dd>A handler definition for the "Field" section, which is method of accepting user input from the URL or some other source. The definition is an array; the contents of the array are completely up to the handler, other than the 'handler' definition. If omitted, handler will default to 'views_handler_argument'.</dd>
</dl>
For more information about what handlers need/use what data, visit <a href="http://views.doc.logrus.com">the Views API site</a> and check out the available handlers.
<h3>Support old tabledata</h3>
If you need to rename some tables/fields you can create some references in the views data to be able to continue to work.
Therefore you create the whole table structure of the current views data.
If you have to rename a single table you need to specify
<pre>
$data['oldtable']['moved to'] = 'newtable';
</pre>
If you have to rename/move a single a field to another table you specify
<pre>
$data['oldtable']['oldfield']['field']['moved to'] = array('newtable', 'newfield');
</pre>
or
<pre>
$data['oldtable']['oldfield']['moved to'] = array('newtable', 'newfield');
</pre>

224
help/api-upgrading.html
View File

@ -1,224 +0,0 @@
In order to take advantage of the changes in Drupal 7, Views has gone through several API changes.
Here's what you should know.
<h3>Handler registry</h3>
Views now uses Drupal's dynamic-loading code registry.
You can safely remove your implementations of hook_views_handlers(), since they are no longer used.
Please remember to specify the handlers in your module's .info file. For example:
<pre>
name = Example module
description = "Gives an example of a module."
core = 8.x
files[] = example.module
files[] = example.install
; Views handlers
files[] = includes/views/handlers/example_handler_argument_string.inc
</pre>
<h3>Removed handlers</h3>
Note that views_handler_filter_float has been removed.
This functionality is now handled by views_handler_filter_numeric.
There's no need for having a special handler any more, thanks to the new DB layer in Drupal 7.
views_handler_sort_formula has been removed.
Everyone who used it can extend from views_handler_sort, too.
<h3>Ctools dependency</h3>
Views requires ctools now, so it can use the dependency system of ctools.
The only thing you have to do is to remove views_process_dependency.
<h3>Changed add_where api</h3>
If your field is a plain sql field:
<pre>
$this->query->add_where($this->options['group'], "$this->tableAlias.$this->realField " . $this->operator . " '%s'", $this->value);
</pre>
has to be converted to
<pre>
$this->query->add_where($this->options['group'], "$this->tableAlias.$this->realField", $this->value, $this->operator);
</pre>
If your field is a complex where condition:
<pre>
$this->query->add_where($this->options['group'], "$upper($field) NOT LIKE $upper('%%%s')", $this->value);
</pre>
has to be converted to
<pre>
$placeholder = $this->placeholder();
$this->query->add_where_expression($this->options['group'], "$field LIKE $placeholder", array($placeholder => '%' . db_like($this->value)));
</pre>
placeholder() generates a automatic unique placeholder for you.
add_where with operator 'formula' can be converted to add_where_expression.
add_having with operator 'formula' can be converted to add_having_expression.
<h3>Changed place for display specific settings</h3>
In the new ui the new place for display settings is at the top of the second column.
Therefore use something like this code in your display plugin:
<pre>
$categories['block'] = array(
'title' => t('Block settings'),
'column' => 'second',
'build' => array(
'#weight' => -10,
),
);
</pre>
<h3>Changed filter settings and associated class variables</h3>
'optional' and 'single' are now 'required' and 'multiple', the logic is now opposite.
Also, the 'no_single' and 'no_optional' class variables (known as "object flags" in the API docs)
are now 'always_multiple' and 'always_required'.
<h3>Changed argument settings</h3>
See the init() function in views_handler_argument for an overview of everything
that changed.
1. The default actions 'summary asc', 'summary desc', 'summary asc by count', 'summary asc by count'
have been replaced by a single 'summary' action (which takes the sort order and type as options).
2. Wildcards are now called exceptions.
<pre>
$this->options['exception']['value'] = $options['wildcard'];
$this->options['exception']['title'] = $options['wildcard_substitution'];
</pre>
3. Summary plugin options are now stored in 'summary_options' instead of 'style_options'
<pre>
$this->options['summary_options'] = $options['style_options'];
</pre>
4. The selected summary plugin is no longer stored in 'style_plugin'.
<pre>
$this->options['summary']['format'] = $options['style_plugin'];
</pre>
5. The validator options have been moved.
<pre>
$options['validate']['type'] = $options['validate_type'];
$options['validate']['fail'] = $options['validate_fail'];
</pre>
6. The validator settings have been moved from $form['argument_validate'] to ['validate_options']
This means that dependent code in validate plugins needs to change.
Example change for views_plugin_argument_validate_user:
<pre>
$form['roles'] = array(
'#dependency' => array(
- 'edit-options-argument-validate-user-restrict-roles' => array(1),
+ 'edit-options-validate-options-user-restrict-roles' => array(1),
),
</pre>
<h3>The introduction of get_value() and sanitizeValue()</h3>
The views_handler class got two new functions:
<pre>
/**
* Get the value that's supposed to be rendered.
*
* @param $values
* An object containing all retrieved values.
* @param $field
* Optional name of the field where the value is stored.
*/
function get_value($values, $field = NULL) {
$alias = isset($field) ? $this->aliases[$field] : $this->field_alias;
if (isset($values->{$alias})) {
return $values->{$alias};
}
}
/**
* Sanitize the value for output.
*
* @param $value
* The value being rendered.
* @param $type
* The type of sanitization needed. If not provided, check_plain() is used.
*/
public function sanitizeValue($value, $type = NULL) {
switch ($type) {
case 'xss':
$value = filter_xss($value);
break;
case 'url':
$value = check_url($value);
break;
default:
$value = check_plain($value);
break;
}
return $value;
}
</pre>
These functions are meant to be used in the render() functions of field handlers,
for fetching data (usually by alias) from the $values object, and for sanitizing values.
The abstraction of fetching data from rendering data is important because
different query backends have different ways of storing data in $values, and the field alias
is a SQL specific thing. So instead of overriding the whole render() function and copying
all of the logic there (as well as having to constantly keep up with upstream Views changes),
the backend can just override get_values(), which is significantly less code.
Of course, different ways of fetching and displaying data might require different
ways of sanitizing it, hence the usage of the sanitizeValue() function.
Examples of converting render() field handler implementations:
<pre>
// This
$value = $values->{$this->field_alias};
// Becomes this
$value = $this->get_value($values);
// And this
$format = $values->{$this->aliases['format']};
// Becomes this
$format = $this->get_values($values, 'format');
// Instead of this:
return check_plain($value);
// We write:
return $this->sanitizeValue($value);
// Since sanitizeValue() supports different sanitization functions, this:
return filter_xss($value);
// Can become:
return $this->sanitizeValue($value, 'xss');
</pre>
<h3>Changed views_get_page_view</h3>
In contrast to 6.x views_get_page_view now does stores the current view, not the current page display.
<h3>Removed views-view-row-node</h3>
Due to changes in comment.module there is no extra views-view-row-node template needed to display the comments. If you do some custom stuff there you should now be able to do everything in your node.tpl.php.
<h3>Entity type Key on Base tables</h3>
During the development of the drupal7 version of views the entity type associated with a table got added to $data['name']['table']['base']['entity type']. It should be moved to $data['name']['table']['entity type'].
<h3>Changed views_plugin_style::render_grouping()</h3>
The parameters as well as the structure of the methods return have changed.
The method now accepts a third optional parameter called "$group_rendered".
This parameter defines whether to use the rendered or the raw field value for grouping.
Intention for adding the parameter was that the grouping could have been acted
unexpected if the rendered field contained unique values e.g. by using drupal_html_id().
<dl>
<dt>New return structure</dt>
<dd>
{grouping value} is the value affected by the new parameter.
<pre>
array (
{grouping value} => array(
'group' => {rendered_value of the grouping field},
'rows' => array({group rows}),
),
);
</pre>
</dd>
<dt>Old return structure</dt>
<dd>
<strong>If the new parameter isn't explicitly set or its value is NULL the structure of the return will be the same as in D6!</strong>
<pre>
array (
{rendered_value of the grouping field} => array({group rows}),
);
</pre>
</dd>
</dl>

24
help/api.html
View File

@ -1,24 +0,0 @@
Views allows modules to describe their tables relationships to each other, as well as fields, filters, sort criteria and arguments via <strong>hook_views_data()</strong>. Whenever Views deems it necessary, this hook is called, the data aggregated together and cached. <strong>hook_views_data_alter()</strong> may also be used to modify existing data, changing other module's handlers or adding handlers to other module's tables.
Views also allows modules to create new display types, style types, row styles, argument default handlers and argument validators via <strong>hook_views_handlers()</strong> and <strong>hook_views_plugins()</strong>.
These hooks are kept in a file named MODULENAME.views.inc. This file is automatically included upon need, so there is no need to try and include this in hook_init or any other method of including .inc files. This file should store hook_views_data, hook_views_data_alter(), hook_views_plugins(), hook_views_handlers(), as well as any other hooks and subsidiary data that will only be used by your module when Views is active. All handlers and plugins provided by your module should be in separate .inc files.
There are two similar files, MODULENAME.views_default.inc and MODULENAME.views_convert.inc which contain default views and views 1 to views 2 convert helpers, respectively.
<h3>hook_views_api()</h3>
<strong>In order for your files to be included, your module must first implement hook_views_api()</strong> in the main .module file. This module should return array of information. The following items may be returned:
<dl>
<dt><strong>api</strong></dt>
<dd>This must appear; it should be the oldest API version that your module can work with. If Views is currently running an older version of the API, it will ignore your module's views integration. This is a good thing, as it will prevent code crashes, at the expense of your module's functionality disappearing.
<br />
You may find the current Views API version by calling <strong>views_api_version()</strong> which is implemented at the top of views.module. This version numbering starts at 2.0. Every time changes are made to the Views handlers and plugins or other aspects of the Views API, the number will tick up (by either .001, .01 .1 or 1 depending upon how major the changes are). Note that <strong>views_api_version()</strong> was introduced in Views 2.0-rc2 and may not exist prior to that version. You may use drupal_function_exists() to test to see if this function is there.
<br />
Often these versions are basically compatible with each other and Views won't care if your module implements 2.000, 2.001, 2.002, etc. Your module can request that it won't work with any version older than a given version, however. Views will determine, itself, if a newer version will work.
</dd>
<dt><strong>path</strong></dt>
<dd>If your *.views*.inc files are not in the same directory as the .module file, then return the full path here. You should probably use something like drupal_get_path('module', 'yourmodulename') . '/includepath'.</dd>
<dt><strong>template path</strong></dt>
<dd>A path where the module has stored it's views template files. When you have specificed this key views automatically uses the template files for the views. You can use the same naming conventions like for normal views template files.</dd>
</dl>

106
help/argument.html
View File

@ -1,106 +0,0 @@
Contextual Filters (known in previous versions of Views as "Arguments") are input. While they often come from the URL, they don't always. Don't be shocked when they don't. Each display type may have its own source for contextual filters. Block displays have no source of contextual filters at all; they cannot pull contextual filters from the URL, and often require use of PHP code as a default contextual filter. Various default values can be applied against contextual filters to use filters in a block view. See "Provide default value," under "When the filter value is NOT in the URL" below.
In general, contextual filters are used to filter the view, and in that sense they have a very close relationship to filters. However, this isn't necessarily true for every contextual filter. Contextual filters can be used for any purpose, really; the extent of what the contextual filter does is up to the developer of the contextual filter.
A typical use of an contextual filter might be to reduce a view to a single node, a single user, or nodes with a given taxonomy term.
<h3>When the filter value is NOT in the URL</h3>
<dl>
<dt>Display all results for the specified field</dt>
<dd>If this option is selected, the contextual filter is removed from the view as though it weren't there and all results will be displayed.</dd>
<dt>Provide default value</dt>
<dd>If no contextual filter is given, a default contextual filter can be selected. You may choose from a number of different default filter options. See "Default contextual filters" below.</dd>
<dt>Hide view</dt>
<dd>The view will remove itself entirely if the contextual filter is not present; for a block this means it simply won't appear. For page views the view will return a 404 and present a "Page not found" error. </dd>
<dt>Display a summary</dt>
<dd>The view will attempt to display a summary of contextual filters available, based upon the view, and provide links to the view with those contextual filters. Summaries have their own style handlers as well as options. The default summary style simply displays a list of contextual filters with a count of entries found per contextual filter. This special mode is a very powerful part of Views.</dd>
<dt>Display contents of "No results found"</dt>
<dd>If this option is selected, the value specified under "No results behavior" on the main view page will be displayed when there is no filter value in the URL.</dd>
</dl>
An exception value can be set under the "Exceptions" menu. If this exception value is received, any filter value specified under "When the filter value is NOT in the URL" will be ignored. This is a literal value: if you enter the word "everything" here, the exception will apply only if the value "everything" is received.
<h3>Default contextual filters</h3>
The Default contextual filter selection is available <strong>only if the action to take is "Provide default value"</strong> under "When the filter value is NOT in the URL." When that option is selected, a new fieldset will appear that will allow you to choose default contextual filters. Views provides the following default selectors by default (but other modules may add more):
<dl>
<dt>Content ID from URL</dt>
<dd>This will attempt to find a Node ID from the URL, and is primarily useful for the Node: ID contextual filter (though other contextual filters that use Node IDs, such as the CCK Node Reference contextual filter, will find it useful, too). For example, when visiting the path "node/1" or "node/1/edit" it will know that the "1" in that path is a node ID and use it.</dd>
<dt>Fixed value</dt>
<dd>You may directly enter what the contextual filter will be. This is not a variable, it will always be the same contextual filter. </dd>
<dt>PHP Code</dt>
<dd>Arbitrary php code inserted here will run whenever a contextual filter is not present in the URL.</dd>
<dt>Taxonomy term ID from URL</dt>
<dd>This default filter will attempt to return a taxonomy term from the current path. Selecting this option gives you the choice to also load default filters from terms.</dd>
<dt>User ID from URL</dt>
<dd>Like Node ID and Taxonomy term ID from URL, this will attempt to find a user ID from the path. It also includes an option to look for a node and use the node author as the user ID.</dd>
<dt>User ID from logged in user</dt>
<dd>If a user is currently logged in and accessing this view, their user ID will be returned as the contextual filter.</dd>
<dt>Current date</dt>
<dd>This option simply returns today's date.</dd>
<dt>Current node's creation time</dt>
<dd>Select this to return a node's creation time as a contextual filter.</dd>
<dt>Current node's update time</dt>
<dd>Not surprisingly, this filter returns the current node's update time</dd>
</dl>
Please bear in mind that the selection of a default contextual filter happens only if a contextual filter is not provided. If you are using a display that has no contextual filter source, such as a block, the contextual filter value selected here will always be used. However, if using a display that reads contextual filters from the URL, the options selected here will only be applied if the URL did not contain an contextual filter.
The "Skip default argument for view URL" option gives you the choice of ignoring the default argument totally. This is useful for certain applications, like the creation of feeds.
<h3>When the filter value IS in the URL or a default is provided</h3>
<dl>
<dt>Override title</dt>
<dd>Selecting this option will allow you to replace the default view title with a piece of arbitrary text. Argument substitutions in the form of %1, %2, etc. may be used here.</dd>
<dt>Override breadcrumb</dt>
<dd>This option will allow you to overwrite the view name in breadcrumbs. The same substitution values as in "Override title" may be used.</dd>
<dt>Specify validation criteria</dt>
<dd>Contextual filters can have validators, which are pluggable systems used to ensure that contextual filters fit within certain parameters. When a validator is chosen, it may provide some specific settings, including the action to take if an contextual filter is presented, but it fails to validate. These actions are generally the same as the default actions above, excluding the ability to provide another default filter. See "Contextual filter validation" below for a detailed description.</dd>
</dl>
<h3>Contextual filter validation</h3>
Note: If a view provides a menu option, such as a tab, the tab will not appear if the contextual filter does not validate.
This sytem can have other validators plugged in; by default, Views provides:
<dl>
<dt>Basic validation</dt>
<dd>This validator ensures that the contextual filter is present. A PHP NULL value (from eg. PHP default contextual filter code) will invalidate.</dd>
<dt>Content</dt>
<dd>This validator ensures that the contextual filter is a valid Node ID. You may select which node types the validator will accept.</dd>
<dt>Numeric</dt>
<dd>This validator ensures that the contextual filter is a valid number.</dd>
<dt>PHP Code</dt>
<dd>You may enter arbitrary PHP code here, similar to the "PHP code" option under "Provide default value" in "When the filter value is NOT in the URL" above, to determine if the contextual filter is valid or not.</dd>
<dt>Taxonomy term</dt>
<dd>Ensures that the contextual filter is a valid taxonomy term. This includes options to limit to specific vocabularies and can transform the contextual filter to the right type depending upon the actual contextual filter. Set the contextual filter value type option to the actual type of data that the contextual filter being used is expecting.</dd>
<dt>User</dt>
<dd>Ensures that the contextual filter refers to a valid user. If you select this validator, additional options are available to accept numeric user IDs, usernames or both, as well as to consider a user's role when filtering the view.</dd>
</dl>
If you select the "Specify validation criteria" option to select a specific validator, you will have the option to select an action to take if the filter value does not validate.
<dl>
<dt>Display all results for the specified field</dt>
<dd>Selecting this option will return all values if the filter value does not validate, similar to "Display all results for the specified field" under "When the filter value is not in the URL" above.</dd>
<dt>Hide View</dt>
<dd>Similar to "Hide view" under "When the filter value is NOT in the URL" above, if this option is selected and the selector does not validate, the view will hide itself. If the view is a block, nothing will appear. If it is a page, it will throw a 404 and present a "Page not found" error.</dd>
<dt>Return Summary</dt>
<dd>If you select this option and the filter does not validate, a summary of all values that are valid will be returned, as in the option of the same name under "When the filter value is NOT in the URL above."</dd>
<dt>Display contents of "No results found"</dt>
<dd>If this option is selected and the selector does not validate, the value specified under "No results behavior" on the main view page will be displayed.</dd>
</dl>
<h3>Adminstrative title</h3>
Located under the "More" group at the bottom of the "Contextual filters" menu, this option allows you to specify a custom name for the contextual filter. This may be particularly useful if you use the same contextual filter twice and you'd like to distinguish between the two filters.
<h3>Grouping of contextual filters</h3>
Even though contextual filters do not appear in the "<em>and/or</em>" user interface for sorting and grouping regular filters, contextual filters are always added to the <em>first</em> group of filters. Thus the order of the groups can cause the contextual filter to have entirely different effects on the results of a view that has contextual filters. Even though differences might not be apparent through the user interface.
Multiple contextual filters are therefore always in the same "and/or" group of filters, and can not be placed in different groups. There is <a href="http://drupal.org/node/357082">an effort to add this feature</a>.

20
help/basic-settings.html
View File

@ -1,20 +0,0 @@
You choose the <strong>name</strong> of the current display.
This <strong>title</strong> will be displayed with the view, wherever titles are normally displayed; i.e, as the page title, block title, etc.
When you use have many items to display, you have the choice to display them in different variants.
<dl>
<dt>Display a specified number of items</dt>
<dd>Specify the number of items to display per page and an offset. The offset is the number of items to skip. For example, if this field is 3, the first 3 items will be skipped and not displayed.
<dt>Display all items</dt>
<dd>All items will display, but you can choose an offset. The number of items to skip. For example, if this field is 3, the first 3 items will be skipped and not displayed.</dd>
<dt>Paged output, full pager</dt>
<dd>A Pager can be used to display items, with the possibility to select the next page and also the first and last page. When you have many items the query is very <i>expensive</i>. To avoid this, you can choose the mini pager.
You can also choose the number of items per page. If you enter 0, then there is no limit. Pagers also will respect an offset, if present. If multiple pagers are present on one page you may need to set this number to a higher value so as not to conflict within the ?page= array. Large values will add commas to your URLs, so avoid this if possible. Unless you're experiencing problems with pagers related to this view, you should leave this at 0. Enter the total number of pages to limit the number of values. When you leave the field empty all pages will show.
The <strong>Exposed options</strong> allow users to define their values in a exposed form when view is displayed.
You can choose "Expose items per page". With this option the user can determine how many items per page show in a view. Options for which label should display and what numberic options are also available.
Furthermore, you can choose "Expose Offset". When checked, users can determine how many items should be skipped at the beginning. You can define a label.
</dd>
<dt>Paged output, mini pager</dt>
<dd>The pager optiona are the same as for the "Paged output, full pager" but you have no possibility to jump to the last or first items. </dd>
</dl>
Normally, all views are created with <strong>unrestricted access</strong>. This means any site visitor can see the views. Please consider this when you make a view with a menu link and private data as output. You have by default two options: "Permission" and "Role". If you choose permission, you get a list of all permissions. Only users with the selected permission flag will be able to access this display. If you choose role, you get all roles as checkboxes. Only the checked roles will be able to access this display. Note that users with "access all views" can see any view, regardless of role.

5
help/demo-video.html
View File

@ -1,5 +0,0 @@
<p>Here are some links to demonstration videos. It will get you started working with Views.</p>
<p><a href="http://drupal.org/node/248766">Views 2 (Drupal 6) Demonstration Video - Drupal Handbook</a></p>
<p><a href="http://nodeone.se/blogg/taming-the-beast-learn-views-with-nodeone">NodeOne's initial screencasts on the Views 3 UI.</a>

1
help/display-attachment.html
View File

@ -1 +0,0 @@
Attachment displays are 'attached' to another display in the same view. When the display is visited, the attached display will also be rendered and may be placed before, after or both before and after the original display. Attachment displays are often useful for displaying an argument summary view along with a page display that accepts arguments. This can be used to provide a kind of glossary.

11
help/display-block.html
View File

@ -1,11 +0,0 @@
Block displays will show up on your blocks administration page. Once a block display is created and saved, it can be enabled and positioned in your theme by visiting <strong>administer &gt;&gt; site building &gt;&gt; blocks</strong> and selecting it from the list.
Blocks <strong>do not</strong> accept arguments from any source; the only way to get arguments to a block is to provide defaults to it, possibly via the PHP Code default setting.
<ul>
<li>Edit the argument in question; you may want to override this argument if you have multiple displays using it.</li>
<li>Change the "Action to take if argument is not present" to "Provide default argument". This will bring up a new box called "Provide default argument options".</li>
<li>The most common default argument type used for blocks is Node from URL, where it attempts to determine if the URL refers to a node, for example if visiting 'node/1' or 'node/1/edit'. User ID from URL is also very common.</li>
<li>If you change the default argument type to 'PHP Code' (note: You must have permission to use PHP code on your site) you can enter PHP to define the argument needed. Simply return the argument.</li>
<li>If you are using a <strong>more link</strong> with a block, you must have a page display for that more link to attach to. The more link will not print if there is no place (no display) for it to link to.</li>
</ul>

3
help/display-default.html
View File

@ -1,3 +0,0 @@
The default display is primarily a display to store settings, and isn't actually used anywhere within the Views system. It is possible for external programs to use the default display, but if they do they will (hopefully) tell you which display they will be working with. The default display is also a convenient display to use to embed into your site using PHP snippets; this is useful, for example, in node content, but this is something that should generally only be done by administrators.
In general, you probably want to add either a <a href="topic:views/display-page">page display</a> or a <a href="topic:views/display-block">block display</a>.

1
help/display-feed.html
View File

@ -1 +0,0 @@
A feed display allows you to attach an RSS feed to a view.

7
help/display-page.html
View File

@ -1,7 +0,0 @@
Page displays have a <a href="topic:views/path">path</a> and an optional <a href="topic:views/menu">menu</a> component. Page displays will be the primary content for the page, meaning they will be displayed in the main content area when you visit the URL that corresponds to the path.
Page displays take their arguments from the URL. You can embed arguments into the URL using %; in previous versions of Views, this was '$arg'. For example, 'node/%/foo' will accept URLs such as 'node/1/foo'.
Please remember that using a % placeholder makes the argument required. If you wish to have an optional argument, simply omit the % from the path. I.e. using "page/%" as the path requires an argument and visiting 'http://www.example.com/page' will not trigger the view.
If you intend to embed a view manually into another view, it is recommended that the page display not be used for embedding. Select a different display type to embed.

13
help/display.html
View File

@ -1,13 +0,0 @@
Displays tell Views where the output should go. By adding a display to a View, you can have your view appear as a page, or as a block, or even as an attachment to a different display on the view.
Displays tell Views where the output should go. By adding a display to a View, you can have your view appear as a page, or as a block, or even as an attachment to a different display on the view. You must create at least one display in order to place a View on your site.
Each display can have its own settings, but when created, a display will take all of its <em>basic settings</em> from the <strong>default display</strong> which all Views must have. For most settings, there is an <a href="topic:views/overrides">override</a> button that will override that single setting for the current display. Overridden settings will have a mark in the summary for that display. All 'default display settings' are shown in the other displays in '<i>italic</i>'. When you override a setting, then it is shown 'normal'.
Please keep in mind that when you are editing a setting on a display that is not overridden, then by default you are editing that for all displays.
Overriding <strong>fields</strong>, <strong>arguments</strong>, <strong>sorts</strong>, <strong>filters</strong> and <strong>relationships</strong>, can only be done by overriding the entire group or none of them. To do this, click on the header for the filters or the rearrange button. Once you override, the display will then have its own copies of the fields/filters/etc and changes to the defaults will not be reflected on your display.
With the <strong>Reorder</strong> button you can organize the order of your displays.
With the <strong>Analysis</strong> button the system checks the view and may give you suggestions if something is wrong.
You can <strong>clone a display</strong> by using the link in the header of the display.

13
help/drush.html
View File

@ -1,13 +0,0 @@
There are some Drush commands available for Views, initially added in <a href="http://drupal.org/node/1079178">Drush command to revert views</a>:
<ul>
<li>views-dev (vd) - Setup the views settings to a more developer oriented value</li>
<li>views-revert (vr) - Revert overridden views to their default state. Make backups first!</li>
</ul>
Examples:
drush views-revert
[prompts the user with a list of overridden views to choose from, or to revert all]
drush views-revert archive myview2
[reverts the two specified views]

24
help/embed.html
View File

@ -1,24 +0,0 @@
You can easily embed the results of a view into other parts of your site;
either with code as a module, or in nodes or blocks as snippets. The
easiest way is to use the function <strong>views_embed_view()</strong>:
<code>/**
* Embed a view using a PHP snippet.
*
* This function is meant to be called from PHP snippets, should one wish to
* embed a view in a node or something. It's meant to provide the simplest
* solution and doesn't really offer a lot of options, but breaking the function
* apart is pretty easy, and this provides a worthwhile guide to doing so.
*
* @param $name
* The name of the view to embed.
* @param $display_id
* The display id to embed. If unsure, use 'default', as it will always be
* valid. But things like 'page' or 'block' should work here.
* @param ...
* Any additional parameters will be passed as arguments.
*/
function views_embed_view($name, $display_id = 'default') {
</code>
To figure out the id of a display, hover your mouse over the tab to select that display. Everything after the '#views-tab-' is the id of that display. This ID is guaranteed never to change unless you delete the display and create a new one.

3
help/empty-text.html
View File

@ -1,3 +0,0 @@
The Emtpy Text content will be displayed when you choose the option <em>Display empty text</em> under the <strong>Arguments</strong> labelled <em>Action to take if argument is not present</em>.
By default you can choose one or more text areas.

77
help/example-author-block.html
View File

@ -1,77 +0,0 @@
<p>In this example you will create a context-sensitive block that shows the titles of recent blog entries by an author when viewing one of their posts. This will demonstrate using Views <em>arguments</em> to dynamically filter a view's contents at display time.</p>
<p>Before working through this example, enable the <strong>Blog</strong> module and populate some entries from a few different users.</p>
<h3>Creating the View</h3>
<p>The first step is creating a view for our recent blog entries block. Because the block will show the titles of blog entries, this view is considered a "Node" type. Go to <a target="_blank" href="base_url:admin/structure/views/add">add new view</a>, enter the following properties, and click <strong>Next</strong>:</p>
<dl>
<dt>View name</dt>
<dd>recent_blog_entries</dd>
<dt>View description</dt>
<dd>List of recent blog entries for a given author.</dd>
<dt>View tag</dt>
<dd>blog</dd>
<dt>View type</dt>
<dd>Node</dd>
</dl>
<h3>Generating a list of blog entries</h3>
<p>It will be much easier to see the view progress if we can see it doing something. In this section, we will create a basic view displaying blog entry titles.</p>
<ol>
<li>In the third column, locate the <strong>Fields</strong> area. Generally speaking, fields are the pieces of information that you want to display in the view (in this case, node title). Click the <strong>+</strong> icon to add a field.</li>
<li>Scroll down to <strong>Defaults: Add fields</strong>, below the settings table. A large selection of fields will be available.</li>
<li>In the <strong>Groups</strong> drop-down menu, select <em>Node</em>. This will limit the list to only the default fields exposed by Node module.</li>
<li>Scroll down the list, select the <em>Node: Title</em> field, and click <strong>Add</strong>.</li>
<li>You will now be presented with settings for the <em>Node: Title</em> field. Delete the label from the <strong>Label</strong> field, so that each individual node title is not prefixed with the word "Title." Additionally, check the <em>Link this field to its node</em> box so that visitors who see an interesting title can click directly on it to read the blog entry to which it belongs.</li>
<li>When finished, click <strong>Update</strong>. If you scroll down to the <strong>Live Preview</strong> section, you should now see a list of several node titles; however both blog entries and other node types will be in the list. Let's fix that.</li>
<li>In the fourth column, locate the <strong>Filters</strong> area. Filters limit the results displayed in the view, and we can use this to our advantage here by showing node titles only from blog entries and not every type of node. Click the <strong>+</strong> icon to add a filter.</li>
<li>As before, scroll down to the <strong>Defaults: Add filters</strong> section, select <em>Node</em> from the <strong>Groups</strong> select box to limit the list of options to only those exposed by Node module.</li>
<li>Scroll down and select the <em>Node: Type</em> field and click <strong>Add</strong>. In the settings page that appears, leave <strong>Operator</strong> as <em>Is one of</em> and select <em>Blog entry</em> under <strong>Node type</strong>. Click <strong>Update</strong> when finished.</li>
<li>Now, by scrolling down to <strong>Live preview</strong>, you'll see that the list only shows blog entries.</li>
</ol>
<h3>Adding context with arguments</h3>
<p>While filters are very useful for limiting the results of a view when the condition is always consistent (for example, a view of blog entry nodes should <em>always</em> be filtered by the blog entry type), something filters can't do is smart decision-making based on the page context. In our case, we want the view to display a different list of blog entries when looking at a post by user 'admin' than we do when looking at a post by user 'member', and filters won't be able to help.</p>
<p>Luckily, there's another way to filter a view's content: <em>arguments</em>. Through arguments, Views are able to obtain additional context (typically via dynamic URLs with IDs in them) and can take this context into consideration when displaying the view.</p>
<p>Let's walk through adding and configuring an argument to our view so that we can change its contents based on post author.</p>
<ol>
<li>In the third column, locate the <strong>Arguments</strong> area. Click the <strong>+</strong> icon to add an argument.</li>
<li>Because we are basing the view around content <em>authors</em>, this time under <strong>Groups</strong> select <em>User</em>. Check <em>User: Uid</em> and click <strong>Add</strong>.</li>
<li>The <strong>Defaults: Configure Argument User: Uid</strong> settings page has a lot going on, but only a few things that need our attention.</li>
<li>The <strong>Title</strong> field here, unlike the Title field under <em>Basic Settings</em>, can be based upon the context that the view is being displayed in. Change the title to 'Recent entries by %1.' %1 will later be expanded to the user's name (based on the User: Uid argument) when the view is displayed.</li>
<li>Under <strong>Action to take if argument is not present</strong>, there are a variety of options, ranging from displaying a 404 or a 403 page to simply displaying all values in the view. In our case, if an argument isn't specified (which it won't be, since this view will be displayed in a sidebar block, not as a page with its own URL), we want to give it a default one to act on. Select <em>Provide default argument</em>.</li>
<li>Assuming JavaScript is enabled in your browser, you should now get another selection for <strong>Default argument type</strong>. Select <em>User ID from URL</em>, which will then provide a new option, <em>Also look for a node and use the node author</em>. Select it. This will cause Views to first see if it can figure out a user ID from the current URL (for example, user/1). If it can't, it will instead check to see if the current page is a node page (such as node/42) and, if so, take the user ID from the node's author field instead.</li>
<li><strong>Validator options</strong> provide a useful way to control what kind of arguments your view will accept. Select <em>User</em> as the <strong>Validator</strong>. By default, changing this setting will check the incoming argument and ensure it's a valid user ID; if not, the view will be hidden from the page.</li>
<li>Once you have changed the argument's title, default argument, and validator options, click <strong>Update</strong> to save your changes.</li>
<li>You'll notice that now the Live preview no longer shows anything. Did we just break the view? Fortunately, no. It's merely abiding by our wishes to hide itself if there is no valid user ID given to it. Try entering a '1' in the <strong>Arguments</strong> box and clicking <strong>Preview</strong>. You should now see a list of only user 1's blog entries.</li>
</ol>
<h3>Creating the block</h3>
<p>So the live preview is now showing basically what we want. There's just one problem: we have no way to stick what we've done so far into a sidebar block! Let's fix that by adding a new <strong>Display</strong>.</p>
<ol>
<li>In the first column, under <strong>Defaults</strong>, there is a select box containing entries such as <em>Page</em>, <em>Feed</em>, and, yes, <em>Block</em>! Select <em>Block</em> and click <strong>Add display</strong>.</li>
<li>There's not much else to do here as far as Views is concerned. Under <strong>Block settings</strong>, click the <em>None</em> link next to <strong>Admin</strong> and fill in a description for the block in the administrative interface, such as: 'Recent blog entries by author.' and click <strong>Update</strong>.</li>
<li>Save your work by clicking the <strong>Save</strong> button at the bottom of the Views interface. You should receive a message that the view has been saved.</li>
<li>Next, navigate to the <a target="_blank" href="base_url:admin/structure/block">blocks interface</a> and drag the 'Recent blog entries by author' block to the right sidebar region (or similar) and click <strong>Save blocks</strong>.</li>
<li>You'll notice this appeared to do nothing. No block shows in the sidebar. But remember, we are looking at an adminitrative page; we are not looking at a page that would provide a user ID context. Navigate to the <a target="_blank" href="base_url:blog">main blog listing</a> and click on an entry there. You should now see a sidebar block, titled something like "Recent entries by admin," with a list of blog entries beneath it.</li>
</ol>
<h3>Finishing touches</h3>
<p>There are still a few remaining things to do before our view is complete. For example, we said that the block was to show <em>recent</em> blog entries, but instead it's showing them in the order they were entered, with oldest on top. Additionally, even unpublished entries are showing in the list currently.</p>
<ol>
<li>Return to the <a target="_blank" href="base_url:admin/structure/views/view/recent_blog_entries">recent_blog_entries view edit page</a>.</li>
<li>Add an additional filter by clicking the <strong>+</strong> icon in the <strong>Filters</strong> section in the fourth column.</li>
<li>Change <strong>Groups</strong> to <em>Node</em> and select <em>Node: Published</em>. Click <strong>Add</strong>.</li>
<li>Under the <strong>Published</strong> selection, choose <em>Yes</em> and click <strong>Update</strong>.</li>
<li>To handle sorting, locate the <strong>Sort criteria</strong> area, just above filters, and click the <strong>+</strong> icon there.</li>
<li>Under <strong>Groups</strong>, again select <em>Node</em>. From the list of options, check <em>Node: Post date</em> and click <strong>Add</strong>.</li>
<li>In the settings page, change <strong>Sort order</strong> to <em>Descending</em>. This will place the newer posts on top of the older ones. Click <strong>Update</strong> when finished.</li>
<li>Finally, <strong>Save</strong> the view for your new settings to take effect.</li>
</ol>

46
help/example-filter-by-current-user.html
View File

@ -1,46 +0,0 @@
<p>In this example you will create a page that displays a list of the content authored by the current logged-in user. This will demonstrate using Views <em>filters</em> and <em>relationships</em> to dynamically filter the view's contents at display time.</p>
<p>For this example, we are assuming you have a content type "Blog Post".</p>
<h3>Creating the View</h3>
<p>The first step is creating a view for our content list page. Because the page will show the titles of content, this view is considered a "Content" type. Go to <a target="_blank" href="base_url:admin/structure/views/add">add new view</a>, enter the following properties, and click <strong>Next</strong>:</p>
<dl>
<dt>View name</dt>
<dd>content_by_current_user</dd>
<dt>Description</dt>
<dd>List of content authored by the current user.</dd>
</dl>
<p>Choose <strong>Show</strong> <em>Content</em> <strong>of type</strong> <em>Blog Post</em>. You can choose any way you wish to sort the content.</p>
<h3>Creating the page</h3>
<p>Tick the box next to <strong>Create a page</strong>. Enter a page title and a path. For our purposes here, the default settings for the rest of this page are sufficient.</p>
<p>Click on <strong>Continue &amp; edit</strong>.</p>
<h3>Creating the relationship</h3>
<p>In order to have access to the author of the content, it is important to create a relationship between the current content type, and users.</p>
<p>Under <strong>Advanced</strong> in the right culumn, select <strong>add</strong> next to <strong>Relationships</strong>.</p>
<p>Select <em>Content: Author</em> and click on <strong>Add and configure relationships</strong>. Leave the settings as they are and click on <strong>Apply (all displays)</strong>.</p>
<p>You now have access to the user data related to the content you are viewing.</p>
<h3>Filtering the view</h3>
<p>Now you need to filter the view to display only content authored by the current user. This data is now available for the content because you have created the relationship in the step above.</p>
<p>Next to <strong>Filter criteria</strong> click on <strong>add</strong> to add a new filter to your view.</p>
<p>Filter the list of fields by selecting <em>User</em> next to <strong>Filter</strong> at the top. You now have more fields than before due to the relationship you created.</p>
<p>Select <em>User: Current</em> from the list and click on <strong>Add and configure filter criteria</strong>.</p>
<p>Since this field is only visible due to the relationship you created, <em>author</em> will already be selected under <strong>Relationship</strong>. This shows that the relationship you created is being used for the filter field.</p>
<p>Select <em>Yes</em> under <strong>Is the logged in user</strong>, and click on <strong>Apply (all displays)</strong>.</p>
<p>If you have authored content of the type <em>Blog Post</em>, you should now see a list of those posts under the preview section at the bottom.</p>
<h3>Saving &amp; testing the view</h3>
<p>Click on <strong>Save</strong> to save the view.</p>
<p>You can test the view by going to the path you entered in the first part of this example.</p>

57
help/example-recent-stories.html
View File

@ -1,57 +0,0 @@
In this example you will create a list of nodes of the content type "story", to be shown in a block. Through this step-by-step process, you will become familiar with some basic steps in creating a view, and familiarize yourself with the Views User Interface.
<ol>
<li><h3>Creating a new view</h3>
<p>Go to <a target="_blank" href="base_url:admin/structure/views/add">add new view</a>. Give your new view the name 'recent_stories', description 'Recent Stories', tag 'story', type 'Node' and click <strong>Next</strong>.</p></li>
<li><h3>About the interface</h3>
<p>You have been brought to Views User Interface. As you start, you are editing the "Default" options for the view. In the 1st column on the left you can see the drop-down menu offers 'block', for example, to select settings specific only to block views. In the remaining columns, you will be able to add or change options by clicking on links or icons. These options will then appear below this main area. Most likely, you will need to scroll a bit to see the options appear.</p></li>
<li><h3>Selecting the fields to display</h3>
<ol>
<li>In 3rd column locate the <strong>Fields</strong> options. Click the <strong>+</strong> icon to add fields.</li>
<li>Scroll down to <strong>Defaults: Add fields</strong>. In the <strong>Groups</strong> drop-down menu select 'Node', then check the following two fields: <em>Node: Post date</em>, <em>Node: Title</em>. Then click <strong>Add</strong>.</li>
<li>You will be taken through the fields you added one at a time. Make the changes specified below.
<ul>
<li>For the <em>Post date</em> field: Delete the 'Post date' label. Change the <strong>Date format</strong> to <em>Custom</em>, and the <strong>Custom date format</strong> to 'F j, Y, g:i a' (do not type the single quotes; for the meaning of these letter codes, click on <em>the PHP docs</em> link under that box to arrive at the explanation). Click <strong>Update</strong>.</li>
<li>For the <em>Title</em> field: Delete the 'Title' label. Select <em>Link this field to its node.</em> Click <strong>Update</strong>.</li>
</ul>
</li>
<li>Scroll back up to <strong>Fields</strong> and click the <strong>&uarr;&darr;</strong> icon to rearrange fields.</li>
<li>Drag the four-sided arrow next to <em>Node: Title</em> so that it appears above <em>Node: Post date</em>. Click <strong>Update</strong> to save the new field order.</li>
</ol>
</li>
<li><h3>Filtering to <em>story</em> nodes only</h3>
<ol>
<li>Click the <strong>+</strong> icon next to <strong>Filters</strong>.</li>
<li>In the <strong>Groups</strong> drop-down menu select 'Node', then check the <em>Node: Published</em> and <em>Node: Type</em> filters, and click <strong>Add</strong>.</li>
<li>Select the <em>Published</em> checkbox. Click <strong>Update</strong></li>
<li>Select <em>Is one of</em> and check <em>Story</em> in the <em>Node Type</em> field. Click <strong>Update</strong>.</li>
</ol>
</li>
<li><h3>Sorting to show most recent first</h3>
<ol>
<li>Scroll up to <strong>Sort criteria</strong> and click the <strong>+</strong> icon.</li>
<li>In the <strong>Groups</strong> drop-down menu below, select 'Node', then check <em>Node: Post date</em>, and click <strong>Add</strong>. Alternatively, you may instead check <em>Node: Last comment time</em>, or <em>Node: Updated/commented date</em>, or <em>Node: Updated date</em>.</li>
<li>Select <em>Descending</em> <strong>Sort order</strong>. Click <strong>Update</strong>.</li>
</ol>
</li>
<li><h3>Refining the basic settings</h3>
<ul>
<li>In 1st column under <strong>Basic settings</strong> locate these options:
<ul>
<li><em>Items to Display</em> setting, click <em>10</em>. Change the '10' to '4'. Click <strong>Update</strong></li>
<li><em>Style</em> setting, click <em>Unformatted</em>. Change to <em>List</em>. Click <strong>Update</strong>.</li>
</ul>
</li>
</ul>
</li>
<li><h3>Adding a block display for custom options</h3>
<ol>
<li>In the dropdown on the left, ensure that <em>Block</em> is selected, and click <strong>Add Display</strong>.</li>
<li>Under <strong>Block settings</strong>, click the <em>None</em> link next to the <em>Admin</em> setting. Change <strong>Block: Block admin description</strong> to 'Recent Stories'.</li>
</ol>
</li>
<li><h3>Saving the view</h3>
<p>Click <strong>Save</strong> to save your work.</p></li>
<li><h3>Instructing Drupal to show the block</h3>
<p>Finally, you should tell Drupal to show this block. Configure your block by going to <a target="_blank" href="base_url:admin/structure/block">admin/structure/block</a>. Locate the block in the list: it is labeled <em>Recent Stories</em>. Place this block in a region and click <strong>Save</strong>. You may click <em>Configure</em> to set a different title, to determine which roles can view the block, and on which pages it appears; If you want your block on the front page only, enter '&lt;front&gt;'.</p></li>
</ol>

54
help/example-slideshow-thumb-pager.html
View File

@ -1,54 +0,0 @@
<p>In this example you will create a views block that displays images in a slideshow using thumbnails of the images as a pager underneath the slideshow. This will demonstrate using <em>Views Slideshow </em>and <em>Image Styles</em> to display images.</p>
<p>For this example, we are going to display a single image from each content item of the type &quot;Photos&quot;, which we assume you have already set up with an image field. We are also assuming that <em>Views Slideshow</em> and at least one plugin is installed and activated.</p>
<h3>Creating the image styles</h3>
<p>The first step is creating the right image styles to display the images from the node. We will create one for the slideshow image, and one for the pagers. Go to <a target="_blank" href="base_url:admin/structure/views/add">Image Styles</a> and create the following two styles:</p>
<dl>
<dt>Style name</dt>
<dd>slideshow_image</dd>
<dt>Effects</dt>
<dd>Scale and crop: 600px wide, 400px high</dd>
</dl>
<dl>
<dt>Style name</dt>
<dd>slideshow_thumbnail</dd>
<dt>Effects</dt>
<dd>Scale and crop: 30px wide, 20px high</dd>
</dl>
<h3>Creating the View and block</h3>
<p>The next step is creating a view for the slideshow. Because the block will show the images in content, this view is considered a "Content" view. Go to <a target="_blank" href="base_url:admin/structure/views/add">add new view</a>, enter the following properties, and click <strong>Next</strong>:</p>
<dl>
<dt>View name</dt>
<dd>Photo Slideshow</dd>
<dt>Description</dt>
<dd>Slideshow of images from Photos.</dd>
</dl>
<p>Choose <strong>Show</strong> <em>Content</em> <strong>of type</strong> <em>Photos</em>. You can choose any way you wish to sort the content.</p>
<p>Untick the box next to <strong>Create a page</strong> and tick the box next to <strong>Create a block</strong>. Enter a block title and choose Slideshow from the <strong>Display format</strong> select box. Select <em>fields</em> from the other select box. Leave the remaining settings as they are.</p>
<p>Click on <strong>Continue &amp; edit</strong>.</p>
<h3>Editing the view settings</h3>
<p>Turn off the pager by clicking on <strong>Display a specified number of items</strong> in the middle column and selecting <strong>Display all items</strong> in the next screen, and applying the settings.</p>
<p>Enter a Block name by clicking on <strong>None</strong> at the top of the middle column.</p>
<p>Next, remove the <em>Content: Title</em> field from the fields list in the left column by blicking on <strong>rearrage</strong> under the arrow.</p>
<p>Next we have to add the thumbnail image field. Click on <strong>Add</strong> under the fields section and select your image field from the list. In the next screen, turn off the label, select <em>Exclude from display</em> and select <em>slideshow_thumbnail</em> from the Image Style select box. Under MORE, enter <em>Thumbnail</em> under Administrative Title.</p>
<p>Click on <strong>Apply (all displays)</strong>.</p>
<p>Now we have to add the image field to display in the slideshow. Clcik on <strong>Add</strong> under the fields section and select your image field from the list. In the next screen, turn off the label and select <em>slideshow_image</em> from the Image Style select box. Under MORE, enter <em>Display Image</em> under Administrative Title.</p>
<p>Click on <strong>Apply (all displays)</strong>.</p>
<h3>Editing the slideshow settings</h3>
<p>Click on <strong>Settings</strong> next to Format: Slideshow in the first column. In the screen that opens we can choose the options for our slideshow.</p>
<p>For the purpose of this example, we will only add the thumbnails as a pager, and leave the remaining slideshow settings as they are. Select the tick box next to <em>Pager</em> under Bottom Widgets. Select <em>Fields</em> from the Pager Type select box. Select the tick box next to <em>Thumbnail</em>.</p>
<p>Click on <strong>Apply (all displays)</strong>.</p>
<h3>Saving &amp; testing the view</h3>
<p>Click on <strong>Save</strong> to save the view.</p>
<p>You can test the view by adding the block you have created to your theme.</p>

73
help/example-user-feed.html
View File

@ -1,73 +0,0 @@
<p>In this example you will create a <em>Feed display</em> to show nodes by individual users, dynamically selected through the URL. You will become familiar with the Views 2 interface, as well as learn how to use an argument to pull in a user name and use it in a dynamically created path.</p>
<p>A <em>feed</em> is a data format that places your site's content into a file that can be read and displayed by news reader programs. When visiting a site, you may notice a small <a href="http://drupal.org/misc/feed.png">RSS transmission icon</a>, whereby clicking on it, you can subscribe to the site's most recent content. This makes it easier for your visitors to keep up to date with your website. You can also use this format to aggregate information into other sites. For more information, please watch a video from Common Craft about <a href="http://www.commoncraft.com/rss_plain_english">RSS in plain English</a>.</p>
<p>Note, Drupal automatically creates a feed for your website, but you may want to create feeds with specific information. In this case, a list per user. </p>
<ol>
<li>
<h3>Creating a new view </h3>
<ol>
<li>Go to <a target="_blank" href="base_url:admin/structure/views/add">add new view</a>. Give it the name 'user_feed', description 'A feed of user nodes.', tag 'users', type 'Node' and click Next.</li>
</ol>
</li>
<li><strong>About the Interface.</strong> You have been brought to the Views User Interface. As you start, you are editing the &quot;Default&quot; options for the view. In the 1st column on the left- you can see the pull-down menu offers 'Feed', for example, to select settings specific only to RSS views. In the remaining columns, you will be able to add or change options by clicking on links or icons. These options appear below this main area. Most likely, you will need to scroll to see the options appear. As you make changes, these options will appear in bold until you save your view.</li>
<li>
<h3>Change default display</h3>
<ol>
<li>Under <strong>Basic Settings</strong> in the 2nd column, click <em>Row style: Fields</em></li>
<li>A menu loads below, <em>Defaults: How should each row in this view be styled</em>, check the <em>Node</em> option, and click <strong>Update</strong>.</li>
<li>This loads another options menu, <em>Defaults: Row style options</em> click <strong>Update</strong>.</li>
</ol>
</li>
<li>
<h3>Create the RSS view </h3>
<ol>
<li>In the 1st column, select 'Feed' in the drop-down menu, and click <strong>Add Display</strong>.</li>
<li>Under <strong>Basic Settings </strong>in the 2nd column, click<em> Row style:Missing style plugin</em></li>
<li>Note, options appear below the Views Interface, you may need to scroll to see <em>Feed: How should each row in this view be styled</em><br />
tick <strong>Node</strong>, then <strong>Update</strong></li>
<li>This loads the next options menu- <em>Display type: </em>select &quot;Use default RSS settings&quot;, click <strong>Update</strong>.</li>
</ol>
</li>
<li>
<h3>Set the path for accessing your feed</h3>
<ol>
<li> In the 2nd column under <strong>Feed settings</strong>, click <em>Path: None </em></li>
<li>In options below <em>Feed: The menu path or URL of this view</em> enter in the path with an argument feeds/%/rss.xml</li>
<li>Click <strong>Update</strong></li>
</ol>
</li>
<li>
<h3>Set up your arguments to say which user's nodes to display</h3>
<ol>
<li>To the right of <strong>Arguments</strong>, click the + sign to add and argument</li>
<li>In the Feed: Add arguments menu that loads below, select User in the pull-down menu</li>
<li>Check the box <em>User: Name</em>, click <strong>Add</strong></li>
<li>Scroll down to options to find <strong>Case in path:</strong> select <em>Lower case</em></li>
<li>Check the box <em>Transform spaces to dashes in URL</em></li>
<li>Click <strong>Update default display</strong></li>
</ol>
</li>
<li>
<h3>Sort to show most recent at top of feed</h3>
<ol>
<li>Scroll up to <strong>Sort criteria</strong> in the right most column and click the + icon.</li>
<li>In the <strong>Groups</strong> drop-down menu below, select 'Node', then check <em>Node: Post date</em>, and click <strong>Add</strong>. </li>
<li>Select <em>Descending</em> <strong>Sort order</strong>. Click <strong>Update</strong>.</li>
</ol>
</li>
<li>
<h3>Set filters to hide unpublished entries</h3>
<ol>
<li>Click the + icon next to <strong>Filters</strong>. In the options below, select <em>Node</em> under <strong>Groups</strong> drop-down menu, choose the <em>Node: Published</em> filter, and click <strong>Add</strong>.</li>
<li>Check the box <em>Published</em>. Click <strong>Update default display</strong></li>
</ol>
</li>
<li>
<h3>Test</h3>
<ol>
<li>Click <strong>Save</strong></li>
<li>Under <strong>Live preview</strong> type in the name of a user, in lowercase, replacing spaces with dashes, click <strong>Preview</strong>.</li>
<li>You should test and find your feeds at URLs like http://yoursite.com/feeds/user-name/rss.xml</li>
<li>You can use this path for aggregating on another site. You can also attach the RSS feed to another display of view to make the feed link appear on that display.</li>
</ol>
</li>
</ol>

47
help/example-users-by-role.html
View File

@ -1,47 +0,0 @@
In this example you will create a page view listing users on your site. Through this step-by-step process, you will become familiar with some basic steps in creating a view, and familiarize yourself with the Views User Interface.
<ol>
<li><h3>Creating a new view</h3>
<p>Go to <a target="_blank" href="base_url:admin/structure/views/add">add new view</a>. Give your new view the name 'user_list', description 'A simple user listing.', tag 'users', type 'User' and click <strong>Next</strong>.</p></li>
<li><h3>About the Interface</h3>
<p>You have been brought to the Views User Interface. As you start, you are editing the "Default" options for the view. In the 1st column on the left you can see the drop-down menu offers 'block', for example, to select settings specific only to block views. In the remaining columns, you will be able to add or change options by clicking on links or icons. These options will then appear below this main area. Most likely, you will need to scroll to see the options appear. As you make changes, these options will appear in bold until you save your view.</p></li>
<li><h3>Creating a page display; choosing a URL and creating a menu link</h3>
<ol>
<li>In the 1st column, ensure that 'Page' is selected in the drop-down menu, and click <strong>Add Display</strong>.</li>
<li>Next we'll define the path for this page. A page must have a path, and we define it early so that Views doesn't warn us "Display Page uses path but path is undefined." Locate the <strong>Page settings</strong> in the 2nd column, and click the <em>None</em> link next to the <em>Path</em> setting. In the options editing area that appears below, set the path to 'user_list' (or something Implement you prefer) and click <strong>Update</strong>.</li>
<li>Next to <em>Menu</em> setting, Click the <em>No menu</em> link. In the options which appear below, select <em>Normal menu entry</em>, and set the title to 'User list' and click <strong>Update</strong>.</li>
<li>Scroll up to <strong>Basic settings</strong>, in that same 2nd column, and click the <em>No</em> link next to <em>Use pager</em>. Below, in the options, select <em>Full pager</em> and click <strong>Update default display</strong>.</li>
</ol>
</li>
<li><h3>Selecting the fields to display</h3>
<ol>
<li>In 3rd column locate the <strong>Fields</strong> options. Click the <strong>+</strong> icon to add fields.</li>
<li>Scroll down to <strong>Defaults: Add fields</strong>. In the <strong>Groups</strong> drop-down menu select 'User', then check the following fields: <em>User: Created date</em>, <em>User: Delete link</em>, <em>User: Edit link</em>, <em>User: Last access</em>, <em>User: Name</em> and <em>User: Picture</em>. Then click <strong>Add</strong>.</li>
<li>You will be taken through the fields you added one at a time. Click <strong>Update default display</strong> to go to each next field. Leave the default options on all fields except <em>Delete link</em>; change that field's label to 'Operations'.</li>
<li>Scroll back up to <strong>Fields</strong> and click the <strong>&uarr;&darr;</strong> icon to rearrange fields. Down below, drag the <em>Name</em> field, by dragging its four-sided arrow, to the top. Drag the <em>Delete link (Operations)</em> field to the bottom, and the <em>Edit link</em> field just above it. Then click <strong>Update</strong>.</li>
</ol>
</li>
<li><h3>Seeing what we've done so far</h3>
<p>At this point, you have done enough to create a valid view. If you scroll down, you will see a preview of your view. If it doesn't show already, click the <strong>Preview</strong> button; but generally this display updates automatically whenever you finish working in one of the mini forms.</p></li>
<li><h3>Styling the view as a table; combining related fields into columns</h3>
<ol>
<li>Under <strong>Basic settings</strong>, in the 1st column, click the <em>Unformatted</em> link next to the <em>Style</em> setting. In the options below, under <strong>Page: How should this view be styled</strong>, choose <em>Table</em> and click <strong>Update default display</strong>.</li>
<li>You will be taken to a <strong>Page: Style options</strong> form to edit the table settings. Locate our <em>Edit link</em> field in this mini form, and notice the <strong>Column</strong> drop-down. Change this drop-down to show <em>Operations</em>. In the <strong>Separator</strong> column next to the <em>Operations</em> field, type ' | ' (note the spaces around the <strong>|</strong> symbol). Check all of the <strong>Sortable</strong> checkboxes, and set <strong>Default sort</strong> to <em>Name</em>. When finished, click <strong>Update default display</strong>.</li>
</ol>
</li>
<li><h3>Filtering the user list to exclude unwanted entries</h3>
<ol>
<li>Click the <strong>+</strong> icon next to <strong>Filters</strong>.</li>
<li>In the <strong>Groups</strong> drop-down menu select 'User', then check the <em>User: Name</em> filter, and click <strong>Add</strong>.</li>
<li>Select <em>Is not one of</em> and enter 'Anonymous' in the <strong>Usernames</strong> box. Click <strong>Update default display</strong>.</li>
</ol>
</li>
<li><h3>Adding an argument to list users by role dynamically</h3>
<ol>
<li>Scroll up to <strong>Arguments</strong>, and click its <strong>+</strong> icon.</li>
<li>Check the <em>User: Roles</em> argument, and click <strong>Add</strong>. Set the title to '%1' (don't type the quotes), and under <strong>Action to take if argument is not present</strong> select <em>Summary, sorted ascending</em>. Leave the other settings as they are. Click <strong>Update default display</strong>, and click <strong>Update</strong> through the prompts that follow to accept their default values.</li>
</ol>
</li>
<li><h3>Saving the view</h3>
<p>Finally, click the <strong>Save</strong> button to save your work. At the very top, click <strong>View "Page"</strong> to go to your new view!</p></li>
</ol>

24
help/exposed-form.html
View File

@ -1,24 +0,0 @@
This is used when you want to position the exposed form in the sidebar or anywhere else, but not with the view. Instead, a block will be made available to the Drupal block administration system, and the exposed form will appear there. Note that this block must be enabled manually, Views will not enable it for you.
To do this select "Exposed form in block: Yes" and choose one option from "Exposed form style".
<dl>
<dt>Basic</dt>
<dd>When you expose a form and the view is loaded, no filter is selected and all items will displayed.</dd>
<dt>Input required</dt>
<dd>When you expose a form and the view is loaded, only the filter settings are shown. After you select one filter and hit the apply button, the items willi be shown.</dd>
</dl>
You have several options to customize the appearance of the exposed forms:
<dl>
<dt>Submit button text</dt>
<dd>Text to display in the submit button of the exposed form.</dd>
<dt>Include reset button</dt>
<dd>If checked the exposed form will provide a button to reset all the applied exposed filters</dd>
<dt>Reset button label</dt>
<dd>Text to display in the reset button of the exposed form.</dd>
<dt>Exposed sorts label</dt>
<dd>Text to display as the label of the exposed sort select box.</dd>
<dt>Ascending</dt>
<dd>Text to use when exposed sort is ordered ascending.</dd>
<dt>Descending</dt>
<dd>Text to use when exposed sort is ordered descending.</dd>
</dl>

27
help/field.html
View File

@ -1,27 +0,0 @@
Fields are the individual pieces of data being displayed. Adding the fields <em>Node: Title</em>, <em>Node: Type</em>, and <em>Node: Post date</em> to a node view, for example, includes the title, content type and creation date in the displayed results).
Fields may not appear on every display, because not all style plugins actually use <a href="topic:views/style-fields">fields</a>. For example, the '<a href="topic:views/style-node">node</a>' <a href="topic:views/style-row">row plugin</a> simply displays the node through Drupal's normal mechanisms, and fields are not involved.
For the most part, the field settings should be self explanatory. Fields will appear in the order that they are arranged in, and they will usually appear with the label they are given.
If you add new cck fields you will find them under the Group "Content". Search for the field name. With new modules the list of groups will grow. Modules can add new items with the <em>hook_views_data()</em> hook.
If you do not find a field, consider whether or not you need a <a href="topic:views/relationship">Relationship</a>.
You can override the entire field section - see <a href="topic:views/overrides">here</a> for more information.
When a field is added, the "Configure field" modal opens. It has a dropdown at the top that lets you choose what display this field configuration is valid for (ie, this display, or all displays.)
You start by configuring three checkboxes:
<ul>
<li>Create a label: when checked, this opens a textbox that can be filled out to label the field. </li>
<li>Exclude from display: Loads the field, but hides it from general view. This is useful for grouping fields by hiding the group from the user's view.</li>
<li>Link this field to the original piece of content: overrides any default link set up.</li>
</ul>
Style settings give you several options for wrapping an HTML element around a field; title, for example, can be wrapped in an H1-H6, a SPAN, DIV, etc. It can also be given a particular identifying CSS class of its own here. You can do the same with the label or do them both at the same time. This is part of the Semantic Views integration. Alternately, you can leave the default Views classes to identify the field and content.
If you have No Results, you can customize that in this modal also. You have the options to count 0 as empty, or to hide the entire field if it's empty.
Next up is the Rewrite results: all the options you need to rewrite the output of the field with tokens, custom text, a link, etc. If your field is output as a link using the <strong>Output this field as a link</strong> option, you can include the "Alt" text for a link hover in a Title attribute. This is important for accessibility.
The last section is the administrative title, which just gives you a place to give the field a special name on the admin screen in case you have more than one copy.

35
help/filter.html
View File

@ -1,35 +0,0 @@
Filters are used to reduce the data set that Views provides. That is to say, without any filters applied, Views will return all of your content. You don't want that, so at least some filters must be used.
Some very commonly used filters:
<ul>
<li> The 'Node: Published' filter is used to restrict a node View to only nodes that are are have the 'published' box checked. This can be very important to prevent users from viewing content they should not have access to.</li>
<li> The 'Node: Promoted to front page' filter can be used to show only nodes that have the 'promote to front page' turned on. </li>
<li> The 'Node: Type' filter is useful for showing only certain types of nodes. Let's say you wanted users to see only nodes that were 'book' nodes, or a combination of 'book' nodes and 'staff-blog' nodes. This filter allows you to select exactly that.</li>
<li> The 'User: Current' filter will show only nodes that the logged in user has authored.</li>
<li> The 'Node: Post date' filter can be used to show only nodes posted before, after, or between a range of dates.</li>
</ul>
The above list is only a tiny fraction of the filters available in Views, referenced here to give an idea of the kinds of tasks filters can accomplish. When you do not find a filter type, you may need to choose a <a href="topic:views/relationship">Relationship</a> before the expected filter will show, or to install a new module that contains the requested filter.
When you click the Rearrange Icon you can first rearrange your filters, easily delete filters and select an operator: "AND" or "Or". By default the "AND" operator is selcted. At the lower right of the window is the new button "Add new group". When you click on it, you can drag and drop an individual filter to the new group "Group 1". For this new group and the default group you can select the "Group operator": "And" or "Or". To remove a group, remove all filters and click the "Remove group 1" button.
When you want that the user to select their own filter, you can expose the filter. A selection box will show for the user and they will be able to select one item. After that the view will reload and only the selected item will be displayed. You can also choose to expose the selection to a block, see <a href="topic:views/exposed-form">here</a>.
For exposed filters, you can create a grouped filter. When filters are in a group, each item of the group represents a set of operators and values. The following table illustrates how this feature works. The values of the first column of the table are displayed as options of a single select box:
<table>
<thead>
<tr><th>What the user see</th><th>What views does</th></tr>
</thead>
<tbody>
<tr><td>Is lower than 10</td><td><strong>Operator:</strong> Is Lower than. <strong>Value:</strong> 10</td></tr>
<tr><td>Is between 10 and 20</td><td><strong>Operator:</strong> Is between. <strong>Value:</strong> 10 and 20</td></tr>
<tr><td>Is greater than 20</td><td><strong>Operator:</strong> Is Greater. <strong>Value:</strong> 20</td></tr>
</tbody>
</table>
<strong>Please note:</strong> When using grouped filters with the option: 'Enable to allow users to select multiple items' checked, you probably may want to to place the filter in a separated group and define the operator of the group as 'OR'. This may be neccesary because in order to use multiple times the same filter, all options have to be applied using the OR operator, if not, probably you will get nothing listed since usually items in a group are mutually exclusive.
Taxonomy filters have been significantly altered in Views 7.x-3.x. D7 significantly re-organized taxonomy, there was a lot of duplicate taxonomy related fields and filters. Some of them were removed to try and reduce confusion between them. Implicit relationships to taxonomy have been removed, in favor of explicit relationships. If the filters you can find don't do what you need, try adding either the related taxonomy terms relationship, or a relationship on the specific taxonomy field. That will give you the term specific filters.
You can override the complete filter section - see <a href="topic:views/overrides">here</a> for more information.

16
help/get-total-rows.html
View File

@ -1,16 +0,0 @@
The flag $view->get_total_rows is used to force the query of the view to calculate the total number of results of the set.
This parameter is TRUE by default in views that get all the results (no limit) or those which have a pager, so you always have the $view->total_rows variable populated in those cases.
But when you have a view that gets only a given number of results and no pager, the count query is not executed by default so you have to force it, i.e. in the hook_views_pre_execute so you have $view->total_rows populated for later use.
This code will help you do that.
<pre>
&lt;?php
function my_module_views_pre_execute(&$view) {
if ($view->name == 'my_view' && $view->current_display == 'my_display') {
$view->get_total_rows = TRUE;
}
}
?&gt;
</pre>

23
help/getting-started.html
View File

@ -1,23 +0,0 @@
For those new to Views, it can be a complex system that appears totally overwhelming. The good news is that the UI is designed to compartmentalize everything; this means that for the most part, you can ignore the parts you're not interested in. Start small and build your way up.
Because of this, the edit UI can seem overwhelming at first, but there are really just a few things you <strong>have</strong> to know. The rest you can find through exploration. The Views Edit UI image, below, gives an overview of what you'll find on the edit UI.
<div class="help-box" style="text-align:center">
<a href="path:images/overview-ui-large.png"><img src="path:images/overview-ui-small.png" /></a>
<em>The Views Edit UI</em>
</div>
Notes:
1) Every view has a number of <a href="topic:views/display">displays</a> which represent where output will be placed. If you're familiar with the original Views 1, you could set a view to be a 'page', with a URL (path), or a block that could show up in a sidebar. With Views 2, you can add as many displays as you like. In addition, you have the <em>default</em> display which contains the basic settings, but doesn't actually show up anywhere.
2) When you click on the link for an item, a form will open up. For browsers with smaller resolutions, you may have to scroll down a little to see this form. If a form is open, the item its attached to will be highlighted.
3) <a href="topic:views/overrides">Overrides</a> mean that a particular display is <strong>not</strong> using default settings. When you create a new display, many of its settings will start off using default values. This will be indicated by italics and a lighter color. <strong>If you change these values without first overriding them, you will change the default value for all displays that use them.</strong>
4) Some items, particularly styles, have additional settings. Ordinarily when you <em>update</em> a style, if it has additional settings you will automatically see that form next. Often, you will need to go directly to those settings.
5) You can safely leave a view page to go and do other things. If you come back, the view will still be there, stored in a cache. Keep in mind, however, that while you do this, that view is <em>locked</em>, meaning another user cannot edit this view without breaking the lock. Breaking the lock will discard your changes.
6) Don't forget permissions. Views installs with two default permissions. Users with access all views permissions will have access to all views. Users with administer views permissions will be able to edit and change views. If you are trying to restrict access based on role, make sure that the role does not have access all views checked.
It helps to have something particular in mind that you want to accomplish when using Views. Here are a couple of ideas and a brief sketch of how to accomplish what you want.

17
help/group-by.html
View File

@ -1,17 +0,0 @@
This is another major new feature for Views that has been long requested. It incorporates another module that has seen a relatively wide amount of use: views_groupby. This feature provides multiple new options for manipulating data. First, it includes the important “group” SQL functionality, and then enables aggregation functions for Views, such as SUM and COUNT.
<div class="help-box" style="text-align:center">
<a href="path:images/views3-group-aggregation.png"><img src="path:images/views3-group-aggregation.png" /></a>
<em>Where to set aggregation to get group settings</em>
</div>
Grouping is available for sorts and filters. To use grouping, “Use grouping” must be enabled on a per-view basis in the Views UI. This is toggled in the Advanced settings box by clicking the link next to “Use grouping”. Once you activate this checkbox (be sure to read the notes in the UI!), functions for aggregating particular fields will become available. The gear icon that should be familiar to users with any amount of Views experience will now appear next to any sorted or filtered field with aggregation capabilities. Choosing that icon will open up the configuration for the aggregation functions. As an example, this could be used to count things like number of posts in a day, or number of published posts. This could also be used to sum the values of a row, instead of everything in the view.
Setting only the "Use aggregation" turned on itself does nothing. It only gives the possibility to set Aggregation types.
<div class="help-box" style="text-align:center">
<a href="path:images/views3-group-aggregation-types.png"><img src="path:images/views3-group-aggregation-types.png" /></a>
<em>Different aggregation possibilities</em>
</div>
It should be noted that modules that are providing data to Views are responsible for noting whether a field supports aggregation or not; modules that do not provide this information may not have all of their fields available to Views if this data is not in place.

3
help/header.html
View File

@ -1,3 +0,0 @@
In this section you can choose one or more areas, by default a text area, which will display above the view output.
You can override the complete header section - see <a href="topic:views/overrides">here</a> for more information.

BIN
help/images/node-term_node-term_data-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.0 KiB

BIN
help/images/node-term_node-term_data.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.4 KiB

BIN
help/images/overview-ui-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 82 KiB

BIN
help/images/overview-ui-small.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 44 KiB

BIN
help/images/style-breakdown-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 46 KiB

BIN
help/images/style-breakdown.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 15 KiB

BIN
help/images/views1-admin-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 66 KiB

BIN
help/images/views1-admin.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 24 KiB

BIN
help/images/views1-changeviewtype-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 36 KiB

BIN
help/images/views1-changeviewtype.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 17 KiB

BIN
help/images/views2-addaview-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 45 KiB

BIN
help/images/views2-addaview.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 19 KiB

BIN
help/images/views2-adddisplay-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 42 KiB

BIN
help/images/views2-adddisplay.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

BIN
help/images/views2-addfields-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 29 KiB

BIN
help/images/views2-addfields.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

BIN
help/images/views2-addfieldsajax-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 26 KiB

BIN
help/images/views2-addfieldsajax.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 16 KiB

BIN
help/images/views2-admin-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 52 KiB

BIN
help/images/views2-admin.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

BIN
help/images/views2-changedisplaystyle-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 42 KiB

BIN
help/images/views2-changedisplaystyle.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 16 KiB

BIN
help/images/views2-fieldspreview-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 40 KiB

BIN
help/images/views2-fieldspreview.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 12 KiB

BIN
help/images/views2-newview-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 35 KiB

BIN
help/images/views2-newview.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 17 KiB

BIN
help/images/views2-rearrangefields-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 33 KiB

BIN
help/images/views2-rearrangefields.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 19 KiB

BIN
help/images/views2-tablestyle-large.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 38 KiB

BIN
help/images/views2-tablestyle.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

BIN
help/images/views3-group-aggregation-types.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 16 KiB

BIN
help/images/views3-group-aggregation.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 54 KiB

BIN
help/images/views3-jump-style-menu.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 39 KiB

BIN
help/images/views3-semanticviews.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.5 KiB

BIN
help/images/views3-views-all.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 38 KiB

21
help/menu.html
View File

@ -1,21 +0,0 @@
Page displays can hook into the Drupal menu system and provide <strong>menu links</strong> that will appear in the Navigation system as well as <strong>tabs</strong> that can be used to keep Views next to each other.
For simple <strong>menu links</strong>, there is very little you need to do; simply select 'Normal menu entry' and fill in the text for the title. This will appear in the Navigation menu by default; you will need to visit the menu administration page to move this to another menu.
Tabs are not quite so simple; there are some complex rules for using tabs in Drupal.
<ol>
<li> All tabs must have a parent, which is the next level up in the path hierarchy. For example, if the view path is 'example/taba' then the parent must be 'example'.
<li> All tabs must have one and only one default tab; this is usually the same content as the parent.
<li> If a parent does not exist, when creating the 'default' tab, Views will allow you to also create a parent item. It will automatically set up the URL for you when it does this.
<li> Tab weight is used to control what order the tabs are displayed in. Lower numbers will display more to the left. For tabs whose numbers are the same, they will be displayed alphabetically.
<li> Drupal only supports 2 levels of tabs, so be careful about trying to put tabs within tabs within tabs. That won't work.
</ol>
For example, if you have two views that you want to be tabs, you could set it up like this:
<ul>
<li> In the first view, set the path to 'tabs/tab1'. Set it to be the 'default tab', set the title to 'Tab 1' and the weight to 0.
<li> Click update and you will be taken to a form that lets you define the parent. Since 'tabs' doesn't already exist in the system, select 'Normal menu item', and set the title to 'Tabs'.
<li> On the second view, set the path to 'tabs/tab2'; set it to be a 'Menu tab', and set the title to 'Tab 2'.
</ul>
With this done, you will now have a Navigation link named 'Tabs' and when you click on it, you will go to the tabs, with 'Tab 1' being the default tab that appears. You can then click between Tab 1 and Tab 2.

11
help/misc-notes.html
View File

@ -1,11 +0,0 @@
<h3>Image Assist &amp; ImageField Assist</h3>
Under certain conditions these modules can block access to the header input section of the admin.
They need to be disabled on certain views paths. To do this go to
Image assist ->Access settings
check "NOT on specific paths":
and enter
Drupal 7.x has different paths
admin/structure/views/ajax/display/*
admin/structure/views/ajax/*
For futher reference please see <a href="http://drupal.org/node/415990">this issue for more information</a>

131
help/new.html
View File

@ -1,131 +0,0 @@
Views 3 is the newest major release of Views and is coded for Drupal 6. Views 3 retains all of the core functionality of previous releases, together with a completely revamped user interface and a large set of new features.
Major new features (these need help files):
<ol>
<li>Views Or has been incorporated.</li>
<li><a href="topic:views/semantic-views">Semantic views</a> have been incorporated.</li>
<li><a href="topic:views/group-by">Group by</a> possibility.</li>
<li>The Jump Menu style has been added.</li>
<li>The Panel Fields style has been added.</li>
<li>Pluggable back ends</li>
<li>Pluggable text areas, pagers, and forms</li>
<li>Translation plugin</li>
<li>Exposed sorts</li>
<li>Reliance on CTools</li>
</ol>
Everything below this point is subject to change based on the new Views wizard and UI in 7.x.
<p>Note: Only UID 1 or users with the "Use PHP code" permission from the phpfilter module will be able to import views.</p>
<h2>Admin interface</h2>
The first thing that pops out after you install Views 2 is the radically different admin interface:
<div class="help-box" style="text-align:center">
<a href="path:images/views2-admin-large.png"><img src="path:images/views2-admin.png" /></a>
<em>Views 2 admin interface</em>
</div>
compared to the old comfy Views 1 interface:
<div class="help-box" style="text-align:center">
<a href="path:images/views1-admin-large.png"><img src="path:images/views1-admin.png" /></a>
<em>Views 1 admin interface</em>
</div>
The new admin interface performs the same functions as the old -- listing all the views in the system, providing links to add or import views and a link to Views Tools -- but has been compacted, with each view displayed as a paragraph style-row compared to the table of Views 1 and set of filters on top to ease locating views among a large list.
Context-help is available by clicking the small blue question-mark icon. Context-help in Views 2 is provided by the <a href="http://drupal.org/project/advanced_help">Advanced Help</a> module, so make sure to install that together with installing Views 2. The small blue help icons will be available in various parts of the Views UI. In particular, look for them as part of the description of a <strong>display</strong>, when setting <strong>style</strong> options, and in various editing sections such as <strong>path</strong>, <strong>menu</strong> and the like.
Several new attributes of each view are visible in the filter header:
<ol>
<li><strong>Tag</strong> - This is just another label for organizing and sorting views. Tags can be any text. Views that are provided by modules will often be tagged together to make it easy to find them. Tags are also added to your template suggestions, so take care what you set here. For example setting the tag <i>Page</i> will give all your views the Page template.</li>
<li><strong>Display</strong> - In Views 1 each view query was tied to its display; in other words your fields, sorts, filters, and arguments could only be displayed in the single page or block display provided in the view definition. In Views 2, view displays have been decoupled from view queries - it is now possible to have multiple page, block, and feed displays from a single view. More on view displays later. </li>
<li><strong>Type</strong> - Views 2 view types are radically different from Views 1 types. Views 1 types basically defined how the node list displays were <i>styled</i> - you had Full Nodes, Teaser List, Table View, and so on. In Views 2 view display styles have been broken out into the separate <i>Style</i> attribute. View types now refer to the primary table on which information for the query will be retrieved which controls what arguments, fields, sort criteria and filters are available. Views 2 view types are discussed later.
</li>
</ol>
<h2>Adding a view</h2>
So let's jump in and add a view. For this example, we're going to create a <strong>user</strong> view, which will display a list of users.
<div class="help-box" style="text-align:center">
<a href="path:images/views2-addaview-large.png"><img src="path:images/views2-addaview.png" /></a>
<em>Adding a view</em>
</div>
The first step in adding a view is simply entering a name (only alphanumeric characters, no spaces) a description, tag, and the view type. To get the user view, we selected the <strong>User</strong> radio button.
<div class="help-box" style="text-align:center">
<a href="path:images/views2-newview-large.png"><img src="path:images/views2-newview.png" /></a>
<em>Configuring the new view</em>
</div>
This might be the 2nd whoa moment as the interface here is also completely revamped from Views 1.x. The best way to summarize is to say all the pieces from the Views 1.x interface are still there...just in different places. Fields, arguments, sort critera and filters are all still there there, just in new AJAXY-flavours.
Let's start by adding some fields:
<div class="help-box" style="text-align:center">
<a href="path:images/views2-addfields-large.png"><img src="path:images/views2-addfields.png" /></a>
<em>Adding fields</em>
</div>
Clicking on the [+] icon next to the word Fields unfurls a section beneath the view information with all the available fields grouped by Comment, File, Node, Node revision, Taxonomy and User, and probably a few others. This is a general paradigm for the Views 2 interface -- clicking on a widget or link unfurls a section beneath the view information with the relevant interface. Usually, what is being edited will be hilited in yellow, as well.
When adding items, you can use the Groups drop-down box to show only a subset of the fields available according to the above groups, or select All to see all fields available, which is what was selected when the section unfurled. For our example, we're selecting the 'User' group and adding the <strong>User: E-mail</strong>, <strong>User: Name</strong> and <strong>User: Picture</strong> fields.
<div class="help-box" style="text-align:center">
<a href="path:images/views2-addfieldsajax-large.png"><img src="path:images/views2-addfieldsajax.png" /></a>
<em>Adding fields</em>
</div>
Once we add our fields they show up in the Fields section of the interface. We will be walked through each field we added, so keep clicking <strong>update</strong>, even if you don't make changes to the field and you will see the next one.
The fields we added can be rearranged by clicking the up/down icon, right next to the add icon we used earlier. We can also remove a field using the same interface.
<div class="help-box" style="text-align:center">
<a href="path:images/views2-rearrangefields-large.png"><img src="path:images/views2-rearrangefields.png" /></a>
<em>Rearranging fields</em>
</div>
From here, the fields can be dragged up and down by grabbing the little drag handle on the left and moving them where you like. Making a change to any part of the view by clicking update usually triggers a refresh of the view preview which is conveniently located right below the main interface.
<div class="help-box" style="text-align:center">
<a href="path:images/views2-fieldspreview-large.png"><img src="path:images/views2-fieldspreview.png" /></a>
<em>Views preview</em>
</div>
Now that we have some fields set up we can turn our attention to Basic Settings for the view.
It's important to note that all the interface elements pertain to the current <i>Display</i> selected for the view. As mentioned before a view can have multiple displays. The first time you create a view you'll be manipulating the <i>Default</i> display. You can add displays using the Add Display button, whose Basic Settings are completely different from each other; this lets you have as many displays of a view as you would like all sharing items such as Sort Criteria, Filters and Arguments but different display settings like Title, Style, Fields, and Pager settings. Also, any display you add automatically inherits display settings from the default display initially, so you can keep a core of common settings in your default display and add additional settings for every other display.
<div class="help-box" style="text-align:center">
<a href="path:images/views2-adddisplay-large.png"><img src="path:images/views2-adddisplay.png" /></a>
<em>Adding a <strong>Page</strong> display </em>
</div>
Let's stick with the Default display and twiddle some settings. We can set the <i>Title</i> to "User View 1" and the <i>Style</i> to Table. As mentioned earlier, view styles in Views 2 correspond more to view types in Views 1 (remember, List, Table, Teasers, Full nodes).
<div class="help-box" style="text-align:center">
<a href="path:images/views1-changeviewtype-large.png"><img src="path:images/views1-changeviewtype.png" /></a>
<em>Selecting a Views 1 View Type</em>
</div>
In Views 2, view <i>styles</i> control how a view display looks. These styles are significantly different from the Types in Views 1; in particular, types have been 'broken up'; there is now the <em>style</em> as well as the <em>row style</em> which focus on different parts of the output.
<div class="help-box" style="text-align:center">
<a href="path:images/style-breakdown-large.png"><img src="path:images/style-breakdown.png" /></a>
<em>A breakdown of View output</em>
</div>
We change the style by clicking on the current style on the left hand side of the View information area.
<div class="help-box" style="text-align:center">
<a href="path:images/views2-changedisplaystyle-large.png"><img src="path:images/views2-changedisplaystyle.png" /></a>
<em>Selecting a Views 2 Display Style</em>
</div>
We're given the style options of <strong>Grid</strong>, <strong>List</strong>, <strong>Table</strong> and <strong>Unformatted</strong>. Additional display styles can be added by modules which have Views <i>style plugins</i>. Choosing a style reveals a "settings" button which you can click to configure the style you've chosen. In the shot below we've selected and are configuring the Table style, which we're using to produce a more compact output than we had earlier.
<div class="help-box" style="text-align:center">
<a href="path:images/views2-tablestyle-large.png"><img src="path:images/views2-tablestyle.png" /></a>
<em>Selecting and configuring the table style</em>
</div>
... TODO: Finish this document ...

9
help/other-help.html
View File

@ -1,9 +0,0 @@
There are many tutorials, podcasts, and a few books on Views that you can turn to for further help.
Books:
<a href="http://www.drupal-building-blocks.com">Drupal Building Blocks</a> is the Views' author book; check <a href="http://www.drupal.org/books">the Drupal.org books page</a> for a fairly comprehensive list.
Videos:
See <a href="topic:views/demo-video">this page.</a>
Google. Many Drupal shops put together helpful tutorials and publish them to Drupal Planet, not to mention the countless users of Views who do it for the community.

6
help/overrides.html
View File

@ -1,6 +0,0 @@
If an item is <strong>using defaults</strong> then it is using values from the <strong>default <a href="topic:views/display">display</a></strong>. <em>IMPORTANT NOTE:</em> If you modify this value, you are modifying the <strong>default <a href="topic:views/display">display</a></strong> and thus modifying for all displays that are using default values.
If that is not what you intend, you must click the <strong>override</strong> button. Once overridden, that display now has its own version of the value; modifying it will not modify it for other displays. You can override in the settings of the non-default display when you are clicking on the header of the section or on the rearrange button.
For <a href="topic:views/relationship">relationships</a>, <a href="topic:views/argument">arguments</a>, <a href="topic:views/field">fields</a>, <a href="topic:views/sort">sort criterias</a>, and <a href="topic:views/filter">filters</a>, each of these must be overridden as a group! In other words, you cannot override a single filter, but instead must override all filters. A message will appear on the item to let you know what its status is, but you can only change the status by clicking on the header or the rearrange button for that item.

7
help/path.html
View File

@ -1,7 +0,0 @@
If a display has a path that means that it can be retrieved directly by calling a URL as a first class page on your Drupal site. Any items after the path will be passed into the view as arguments. For example, if the path is <strong>foo/bar</strong> and a user visits <strong>http://www.example.com/foo/bar/baz/beta</strong>, 'baz' and 'beta' will be given as arguments to the view. These can be handled by adding items to the <a href="topic:views/arguments">arguments</a> section.
You may also use placeholders in your path to represent arguments that come in the middle. For example, the path <strong>node/%/someview</strong> would expect the first argument to be the second part of the path. For example, <strong>node/21/someview</strong> would have an argument of '21'.
<em>Note:</em> Views 1 used <strong>$arg</strong> for this kind of thing. $arg is no longer allowed as part of the path. You must use % instead.
If multiple displays <strong>within the same view</strong> have the same path, the user will get the first display they have access to. This means you can create successfuly less restricted displays in order to give administrators and privileged users different content at the same path.

5
help/performance-views-vs-displays.html
View File

@ -1,5 +0,0 @@
<p>Multiple displays in one view is <strong>appropriate</strong> when they are <strong>fundamentally similar</strong> and are <strong>sharing quite a fair amount of data</strong>. For example, showing upcoming events in either blocks or page and sorting it according to either event name or date of the event will be appropriate to be implemented by four displays (two blocks and two pages) in one view.</p>
<p>In the other hand, having multiple displays in one view that contains <strong>mostly overrides</strong> will be a burden to the system and will be hard to maintain. The effect of having only couple of such displays has negligible performance difference. It will be magnified when the number of displays in one view is large.</p>
<p>Another consideration is the use of Views, especially when using multiple views in conjunction with other modules such as Panels. It is entirely possible to have many views on a page due to Panels' ability to contain a view in each pane. Some people have mistaken this as a problem on Panels' or Views' part, but realistically it is likely to be the sheer number of queries that are being run during page render. </p>

1
help/performance.html
View File

@ -1 +0,0 @@
<p>Views module is optimized for certain practices. To ensure Views has its best performance, please follow these best practices for Views.</p>

14
help/relationship-representative.html
View File

@ -1,14 +0,0 @@
A representative relationship obtains just one object from the linked in objects.
This is best explained with an example. Suppose you have a term view that shows you the terms in your vocabulary: Horse, Cat, Aardvark.
In addition to the term names, you want to show the title of the most recent node in that term. This would give you a view that shows: Horse - latest horse node title, Cat - latest cat node title, Aardvark - latest aardvark node title.
Each of these is the title of the <em>representative node</em> for that term, chosen by creation time.
Any sort criterion can be used to choose the representative node. You might instead want to show the node with the most comments for each term, the first node in alphabetical order, or if you have a voting module installed, the most popular node.
The options for a representative relationship let you choose a sort criterion and a sort order. This determines how the representative object is chosen: the first object returned by the sort is shown. For example, choose 'Node: title' and 'Ascending' to get the first node by title as the representative; or 'Node: comment count' and 'Descending' to get the node with the most comments.
<h2>Performance</h2>
These relationships require a correlated subquery. This can be slow to run on large amounts of data, as the subquery must be run for every row of the main query.
For more on this topic, see the <a href="http://dev.mysql.com/doc/refman/5.0/en/example-maximum-column-group-row.html">MySQL tutorial on group-wise maximum queries</a>.

17
help/relationship.html
View File

@ -1,17 +0,0 @@
Relationships allow you to expand the query to include objects other than the base query. This is actually made more difficult to understand by the fact that Views actually includes a few relationships by default, and doesn't tell you they're there. For historical reasons, it would be inconvenient to remove these default relationships. When relationships are present, all fields (including relationships) will gain a new form item to let you select which relationship they will use. They will default to using no relationship at all.
The main example of the relationship that is there by default is the node --&gt; user relationship; every node has an author, and if a node is in the query, the user who wrote that node is automatically made available. [Note: the author considers it an error that this relationship is automatic, but by the time it was realized this was in error, it was too late to change it.]
A similar relationship that is <b>not</b> automatically made available is for node revisions. Each revision has its own author, which is the user who made the revision. By adding the "Node revision: User" relationship, all of the 'user' fields, sorts, filters and arguments available to a user will now be available for the revision author.
When a relationship is added to the view, all applicable items will gain a "Relationship" select box, where you can choose which version of that particular item you wish to use. This can be illustrated with an example:
A 'comment' view contains the relationships 'Comment: node' and 'Comment: user'. This means that all the fields for the node that a comment is attached to are available, and all the user fields for that node author also become available. The other relationship makes fields for the author of the comment available -- very often not the author of the node!
When you add the "User: name" field, you will be presented with a select box. Either the node relationship or the user relationship must be selected, because there are two possible user names in the view to choose from.
Another example of relationships involves the <strong>Files</strong> table. In Drupal, files are related to users, but files are not necessarily related to nodes. However, the upload.module allows some files to be attached to nodes. The only way for Views to deal with this discrepancy is with relationships. When creating a 'node' view, it's possible to add an uploaded files relationship to get file data for nodes that were attached with the upload module. It is also possible to go the other way; from a files view you may add a relationship via the Upload table to view information about the node.
Drupal 7 made significant changes to Taxonomy. Because of this, many taxonomy functions Views can perform are now part of relationships. If you can't find the filter you need, add either the related taxonomy terms relationship, or a relationship on the specific taxonomy field.
You can override the complete relationship section - see <a href="topic:views/overrides">overrides</a> for more information.

3
help/reports.html
View File

@ -1,3 +0,0 @@
Visit <a href="/admin/reports/views-fields">admin/reports/views-fields</a> to see an overview of fields usage across all the views.
It's useful to check for unused or misused fields.

28
help/select-multple-nids-contextual-filters.html
View File

@ -1,28 +0,0 @@
We assume that you have a properly configured view at this point. You should have a page or block display with fields/node to be displayed in it.
<ol>
<li>In the views administration screen add a new 'contextual filter' using 'add'. You will see a configuration screen appear as a modal.</li>
<li>In the 'Filter' jump menu that you now see select 'Content'. A list will appear below the jump menu.</li>
<li>In the list look for 'Content: Nid', and check it. </li>
<li>Press the 'Add and configure contextual filters' button. You will now get the configuration screen for 'Content: Nid'.</li>
<li>Under 'When the filter value is NOT in the URL' select 'Provide default argument', and leave it set at 'Fixed value'.</li>
<li>In the field 'Fixed value' add the Nids of the nodes separated by a '+' that you want to show by default.</li>
<li>In 'When the filter value IS in the URL or a default is provided' choose 'Specify validation criteria'. Now select the content types you want, or leave blank for all nodes.</li>
<li>Check the 'Validate user has access to the node'. This will check if a user has permission to view nodes, that are going to be displayed</li>
<li>For the 'Filter value format' select 'Node IDs separated by , or +'.</li>
<li>Select the MORE link.</li>
<li>Check 'Allow Multiple Terms per Argument' and press 'Apply (all displays
)' (or choose a particular display in the dropdown at the top and Apply (this display)). </li>
</ol>
Preview should now show nodes, that you selected as "default argument". You can now pass arguments to your view, to select custom node IDs. If you provide no argument, default will be used. Save the view when ready.

18
help/semantic-views.html
View File

@ -1,18 +0,0 @@
The <a href="http://drupal.org/project/semanticviews">Semantic Views</a> module has been mostly incorporated into Views 3.x. Semantic Views is still around for people who need it, though. For some details on how the original module is different from the Views implementation, please see <a href="http://drupal.org/node/1013876">this issue</a>.
Semantic views help you insert markup of your own from the Views UI, so that you can fairly easily override the default markup without having to restyle via templates.
As a usage example,
In a view with a field:
<ol>
<li>Configure the field. (Click on the field.)</li>
<li>In the modal that opens, scroll down to <strong>Style Settings</strong>.</li>
<li>Choose one or more of the three <i>Customize</i> options. This will reveal a dropdown menu where you can choose from one or more HTML tags to use on that field and allow you to add a CSS class specific to that field should you desire.</li>
<li>Decide if you want to keep the Views default classes. Unchecking this box means your markup is *it*.</li>
</ol>
<a href="path:images/views3-semanticviews.png"><img src="path:images/views3-semanticviews.png" />

28
help/sort.html
View File

@ -1,28 +0,0 @@
Sort criteria determine what order the records are retrieved from the database and displayed in; generally, all you need to do is pick a field and choose ascending (1, 2, 3, 4) or descending (4, 3, 2, 1) and it will be done. If you have multiple sort criteria, the second (and later) items only come into play if the first item is the same.
In Views 3.x, sorts may be exposed just as filters are. Note that if only one item is exposed for sorting, the dropdown menu created by the exposed sort will only have one item in it. Some users may find this odd.
Different data types sort just a little bit differently from others:
<dl>
<dt>Number fields</dt>
<dd>Number fields sort like you would expect. 1 comes before 2 which comes before 10 which comes before 100 which comes before 200, etc.</dd>
<dt>Text fields</dt>
<dd>Text fields always sort alphabetically, even if the text contains numbers. This can have some odd effects if you have numbers stored in text, because the values 1, 3, 7, 10, 12, 20, 100, 120 will sort like this:
<ul>
<li> 1 </li>
<li> 10 </li>
<li> 100 </li>
<li> 12 </li>
<li> 120 </li>
<li> 200 </li>
<li> 3 </li>
<li> 7 </li>
</ul>
This is because these fields sort purely by characters, and not numeric value. i.e, comparing 200 and 3, the '2' comes before the '3', therefore, '200' is "smaller" than '3'.
</dd>
<dt>Date fields</dt>
<dd>Date fields often can have a 'granularity', which is a way of making similar dates actually be the same date. Take two dates that are close to each other: <strong>May 1, 2007 5:30 am</strong> and <strong>May 1, 2007 9:45am</strong>. Without granularity, the two dates are compared and the first date comes before the second date. However, if the granularity is set to 'day' it only looks at the parts of the date up to the day: <strong>May 1, 2007</strong> and <strong>May 1, 2007</strong>. At that point, they are the same, and the sort would move on to the next sort criterion.</dd>
</dl>
You can override the complete sort criteria section - see <a href="topic:views/overrides">here</a> for more information.

1
help/style-comment-rss.html
View File

@ -1 +0,0 @@
This row style is only available to RSS styles. It produces XML necessary for an RSS feed for the comment.

16
help/style-fields.html
View File

@ -1,16 +0,0 @@
The <strong>fields</strong> row style displays each field defined in the view, one after another. Each field defines its own output.
By default, each field is put in a &lt;div&gt; unless it is selected to be <em>inline</em>. If it is inline, it is put in a &lt;span&gt;. Two items in &lt;div&gt;s will be displayed one after another, with the second one below the first. Two items in &lt;span&gt;s will be displayed on the same line. One item in a &lt;span&gt; next to &lt;div&gt;s is the same as two items in &lt;div&gt;s. This means that for the <em>inline</em> setting to do anything, at least two consecutive items must be set inline.
You may define a <i>separator</i> which will be placed between each item. This separator may be html. You can use &amp;nbsp; to print blank space.
If the view's row style is set to "fields", fields must be added to the View. If there are no fields, you may receive validation errors such as:
<i>* Display "Defaults" uses fields but there are none defined for it or all are excluded.
* Display "Page" uses fields but there are none defined for it or all are excluded.</i>
This is because the row style "fields" expects at least one field for display.
There is also an option to hide empty fields, so empty fields, along with their labels or markup will not be displayed.
There is also an option to hide empty fields, so empty fields, along with their labels or markup will not be displayed.

22
help/style-grid.html
View File

@ -1,22 +0,0 @@
The <strong>grid</strong> style will display each row of your view within a grid. You may customize the <strong>number of columns</strong>, though it defaults to 4. A grid looks like this:
<table width="100%">
<tr><td>row 1</td><td>row 2</td><td>row 3</td><td>row 4</td></tr>
<tr><td>row 5</td><td>row 6</td><td>row 7</td><td>row 8</td></tr>
<tr><td>row 9</td><td>row 10</td><td>row 11</td><td>row 12</td></tr>
<tr><td>row 13</td><td>row 14</td><td>row 15</td><td>row 16</td></tr>
</table>
The above uses the <strong>horizontal</strong> alignment, where rows are added into the grid from left to right.
With a <strong>vertical</strong> alignment, rows will be placed from top to bottom, like this (your <strong>row</strong> results will appear as columns):
<table width="100%">
<tr><td>row 1</td><td>row 5</td><td>row 9</td><td>row 13</td></tr>
<tr><td>row 2</td><td>row 6</td><td>row 10</td><td>row 14</td></tr>
<tr><td>row 3</td><td>row 7</td><td>row 11</td><td>row 15</td></tr>
<tr><td>row 4</td><td>row 8</td><td>row 12</td><td>row 16</td></tr>
</table>
You can also choose to <strong>group a field</strong> from the Fields Section. This grouping field will be displayed as a header, and all rows will be displayed beneath it.
This style uses a <a href="topic:views/style-row">row style</a> to determine what each row will look like.

7
help/style-grouping.html
View File

@ -1,7 +0,0 @@
Many styles can be <strong>grouped</strong>. For styles that can, there will be a 'grouping field' option; pick one of the fields to group by. This grouping field will be displayed as a header, and all rows will be displayed beneath it.
If the style is not <strong>grouped</strong> then the corresponding style output template will by invoked once when displaying the view. If the style is grouped, then the style output template will be invoked once per group. The text if the grouping filed is passed to the template in the <strong>$title</strong> variable.
Views is very naive about <strong>grouping</strong>, and it can only group on one field. It doesn't understand anything about which object (node, comment, etc.) the field belongs to, and doesn't make any smart grouping choices based on the parent object of the grouping field. The grouping field does not modify the views SQL query - grouping is handed after records are retrieved from the database.
The devel_themer module is known to break grouping. If grouping is not working, please check and make sure the devel modules are disabled.

48
help/style-jump.html
View File

@ -1,48 +0,0 @@
With the <strong>jump menu</strong> style can you create selectbox menus for the content of your site.
<a href="path:images/views3-jump-style-menu.png"><img src="path:images/views3-jump-style-menu.png" /></a>
The <strong>jump menu</strong> style will display each row of your view within a jump menu. This style requires that your view's <a href="topic:views/style-row">row style</a> is set to <a href="topic:views/style-fields">fields</a>.
To properly configure a jump menu, you must select one field that will represent the path to utilize. In most cases, you will need to rewrite the output of this field. You should set that field to exclude from display. All other displayed fields will be part of the menu. Please note that all HTML will be stripped from this output as select boxes cannot show HTML.
Some examples of how this might be useful:
<h3>Jump to a node</h3>
<ol>
<li>Create a new <strong>Node</strong> view</li>
<li>Select the <strong>Node: Path</strong> and <strong>Node: Title</strong> fields</li>
<li>Configure the <strong>Node: Path</strong> field to "exclude from display" and check "Use absolute link"</li>
<li>Configure the <strong>Node: Title</strong> field by removing the "Label" and unchecking "Link this field to its node"</li>
<li>Set the view style to <strong>jump menu</strong></li>
<li>In the style settings, set the "Path field" to <strong>Node: Path</strong></li>
</ol>
Your view will now display with a select list and a <strong>Go</strong> button. If you select an item in the list and hit the <strong>Go</strong> button you will see the selected node's page in the browser.
<h3>Jump to a node's edit page</h3>
<ol>
<li>Create a new <strong>Node</strong> view</li>
<li>Select the <strong>Node: Nid</strong> and <strong>Node: Title</strong> fields</li>
<li>Configure the <strong>Node: Nid</strong> field to "exclude from display" and check "Rewrite the output of this field"</li>
<li>In the text field that appears for rewriting the output of this field, enter <strong>node/[nid]/edit</strong></li>
<li>Configure the <strong>Node: Title</strong> field by removing the "Label" and unchecking "Link this field to its node"</li>
<li>Set the view style to <strong>jump menu</strong></li>
<li>In the style settings, set the "Path field" to <strong>Node: Nid</strong></li>
</ol>
Your view will now display with a select list and a <strong>Go</strong> button. If you select an item in the list and hit the <strong>Go</strong> button you will see the selected node's edit page in the browser. Please note that users without rights to the node's edit page will see an access denied message.
<h3>Jump to a user profile</h3>
<ol>
<li>Create a new <strong>User</strong> view</li>
<li>Select the <strong>User: Uid</strong> and <strong>User: Name</strong> fields</li>
<li>Configure the <strong>User: Uid</strong> field to "exclude from display" and check "Rewrite the output of this field"</li>
<li>In the text field that appears for rewriting the output of this field, enter <strong>user/[uid]</strong></li>
<li>Configure the <strong>User: Name</strong> field by removing the "Label" and unchecking "Link this field to its user"</li>
<li>Set the view style to <strong>jump menu</strong></li>
<li>In the style settings, set the "Path field" to <strong>User: Uid</strong></li>
</ol>
Your view will now display with a select list and a <strong>Go</strong> button. If you select an item in the list and hit the <strong>Go</strong> button you will see the selected user's profile page in the browser.

20
help/style-list.html
View File

@ -1,20 +0,0 @@
The <strong>List</strong> view style will display every row of the view as part of an HTML list construct. For example:
<ul>
<li> Row 1 </li>
<li> Row 2 </li>
<li> Row 3 </li>
<li> Row 4 </li>
</ul>
You may select whether or not the list is <em>ordered</em> which just means whether or not it uses numbers instead of the bullet:
<ol>
<li> Row 1 </li>
<li> Row 2 </li>
<li> Row 3 </li>
<li> Row 4 </li>
</ol>
The list style also uses a <em>row style</em> which means that it doesn't care what the actual output for each row of the view is.
If you need information about using CSS to style list views, you may find this <a href="http://www.alistapart.com/stories/taminglists/">A list apart guide to styling lists</a> useful.

1
help/style-node-rss.html
View File

@ -1 +0,0 @@
This row style is only available to RSS styles. It produces XML necessary for an RSS feed for the node record.

11
help/style-node.html
View File

@ -1,11 +0,0 @@
The <strong>node</strong> row style will display each item of the view through Drupal's standard <em>node_view()</em> function. Views has very little control over this output, except for the options you see. You can choose from different <strong>Build modes</strong>. By default there are "Teaser" and "Full node". You can also decide if you want to "Display links" and/or "Display node comments".
Because the output is run through the standard node template mechanism (typically <strong>node.tpl.php</strong> or a variant thereof), any decisions about what is output may be done there.
Views does add an extra 'suggestion' to the list of possible node templates: <strong>node--view--VIEWNAME.tpl.php</strong> -- you may use this to theme a node specifically for the view. This can be handy for creating very small teasers and the like.
You may opt to display the full node body or the node teaser, and you may add the node links (such as the 'comment' links that appear after a node) or not.
Because of this behavior, <strong>the node row style does not utilize fields</strong> and the Fields section will not be displayed.
<strong>Please note that this row style performs a node_load() for every row, and as such can produce a lot of extra queries.</strong> Sometimes this is necessary, but it can have a negative impact on your site's performance!

11
help/style-row.html
View File

@ -1,11 +0,0 @@
A row style is an individual style to display only an individual record within a view. You can choose between <a href="topic:views/style-node">node</a> or <a href="topic:views/style-fields">fields</a>. For example, a node type view would display one node per row; a user type view would display one user per row.
When you choose <strong>fields</strong>, you must have entries in the <a href="topic:views/field">Fields</a> section to produce an output. To set some options for fields, read <a href="topic:views/style-fields">here</a>.
Some row styles use <em>fields</em> which means you may select from the available fields to display. Others row styles do not - they are able to use the base type and create a display. Usually, row styles that do not use fields produce less efficient (slower) views, so bear this in mind when contemplating the performance of your site.
When you choose <strong>node</strong> the complete node will display through Drupal's standard <em>node_view()</em> function. You can choose some <a href="topic:views/style-node">options</a>.
When styling views, it's important to realize that the unformatted styles will take the majority of styling from more specific templates. In an unformatted style, the row style will provide theming. For instance, in a view that uses fields as its primary data, the views-view-fields.tpl.php will provide the theming.
Mustardseed created a videocast on row theming that can be viewed <a href="http://mustardseedmedia.com/podcast/episode30">here</a>.

5
help/style-rss.html
View File

@ -1,5 +0,0 @@
The <strong>RSS</strong> output style is only available for <em>Feed</em> display types. It will display the view as an RSS feed, which is a specialized XML output. This output is not user visible, but can be parsed by feed readers for aggregation.
You may supply a description for the RSS feed; most feed readers will display this description along with the contents of the feed. You may also select to use the site's mission statement for the description.
Please note that when using RSS views only comes with the one RSS style. There's no style override for RSS. Modules can add more.

Some files were not shown because too many files have changed in this diff Show More