Chris@0
|
1 /**
|
Chris@0
|
2 * Implements hook_views_data().
|
Chris@0
|
3 */
|
Chris@0
|
4 function {{ machine_name }}_views_data() {
|
Chris@0
|
5 // This example describes how to write hook_views_data() for a table defined
|
Chris@0
|
6 // like this:
|
Chris@0
|
7 // CREATE TABLE example_table (
|
Chris@0
|
8 // nid INT(11) NOT NULL COMMENT 'Primary key: {node}.nid.',
|
Chris@0
|
9 // plain_text_field VARCHAR(32) COMMENT 'Just a plain text field.',
|
Chris@0
|
10 // numeric_field INT(11) COMMENT 'Just a numeric field.',
|
Chris@0
|
11 // boolean_field INT(1) COMMENT 'Just an on/off field.',
|
Chris@0
|
12 // timestamp_field INT(8) COMMENT 'Just a timestamp field.',
|
Chris@0
|
13 // langcode VARCHAR(12) COMMENT 'Language code field.',
|
Chris@0
|
14 // PRIMARY KEY(nid)
|
Chris@0
|
15 // );
|
Chris@0
|
16
|
Chris@0
|
17 // Define the return array.
|
Chris@0
|
18 $data = [];
|
Chris@0
|
19
|
Chris@0
|
20 // The outermost keys of $data are Views table names, which should usually
|
Chris@0
|
21 // be the same as the hook_schema() table names.
|
Chris@0
|
22 $data['example_table'] = [];
|
Chris@0
|
23
|
Chris@0
|
24 // The value corresponding to key 'table' gives properties of the table
|
Chris@0
|
25 // itself.
|
Chris@0
|
26 $data['example_table']['table'] = [];
|
Chris@0
|
27
|
Chris@0
|
28 // Within 'table', the value of 'group' (translated string) is used as a
|
Chris@0
|
29 // prefix in Views UI for this table's fields, filters, etc. When adding
|
Chris@0
|
30 // a field, filter, etc. you can also filter by the group.
|
Chris@0
|
31 $data['example_table']['table']['group'] = t('Example table');
|
Chris@0
|
32
|
Chris@0
|
33 // Within 'table', the value of 'provider' is the module that provides schema
|
Chris@0
|
34 // or the entity type that causes the table to exist. Setting this ensures
|
Chris@0
|
35 // that views have the correct dependencies. This is automatically set to the
|
Chris@0
|
36 // module that implements hook_views_data().
|
Chris@0
|
37 $data['example_table']['table']['provider'] = 'example_module';
|
Chris@0
|
38
|
Chris@0
|
39 // Some tables are "base" tables, meaning that they can be the base tables
|
Chris@0
|
40 // for views. Non-base tables can only be brought in via relationships in
|
Chris@0
|
41 // views based on other tables. To define a table to be a base table, add
|
Chris@0
|
42 // key 'base' to the 'table' array:
|
Chris@0
|
43 $data['example_table']['table']['base'] = [
|
Chris@0
|
44 // Identifier (primary) field in this table for Views.
|
Chris@0
|
45 'field' => 'nid',
|
Chris@0
|
46 // Label in the UI.
|
Chris@0
|
47 'title' => t('Example table'),
|
Chris@0
|
48 // Longer description in the UI. Required.
|
Chris@0
|
49 'help' => t('Example table contains example content and can be related to nodes.'),
|
Chris@0
|
50 'weight' => -10,
|
Chris@0
|
51 ];
|
Chris@0
|
52
|
Chris@0
|
53 // Some tables have an implicit, automatic relationship to other tables,
|
Chris@0
|
54 // meaning that when the other table is available in a view (either as the
|
Chris@0
|
55 // base table or through a relationship), this table's fields, filters, etc.
|
Chris@0
|
56 // are automatically made available without having to add an additional
|
Chris@0
|
57 // relationship. To define an implicit relationship that will make your
|
Chris@0
|
58 // table automatically available when another table is present, add a 'join'
|
Chris@0
|
59 // section to your 'table' section. Note that it is usually only a good idea
|
Chris@0
|
60 // to do this for one-to-one joins, because otherwise your automatic join
|
Chris@0
|
61 // will add more rows to the view. It is also not a good idea to do this if
|
Chris@0
|
62 // most views won't need your table -- if that is the case, define a
|
Chris@0
|
63 // relationship instead (see below).
|
Chris@0
|
64 //
|
Chris@0
|
65 // If you've decided an automatic join is a good idea, here's how to do it;
|
Chris@0
|
66 // the resulting SQL query will look something like this:
|
Chris@0
|
67 // ... FROM example_table et ... JOIN node_field_data nfd
|
Chris@0
|
68 // ON et.nid = nfd.nid AND ('extra' clauses will be here) ...
|
Chris@0
|
69 // although the table aliases will be different.
|
Chris@0
|
70 $data['example_table']['table']['join'] = [
|
Chris@0
|
71 // Within the 'join' section, list one or more tables to automatically
|
Chris@0
|
72 // join to. In this example, every time 'node_field_data' is available in
|
Chris@0
|
73 // a view, 'example_table' will be too. The array keys here are the array
|
Chris@0
|
74 // keys for the other tables, given in their hook_views_data()
|
Chris@0
|
75 // implementations. If the table listed here is from another module's
|
Chris@0
|
76 // hook_views_data() implementation, make sure your module depends on that
|
Chris@0
|
77 // other module.
|
Chris@0
|
78 'node_field_data' => [
|
Chris@0
|
79 // Primary key field in node_field_data to use in the join.
|
Chris@0
|
80 'left_field' => 'nid',
|
Chris@0
|
81 // Foreign key field in example_table to use in the join.
|
Chris@0
|
82 'field' => 'nid',
|
Chris@0
|
83 // 'extra' is an array of additional conditions on the join.
|
Chris@0
|
84 'extra' => [
|
Chris@0
|
85 0 => [
|
Chris@0
|
86 // Adds AND node_field_data.published = TRUE to the join.
|
Chris@0
|
87 'field' => 'published',
|
Chris@0
|
88 'value' => TRUE,
|
Chris@0
|
89 ],
|
Chris@0
|
90 1 => [
|
Chris@0
|
91 // Adds AND example_table.numeric_field = 1 to the join.
|
Chris@0
|
92 'left_field' => 'numeric_field',
|
Chris@0
|
93 'value' => 1,
|
Chris@0
|
94 // If true, the value will not be surrounded in quotes.
|
Chris@0
|
95 'numeric' => TRUE,
|
Chris@0
|
96 ],
|
Chris@0
|
97 2 => [
|
Chris@0
|
98 // Adds AND example_table.boolean_field <>
|
Chris@0
|
99 // node_field_data.published to the join.
|
Chris@0
|
100 'field' => 'published',
|
Chris@0
|
101 'left_field' => 'boolean_field',
|
Chris@0
|
102 // The operator used, Defaults to "=".
|
Chris@0
|
103 'operator' => '!=',
|
Chris@0
|
104 ],
|
Chris@0
|
105 ],
|
Chris@0
|
106 ],
|
Chris@0
|
107 ];
|
Chris@0
|
108
|
Chris@0
|
109 // You can also do a more complex join, where in order to get to a certain
|
Chris@0
|
110 // base table defined in a hook_views_data() implementation, you will join
|
Chris@0
|
111 // to a different table that Views knows how to auto-join to the base table.
|
Chris@0
|
112 // For instance, if another module that your module depends on had
|
Chris@0
|
113 // defined a table 'foo' with an automatic join to 'node_field_table' (as
|
Chris@0
|
114 // shown above), you could join to 'node_field_table' via the 'foo' table.
|
Chris@0
|
115 // Here's how to do this, and the resulting SQL query would look something
|
Chris@0
|
116 // like this:
|
Chris@0
|
117 // ... FROM example_table et ... JOIN foo foo
|
Chris@0
|
118 // ON et.nid = foo.nid AND ('extra' clauses will be here) ...
|
Chris@0
|
119 // JOIN node_field_data nfd ON (definition of the join from the foo
|
Chris@0
|
120 // module goes here) ...
|
Chris@0
|
121 // although the table aliases will be different.
|
Chris@0
|
122 $data['example_table']['table']['join']['node_field_data'] = [
|
Chris@0
|
123 // 'node_field_data' above is the base we're joining to in Views.
|
Chris@0
|
124 // 'left_table' is the table we're actually joining to, in order to get to
|
Chris@0
|
125 // 'node_field_data'. It has to be something that Views knows how to join
|
Chris@0
|
126 // to 'node_field_data'.
|
Chris@0
|
127 'left_table' => 'foo',
|
Chris@0
|
128 'left_field' => 'nid',
|
Chris@0
|
129 'field' => 'nid',
|
Chris@0
|
130 // 'extra' is an array of additional conditions on the join.
|
Chris@0
|
131 'extra' => [
|
Chris@0
|
132 // This syntax matches additional fields in the two tables:
|
Chris@0
|
133 // ... AND foo.langcode = example_table.langcode ...
|
Chris@0
|
134 ['left_field' => 'langcode', 'field' => 'langcode'],
|
Chris@0
|
135 // This syntax adds a condition on our table. 'operator' defaults to
|
Chris@0
|
136 // '=' for non-array values, or 'IN' for array values.
|
Chris@0
|
137 // ... AND example_table.numeric_field > 0 ...
|
Chris@0
|
138 ['field' => 'numeric_field', 'value' => 0, 'numeric' => TRUE, 'operator' => '>'],
|
Chris@0
|
139 ],
|
Chris@0
|
140 ];
|
Chris@0
|
141
|
Chris@0
|
142 // Other array elements at the top level of your table's array describe
|
Chris@0
|
143 // individual database table fields made available to Views. The array keys
|
Chris@0
|
144 // are the names (unique within the table) used by Views for the fields,
|
Chris@0
|
145 // usually equal to the database field names.
|
Chris@0
|
146 //
|
Chris@0
|
147 // Each field entry must have the following elements:
|
Chris@0
|
148 // - title: Translated label for the field in the UI.
|
Chris@0
|
149 // - help: Description of the field in the UI.
|
Chris@0
|
150 //
|
Chris@0
|
151 // Each field entry may also have one or more of the following elements,
|
Chris@0
|
152 // describing "handlers" (plugins) for the field:
|
Chris@0
|
153 // - relationship: Specifies a handler that allows this field to be used
|
Chris@0
|
154 // to define a relationship to another table in Views.
|
Chris@0
|
155 // - field: Specifies a handler to make it available to Views as a field.
|
Chris@0
|
156 // - filter: Specifies a handler to make it available to Views as a filter.
|
Chris@0
|
157 // - sort: Specifies a handler to make it available to Views as a sort.
|
Chris@0
|
158 // - argument: Specifies a handler to make it available to Views as an
|
Chris@0
|
159 // argument, or contextual filter as it is known in the UI.
|
Chris@0
|
160 // - area: Specifies a handler to make it available to Views to add content
|
Chris@0
|
161 // to the header, footer, or as no result behavior.
|
Chris@0
|
162 //
|
Chris@0
|
163 // Note that when specifying handlers, you must give the handler plugin ID
|
Chris@0
|
164 // and you may also specify overrides for various settings that make up the
|
Chris@0
|
165 // plugin definition. See examples below; the Boolean example demonstrates
|
Chris@0
|
166 // setting overrides.
|
Chris@0
|
167
|
Chris@0
|
168 // Node ID field, exposed as relationship only, since it is a foreign key
|
Chris@0
|
169 // in this table.
|
Chris@0
|
170 $data['example_table']['nid'] = [
|
Chris@0
|
171 'title' => t('Example content'),
|
Chris@0
|
172 'help' => t('Relate example content to the node content'),
|
Chris@0
|
173
|
Chris@0
|
174 // Define a relationship to the node_field_data table, so views whose
|
Chris@0
|
175 // base table is example_table can add a relationship to nodes. To make a
|
Chris@0
|
176 // relationship in the other direction, you can:
|
Chris@0
|
177 // - Use hook_views_data_alter() -- see the function body example on that
|
Chris@0
|
178 // hook for details.
|
Chris@0
|
179 // - Use the implicit join method described above.
|
Chris@0
|
180 'relationship' => [
|
Chris@0
|
181 // Views name of the table to join to for the relationship.
|
Chris@0
|
182 'base' => 'node_field_data',
|
Chris@0
|
183 // Database field name in the other table to join on.
|
Chris@0
|
184 'base field' => 'nid',
|
Chris@0
|
185 // ID of relationship handler plugin to use.
|
Chris@0
|
186 'id' => 'standard',
|
Chris@0
|
187 // Default label for relationship in the UI.
|
Chris@0
|
188 'label' => t('Example node'),
|
Chris@0
|
189 ],
|
Chris@0
|
190 ];
|
Chris@0
|
191
|
Chris@0
|
192 // Plain text field, exposed as a field, sort, filter, and argument.
|
Chris@0
|
193 $data['example_table']['plain_text_field'] = [
|
Chris@0
|
194 'title' => t('Plain text field'),
|
Chris@0
|
195 'help' => t('Just a plain text field.'),
|
Chris@0
|
196
|
Chris@0
|
197 'field' => [
|
Chris@0
|
198 // ID of field handler plugin to use.
|
Chris@0
|
199 'id' => 'standard',
|
Chris@0
|
200 ],
|
Chris@0
|
201
|
Chris@0
|
202 'sort' => [
|
Chris@0
|
203 // ID of sort handler plugin to use.
|
Chris@0
|
204 'id' => 'standard',
|
Chris@0
|
205 ],
|
Chris@0
|
206
|
Chris@0
|
207 'filter' => [
|
Chris@0
|
208 // ID of filter handler plugin to use.
|
Chris@0
|
209 'id' => 'string',
|
Chris@0
|
210 ],
|
Chris@0
|
211
|
Chris@0
|
212 'argument' => [
|
Chris@0
|
213 // ID of argument handler plugin to use.
|
Chris@0
|
214 'id' => 'string',
|
Chris@0
|
215 ],
|
Chris@0
|
216 ];
|
Chris@0
|
217
|
Chris@0
|
218 // Numeric field, exposed as a field, sort, filter, and argument.
|
Chris@0
|
219 $data['example_table']['numeric_field'] = [
|
Chris@0
|
220 'title' => t('Numeric field'),
|
Chris@0
|
221 'help' => t('Just a numeric field.'),
|
Chris@0
|
222
|
Chris@0
|
223 'field' => [
|
Chris@0
|
224 // ID of field handler plugin to use.
|
Chris@0
|
225 'id' => 'numeric',
|
Chris@0
|
226 ],
|
Chris@0
|
227
|
Chris@0
|
228 'sort' => [
|
Chris@0
|
229 // ID of sort handler plugin to use.
|
Chris@0
|
230 'id' => 'standard',
|
Chris@0
|
231 ],
|
Chris@0
|
232
|
Chris@0
|
233 'filter' => [
|
Chris@0
|
234 // ID of filter handler plugin to use.
|
Chris@0
|
235 'id' => 'numeric',
|
Chris@0
|
236 ],
|
Chris@0
|
237
|
Chris@0
|
238 'argument' => [
|
Chris@0
|
239 // ID of argument handler plugin to use.
|
Chris@0
|
240 'id' => 'numeric',
|
Chris@0
|
241 ],
|
Chris@0
|
242 ];
|
Chris@0
|
243
|
Chris@0
|
244 // Boolean field, exposed as a field, sort, and filter. The filter section
|
Chris@0
|
245 // illustrates overriding various settings.
|
Chris@0
|
246 $data['example_table']['boolean_field'] = [
|
Chris@0
|
247 'title' => t('Boolean field'),
|
Chris@0
|
248 'help' => t('Just an on/off field.'),
|
Chris@0
|
249
|
Chris@0
|
250 'field' => [
|
Chris@0
|
251 // ID of field handler plugin to use.
|
Chris@0
|
252 'id' => 'boolean',
|
Chris@0
|
253 ],
|
Chris@0
|
254
|
Chris@0
|
255 'sort' => [
|
Chris@0
|
256 // ID of sort handler plugin to use.
|
Chris@0
|
257 'id' => 'standard',
|
Chris@0
|
258 ],
|
Chris@0
|
259
|
Chris@0
|
260 'filter' => [
|
Chris@0
|
261 // ID of filter handler plugin to use.
|
Chris@0
|
262 'id' => 'boolean',
|
Chris@0
|
263 // Override the generic field title, so that the filter uses a different
|
Chris@0
|
264 // label in the UI.
|
Chris@0
|
265 'label' => t('Published'),
|
Chris@0
|
266 // Override the default BooleanOperator filter handler's 'type' setting,
|
Chris@0
|
267 // to display this as a "Yes/No" filter instead of a "True/False" filter.
|
Chris@0
|
268 'type' => 'yes-no',
|
Chris@0
|
269 // Override the default Boolean filter handler's 'use_equal' setting, to
|
Chris@0
|
270 // make the query use 'boolean_field = 1' instead of 'boolean_field <> 0'.
|
Chris@0
|
271 'use_equal' => TRUE,
|
Chris@0
|
272 ],
|
Chris@0
|
273 ];
|
Chris@0
|
274
|
Chris@0
|
275 // Integer timestamp field, exposed as a field, sort, and filter.
|
Chris@0
|
276 $data['example_table']['timestamp_field'] = [
|
Chris@0
|
277 'title' => t('Timestamp field'),
|
Chris@0
|
278 'help' => t('Just a timestamp field.'),
|
Chris@0
|
279
|
Chris@0
|
280 'field' => [
|
Chris@0
|
281 // ID of field handler plugin to use.
|
Chris@0
|
282 'id' => 'date',
|
Chris@0
|
283 ],
|
Chris@0
|
284
|
Chris@0
|
285 'sort' => [
|
Chris@0
|
286 // ID of sort handler plugin to use.
|
Chris@0
|
287 'id' => 'date',
|
Chris@0
|
288 ],
|
Chris@0
|
289
|
Chris@0
|
290 'filter' => [
|
Chris@0
|
291 // ID of filter handler plugin to use.
|
Chris@0
|
292 'id' => 'date',
|
Chris@0
|
293 ],
|
Chris@0
|
294 ];
|
Chris@0
|
295
|
Chris@0
|
296 // Area example. Areas are not generally associated with actual data
|
Chris@0
|
297 // tables and fields. This example is from views_views_data(), which defines
|
Chris@0
|
298 // the "Global" table (not really a table, but a group of Fields, Filters,
|
Chris@0
|
299 // etc. that are grouped into section "Global" in the UI). Here's the
|
Chris@0
|
300 // definition of the generic "Text area":
|
Chris@0
|
301 $data['views']['area'] = [
|
Chris@0
|
302 'title' => t('Text area'),
|
Chris@0
|
303 'help' => t('Provide markup text for the area.'),
|
Chris@0
|
304 'area' => [
|
Chris@0
|
305 // ID of the area handler plugin to use.
|
Chris@0
|
306 'id' => 'text',
|
Chris@0
|
307 ],
|
Chris@0
|
308 ];
|
Chris@0
|
309
|
Chris@0
|
310 return $data;
|
Chris@0
|
311 }
|