"+(a.type||"Syntax")+"Error: "+(a.message||"There is an error in your .less file")+'
in '+m+" ";var n=function(a,c,d){a.extract[c]!==b&&k.push(i.replace(/\{line\}/,(parseInt(a.line,10)||0)+(c-1)).replace(/\{class\}/,d).replace(/\{content\}/,a.extract[c]))};a.extract?(n(a,0,""),n(a,1,"line"),n(a,2,""),f+="on line "+a.line+", column "+(a.column+1)+":
+ If you can see CKEditor below, it means that the installation succeeded.
+ You can now try out your new editor version, see its features, and when you are ready to move on, check some of the most useful resources recommended below.
+
Modular build and numerous configuration options give you nearly endless possibilities to customize CKEditor. Replace the content of your config.js file with the following code and refresh this page (remember to clear the browser cache)!
If you want to reorder toolbar buttons or remove some of them, check this handy tool!
+
+
+
+
More Samples!
+
Visit the CKEditor SDK for a huge collection of samples showcasing editor features, with source code readily available to copy and use in your own implementation.
+
+
+
+
Developer's Guide
+
The most important resource for all developers working with CKEditor, integrating it with their websites and applications, and customizing to their needs. You can start from here:
+
+
Getting Started – Explains most crucial editor concepts and practices as well as the installation process and integration with your website.
+
Advanced Installation Concepts – Describes how to upgrade, install additional components (plugins, skins), or create a custom build.
+
+
When you have the basics sorted out, feel free to browse some more advanced sections like:
+ This sample shows how to create and destroy CKEditor instances on the fly. After the removal of CKEditor the content created inside the editing
+ area will be displayed in a <div> element.
+
+
+ For details of how to create this setup check the source code of this sample page
+ for JavaScript code responsible for the creation and destruction of a CKEditor instance.
+
+
+
Click the buttons to create and remove a CKEditor instance.
+ The CKEDITOR.appendTo() method serves to to place editors inside existing DOM elements. Unlike CKEDITOR.replace(),
+ a target container to be replaced is no longer necessary. A new editor
+ instance is inserted directly wherever it is desired.
+
+
CKEDITOR.appendTo( 'container_id',
+ { /* Configuration options to be used. */ }
+ 'Editor content to be used.'
+);
+ This sample page demonstrates the idea of Advanced Content Filter
+ (ACF), a sophisticated
+ tool that takes control over what kind of data is accepted by the editor and what
+ kind of output is produced.
+
+
When and what is being filtered?
+
+ ACF controls
+ every single source of data that comes to the editor.
+ It process both HTML that is inserted manually (i.e. pasted by the user)
+ and programmatically like:
+
+
+editor.setData( '<p>Hello world!</p>' );
+
+
+ ACF discards invalid,
+ useless HTML tags and attributes so the editor remains "clean" during
+ runtime. ACF behaviour
+ can be configured and adjusted for a particular case to prevent the
+ output HTML (i.e. in CMS systems) from being polluted.
+
+ This kind of filtering is a first, client-side line of defense
+ against "tag soups",
+ the tool that precisely restricts which tags, attributes and styles
+ are allowed (desired). When properly configured, ACF
+ is an easy and fast way to produce a high-quality, intentionally filtered HTML.
+
+
+
How to configure or disable ACF?
+
+ Advanced Content Filter is enabled by default, working in "automatic mode", yet
+ it provides a set of easy rules that allow adjusting filtering rules
+ and disabling the entire feature when necessary. The config property
+ responsible for this feature is config.allowedContent.
+
+
+ By "automatic mode" is meant that loaded plugins decide which kind
+ of content is enabled and which is not. For example, if the link
+ plugin is loaded it implies that <a> tag is
+ automatically allowed. Each plugin is given a set
+ of predefined ACF rules
+ that control the editor until
+ config.allowedContent
+ is defined manually.
+
+
+ Let's assume our intention is to restrict the editor to accept (produce) paragraphs
+ only: no attributes, no styles, no other tags.
+ With ACF
+ this is very simple. Basically set
+ config.allowedContent to 'p':
+
+// Trying to insert disallowed tag and attribute.
+editor.setData( '<p style="color: red">Hello <em>world</em>!</p>' );
+alert( editor.getData() );
+
+// Filtered data is returned.
+"<p>Hello world!</p>"
+
+
+ What happened? Since config.allowedContent: 'p' is set the editor assumes
+ that only plain <p> are accepted. Nothing more. This is why
+ style attribute and <em> tag are gone. The same
+ filtering would happen if we pasted disallowed HTML into this editor.
+
+ ACF is far more than
+ I/O control: the entire
+ UI of the editor is adjusted to what
+ filters restrict. For example: if <a> tag is
+ disallowed
+ by ACF,
+ then accordingly link command, toolbar button and link dialog
+ are also disabled. Editor is smart: it knows which features must be
+ removed from the interface to match filtering rules.
+
+
+ CKEditor can be far more specific. If <a> tag is
+ allowed by filtering rules to be used but it is restricted
+ to have only one attribute (href)
+ config.allowedContent = 'a[!href]', then
+ "Target" tab of the link dialog is automatically disabled as target
+ attribute isn't included in ACF rules
+ for <a>. This behaviour applies to dialog fields, context
+ menus and toolbar buttons.
+
+
+
Sample configurations
+
+ There are several editor instances below that present different
+ ACF setups. All of them,
+ except the inline instance, share the same HTML content to visualize
+ how different filtering rules affect the same input data.
+
+
+
+
+
+
+
+ This editor is using default configuration ("automatic mode"). It means that
+
+ config.allowedContent is defined by loaded plugins.
+ Each plugin extends filtering rules to make it's own associated content
+ available for the user.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This editor is using a custom configuration for
+ ACF:
+
+ The following rules may require additional explanation:
+
+
+
+ h1 h2 h3 p blockquote strong em - These tags
+ are accepted by the editor. Any tag attributes will be discarded.
+
+
+ a[!href] - href attribute is obligatory
+ for <a> tag. Tags without this attribute
+ are disarded. No other attribute will be accepted.
+
+
+ img(left,right)[!src,alt,width,height] - src
+ attribute is obligatory for <img> tag.
+ alt, width, height
+ and class attributes are accepted but
+ class must be either class="left"
+ or class="right"
+
+
+ table tr th td caption - These tags
+ are accepted by the editor. Any tag attributes will be discarded.
+
+
+ span{!font-family}, span{!color},
+ span(!marker) - <span> tags
+ will be accepted if either font-family or
+ color style is set or class="marker"
+ is present.
+
+
+ del ins - These tags
+ are accepted by the editor. Any tag attributes will be discarded.
+
+
+
+ Please note that UI of the
+ editor is different. It's a response to what happened to the filters.
+ Since text-align isn't allowed, the align toolbar is gone.
+ The same thing happened to subscript/superscript, strike, underline
+ (<u>, <sub>, <sup>
+ are disallowed by
+ config.allowedContent) and many other buttons.
+
+
+
+
+
+
+
+
+
+
+
+
+ This editor is using a custom configuration for
+ ACF.
+ Note that filters can be configured as an object literal
+ as an alternative to a string-based definition.
+
+ As you can see, removing plugins and buttons implies filtering.
+ Several tags are not allowed in the editor because there's no
+ plugin/button that is responsible for creating and editing this
+ kind of content (for example: the image is missing because
+ of removeButtons: 'Image'). The conclusion is that
+ ACF works "backwards"
+ as well: modifying UI
+ elements is changing allowed content rules.
+
+
+
+
+
+
+
+
+
+
+
+
+ This editor is built on editable <h1> element.
+ ACF takes care of
+ what can be included in <h1>. Note that there
+ are no block styles in Styles combo. Also why lists, indentation,
+ blockquote, div, form and other buttons are missing.
+
+
+ ACF makes sure that
+ no disallowed tags will come to <h1> so the final
+ markup is valid. If the user tried to paste some invalid HTML
+ into this editor (let's say a list), it would be automatically
+ converted into plain text.
+
+
+
+ Apollo 11 was the spaceflight that landed the first humans, Americans Neil Armstrong and Buzz Aldrin, on the Moon on July 20, 1969, at 20:18 UTC.
+
+
+
+
+
+
+
+
+
+ This editor is using a custom configuration for ACF.
+ It's using the
+ Disallowed Content property of the filter to eliminate all title attributes.
+
+ This editor is using a custom configuration for ACF.
+ It's using the
+ Disallowed Content property of the filter to eliminate all a and img tags,
+ while allowing all other tags.
+
+ This sample shows how to use the
+ CKEditor Dialog API
+ to customize CKEditor dialog windows without changing the original editor code.
+ The following customizations are being done in the example below:
+
+
+ For details on how to create this setup check the source code of this sample page.
+
+
+
A custom dialog is added to the editors using the pluginsLoaded event, from an external dialog definition file:
+
+
Creating a custom dialog window – "My Dialog" dialog window opened with the "My Dialog" toolbar button.
+
Creating a custom button – Add button to open the dialog with "My Dialog" toolbar button.
+
+
+
+
The below editor modify the dialog definition of the above added dialog using the dialogDefinition event:
+
+
Adding dialog tab – Add new tab "My Tab" to dialog window.
+
Removing a dialog window tab – Remove "Second Tab" page from the dialog window.
+
Adding dialog window fields – Add "My Custom Field" to the dialog window.
+
Removing dialog window field – Remove "Select Field" selection field from the dialog window.
+
Setting default values for dialog window fields – Set default value of "Text Field" text field.
+
Setup initial focus for dialog window – Put initial focus on "My Custom Field" text field.
+ This sample shows how to automatically replace <div> elements
+ with a CKEditor instance on the fly, following user's doubleclick. The content
+ that was previously placed inside the <div> element will now
+ be moved into CKEditor editing area.
+
+
+ For details on how to create this setup check the source code of this sample page.
+
+
+
+ Double-click any of the following <div> elements to transform them into
+ editor instances.
+
+
+
+ Part 1
+
+
+ Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Cras et ipsum quis mi
+ semper accumsan. Integer pretium dui id massa. Suspendisse in nisl sit amet urna
+ rutrum imperdiet. Nulla eu tellus. Donec ante nisi, ullamcorper quis, fringilla
+ nec, sagittis eleifend, pede. Nulla commodo interdum massa. Donec id metus. Fusce
+ eu ipsum. Suspendisse auctor. Phasellus fermentum porttitor risus.
+
+
+
+
+ Part 2
+
+
+ Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Cras et ipsum quis mi
+ semper accumsan. Integer pretium dui id massa. Suspendisse in nisl sit amet urna
+ rutrum imperdiet. Nulla eu tellus. Donec ante nisi, ullamcorper quis, fringilla
+ nec, sagittis eleifend, pede. Nulla commodo interdum massa. Donec id metus. Fusce
+ eu ipsum. Suspendisse auctor. Phasellus fermentum porttitor risus.
+
+
+ Donec velit. Mauris massa. Vestibulum non nulla. Nam suscipit arcu nec elit. Phasellus
+ sollicitudin iaculis ante. Ut non mauris et sapien tincidunt adipiscing. Vestibulum
+ vitae leo. Suspendisse nec mi tristique nulla laoreet vulputate.
+
+
+
+
+ Part 3
+
+
+ Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Cras et ipsum quis mi
+ semper accumsan. Integer pretium dui id massa. Suspendisse in nisl sit amet urna
+ rutrum imperdiet. Nulla eu tellus. Donec ante nisi, ullamcorper quis, fringilla
+ nec, sagittis eleifend, pede. Nulla commodo interdum massa. Donec id metus. Fusce
+ eu ipsum. Suspendisse auctor. Phasellus fermentum porttitor risus.
+
+ This sample shows how to configure the Enter and Shift+Enter keys
+ to perform actions specified in the
+ enterMode
+ and shiftEnterMode
+ parameters, respectively.
+ You can choose from the following options:
+
+
+
ENTER_P – new <p> paragraphs are created;
+
ENTER_BR – lines are broken with <br> elements;
+
ENTER_DIV – new <div> blocks are created.
+
+
+ The sample code below shows how to configure CKEditor to create a <div> block when Enter key is pressed.
+
+ This sample shows how to configure CKEditor to output
+ HTML code that can be used with
+
+ Adobe Flash.
+ The code will contain a subset of standard HTML elements like <b>,
+ <i>, and <p> as well as HTML attributes.
+
+
+ To add a CKEditor instance outputting Flash compliant HTML code, load the editor using a standard
+ JavaScript call, and define CKEditor features to use HTML elements and attributes.
+
+
+ For details on how to create this setup check the source code of this sample page.
+
+
+
+ To see how it works, create some content in the editing area of CKEditor on the left
+ and send it to the Flash object on the right side of the page by using the
+ Send to Flash button.
+
+ This sample shows how to configure CKEditor to output valid
+ HTML 4.01 code.
+ Traditional HTML elements like <b>,
+ <i>, and <font> are used in place of
+ <strong>, <em>, and CSS styles.
+
+
+ To add a CKEditor instance outputting legacy HTML 4.01 code, load the editor using a standard
+ JavaScript call, and define CKEditor features to use the HTML compliant elements and attributes.
+
+
+ A snippet of the configuration code can be seen below; check the source of this page for
+ full definition:
+
This sample page demonstrates the inline editing feature - CKEditor instances will be created automatically from page elements with contentEditable attribute set to value true:
+
<div contenteditable="true" > ... </div>
+
Click inside of any element below to start editing.
+
+
+
+
+
+
+ CKEditor Goes Inline!
+
+
+ Lorem ipsum dolor sit amet dolor duis blandit vestibulum faucibus a, tortor.
+
+
+
+
+
+ Lorem ipsum dolor sit amet enim. Etiam ullamcorper. Suspendisse a pellentesque dui, non felis. Maecenas malesuada elit lectus felis, malesuada ultricies.
+
+
+ Curabitur et ligula. Ut molestie a, ultricies porta urna. Vestibulum commodo volutpat a, convallis ac, laoreet enim. Phasellus fermentum in, dolor. Pellentesque facilisis. Nulla imperdiet sit amet magna. Vestibulum dapibus, mauris nec malesuada fames ac.
+
+
+
+
+
+
+
+
+ Fusce vitae porttitor
+
+
+
+ Lorem ipsum dolor sit amet dolor. Duis blandit vestibulum faucibus a, tortor.
+
+
+
+ Proin nunc justo felis mollis tincidunt, risus risus pede, posuere cubilia Curae, Nullam euismod, enim. Etiam nibh ultricies dolor ac dignissim erat volutpat. Vivamus fermentum nisl nulla sem in metus. Maecenas wisi. Donec nec erat volutpat.
+
+
+
+ Fusce vitae porttitor a, euismod convallis nisl, blandit risus tortor, pretium.
+ Vehicula vitae, imperdiet vel, ornare enim vel sodales rutrum
+
+
+
+
+ Libero nunc, rhoncus ante ipsum non ipsum. Nunc eleifend pede turpis id sollicitudin fringilla. Phasellus ultrices, velit ac arcu.
+
+
+
Pellentesque nunc. Donec suscipit erat. Pellentesque habitant morbi tristique ullamcorper.
+
Mauris mattis feugiat lectus nec mauris. Nullam vitae ante.
+
+
+
+
+
+ Integer condimentum sit amet
+
+
+ Aenean nonummy a, mattis varius. Cras aliquet.
+ Praesent magna non mattis ac, rhoncus nunc, rhoncus eget, cursus pulvinar mollis.
+
Proin id nibh. Sed eu libero posuere sed, lectus. Phasellus dui gravida gravida feugiat mattis ac, felis.
+
Integer condimentum sit amet, tempor elit odio, a dolor non ante at sapien. Sed ac lectus. Nulla ligula quis eleifend mi, id leo velit pede cursus arcu id nulla ac lectus. Phasellus vestibulum. Nunc viverra enim quis diam.
+
+
+
+ Praesent wisi accumsan sit amet nibh
+
+
Donec ullamcorper, risus tortor, pretium porttitor. Morbi quam quis lectus non leo.
+
Integer faucibus scelerisque. Proin faucibus at, aliquet vulputate, odio at eros. Fusce gravida, erat vitae augue. Fusce urna fringilla gravida.
+
In hac habitasse platea dictumst. Praesent wisi accumsan sit amet nibh. Maecenas orci luctus a, lacinia quam sem, posuere commodo, odio condimentum tempor, pede semper risus. Suspendisse pede. In hac habitasse platea dictumst. Nam sed laoreet sit amet erat. Integer.
+
+
+
+
+
+
+
+
Quisque justo neque, mattis sed, fermentum ultrices posuere cubilia Curae, Vestibulum elit metus, quis placerat ut, lectus. Ut sagittis, nunc libero, egestas consequat lobortis velit rutrum ut, faucibus turpis. Fusce porttitor, nulla quis turpis. Nullam laoreet vel, consectetuer tellus suscipit ultricies, hendrerit wisi. Donec odio nec velit ac nunc sit amet, accumsan cursus aliquet. Vestibulum ante sit amet sagittis mi.
+
+ Nullam laoreet vel consectetuer tellus suscipit
+
+
+
Ut sagittis, nunc libero, egestas consequat lobortis velit rutrum ut, faucibus turpis.
Nullam laoreet vel, consectetuer tellus suscipit ultricies, hendrerit wisi. Ut sagittis, nunc libero, egestas consequat lobortis velit rutrum ut, faucibus turpis. Fusce porttitor, nulla quis turpis.
+
Donec odio nec velit ac nunc sit amet, accumsan cursus aliquet. Vestibulum ante sit amet sagittis mi. Sed in nonummy faucibus turpis. Mauris eget tellus. Donec non felis. Nam eget dolor. Vestibulum enim. Donec.
+ This sample shows how to create an inline editor instance of CKEditor. It is created
+ with a JavaScript call using the following code:
+
+
+// This property tells CKEditor to not activate every element with contenteditable=true element.
+CKEDITOR.disableAutoInline = true;
+
+var editor = CKEDITOR.inline( document.getElementById( 'editable' ) );
+
+
+ Note that editable in the code above is the id
+ attribute of the <div> element to be converted into an inline instance.
+
+
+
+
Apollo 11
+
+
Apollo 11 was the spaceflight that landed the first humans, Americans Neil Armstrong and Buzz Aldrin, on the Moon on July 20, 1969, at 20:18 UTC. Armstrong became the first to step onto the lunar surface 6 hours later on July 21 at 02:56 UTC.
+
+
Armstrong spent about three and a half two and a half hours outside the spacecraft, Aldrin slightly less; and together they collected 47.5 pounds (21.5 kg) of lunar material for return to Earth. A third member of the mission, Michael Collins, piloted the command spacecraft alone in lunar orbit until Armstrong and Aldrin returned to it for the trip back to Earth.
+
+
Broadcasting and quotes
+
+
Broadcast on live TV to a world-wide audience, Armstrong stepped onto the lunar surface and described the event as:
+
+
+
One small step for [a] man, one giant leap for mankind.
+
+
+
Apollo 11 effectively ended the Space Race and fulfilled a national goal proposed in 1961 by the late U.S. President John F. Kennedy in a speech before the United States Congress:
+
+
+
[...] before this decade is out, of landing a man on the Moon and returning him safely to the Earth.
+
+
+
Technical details
+
+
+
Mission crew
+
+
+
Position
+
Astronaut
+
+
+
+
+
Commander
+
Neil A. Armstrong
+
+
+
Command Module Pilot
+
Michael Collins
+
+
+
Lunar Module Pilot
+
Edwin "Buzz" E. Aldrin, Jr.
+
+
+
+
+
Launched by a Saturn V rocket from Kennedy Space Center in Merritt Island, Florida on July 16, Apollo 11 was the fifth manned mission of NASA's Apollo program. The Apollo spacecraft had three parts:
+
+
+
Command Module with a cabin for the three astronauts which was the only part which landed back on Earth
+
Service Module which supported the Command Module with propulsion, electrical power, oxygen and water
+
Lunar Module for landing on the Moon.
+
+
+
After being sent to the Moon by the Saturn V's upper stage, the astronauts separated the spacecraft from it and travelled for three days until they entered into lunar orbit. Armstrong and Aldrin then moved into the Lunar Module and landed in the Sea of Tranquility. They stayed a total of about 21 and a half hours on the lunar surface. After lifting off in the upper part of the Lunar Module and rejoining Collins in the Command Module, they returned to Earth and landed in the Pacific Ocean on July 24.
+ You can also create an inline editor from a textarea
+ element. In this case the textarea will be replaced
+ by a div element with inline editing enabled.
+
+
+// "article-body" is the name of a textarea element.
+var editor = CKEDITOR.inline( 'article-body' );
+
+ This sample shows the advantages of Magicline plugin
+ which is to enhance the editing process. Thanks to this plugin,
+ a number of difficult focus spaces which are inaccessible due to
+ browser issues can now be focused.
+
+
+ Magicline plugin shows a red line with a handler
+ which, when clicked, inserts a paragraph and allows typing. To see this,
+ focus an editor and move your mouse above the focus space you want
+ to access. The plugin is enabled by default so no additional
+ configuration is necessary.
+
+ This sample shows how to use the
+ setReadOnly
+ API to put editor into the read-only state that makes it impossible for users to change the editor contents.
+
+
+ For details on how to create this setup check the source code of this sample page.
+
+
+
+
+
+
diff --git a/frontend/drupal/sites/all/libraries/ckeditor/samples/old/replacebyclass.html b/frontend/drupal/sites/all/libraries/ckeditor/samples/old/replacebyclass.html
new file mode 100644
index 000000000..23652d6b3
--- /dev/null
+++ b/frontend/drupal/sites/all/libraries/ckeditor/samples/old/replacebyclass.html
@@ -0,0 +1,60 @@
+
+
+
+
+
+ Replace Textareas by Class Name — CKEditor Sample
+
+
+
+
+
+ This sample shows how tab key navigation among editor instances is
+ affected by the tabIndex attribute from
+ the original page element. Use TAB key to move between the editors.
+
+ This sample page demonstrates editor with loaded full toolbar (all registered buttons) and, if
+ current editor's configuration modifies default settings, also editor with modified toolbar.
+
+
+
Since CKEditor 4 there are two ways to configure toolbar buttons.
+ You can explicitly define which buttons are displayed in which groups and in which order.
+ This is the more precise setting, but less flexible. If newly added plugin adds its
+ own button you'll have to add it manually to your config.toolbar setting as well.
+
+
+
To add a CKEditor instance with custom toolbar setting, insert the following JavaScript call to your code:
+
+
+CKEDITOR.replace( 'textarea_id', {
+ toolbar: [
+ { name: 'document', items: [ 'Source', '-', 'NewPage', 'Preview', '-', 'Templates' ] }, // Defines toolbar group with name (used to create voice label) and items in 3 subgroups.
+ [ 'Cut', 'Copy', 'Paste', 'PasteText', 'PasteFromWord', '-', 'Undo', 'Redo' ], // Defines toolbar group without name.
+ '/', // Line break - next group will be placed in new line.
+ { name: 'basicstyles', items: [ 'Bold', 'Italic' ] }
+ ]
+});
+ You can define which groups of buttons (like e.g. basicstyles, clipboard
+ and forms) are displayed and in which order. Registered buttons are associated
+ with toolbar groups by toolbar property in their definition.
+ This setting's advantage is that you don't have to modify toolbar configuration
+ when adding/removing plugins which register their own buttons.
+
+
+
To add a CKEditor instance with custom toolbar groups setting, insert the following JavaScript call to your code:
+
+
+CKEDITOR.replace( 'textarea_id', {
+ toolbarGroups: [
+ { name: 'document', groups: [ 'mode', 'document' ] }, // Displays document group with its two subgroups.
+ { name: 'clipboard', groups: [ 'clipboard', 'undo' ] }, // Group's name will be used to create voice label.
+ '/', // Line break - next group will be placed in new line.
+ { name: 'basicstyles', groups: [ 'basicstyles', 'cleanup' ] },
+ { name: 'links' }
+ ]
+
+ // NOTE: Remember to leave 'toolbar' property with the default value (null).
+});
+
+
+
+
Current toolbar configuration
+
Below you can see editor with current toolbar definition.
+
+
+
+
+
+
Full toolbar configuration
+
Below you can see editor with full toolbar, generated automatically by the editor.
+
+ Note: To create editor instance with full toolbar you don't have to set anything.
+ Just leave toolbar and toolbarGroups with the default, null values.
+
+ This sample shows how to automatically replace <textarea> elements
+ with a CKEditor instance with an option to change the color of its user interface.
+ Note:The UI skin color feature depends on the CKEditor skin
+ compatibility. The Moono and Kama skins are examples of skins that work with it.
+
+ This sample shows how to automatically replace <textarea> elements
+ with a CKEditor instance with an option to change the language of its user interface.
+
+
+ It pulls the language list from CKEditor _languages.js file that contains the list of supported languages and creates
+ a drop-down list that lets the user change the UI language.
+
+
+ By default, CKEditor automatically localizes the editor to the language of the user.
+ The UI language can be controlled with two configuration options:
+ language and
+
+ defaultLanguage. The defaultLanguage setting specifies the
+ default CKEditor language to be used when a localization suitable for user's settings is not available.
+
+
+ To specify the user interface language that will be used no matter what language is
+ specified in user's browser or operating system, set the language property:
+
+
+CKEDITOR.replace( 'textarea_id', {
+ // Load the German interface.
+ language: 'de'
+});
+
+ Note that textarea_id in the code above is the id attribute of
+ the <textarea> element to be replaced.
+
+ Note that textarea_id in the code above is the id attribute of
+ the <textarea> element to be replaced.
+
+
+ The allowedContent in the code above is set to true to disable content filtering.
+ Setting this option is not obligatory, but in full page mode there is a strong chance that one may want be able to freely enter any HTML content in source mode without any limitations.
+
+ This sample shows how to configure CKEditor to output valid
+ XHTML 1.1 code.
+ Deprecated elements (<font>, <u>) or attributes
+ (size, face) will be replaced with XHTML compliant code.
+
+
+ To add a CKEditor instance outputting valid XHTML code, load the editor using a standard
+ JavaScript call and define CKEditor features to use the XHTML compliant elements and styles.
+
+
+ A snippet of the configuration code can be seen below; check the source of this page for
+ full definition:
+
You can replace the content of the config.js file with the generated configuration. If you already set some configuration options you will need to merge both configurations.
+
+
+
Read more about different ways of setting configuration and do not forget about clearing browser cache.
+
Arranging toolbar groups is the recommended way of configuring the toolbar, but if you need more freedom you can use the advanced configurator.
You can replace the content of the config.js file with the generated configuration. If you already set some configuration options you will need to merge both configurations.
+
+
+
Read more about different ways of setting configuration and do not forget about clearing browser cache.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/frontend/drupal/sites/all/modules/ckeditor/images/buttons/index.html b/frontend/drupal/sites/all/modules/ckeditor/images/buttons/index.html
new file mode 100644
index 000000000..fa6d84e80
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ckeditor/images/buttons/index.html
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ckeditor/includes/uicolor/samples/uicolor.html b/frontend/drupal/sites/all/modules/ckeditor/includes/uicolor/samples/uicolor.html
new file mode 100644
index 000000000..8b656f0e1
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ckeditor/includes/uicolor/samples/uicolor.html
@@ -0,0 +1,103 @@
+
+
+
+
+ UI Color Picker — CKEditor Sample
+
+
+
+
+
+
+
+
+
+ This sample shows how to use the UI Color picker toolbar button to preview the skin color of the editor.
+ Note:The UI skin color feature depends on the CKEditor skin
+ compatibility. The Moono and Kama skins are examples of skins that work with it.
+
We can use access plugins to determine access to a page or visibility of the panes in a page. Basically, we just determine access based on configuration settings and the various contexts that are available to us.
+
The arbitrary example in plugins/access/arg_length.inc determines access based on the length of the simplecontext argument. You can configure whether access should be granted if the simplecontext argument is greater or less than some number.
+
+
+
+
+
+
+
+
+
diff --git a/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Argument-Plugins--Starting-at-the-beginning.html b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Argument-Plugins--Starting-at-the-beginning.html
new file mode 100644
index 000000000..4dd569d71
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Argument-Plugins--Starting-at-the-beginning.html
@@ -0,0 +1,20 @@
+
+
+
+
+
+
+
Contexts are fundamental to CTools, and they almost always start with an argument to a panels page, so we'll start there too.
+
We first need to process an argument.
+
We're going to work with a "Simplecontext" context type and argument, and then with a content type that displays it. So we'll start by with the Simplecontext argument plugin in plugins/arguments/simplecontext_arg.inc.
+
Note that the name of the file (simplecontext_arg.inc) is built from the machine name of our plugin (simplecontext_arg). And note also that the primary function that we use to provide our argument (ctools_plugin_example_simplecontext_arg_ctools_arguments()) is also built from the machine name. This magic is most of the naming magic that you have to know.
+
You can browse plugins/arguments/simplecontext_arg.inc and see the little that it does.
+
+
+
+
+
+
+
+
+
diff --git a/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Chaos-Tools--CTools--Plugin-Examples.html b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Chaos-Tools--CTools--Plugin-Examples.html
new file mode 100644
index 000000000..7576c80bc
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Chaos-Tools--CTools--Plugin-Examples.html
@@ -0,0 +1,19 @@
+
+
+
+
+
+
+
This demonstration module is intended for developers to look at and play with. CTools plugins are not terribly difficult to do, but it can be hard to sort through the various arguments and required functions. The idea here is that you should have a starting point for most anything you want to do. Just work through the example, and then start experimenting with changing it.
+
There are two parts to this demo:
+
First, there is a sample panel provided that uses all the various plugins. It's at ctools_example/12345. You can edit the panel and configure all the panes on it.
+
Second, the code is there for you to experiment with and change as you see fit. Sometimes starting with simple code and working with it can take you places that it's hard to go when you're looking at more complex examples.
+
+
+
+
+
+
+
+
+
diff --git a/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Content-Type-Plugins--Displaying-content-using-a-context.html b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Content-Type-Plugins--Displaying-content-using-a-context.html
new file mode 100644
index 000000000..918a13cb8
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Content-Type-Plugins--Displaying-content-using-a-context.html
@@ -0,0 +1,17 @@
+
+
+
+
+
+
+
Now we get to the heart of the matter: Building a content type plugin. A content type plugin uses the contexts available to it to display something. plugins/content_types/simplecontext_content_type.inc does this work for us.
+
Note that our content type also has an edit form which can be used to configure its behavior. This settings form is accessed through the panels interface, and it's up to you what the settings mean to the code and the generation of content in the display rendering.
+
+
+
+
+
+
+
+
+
diff --git a/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Context-plugins--Creating-a--context--from-an-argument.html b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Context-plugins--Creating-a--context--from-an-argument.html
new file mode 100644
index 000000000..e8efbb390
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Context-plugins--Creating-a--context--from-an-argument.html
@@ -0,0 +1,21 @@
+
+
+
+
+
+
+
Now that we have a plugin for a simplecontext argument, we can create a plugin for a simplecontext context.
+
Normally, a context would take an argument which is a key like a node ID (nid) and retrieve a more complex object from a database or whatever. In our example, we'll artificially transform the argument into an arbitrary "context" data object.
Note that there are actually two ways to create a context. The normal one, which we've been referring to, is to create a context from an argument. However, it is also possible to configure a context in a panel using the panels interface. This is quite inflexible, but might be useful for configuring single page. However, it means that we have a settings form for exactly that purpose. Our context would have to know how to create itself from a settings form as well as from an argument. Simplecontext can do that.
+
A context plugin can also provide keywords that expose parts of its context using keywords like masterkeyword:dataitem. The node plugin for ctools has node:nid and node:title, for example. The simplecontext plugin here provides the simplest of keywords.
+
+
+
+
+
+
+
+
+
+
diff --git a/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Module-setup-and-hooks.html b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Module-setup-and-hooks.html
new file mode 100644
index 000000000..f816917dd
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Module-setup-and-hooks.html
@@ -0,0 +1,20 @@
+
+
+
+
+
+
+
Your module must provide a few things so that your plugins can be found.
+
First, you need to implement hook_ctools_plugin_directory(). Here we're telling CTools that our plugins will be found in the module's directory in the plugins/<plugintype> directory. Context plugins will be in ctools_plugin_example/plugins/contexts, Content-type plugins will be in ctools_plugin_example/plugins/content_types.
+
<?php function ctools_plugin_example_ctools_plugin_directory($module, $plugin) { if ($module == 'ctools' && !empty($plugin)) { return "plugins/$plugin"; } } ?>
+
Second, if you module wants to provide default panels pages, you can implement hook_ctools_plugin_api(). CTools will then pick up your panels pages in the file named <modulename>.pages_default.inc.
diff --git a/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Relationships--Letting-one-context-take-us-to-another.html b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Relationships--Letting-one-context-take-us-to-another.html
new file mode 100644
index 000000000..7691245ad
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/ctools_plugin_example/help/Relationships--Letting-one-context-take-us-to-another.html
@@ -0,0 +1,18 @@
+
+
+
+
+
+
+
Often a single data type can lead us to other data types. For example, a node has a user (the author) and the user has data associated with it.
+
A relationship plugin allows this kind of data to be accessed.
+
An example relationship plugin is provided in plugins/relationships/relcontext_from_simplecontext.inc. It looks at a simplecontext (which we got from an argument) and builds an (artificial) "relcontext" from that.
+
+
+
+
+
+
+
+
+
diff --git a/frontend/drupal/sites/all/modules/ctools/help/about.html b/frontend/drupal/sites/all/modules/ctools/help/about.html
new file mode 100644
index 000000000..30b64c2d3
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/about.html
@@ -0,0 +1,29 @@
+
The Chaos Tool Suite is a series of tools for developers to make code that I've found to be very useful to Views and Panels more readily available. Certain methods of doing things, particularly with AJAX, exportable objects and a plugin system, are proving to be ideas that are useful outside of just Views and Panels. This module does not offer much directly to the end user, but instead, creates a library for other modules to use. If you are an end user and some module asked you to install the CTools suite, then this is far as you really need to go. If you're a developer and are interested in these tools, read on!
The plugins tool allows a module to allow other modules (and themes!) to provide plugins which provide some kind of functionality or some kind of task. For example, in Panels there are several types of plugins: Content types (which are like blocks), layouts (which are page layouts) and styles (which can be used to style a panel). Each plugin is represented by a .inc file, and the functionality they offer can differ wildly.
Context is the idea that the objects that are used in page generation have more value than simply creating a single piece of output. Instead, contexts can be used to create multiple pieces of content that can all be put onto the page. Additionally, contexts can be used to derive other contexts via relationships, such as determining the node author and displaying data about the new context.
AJAX (also known as AHAH) is a method of allowing the browser and the server to communicate without requiring a page refresh. It can be used to create complicated interactive forms, but it is somewhat difficult to integrate into Drupal's Form API. These tools make it easier to accomplish this goal. In addition, CTools provides a few other javascript helpers, such as a modal dialog, a collapsible div, a simple dropdown and dependent checkboxes.
Drupal comes with a fantastic array of tools to ensure HTML is safe to output but does not contain any similar tools for CSS. CTools provides a small tool to sanitize CSS, so user-input CSS code can still be safely used. It also provides a method for caching CSS for better performance.
Views and Panels both use objects that can either be in code or in the database, and the objects can be exported into a piece of PHP code, so they can be moved from site to site or out of the database entirely. This library abstracts that functionality, so other modules can use this same concept for their data.
Drupal 6's FAPI really improved over Drupal 5, and made a lot of things possible. Still, it missed a few items that were needed to make form wizards and truly dynamic AJAX forms possible. CTools includes a replacement for drupal_get_form() that has a few more options and allows the caller to examine the $form_state once the form has completed.
Finally! An easy way to have form wizards, which is any 'form' that is actually a string of forms that build up to a final conclusion. The form wizard supports a single entry point, the ability to choose whether or not the user can go forward/back/up on the form and easy callbacks to handle the difficult job of dealing with data in between forms.
For normal forms, all of the data needed for an object is stored in the form so that the browser handles a lot of the work. For multi-step and ajax forms, however, this is impractical, and letting the browser store data can be insecure. The object cache provides a non-volatile location to store temporary data while the form is being worked on. This is much safer than the standard Drupal caching mechanism, which is volatile, meaning it can be cleared at any time and any system using it must be capable of recreating the data that was there. This system also allows for object locking, since any object which has an item in the cache from another person can be assumed to be 'locked for editing'.
+
diff --git a/frontend/drupal/sites/all/modules/ctools/help/ajax.html b/frontend/drupal/sites/all/modules/ctools/help/ajax.html
new file mode 100644
index 000000000..e69de29bb
diff --git a/frontend/drupal/sites/all/modules/ctools/help/collapsible-div.html b/frontend/drupal/sites/all/modules/ctools/help/collapsible-div.html
new file mode 100644
index 000000000..b9b6d9c63
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/collapsible-div.html
@@ -0,0 +1 @@
+
To be written.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/context-access.html b/frontend/drupal/sites/all/modules/ctools/help/context-access.html
new file mode 100644
index 000000000..95a8d7fbe
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/context-access.html
@@ -0,0 +1,12 @@
+
Access plugins allow context based access control to pages.
+
'title' => Title of the plugin
+ 'description' => Description of the plugin
+ 'callback' => callback to see if there is access is available. params: $conf, $contexts, $account
+ 'required context' => zero or more required contexts for this access plugin
+ 'default' => an array of defaults or a callback giving defaults
+ 'settings form' => settings form. params: &$form, &$form_state, $conf
+ settings form validate
+ settings form submit
+
+
+
Warning: your settings array will be stored in the meny system to reduce loads, so be trim.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/help/context-arguments.html b/frontend/drupal/sites/all/modules/ctools/help/context-arguments.html
new file mode 100644
index 000000000..5c479ae65
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/context-arguments.html
@@ -0,0 +1,14 @@
+
Arguments create a context from external input, which is assumed to be a string as though it came from a URL element.
+
+
'title' => title
+ 'description' => Description
+ 'keyword' => Default keyword for the context
+ 'context' => Callback to create the context. Params: $arg = NULL, $conf = NULL, $empty = FALSE
+ 'default' => either an array of default settings or a string which is a callback or null to not use.
+ 'settings form' => params: $form, $form_state, $conf -- gets the whole form. Should put anything it wants to keep automatically in $form['settings']
+ 'settings form validate' => params: $form, $form_state
+ 'settings form submit' => params: $form, $form_state
+ 'criteria form' => params: $form, &$form_state, $conf, $argument, $id -- gets the whole argument. It should only put form widgets in $form[$id]. $conf may not be properly initialized so always guard against this due to arguments being changed and handlers not being updated to match.
+ + submit + validate
+ 'criteria select' => returns true if the selected criteria matches the context. params: $context, $conf
+
diff --git a/frontend/drupal/sites/all/modules/ctools/help/context-content.html b/frontend/drupal/sites/all/modules/ctools/help/context-content.html
new file mode 100644
index 000000000..c1c6a356d
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/context-content.html
@@ -0,0 +1,157 @@
+
The CTools pluggable content system provides various pieces of content as discrete bits of data that can be added to other applications, such as Panels or Dashboard via the UI. Whatever the content is added to stores the configuration for that individual piece of content, and provides this to the content.
+
+
Each content type plugin will be contained in a .inc file, with subsidiary files, if necessary, in or near the same directory. Each content type consists of some information and one or more subtypes, which all use the same renderer. Subtypes are considered to be instances of the type. For example, the 'views' content type would have each view in the system as a subtype. Many content types will have exactly one subtype.
+
+
Because the content and forms can be provided via ajax, the plugin also provides a list of CSS and JavaScript information that should be available on whatever page the content or forms may be AJAXed onto.
+
+
For the purposes of selecting content from the UI, each content subtype will have the following information:
+
+
+
A title
+
A short description
+
A category [Do we want to add hierarchy categories? Do we want category to be more than just a string?]
+
An icon [do we want multiple icons? This becomes a hefty requirement]
+
+
+
Each piece of content provides one or more configuration forms, if necessary, and the system that includes the content will handle the data storage. These forms can be provided in sequence as wizards or as extra forms that can be accessed through advanced administration.
+
+
The plugin for a content type should contain:
+
+
+
title
+
For use on the content permissions screen.
+
content types
+
Either an array of content type definitions, or a callback that will return content type definitions. This callback will get the plugin definition as an argument.
+
+
content type
+
[Optional] Provide a single content type definition. This is only necessary if content types might be intensive.
+
+
render callback
+
The callback to render the content. Parameters:
+
+
$subtype
+
The name of the subtype being rendered. NOT the loaded subtype data.
+
+
$conf
+
The stored configuration for the content.
+
+
$args
+
Any arguments passed.
+
+
$context
+
An array of contexts requested by the required contexts and assigned by the configuration step.
+
+
$incoming_content
+
Any 'incoming content' if this is a wrapper.
+
+
+
+
admin title
+
A callback to provide the administrative title. If it is not a function, then it will be counted as a string to use as the admin title.
+
+
admin info
+
A callback to provide administrative information about the content, to be displayed when manipulating the content. It should contain a summary of configuration.
+
+
edit form
+
Either a single form ID or an array of forms *keyed* by form ID with the value to be used as the title of the form. %title me be used as a placeholder for the administrative title if necessary.
+ Example:
+
array(
+ 'ctools_example_content_form_second' => t('Configure first form'),
+ 'ctools_example_content_form_first' => t('Configure second form'),
+),
+
+The first form will always have required configuration added to it. These forms are normal FAPI forms, but you do not need to provide buttons, these will be added by the form wizard.
+
+
+
add form
+
[Optional] If different from the edit forms, provide them here in the same manner. Also may be set to FALSE to not have an add form.
+
+
css
+
A file or array of CSS files that are necessary for the content.
+
+
js
+
A file or array of javascript files that are necessary for the content to be displayed.
+
+
admin css
+
A file or array of CSS files that are necessary for the forms.
+
+
admin js
+
A file or array of JavaScript files that are necessary for the forms.
+
+
extra forms
+
An array of form information to handle extra administrative forms.
+
+
no title override
+
Set to TRUE if the title cannot be overridden.
+
+
single
+
Set to TRUE if this content provides exactly one subtype.
+
+
render last
+
Set to true if for some reason this content needs to render after other content. This is primarily used for forms to ensure that render order is correct.
+
+
+
TODO: many of the above callbacks can be assumed based upon patterns: modulename + '_' + name + '_' + function. i.e, render, admin_title, admin_info, etc.
+
+
TODO: Some kind of simple access control to easily filter out content.
+
+
The subtype definition should contain:
+
+
+
title
+
The title of the subtype.
+
+
icon
+
The icon to display for the subtype.
+
+
path
+
The path for the icon if it is not in the same directory as the plugin.
+
+
description
+
The short description of the subtype, to be used when selecting it in the UI.
+
+
category
+
Either a text string for the category, or an array of the text string followed by the category weight.
+
+
required context [Optional]
+
+
Either a ctools_context_required or ctools_context_optional or array of contexts for this content. If omitted, no contexts are used.
+
+
create content access [Optional]
+
+
An optional callback to determine if a user can access this subtype. The callback will receive two arguments, the type and subtype.
+
+
+
Rendered content
+
+
Rendered content is a little more than just HTML.
+
+
+
title
+
The safe to render title of the content.
+
+
content
+
The safe to render HTML content.
+
+
links
+
An array of links associated with the content suitable for theme('links').
+
+
more
+
An optional 'more' link (destination only)
+
+
admin_links
+
Administrative links associated with the content, suitable for theme('links').
+
+
feeds
+
An array of feed icons or links associated with the content. Each member of the array is rendered HTML.
+
+
type
+
The content type.
+
+
subtype
+
The content subtype. These two may be used together as module-delta for block style rendering.
+
+
+
Todo: example
+
+
Todo after implementations are updated to new version.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/context-context.html b/frontend/drupal/sites/all/modules/ctools/help/context-context.html
new file mode 100644
index 000000000..2314bd5ff
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/context-context.html
@@ -0,0 +1,13 @@
+
Context plugin data:
+
+
+ 'title' => Visible title
+ 'description' => Description of context
+ 'context' => Callback to create a context. Params: $empty, $data = NULL, $conf = FALSE
+ 'settings form' => Callback to show a context setting form. Params: ($conf, $external = FALSE)
+ 'settings form validate' => params: ($form, &$form_values, &$form_state)
+ 'settings form submit' => params: 'ctools_context_node_settings_form_submit',
+ 'keyword' => The default keyword to use.
+ 'context name' => The unique identifier for this context for use by required context checks.
+ 'no ui' => if TRUE this context cannot be selected.
+
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/help/context-relationships.html b/frontend/drupal/sites/all/modules/ctools/help/context-relationships.html
new file mode 100644
index 000000000..cc9969e1f
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/context-relationships.html
@@ -0,0 +1,13 @@
+
Relationship plugin data:
+
+
+ 'title' => The title to display.
+ 'description' => Description to display.
+ 'keyword' => Default keyword for the context created by this relationship.
+ 'required context' => One or more ctools_context_required/optional objects
+ describing the context input.
+ new panels_required_context(t('Node'), 'node'),
+ 'context' => The callback to create the context. Params: ($context = NULL, $conf)
+ 'settings form' => Settings form. Params: $conf
+ 'settings form validate' => Validate.
+
diff --git a/frontend/drupal/sites/all/modules/ctools/help/context.html b/frontend/drupal/sites/all/modules/ctools/help/context.html
new file mode 100644
index 000000000..e69de29bb
diff --git a/frontend/drupal/sites/all/modules/ctools/help/css.html b/frontend/drupal/sites/all/modules/ctools/help/css.html
new file mode 100644
index 000000000..b9b6d9c63
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/css.html
@@ -0,0 +1 @@
+
To be written.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/dependent.html b/frontend/drupal/sites/all/modules/ctools/help/dependent.html
new file mode 100644
index 000000000..b9b6d9c63
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/dependent.html
@@ -0,0 +1 @@
+
To be written.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/dropbutton.html b/frontend/drupal/sites/all/modules/ctools/help/dropbutton.html
new file mode 100644
index 000000000..b9b6d9c63
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/dropbutton.html
@@ -0,0 +1 @@
+
To be written.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/dropdown.html b/frontend/drupal/sites/all/modules/ctools/help/dropdown.html
new file mode 100644
index 000000000..b9b6d9c63
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/dropdown.html
@@ -0,0 +1 @@
+
To be written.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/export-ui.html b/frontend/drupal/sites/all/modules/ctools/help/export-ui.html
new file mode 100644
index 000000000..e6b1086e0
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/export-ui.html
@@ -0,0 +1,85 @@
+
Most user interfaces for exportables are very similar, so CTools includes a tool to provide the framework for the most common UI. This tool is a plugin of the 'export_ui' type. In order to create a UI for your exportable object with this tool, you first need to ensure that your module supports the plugin:
Then, you need to create a plugin .inc file describing your UI. Most of the UI runs with sane but simple defaults, so for the very simplest UI you don't need to do very much. This is a very simple example plugin for the 'example' export type:
+
+
+$plugin = array(
+ // The name of the table as found in the schema in hook_install. This
+ // must be an exportable type with the 'export' section defined.
+ 'schema' => 'example',
+
+ // The access permission to use. If not provided it will default to
+ // 'administer site configuration'
+ 'access' => 'administer example',
+
+ // You can actually define large chunks of the menu system here. Nothing
+ // is required here. If you leave out the values, the prefix will default
+ // to admin/structure and the item will default to the plugin name.
+ 'menu' => array(
+ 'menu prefix' => 'admin/structure',
+ 'menu item' => 'example',
+ // Title of the top level menu. Note this should not be translated,
+ // as the menu system will translate it.
+ 'menu title' => 'Example',
+ // Description of the top level menu, which is usually needed for
+ // menu items in an administration list. Will be translated
+ // by the menu system.
+ 'menu description' => 'Administer site example objects.',
+ ),
+
+ // These are required to provide proper strings for referring to the
+ // actual type of exportable. "proper" means it will appear at the
+ // beginning of a sentence.
+ 'title singular' => t('example'),
+ 'title singular proper' => t('Example'),
+ 'title plural' => t('examples'),
+ 'title plural proper' => t('Examples'),
+
+ // This will provide you with a form for editing the properties on your
+ // exportable, with validate and submit handler.
+ //
+ // The item being edited will be in $form_state['item'].
+ //
+ // The submit handler is only responsible for moving data from
+ // $form_state['values'] to $form_state['item'].
+ //
+ // All callbacks will accept &$form and &$form_state as arguments.
+ 'form' => array(
+ 'settings' => 'example_ctools_export_ui_form',
+ 'validate' => 'example_ctools_export_ui_form_validate',
+ 'submit' => 'example_ctools_export_ui_form_submit',
+ ),
+
+);
+
+
+
For a more complete list of what you can set in your plugin, please see ctools_export_ui_defaults() in includes/export-ui.inc to see what the defaults are.
+
+
More advanced UIs
+
+
The bulk of this UI is built on an class called ctools_export_ui, which is itself stored in ctools/plugins/export_ui as the default plugin. Many UIs will have more complex needs than the defaults provide. Using OO and overriding methods can allow an implementation to use the basics and still provide more where it is needed. To utilize this, first add a 'handler' directive to your plugin .inc file:
You can override any method found in the class (see the source file for details). In particular, there are several list methods that are good candidates for overriding if you need to provide richer data for listing, sorting or filtering. If you need multi-step add/edit forms, you can override edit_page(), add_page(), clone_page(), and import_page() to put your wizard in place of the basic editing system. For an example of how to use multi-step wizards, see the import_page() method.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/export.html b/frontend/drupal/sites/all/modules/ctools/help/export.html
new file mode 100644
index 000000000..573c98a68
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/export.html
@@ -0,0 +1,294 @@
+
Exportable objects are objects that can live either in the database or in code, or in both. If they live in both, then the object in code is considered to be "overridden", meaning that the version in code is ignored in favor of the version in the database.
+
+
The main benefit to this is that you can move objects that are intended to be structure or feature-related into code, thus removing them entirely from the database. This is a very important part of the deployment path, since in an ideal world, the database is primarily user generated content, whereas site structure and site features should be in code. However, many many features in Drupal rely on objects being in the database and provide UIs to create them.
+
+
Using this system, you can give your objects dual life. They can be created in the UI, exported into code and put in revision control. Views and Panels both use this system heavily. Plus, any object that properly implements this system can be utilized by the Features module to be used as part of a bundle of objects that can be turned into feature modules.
+
+
Typically, exportable objects have two identifiers. One identifier is a simple serial used for database identification. It is a primary key in the database and can be used locally. It also has a name which is an easy way to uniquely identify it. This makes it much less likely that importing and exporting these objects across systems will have collisions. They still can, of course, but with good name selection, these problems can be worked around.
+
+
Making your objects exportable
+
+
To make your objects exportable, you do have to do a medium amount of work.
+
+
+
Create a chunk of code in your object's schema definition in the .install file to introduce the object to CTools' export system.
+
Create a load function for your object that utilizes ctools_export_load_object().
+
Create a save function for your object that utilizes drupal_write_record() or any method you desire.
+
Create an import and export mechanism from the UI.
+
+
+
The export section of the schema file
+
+
Exportable objects are created by adding definition to the schema in an 'export' section. For example:
+
+
+function mymodule_schema() {
+ $schema['mymodule_myobj'] = array(
+ 'description' => t('Table storing myobj definitions.'),
+ 'export' => array(
+ 'key' => 'name',
+ 'key name' => 'Name',
+ 'primary key' => 'oid',
+ 'identifier' => 'myobj', // Exports will be as $myobj
+ 'default hook' => 'default_mymodule_myobj', // Function hook name.
+ 'api' => array(
+ 'owner' => 'mymodule',
+ 'api' => 'default_mymodule_myobjs', // Base name for api include files.
+ 'minimum_version' => 1,
+ 'current_version' => 1,
+ ),
+ // If the key is stored in a table that is joined in, specify it:
+ 'key in table' => 'my_join_table',
+
+ ),
+
+ // If your object's data is split up across multiple tables, you can
+ // specify additional tables to join. This is very useful when working
+ // with modules like exportables.module that has a special table for
+ // translating keys to local database IDs.
+ //
+ // The joined table must have its own schema definition.
+ //
+ // If using joins, you should implement a 'delete callback' (see below)
+ // to ensure that deletes happen properly. export.inc does not do this
+ // automatically!
+ 'join' => array(
+ 'exportables' => array(
+ // The following parameters will be used in this way:
+ // SELECT ... FROM {mymodule_myobj} t__0 INNER JOIN {my_join_table} t__1 ON t__0.id = t__1.id AND extras
+ 'table' => 'my_join_table',
+ 'left_key' => 'format',
+ 'right_key' => 'id',
+ // Optionally you can define a callback to add custom conditions or
+ // alter the query as necessary. The callback function takes 3 args:
+ //
+ // myjoincallback(&$query, $schema, $join_schema);
+ //
+ // where $query is the database query object, $schema is the schema for
+ // the export base table and $join_schema is the schema for the current
+ // join table.
+ 'callback' => 'myjoincallback',
+
+ // You must specify which fields will be loaded. These fields must
+ // exist in the schema definition of the joined table.
+ 'load' => array(
+ 'machine',
+ ),
+
+ // And finally you can define other tables to perform INNER JOINS
+ //'other_joins' => array(
+ // 'table' => ...
+ //),
+ ),
+ )
+ 'fields' => array(
+ 'name' => array(
+ 'type' => 'varchar',
+ 'length' => '255',
+ 'description' => 'Unique ID for this object. Used to identify it programmatically.',
+ ),
+ 'oid' => array(
+ 'type' => 'serial',
+ 'unsigned' => TRUE,
+ 'not null' => TRUE,
+ 'description' => 'Primary ID field for the table. Not used for anything except internal lookups.',
+ 'no export' => TRUE, // Do not export database-only keys.
+ ),
+ // ......
+ 'primary key' => array('oid'),
+ 'unique keys' => array(
+ 'name' => array('name'),
+ ),
+ );
+ return $schema;
+}
+
+
+
+
key
+
This is the primary key of the exportable object and should be a string as names are more portable across systems. It is possible to use numbers here, but be aware that export collisions are very likely. Defaults to 'name'.
+
+
key name
+
Human readable title of the export key. Defaults to 'Name'. Because the schema is cached, do not translate this. It must instead be translated when used.
+
+
primary key
+
A single field within the table that is to be used as the main identifier to discern whether or not the object has been written. As the schema definition's primary key value will be used by default, it is not usually necessary to define this.
+
+
object
+
The class the object should be created as, if 'object factory' is not set. If this is not set either, defaults as stdClass.
+
+
object factory
+
Function used to create the object. The function receives the schema and the loaded data as a parameters: your_factory_function($schema, $data). If this is set, 'object' has no effect since you can use your function to create whatever class you wish.
+
+
admin_title
+
A convenience field that may contain the field which represents the human readable administrative title for use in export UI. If a field "admin_title" exists, it will automatically be used.
+
+
admin_description
+
A convenience field that may contain the field which represents the human readable administrative title for use in export UI. If a field "admin_title" exists, it will automatically be used.
+
+
can disable
+
Control whether or not the exportable objects can be disabled. All this does is cause the 'disabled' field on the object to always be set appropriately, and a variable is kept to record the state. Changes made to this state must be handled by the owner of the object. Defaults to TRUE.
+
+
status
+
Exportable objects can be enabled or disabled, and this status is stored in a variable. This defines what variable that is. Defaults to: 'default_' . $table.
+
+
default hook
+
What hook to invoke to find exportable objects that are currently defined. These will all be gathered into a giant array. Defaults to 'default_' . $table.
+
+
cache defaults
+
If true, default objects will be cached so that the processing of the hook does not need to be called often. Defaults to FALSE. Recommended if you will potentially have a lot of objects in code. Not recommended if code will be the exception.
+
+
default cache bin
+
If default object caching is enabled, what cache bin to use. This defaults to the basic "cache". It is highly recommended that you use a different cache bin if possible.
+
+
identifier
+
When exporting the object, the identifier is the variable that the exported object will be placed in. Defaults to $table.
+
+
bulk export
+
Declares whether or not the exportable will be available for bulk exporting.
+
+
export type string
+
The export type string (Local, Overridden, Database) is normally stored as $item->type. Since type is a very common keyword, it's possible to specify what key to actually use.
+
+
list callback
+
Bulk export callback to provide a list of exportable objects to be chosen for bulk exporting. Defaults to $module . '_' . $table . '_list' if the function exists. If it is not, a default listing function will be provided that will make a best effort to list the titles. See ctools_export_default_list().
+
+
to hook code callback
+
Function used to generate an export for the bulk export process. This is only necessary if the export is more complicated than simply listing the fields. Defaults to $module . '_' . $table . '_to_hook_code'.
+
+
boolean
+
Explicitly indicate if a table field contains a boolean or not. The Schema API does not model the
+difference between a tinyint and a boolean type. Boolean values are stored in tinyint fields. This may cause mismatch errors when exporting a non-boolean value from a tinyint field. Add this to a tinyint field if it contains boolean data and can be exported. Defaults to TRUE.
+
+
create callback
+
CRUD callback to use to create a new exportable item in memory. If not provided, the default function will be used. The single argument is a boolean used to determine if defaults should be set on the object. This object will not be written to the database by this callback.
+
+
load callback
+
CRUD callback to use to load a single item. If not provided, the default load function will be used. The callback will accept a single argument which should be an identifier of the export key.
+
+
load multiple callback
+
CRUD callback to use to load multiple items. If not provided, the default multiple load function will be used. The callback will accept an array which should be the identifiers of the export key.
+
+
load all callback
+
CRUD callback to use to load all items, usually for administrative purposes. If not provided, the default load function will be used. The callback will accept a single argument to determine if the load cache should be reset or not.
+
+
save callback
+
CRUD callback to use to save a single item. If not provided, the default save function will be used. The callback will accept a single argument which should be the complete exportable object to save.
+
+
delete callback
+
CRUD callback to use to delete a single item. If not provided, the default delete function will be used. The callback will accept a single argument which can be *either* the object or just the export key to delete. The callback MUST be able to accept either.
+
+
export callback
+
CRUD callback to use for exporting. If not provided, the default export function will be used. The callback will accept two arguments, the first is the item to export, the second is the indent to place on the export, if any.
+
+
import callback
+
CRUD callback to use for importing. If not provided, the default export function will be used. This function will accept the code as a single argument and, if the code evaluates, return an object represented by that code. In the case of failure, this will return a string with human readable errors.
+
+
status callback
+
CRUD callback to use for updating the status of an object. If the status is TRUE the object will be disabled. If the status is FALSE the object will be enabled.
+
+
api
+
The 'api' key can optionally contain some information for the plugin API definition. This means that the imports can be tied to an API name which is used to have automatic inclusion of files, and can be used to prevent dangerous objects from older versions from being loaded, causing a loss of functionality rather than site crashes or security loopholes.
+
+
If not present, no additional files will be loaded and the default hook will always be a simple hook that must be either part of the .module file or loaded during normal operations.
+
+
api supports these subkeys:
+
+
+
owner
+
The module that owns the API. Typically this is the name of the module that owns the schema. This will be one of the two keys used by hook_ctools_plugin_api() to determine version compatibility. Note that the name of this hook can be tailored via the use of hook_ctools_plugin_api_hook_name(). See ctools_plugin_api_get_hook() for details.
+
api
+
This is the name of the API, and will be the second parameter to the above mentioned hook. It will also be used as part of the name of the file that the hook containing default objects will be in, which comes in the form of MODULENAME.API.inc.
+
minimum_version
+
The minimum version supported. Any module reporting an API less than this will not have its default objects used. This should be updated only when API changes can cause older objects to crash or otherwise break badly.
+
current_version
+
The current version of the API. Any module reporting a required API higher than this will not have its default objects used.
+
+
+
+
+
In addition, each field can contain the following:
+
+
no export
+
Set to TRUE to prevent that field from being exported.
+
+
export callback
+
A function to override the export behavior. It will receive ($myobject, $field, $value, $indent) as arguments. By default, fields are exported through ctools_var_export().
+
+
+
Reserved keys on exportable objects
+
+
Exportable objects have several reserved keys that are used by the CTools export API. Each key can be found at $myobj->{$key} on an object loaded through ctools_export_load_object(). Implementing modules should not use these keys as they will be overwritten by the CTools export API.
+
+
api_version
+
The API version that this object implements.
+
+
disabled
+
A boolean for whether the object is disabled.
+
+
export_module
+
For objects that live in code, the module which provides the default object.
+
+
export_type
+
A bitmask representation of an object current storage. You can use this bitmask in combination with the EXPORT_IN_CODE and EXPORT_IN_DATABASE constants to test for an object's storage in your code.
+
+
+
in_code_only
+
A boolean for whether the object lives only in code.
+
+
table
+
The schema API table that this object belongs to.
+
+
type
+
A string representing the storage type of this object. Can be one of the following:
+
+
Normal is an object that lives only in the database.
+
Overridden is an object that lives in the database and is overriding the exported configuration of a corresponding object in code.
+
Default is an object that lives only in code.
+
+Note: This key can be changed by setting 'export type string' to something else, to try and prevent "type" from conflicting.
+
+
+
+
The load callback
+
Calling ctools_export_crud_load($table, $name) will invoke your load callback, calling ctools_export_crud_load_multiple($table, $names) will invoke your load multiple callback, and calling ctools_export_crud_load_all($table, $reset) will invoke your load all callback. The default handlers should be sufficient for most uses.
+
+
Typically, there will be three load functions. A 'single' load, to load just one object, a 'multiple' load to load multiple objects, and an 'all' load, to load all of the objects for use in administrating the objects or utilizing the objects when you need all of them. Using ctools_export_load_object() you can easily do both, as well as quite a bit in between. This example duplicates the default functionality for loading one myobj.
+Calling ctools_export_crud_save($table, $object) will invoke your save callback. The default handlers should be sufficient for most uses. For the default save mechanism to work, you must define a 'primary key' in the 'export' section of your schema. The following example duplicates the default functionality for the myobj.
+
+
+/**
+* Save a single myobj.
+*/
+function mymodule_myobj_save(&$myobj) {
+ $update = (isset($myobj->oid) && is_numeric($myobj->oid)) ? array('oid') : array();
+ return drupal_write_record('myobj', $myobj, $update);
+}
+
+
+
Default hooks for your exports
+
All exportables come with a 'default' hook, which can be used to put your exportable into code. The easiest way to actually use this hook is to set up your exportable for bulk exporting, enable the bulk export module and export an object.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/form.html b/frontend/drupal/sites/all/modules/ctools/help/form.html
new file mode 100644
index 000000000..b9b6d9c63
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/form.html
@@ -0,0 +1 @@
+
To be written.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/modal.html b/frontend/drupal/sites/all/modules/ctools/help/modal.html
new file mode 100644
index 000000000..761fd2e32
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/modal.html
@@ -0,0 +1,215 @@
+
CTools provides a simple modal that can be used as a popup to place forms. It differs from the normal modal frameworks in that it does not do its work via an iframe. This is both an advantage and a disadvantage. The iframe simply renders normal pages in a sub-browser and they can do their thing. That makes it much easier to put arbitrary pages and forms in a modal. However, the iframe is not very good at actually communicating changes to the main page, so you cannot open the modal, have it do some work, and then modify the page.
+
+
Invoking the modal
+
+
The basic form of the modal can be set up just by including the javascript and adding the proper class to a link or form that will open the modal. To include the proper javascript, simply include the library and call the add_js function:
You can have links and buttons bound to use the modal by adding the class ctools-use-modal. For convenience, there is a helper function to try and do this, though it's not great at doing all links so using this is optional:
+
+/**
+ * Render an image as a button link. This will automatically apply an AJAX class
+ * to the link and add the appropriate javascript to make this happen.
+ *
+ * @param $image
+ * The path to an image to use that will be sent to theme('image') for rendering.
+ * @param $dest
+ * The destination of the link.
+ * @param $alt
+ * The alt text of the link.
+ * @param $class
+ * Any class to apply to the link. @todo this should be a options array.
+ */
+function ctools_modal_image_button($image, $dest, $alt, $class = '') {
+ return ctools_ajax_text_button(theme('image', array('path' => $image), $dest, $alt, $class, 'ctools-use-modal');
+}
+
+/**
+ * Render text as a link. This will automatically apply an AJAX class
+ * to the link and add the appropriate javascript to make this happen.
+ *
+ * Note: 'html' => true so be sure any text is vetted! Chances are these kinds of buttons will
+ * not use user input so this is a very minor concern.
+ *
+ * @param $text
+ * The text to display as the link.
+ * @param $dest
+ * The destination of the link.
+ * @param $alt
+ * The alt text of the link.
+ * @param $class
+ * Any class to apply to the link. @todo this should be a options array.
+ */
+function ctools_modal_text_button($text, $dest, $alt, $class = '') {
+ return ctools_ajax_text_button($text, $dest, $alt, $class, 'ctools-use-modal');
+}
+
+
+
Like with all CTools' AJAX functionality, the href of the link will be the destination, with any appearance of /nojs/ converted to /ajax/.
+
+
For submit buttons, however, the URL may be found a different, slightly more complex way. If you do not wish to simply submit the form to the modal, you can create a URL using hidden form fields. The ID of the item is taken and -url is appended to it to derive a class name. Then, all form elements that contain that class name are founded and their values put together to form a URL.
+
+
For example, let's say you have an 'add' button, and it has a select form item that tells your system what widget it is adding. If the id of the add button is edit-add, you would place a hidden input with the base of your URL in the form and give it a class of 'edit-add-url'. You would then add 'edit-add-url' as a class to the select widget allowing you to convert this value to the form without posting. If no URL is found, the action of the form will be used and the entire form posted to it.
+
+
Customizing the modal
+
+
If you do not wish to use the default modal, the modal can be customized by creating an array of data to define a customized modal. To do this, you add an array of info to the javascript settings to define the customizations for the modal and add an additional class to your modal link or button to tell it which modal to use.
+
+
First, you need to create a settings array. You can do this most easily with a bit of PHP:
The key to the array above (in this case, my-modal-style) is the identifier to your modal theme. You can have multiple modal themes on a page, so be sure to use an ID that will not collide with some other module's use. Using your module or theme as a prefix is a good idea.
+
+
Then, when adding the ctools-use-modal class to your link or button, also add the following class: ctools-modal-ID (in the example case, that would be ctools-modal-my-modal-style).
+
+
modalSize can be 'fixed' or 'scale'. If fixed it will be a raw pixel value; if 'scale' it will be a percentage of the screen.
+
+
You can set:
+
+
modalSize: an array of data to control the sizing of the modal. It can contain:
+
+
type: Either fixed or scale. If fixed, the modal will always be a fixed size. If scale the modal will scale to a percentage of the browser window. Default: scale.
+
width: If fixed the width in pixels. If scale the percentage of the screen expressed as a number less than zero. (For 80 percent, use .8, for example). Default: .8
+
height: If fixed the height in pixels. If scale the percentage of the screen expressed as a number less than zero. (For 80 percent, use .8, for example). Default: .8
+
addWidth: Any additional width to add to the modal in pixels. Only useful if the type is scale. Default: 0
+
addHeight: Any additional height to add to the modal in pixels. Only useful if the type is scale. Default: 0
+
contentRight: The number of pixels to remove from the content inside the modal to make room for scroll bar and decorations. Default: 25
+
contentBottom: The number of pixels to remove from the content inside the modal to make room for scroll bar and decorations. Default: 45
+
+
+
modalTheme: The Drupal javascript themable function which controls how the modal will be rendered. This function must be in the Drupal.theme.prototype namespace. If you set this value, you must include a corresponding function in a javascript file and use drupal_add_js() to add that file. Default: CToolsModalDialog
+
+ Drupal.theme.prototype.CToolsModalDialog = function () {
+ var html = ''
+ html += ' <div id="ctools-modal">'
+ html += ' <div class="ctools-modal-content">' // panels-modal-content
+ html += ' <div class="modal-header">';
+ html += ' <a class="close" href="#">';
+ html += Drupal.CTools.Modal.currentSettings.closeText + Drupal.CTools.Modal.currentSettings.closeImage;
+ html += ' </a>';
+ html += ' <span id="modal-title" class="modal-title"> </span>';
+ html += ' </div>';
+ html += ' <div id="modal-content" class="modal-content">';
+ html += ' </div>';
+ html += ' </div>';
+ html += ' </div>';
+
+ return html;
+ }
+
+
throbberTheme: The Drupal javascript themable function which controls how the modal throbber will be rendered. This function must be in the Drupal.theme.prototype namespace. If you set this value, you must include a corresponding function in a javascript file and use drupal_add_js() to add that file. Default: CToolsModalThrobber
+
+ Drupal.theme.prototype.CToolsModalThrobber = function () {
+ var html = '';
+ html += ' <div id="modal-throbber">';
+ html += ' <div class="modal-throbber-wrapper">';
+ html += Drupal.CTools.Modal.currentSettings.throbber;
+ html += ' </div>';
+ html += ' </div>';
+
+ return html;
+ };
+
+
+
modalOptions: The options object that's sent to Drupal.CTools.Modal.modalContent. Can contain any CSS settings that will be applied to the modal backdrop, in particular settings such as opacity and background. Default: array('opacity' => .55, 'background' => '#fff');
+
animation: Controls how the modal is animated when it is first drawn. Either show, fadeIn or slideDown. Default: show
+
animationSpeed: The speed of the animation, expressed either as a word jQuery understands (slow, medium or fast) or a number of milliseconds for the animation to run. Defaults: fast
+
closeText: The text to display for the close button. Be sure to wrap this in t() for translatability. Default: t('Close window')
+
closeImage: The image to use for the close button of the modal. Default: theme('image', array('path' => ctools_image_path('icon-close-window.png'), 'alt' => t('Close window'), 'title' => t('Close window')))
+
loadingText: The text to display for the modal title during loading, along with the throbber. Be sure to wrap this in t() for translatability. Default: t('Close window')
+
throbber: The HTML to display for the throbber image. You can use this instead of CToolsModalThrobber theme if you just want to change the image but not the throbber HTML. Default: theme('image', array('path' => ctools_image_path('throbber.gif'), 'alt' => t('Loading...'), 'title' => t('Loading')))
+
+
+
Rendering within the modal
+
To render your data inside the modal, you need to provide a page callback in your module that responds more or less like a normal page.
+
+
In order to handle degradability, it's nice to allow your page to work both inside and outside of the modal so that users whose javascript is turned off can still use your page. There are two ways to accomplish this. First, you can embed 'nojs' as a portion of the URL and then watch to see if that turns into 'ajax' when the link is clicked. Second, if you do not wish to modify the URLs, you can check $_POST['js'] or $_POST['ctools_js'] to see if that flag was set. The URL method is the most flexible because it is easy to send the two links along completely different paths if necessary, and it is also much easier to manually test your module's output by manually visiting the nojs URL. It's actually quite difficult to do this if you have to set $_POST['js'] to test.
+
+
In your hook_menu, you can use the a CTools' AJAX convenience loader to help:
The first argument to the page callback will be the result of ctools_js_load() which will return TRUE if 'ajax' was the string, and FALSE if anything else (i.e, nojs) is the string. Which means you can then declare your function like this:
+
+
+function ctools_ajax_sample_login($js) {
+ if ($js) {
+ // react with the modal
+ }
+ else {
+ // react without the modal
+ }
+}
+
+
+
If your modal does not include a form, rendering the output you wish to give the user is just a matter of calling the modal renderer with your data:
If you need to do more than just render your modal, you can use a CTools $commands array. See the function ctools_modal_render() for more information on what you need to do here.
+
+
If you are displaying a form -- and the vast majority of modals display forms -- then you need to do just slightly more. Fortunately there is the ctools_modal_form_wrapper() function:
+
+
+ ctools_include('modal');
+ ctools_include('ajax');
+ $form_state = array(
+ 'title' => t('Title of my form'),
+ 'ajax' => $js,
+ );
+ $output = ctools_modal_form_wrapper('my_form', $form_state);
+ // There are some possible states after calling the form wrapper:
+ // 1) We are not using $js and the form has been executed.
+ // 2) We are using $js and the form was successfully submitted and
+ // we need to dismiss the modal.
+ // Most other states are handled automatically unless you set flags in
+ // $form_state to avoid handling them, so we only deal with those two
+ // states.
+ if ($form_state['executed'] && $js) {
+ $commands = array();
+ $commands[] = ctools_modal_command_dismiss(t('Login Success'));
+ // In typical usage you will do something else here, such as update a
+ // div with HTML or redirect the page based upon the results of the modal
+ // form.
+ print ajax_render($commands);
+ exit;
+ }
+
+ // Otherwise, just return the output.
+ return $output;
+
+
+
You can also use CTools' form wizard inside the modal. You do not need to do much special beyond setting $form_state['modal'] = TRUE in the wizard form; it already knows how to handle the rest.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/object-cache.html b/frontend/drupal/sites/all/modules/ctools/help/object-cache.html
new file mode 100644
index 000000000..801a83672
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/object-cache.html
@@ -0,0 +1,132 @@
+
The CTools Object Cache is a specialized cache for storing data that is non-volatile. This differs from the standard Drupal cache mechanism, which is volatile, meaning that the data can be cleared at any time and it is expected that any cached data can easily be reconstructed. In contrast, data stored in this cache is not expected to be reconstructable. It is primarily used for storing user input which is retrieved in stages, allowing for more complex user interface interactions.
+
+
The object cache consists of 3 normal functions for cache maintenance, and 2 additional functions to facilitate locking.
+
+
To use any of these functions, you must first use ctools_include:
+
+
+ctools_include('object-cache');
+
+
+
+/**
+ * Get an object from the non-volatile ctools cache.
+ *
+ * This function caches in memory as well, so that multiple calls to this
+ * will not result in multiple database reads.
+ *
+ * @param $obj
+ * A 128 character or less string to define what kind of object is being
+ * stored; primarily this is used to prevent collisions.
+ * @param $name
+ * The name of the object being stored.
+ * @param $skip_cache
+ * Skip the memory cache, meaning this must be read from the db again.
+ *
+ * @return
+ * The data that was cached.
+ */
+function ctools_object_cache_get($obj, $name, $skip_cache = FALSE) {
+
+
+
+/**
+ * Store an object in the non-volatile ctools cache.
+ *
+ * @param $obj
+ * A 128 character or less string to define what kind of object is being
+ * stored; primarily this is used to prevent collisions.
+ * @param $name
+ * The name of the object being stored.
+ * @param $cache
+ * The object to be cached. This will be serialized prior to writing.
+ */
+function ctools_object_cache_set($obj, $name, $cache) {
+
+
+
+/**
+ * Remove an object from the non-volatile ctools cache
+ *
+ * @param $obj
+ * A 128 character or less string to define what kind of object is being
+ * stored; primarily this is used to prevent collisions.
+ * @param $name
+ * The name of the object being removed.
+ */
+function ctools_object_cache_clear($obj, $name) {
+
+
+
To facilitate locking, which is the ability to prohibit updates by other users while one user has an object cached, this system provides two functions:
+
+
+/**
+ * Determine if another user has a given object cached.
+ *
+ * This is very useful for 'locking' objects so that only one user can
+ * modify them.
+ *
+ * @param $obj
+ * A 128 character or less string to define what kind of object is being
+ * stored; primarily this is used to prevent collisions.
+ * @param $name
+ * The name of the object being removed.
+ *
+ * @return
+ * An object containing the UID and updated date if found; NULL if not.
+ */
+function ctools_object_cache_test($obj, $name) {
+
+
+
The object returned by ctools_object_cache_test can be directly used to determine whether a user should be allowed to cache their own version of an object.
+
+
To allow the concept of breaking a lock, that is, clearing another users changes:
+
+
+/**
+ * Remove an object from the non-volatile ctools cache for all session IDs.
+ *
+ * This is useful for clearing a lock.
+ *
+ * @param $obj
+ * A 128 character or less string to define what kind of object is being
+ * stored; primarily this is used to prevent collisions.
+ * @param $name
+ * The name of the object being removed.
+ */
+function ctools_object_cache_clear_all($obj, $name) {
+
+
+
Typical best practice is to use wrapper functions such as these:
+
+
+/**
+ * Get the cached changes to a given task handler.
+ */
+function delegator_page_get_page_cache($name) {
+ ctools_include('object-cache');
+ $cache = ctools_object_cache_get('delegator_page', $name);
+ if (!$cache) {
+ $cache = delegator_page_load($name);
+ $cache->locked = ctools_object_cache_test('delegator_page', $name);
+ }
+
+ return $cache;
+}
+
+/**
+ * Store changes to a task handler in the object cache.
+ */
+function delegator_page_set_page_cache($name, $page) {
+ ctools_include('object-cache');
+ $cache = ctools_object_cache_set('delegator_page', $name, $page);
+}
+
+/**
+ * Remove an item from the object cache.
+ */
+function delegator_page_clear_page_cache($name) {
+ ctools_include('object-cache');
+ ctools_object_cache_clear('delegator_page', $name);
+}
+
diff --git a/frontend/drupal/sites/all/modules/ctools/help/plugins-api.html b/frontend/drupal/sites/all/modules/ctools/help/plugins-api.html
new file mode 100644
index 000000000..548f17b51
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/plugins-api.html
@@ -0,0 +1,55 @@
+
APIs are a form of plugins that are tightly associated with a module. Instead of a module providing any number of plugins, each module provides only one file for an API and this file can contain hooks that the module should invoke.
+
+
Modules support this API by implementing hook_ctools_plugin_api($module, $api). If they support the API, they return a packet of data:
+
+
+function mymodule_ctools_plugin_api($module, $api) {
+ if ($module == 'some module' && $api = 'some api') {
+ return array(
+ 'version' => The minimum API version this system supports. If this API version is incompatible then the .inc file will not be loaded.
+ 'path' => Where to find the file. Optional; if not specified it will be the module's directory.
+ 'file' => an alternative version of the filename. If not specified it will be $module.$api.inc
+ );
+ }
+}
+
+
+
This implementation must be in the .module file.
+
+
Modules utilizing this can invole ctools_plugin_api_include() in order to ensure all modules that support the API will have their files loaded as necessary. It's usually easiest to create a small helper function like this:
Using a define will ensure your use of version numbers is consistent and easy to update when you make API changes. You can then use the usual module_invoke type commands:
If you need to pass references, this construct is standard:
+
+
+foreach (mymodule_include_api() as $module => $info) {
+ $function = $module . '_hookname';
+ // Just because they implement the API and include a file does not guarantee they implemented
+ // a hook function!
+ if (!function_exists($function)) {
+ continue;
+ }
+
+ // Typically array_merge() is used below if data is returned.
+ $result = $function($data1, $data2, $data3);
+}
+
+
+
TODO: There needs to be a way to check API version without including anything, as a module may simply
+provide normal plugins and versioning could still matter.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/plugins-creating.html b/frontend/drupal/sites/all/modules/ctools/help/plugins-creating.html
new file mode 100644
index 000000000..6d5b35f61
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/plugins-creating.html
@@ -0,0 +1,204 @@
+There are two primary pieces to using plugins. The first is getting the data, and the second is using the data.
+
+
Defining a plugin
+To define that you offer a plugin that modules can implement, you first must implement hook_ctools_plugin_type() to tell the plugin system about your plugin.
+
+
+
+The following information can be specified for each plugin type:
+
+
cache
+
Defaults to:FALSE
+
If set to TRUE, the results of ctools_get_plugins will be cached in the 'cache' table (by default), thus preventing .inc files from being loaded. ctools_get_plugins looking for a specific plugin will always load the appropriate .inc file.
+
cache table
+
Defaults to:'cache'
+
If 'cache' is TRUE, then this value specifies the cache table where the cached plugin information will be stored.
+
classes
+
Defaults to:array()
+
An array of class identifiers(i.e. plugin array keys) which a plugin of this type uses to provide classes to the CTools autoloader. For example, if classes is set to array('class'), then CTools will search each $plugin['class'] for a class to autoload. Depending of the plugin structure, a class identifier may be either:
+
+
- a file name:
+
the file which holds the class with the name structure as: [filename].[class].php
+
in this case the class name can be different than the class identifier
+
- the class name:
+
if the class is in the same file as the $plugin
+
the plugin .inc file can have a different name than the class identifier
+
+
+
defaults
+
Defaults to:array()
+
An array of defaults that should be added to each plugin; this can be used to ensure that every plugin has the basic data necessary. These defaults will not ovewrite data supplied by the plugin. This could also be a function name, in which case the callback will be used to provide defaults. NOTE, however, that the callback-based approach is deprecated as it is redundant with the 'process' callback, and as such will be removed in later versions. Consequently, you should only use the array form for maximum cross-version compatibility.
+
load themes
+
Defaults to:FALSE
+
If set to TRUE, then plugins of this type can be supplied by themes as well as modules. If this is the case, all themes that are currently enabled will provide a plugin: NOTE: Due to a slight UI bug in Drupal, it is possible for the default theme to be active but not enabled. If this is the case, that theme will NOT provide plugins, so if you are using this feature, be sure to document that issue. Also, themes set via $custom_theme do not necessarily need to be enabled, but the system has no way of knowing what those themes are, so the enabled flag is the only true method of identifying which themes can provide layouts.
+
hook
+
Defaults to: (dynamic value)
+
The name of the hook used to collect data for this plugin. Normally this is $module . '_' . $type -- but this can be changed here. If you change this, you MUST be sure to document this for your plugin implementors as it will change the format of the specially named hook.
+
process
+
Defaults to:''
+
An optional function callback to use for processing a plugin. This can be used to provide automated settings that must be calculated per-plugin instance (i.e., it is not enough to simply append an array via 'defaults'). The parameters on this callback are: callback(&$plugin, $info) where $plugin is a reference to the plugin as processed and $info is the fully processed result of hook_ctools_plugin_api_info().
+
extension
+
Defaults to:'inc'
+
Can be used to change the extension on files containing plugins of this type. By default the extension will be "inc", though it will default to "info" if "info files" is set to true. Do not include the dot in the extension if changing it, that will be added automatically.
+
info file
+
Defaults to:FALSE
+
If set to TRUE, then the plugin will look for a .info file instead of a .inc. Internally, this will look exactly the same, though obviously a .info file cannot contain functions. This can be good for styles that may not need to contain code.
+
use hooks
+
Defaults to:TRUE*
+
Use to enable support for plugin definition hooks instead of plugin definition files. NOTE: using a central plugin definition hook is less optimal for the plugins system, and as such this will default to FALSE in later versions.
+
child plugins
+
Defaults to:FALSE
+
If set to TRUE, the plugin type can automatically have 'child plugins' meaning each plugin can actually provide multiple plugins. This is mostly used for plugins that store some of their information in the database, such as views, blocks or exportable custom versions of plugins.
+
To implement, each plugin can have a 'get child' and 'get children' callback. Both of these should be implemented for performance reasons, since it is best to avoid getting all children if necessary, but if 'get child' is not implemented, it will fall back to 'get children' if it has to.
+
Child plugins should be named parent:child, with the : being the separator, so that it knows which parent plugin to ask for the child. The 'get children' method should at least return the parent plugin as part of the list, unless it wants the parent plugin itself to not be a choosable option, which is not unheard of.
+
'get children' arguments are ($plugin, $parent) and 'get child' arguments are ($plugin, $parent, $child).
+
+
+In addition, there is a 'module' and 'type' settings; these are for internal use of the plugin system and you should not change these.
+
Getting the data
+To create a plugin, a module only has to execute ctools_get_plugins with the right data:
+
+
+
+In the above example, $module should be your module's name and $type is the type of the plugin. It is typically best practice to provide some kind of wrapper function to make this easier. For example, Panels provides the following functions to implement the 'content_types' plugin:
+
+
+/**
+ * Fetch metadata on a specific content_type plugin.
+ *
+ * @param $content type
+ * Name of a panel content type.
+ *
+ * @return
+ * An array with information about the requested panel content type.
+ */
+function panels_get_content_type($content_type) {
+ ctools_include('context');
+ ctools_include('plugins');
+ return ctools_get_plugins('panels', 'content_types', $content_type);
+}
+
+/**
+ * Fetch metadata for all content_type plugins.
+ *
+ * @return
+ * An array of arrays with information about all available panel content types.
+ */
+function panels_get_content_types() {
+ ctools_include('context');
+ ctools_include('plugins');
+ return ctools_get_plugins('panels', 'content_types');
+}
+
+
+
Using the data
+
+Each plugin returns a packet of data, which is added to with a few defaults. Each plugin is guaranteed to always have the following data:
+
+
name
+
The name of the plugin. This is also the key in the array, of the full list of plugins, and is placed here since that is not always available.
+
module
+
The module that supplied the plugin.
+
file
+
The actual file containing the plugin.
+
path
+
The path to the file containing the plugin. This is useful for using secondary files, such as templates, css files, images, etc, that may come with a plugin.
+
+
+
Any of the above items can be overridden by the plugin itself, though the most likely one to be modified is the 'path'.
+
+
The most likely data (beyond simple printable data) for a plugin to provide is a callback. The plugin system provides a pair of functions to make it easy and consistent for these callbacks to be used. The first is ctools_plugin_get_function, which requires the full $plugin object.
+
+
+/**
+ * Get a function from a plugin, if it exists. If the plugin is not already
+ * loaded, try ctools_plugin_load_function() instead.
+ *
+ * @param $plugin
+ * The loaded plugin type.
+ * @param $callback_name
+ * The identifier of the function. For example, 'settings form'.
+ *
+ * @return
+ * The actual name of the function to call, or NULL if the function
+ * does not exist.
+ */
+function ctools_plugin_get_function($plugin, $callback_name)
+
+
+
The second does not require the full $plugin object, and will load it:
+
+
+/**
+ * Load a plugin and get a function name from it, returning success only
+ * if the function exists.
+ *
+ * @param $module
+ * The module that owns the plugin type.
+ * @param $type
+ * The type of plugin.
+ * @param $id
+ * The id of the specific plugin to load.
+ * @param $callback_name
+ * The identifier of the function. For example, 'settings form'.
+ *
+ * @return
+ * The actual name of the function to call, or NULL if the function
+ * does not exist.
+ */
+function ctools_plugin_load_function($module, $type, $id, $callback_name) {
+
+
+
Both of these functions will ensure any needed files are included. In fact, it allows each callback to specify alternative include files. The plugin implementation could include code like this:
Since the data provided by your plugin tends to be specific to your plugin type, you really need to document what the data returned in the hook in the .inc file will be or nobody will figure it out. Use advanced help and document it there. If every system that utilizes plugins does this, then plugin implementors will quickly learn to expect the documentation to be in the advanced help.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/plugins-implementing.html b/frontend/drupal/sites/all/modules/ctools/help/plugins-implementing.html
new file mode 100644
index 000000000..c95e72d42
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/plugins-implementing.html
@@ -0,0 +1,62 @@
+
There are two parts to implementing a plugin: telling the system where it is, and implementing one or more .inc files that contain the plugin data.
+
+
Telling the system where your plugins live
+
How a module implements plugins
+
To implement any plugins at all, you must implement a single function for all plugins: hook_ctools_plugin_directory. Every time a module loads plugins, this hook will be called to see which modules implement those plugins and in what directory those plugins will live.
The directory returned should be relative to your module. Another common usage is to simply return that you implement all plugins owned by a given module (or modules):
Typically, it is recommended that all plugins be placed into the 'plugins' directory for clarity and maintainability. Inside the directory, any number of subdirectories can be used. For plugins that require extra files, such as templates, css, javascript or image files, this is highly recommended:
Themes can implement plugins if the plugin owner specified that it's possible in its hook_ctools_plugin_type() call. If so, it is generally exactly the same as modules, except for one important difference: themes don't get hook_ctools_plugin_directory(). Instead, themes add a line to their .info file:
+
+
+plugins[module][type] = directory
+
+
+
How to structure the .inc file
+
+
The top of the .inc file should contain an array that defines the plugin. This array is simply defined in the global namespace of the file and does not need a function. Note that previous versions of this plugin system required a specially named function. While this function will still work, its use is now discouraged, as it is annoying to name properly.
+
+
This array should look something like this:
+
+
+$plugin = array(
+ 'key' => 'value',
+);
+
+
+
Several values will be filled in for you automatically, but you can override them if necessary. They include 'name', 'path', 'file' and 'module'. Additionally, the plugin owner can provide other defaults as well.
+
+
There are no required keys by the plugin system itself. The only requirements in the $plugin array will be defined by the plugin type.
+
+
After this array, if your plugin needs functions, they can be declared. Different plugin types have different needs here, so exactly what else will be needed will change from type to type.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/plugins.html b/frontend/drupal/sites/all/modules/ctools/help/plugins.html
new file mode 100644
index 000000000..1e64da095
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/plugins.html
@@ -0,0 +1,5 @@
+
The plugins tool allows a module to allow other modules (and themes!) to provide plugins which provide some kind of functionality or some kind of task. For example, in Panels there are several types of plugins: Content types (which are like blocks), layouts (which are page layouts) and styles (which can be used to style a panel). Each plugin is represented by a .inc file, and the functionality they offer can differ wildly.
+
+
A module which uses plugins can implement a hook describing the plugin (which is not necessary, as defaults will be filled in) and then calls a ctools function which loads either all the known plugins (used for listing/choosing) or a specific plugin (used when it's known which plugin is needed). From the perspective of the plugin system, a plugin is a packet of data, usually some printable info and a list of callbacks. It is up to the module implementing plugins to determine what that info means and what the callbacks do.
+
+
A module which implements plugins must first implement the hook_ctools_plugin_directory function, which simply tells the system which plugins are supported and what directory to look in. Each plugin will then be in a separate .inc file in the directory supplied. The .inc file will contain a specially named hook which returns the data necessary to implement the plugin.
diff --git a/frontend/drupal/sites/all/modules/ctools/help/wizard.html b/frontend/drupal/sites/all/modules/ctools/help/wizard.html
new file mode 100644
index 000000000..33fc45622
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/help/wizard.html
@@ -0,0 +1,311 @@
+
Form wizards, or multi-step forms, are a process by which the user goes through or can use an arbitrary number of different forms to create a single object or perform a single task. Traditionally the multi-step form is difficult in Drupal because there is no easy place to put data in between forms. No longer! The form wizard tool allows a single entry point to easily set up a wizard of multiple forms, provide callbacks to handle data storage and updates between forms and when forms are completed. This tool pairs well with the object cache tool for storage.
+
+
The form info array
+
The wizard starts with an array of data that describes all of the forms available to the wizard and sets options for how the wizard will present and control the flow. Here is an example of the $form_info array as used in the delegator module:
The above array starts with an id which is used to identify the wizard in various places and a path which is needed to redirect to the next step between forms. It then creates some settings which control which pieces are displayed. In this case, it displays a form trail and a 'back' button, but not the 'return' button. Then there are the wizard callbacks which allow the wizard to act appropriately when forms are submitted. Finally it contains a list of forms and their order so that it knows which forms to use and what order to use them by default. Note that the keys in the order and list of forms match; that key is called the step and is used to identify each individual step of the wizard.
+
+
Here is a full list of every item that can be in the form info array:
+
+
+
id
+
An id for wizard. This is used like a hook to automatically name callbacks, as well as a form step's form building function. It is also used in trail theming.
+
+
path
+
The path to use when redirecting between forms. %step will be replaced with the key for the form.
+
+
return path
+
When a form is complete, this is the path to go to. This is required if the 'return' button is shown and not using AJAX. It is also used for the 'Finish' button. If it is not present and needed, the cancel path will also be checked.
+
+
cancel path
+
When a form is canceled, this is the path to go to. This is required if the 'cancel' is shown and not using AJAX.
+
+
show trail
+
If set to TRUE, the form trail will be shown like a breadcrumb at the top of each form. Defaults to FALSE.
+
+
show back
+
If set to TRUE, show a back button on each form. Defaults to FALSE.
+
+
show return
+
If set to TRUE, show a return button. Defaults to FALSE.
+
+
show cancel
+
If set to TRUE, show a cancel button. Defaults to FALSE.
+
+
back text
+
Set the text of the 'back' button. Defaults to t('Back').
+
+
next text
+
Set the text of the 'next' button. Defaults to t('Continue').
+
+
return text
+
Set the text of the 'return' button. Defaults to t('Update and return').
+
+
finish text
+
Set the text of the 'finish' button. Defaults to t('Finish').
+
+
cancel text
+
Set the text of the 'cancel' button. Defaults to t('Cancel').
+
+
ajax
+
Turn on AJAX capabilities, using CTools' ajax.inc. Defaults to FALSE.
+
+
modal
+
Put the wizard in the modal tool. The modal must already be open and called from an ajax button for this to work, which is easily accomplished using functions provided by the modal tool.
+
+
ajax render
+
A callback to display the rendered form via ajax. This is not required if using the modal tool, but is required otherwise since ajax by itself does not know how to render the results. Params: &$form_state, $output.
+
+
finish callback
+
The function to call when a form is complete and the finish button has been clicked. This function should finalize all data. Params: &$form_state.
+Defaults to $form_info['id']._finish if function exists.
+
+
+
cancel callback
+
The function to call when a form is canceled by the user. This function should clean up any data that is cached. Params: &$form_state.
+Defaults to $form_info['id']._cancel if function exists.
+
+
return callback
+
The function to call when a form is complete and the return button has been clicked. This is often the same as the finish callback. Params: &$form_state.
+Defaults to $form_info['id']._return if function exists.
+
+
next callback
+
The function to call when the next button has been clicked. This function should take the submitted data and cache it for later use by the finish callback. Params: &$form_state.
+Defaults to $form_info['id']._next if function exists.
+
+
order
+
An optional array of forms, keyed by the step, which represents the default order the forms will be displayed in. If not set, the forms array will control the order. Note that submit callbacks can override the order so that branching logic can be used.
+
+
forms
+
An array of form info arrays, keyed by step, describing every form available to the wizard. If order array isn't set, the wizard will use this to set the default order. Each array contains:
+
+
form id
+
+ The id of the form, as used in the Drupal form system. This is also the name of the function that represents the form builder.
+ Defaults to $form_info['id']._.$step._form.
+
+
+
include
+
The name of a file to include which contains the code for this form. This makes it easy to include the form wizard in another file or set of files. This must be the full path of the file, so be sure to use drupal_get_path() when setting this. This can also be an array of files if multiple files need to be included.
+
+
title
+
The title of the form, to be optionally set via drupal_get_title. This is required when using the modal if $form_state['title'] is not set.
+
+
+
+
+
Invoking the form wizard
+
Your module should create a page callback via hook_menu, and this callback should contain an argument for the step. The path that leads to this page callback should be the same as the 'path' set in the $form_info array.
+
+
The page callback should set up the $form_info, and figure out what the default step should be if no step is provided (note that the wizard does not do this for you; you MUST specify a step). Then invoke the form wizard:
If using AJAX or the modal, This part is actually done! If not, you have one more small step:
+
+
+ return $output;
+
+
+
Forms and their callbacks
+
Each form within the wizard is a complete, independent form using Drupal's Form API system. It has a form builder callback as well as submit and validate callbacks and can be form altered. The primary difference between these forms and a normal Drupal form is that the submit handler should not save any data. Instead, it should make any changes to a cached object (usually placed on the $form_state) and only the _finish or _return handler should actually save any real data.
+
+
How you handle this is completely up to you. The recommended best practice is to use the CTools Object cache, and a good way to do this is to write a couple of wrapper functions around the cache that look like these example functions:
+
+
+/**
+ * Get the cached changes to a given task handler.
+ */
+function delegator_page_get_page_cache($name) {
+ ctools_include('object-cache');
+ $cache = ctools_object_cache_get('delegator_page', $name);
+ if (!$cache) {
+ $cache = delegator_page_load($name);
+ $cache->locked = ctools_object_cache_test('delegator_page', $name);
+ }
+
+ return $cache;
+}
+
+/**
+ * Store changes to a task handler in the object cache.
+ */
+function delegator_page_set_page_cache($name, $page) {
+ ctools_include('object-cache');
+ $cache = ctools_object_cache_set('delegator_page', $name, $page);
+}
+
+/**
+ * Remove an item from the object cache.
+ */
+function delegator_page_clear_page_cache($name) {
+ ctools_include('object-cache');
+ ctools_object_cache_clear('delegator_page', $name);
+}
+
+
+
Using these wrappers, when performing a get_cache operation, it defaults to loading the real object. It then checks to see if another user has this object cached using the ctools_object_cache_test() function, which automatically sets a lock (which can be used to prevent writes later on).
+
+
With this set up, the _next, _finish and _cancel callbacks are quite simple:
+
+
+/**
+ * Callback generated when the add page process is finished.
+ */
+function delegator_page_add_subtask_finish(&$form_state) {
+ $page = &$form_state['page'];
+
+ // Create a real object from the cache
+ delegator_page_save($page);
+
+ // Clear the cache
+ delegator_page_clear_page_cache($form_state['cache name']);
+}
+
+/**
+ * Callback generated when the 'next' button is clicked.
+ *
+ * All we do here is store the cache.
+ */
+function delegator_page_add_subtask_next(&$form_state) {
+ // Update the cache with changes.
+ delegator_page_set_page_cache($form_state['cache name'], $form_state['page']);
+}
+
+/**
+ * Callback generated when the 'cancel' button is clicked.
+ *
+ * All we do here is clear the cache.
+ */
+function delegator_page_add_subtask_cancel(&$form_state) {
+ // Update the cache with changes.
+ delegator_page_clear_page_cache($form_state['cache name']);
+}
+
+
+
All that's needed to tie this together is to understand how the changes made it into the cache in the first place. This happened in the various form _submit handlers, which made changes to $form_state['page'] based upon the values set in the form:
+
+
+/**
+ * Store the values from the basic settings form.
+ */
+function delegator_page_form_basic_submit($form, &$form_state) {
+ if (!isset($form_state['page']->pid) && empty($form_state['page']->import)) {
+ $form_state['page']->name = $form_state['values']['name'];
+ }
+
+ $form_state['page']->admin_title = $form_state['values']['admin_title'];
+ $form_state['page']->path = $form_state['values']['path'];
+
+ return $form;
+}
+
+
+
No database operations were made during this _submit, and that's a very important distinction about this system.
+
+
Proper handling of back button
+
When using 'show back' => TRUE the cached data should be assigned to the #default_value form property. Otherwise when the user goes back to the previous step the forms default values instead of his (cached) input is used.
The data is stored in the my data object on submitting. If the user goes back to this step the cached my data is used as the default form value. The function my_module_get_cache() is like the cache functions explained above.
+
+
Required fields, cancel and back buttons
+
If you have required fields in your forms, the back and cancel buttons will not work as expected since validation of the form will fail. You can add the following code to the top of your form validation to avoid this problem:
+
+/**
+ * Validation handler for step2 form
+ */
+function wizardid_step2_form_validate(&$form, &$form_state) {
+ // if the clicked button is anything but the normal flow
+ if ($form_state['clicked_button']['#next'] != $form_state['next']) {
+ drupal_get_messages('error');
+ form_set_error(NULL, '', TRUE);
+ return;
+ }
+ // you form validation goes here
+ // ...
+}
+
+
+
Wizard for anonymous users
+
If you are creating a wizard which is be used by anonymous users, you might run into some issues with drupal's caching for anonymous users. You can circumvent this by using hook_init and telling drupal to not cache your wizard pages:
+
+/**
+ * Implementation of hook init
+ */
+function mymodule_init() {
+ // if the path leads to the wizard
+ if (drupal_match_path($_GET['q'], 'path/to/your/wizard/*')) {
+ // set cache to false
+ $GLOBALS['conf']['cache'] = FALSE;
+ }
+}
+
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/about.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/about.html
new file mode 100644
index 000000000..fa58acafb
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/about.html
@@ -0,0 +1,11 @@
+The Page Manager module creates and manages pages in your Drupal site. Pages are defined as items that have a path and provide output to the user. It is a complete round trip from getting user input to providing user output.
+
+There are two types of pages that the Page Manager currently supports:
+
+
Custom pages
+
Custom pages are defined completely by the administrator. Their path, access control and visible menu characteristics are completely arbitrary.
+
System pages
+
System pages are defined by Drupal and Drupal modules. They primarily override pre-existing pages to provide different functionality. They often do not allow such features as access control in favor of what already exists, and they will usually 'fall back' to default Drupal behavior.
+
+
+Both types of pages figure out what to show the user by using Variants. Variants are output handlers, and every page should have at least one. Most pages will simply have only one. Pages with multiple variants will choose one and only one Variant to display content to the user and will use the Selection Rules to figure out which Variant to display.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/api-task-handler.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/api-task-handler.html
new file mode 100644
index 000000000..4544a2a86
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/api-task-handler.html
@@ -0,0 +1,43 @@
+task handler definition:
+ title -- visible title of the task handler.
+ description -- description of the task handler.
+ task type -- The type of the task this handler can service.
+ render -- callback of the function to render the handler. The arguments to this callback are specific to the task type.
+ admin title -- callback to render the admin title as this handler is listed.
+ params: $handler, $task, $subtask_id
+ admin summary -- callback to render what's in the collapsible info as the handler is listed. Optional.
+ params: $handler, $task, $subtask_id
+ default conf -- either an array() of default conf data or a callback that returns an array.
+ params: $handler, $task, $subtask_id
+ save -- callback to call just prior to the task handler being saved so it can adjust its data.
+ params: &$handler, $update (as drupal_write_record would receive)
+ export -- callback to call just prior to the task being exported. It should return text to append to the export if necessary.
+ params: &$handler, $indent
+
+ forms => array(
+ 'id' => array(
+ 'form' => form callback (receives $form, $form_state)
+ 'submit' => submit callback
+ 'validate' => validate callback
+ 'include' => an optional file to include to get functionality for this form. Must include full path.
+ 'no return' => hide the 'return' button, meaning that the form requires extra steps if submitted
+ 'alternate next' => an alternate next form. Used for hidden edit forms that don't have tabs.
+ 'no blocks' => if TRUE, use Drupal's mechanism to not render blocks for this form.
+ )
+ )
+ ),
+
+ 'add forms' => array(
+ 'form1', => t('form title'),
+ 'form2', => t('form title'),
+ // ...etc.../
+),
+ 'edit forms' => array(
+ 'id' => t('tab name'),
+ 'id2' => t('tab name'),
+ ),
+
+ If a form name is blank it is a 'hidden' form -- it has no tab but can still be reached.
+
+
+Notes: Because #required validation cannot be skipped when clicking cancel, please don't use it.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/api-task-type.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/api-task-type.html
new file mode 100644
index 000000000..eb87265f6
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/api-task-type.html
@@ -0,0 +1,2 @@
+
+defines a task type, grouping tasks together and providing a common UI for them.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/api-task.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/api-task.html
new file mode 100644
index 000000000..cd6e3d0cb
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/api-task.html
@@ -0,0 +1,38 @@
+task definition:
+ title -- visible title of the task.
+ description -- description of the task.
+ hook menu -- function to delegate from hook_menu. Params: &$items, $task
+ hook menu alter -- function to delegate from hook_menu_alter. Params: &$items, $task
+ hook theme -- function to delegate from hook_theme. Params: &$items, $task
+
+ admin name -- if set an admin menu will appear in the delegator UI
+ admin description -- to describe the admin menu
+
+ admin access callback -- if set, the callback to use to determine administrative
+ access to this task. Defaults to user_access. Note that this is required even
+ if delegator isn't handling administration, since this gets used to on handler
+ edit forms.
+ admin access arguments -- If set, the arguments to use to determine administrative
+ access to this task. Defaults to array('administer delegator');
+
+ type -- The type of the task, used to determine which handlers can service it.
+
+ subtasks -- can be TRUE in which case it supports subtasks with the default
+ configuration or a string (array?) with callbacks to fetch subtask data.
+ subtask callback -- A callback which returns just one subtask. Param: $task, $subtask_id
+ subtasks callback -- A callback which returns an array of all subtasks.
+ This MUST return an array, even if it's empty.Param: $task
+
+ default handlers -- If the task contains any default handlers, they can be included here.
+
+task names must not contain a - as that is used to separate the task name from the subtask ID.
+
+subtasks implement data very similar to their parent task. In particular, they
+implement the following items exactly like their task:
+ hook menu
+ hook menu alter
+ description
+ admin name
+ admin description
+ admin access callback
+ admin access arguments
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages-access.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages-access.html
new file mode 100644
index 000000000..a2643c28c
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages-access.html
@@ -0,0 +1,2 @@
+
+Please visit http://drupal.org/node/528072 to help provide this documentation page.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages-arguments.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages-arguments.html
new file mode 100644
index 000000000..516a4292b
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages-arguments.html
@@ -0,0 +1,2 @@
+
+Please visit http://drupal.org/node/528058 to help provide this documentation page.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages-menu.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages-menu.html
new file mode 100644
index 000000000..48cf9c397
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages-menu.html
@@ -0,0 +1,2 @@
+
+Please visit http://drupal.org/node/528078 to help provide this documentation page.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages.html
new file mode 100644
index 000000000..18e66d4be
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/custom-pages.html
@@ -0,0 +1,2 @@
+
+Please visit http://drupal.org/node/528050 to help provide this documentation page.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-create.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-create.html
new file mode 100644
index 000000000..a3d295e38
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-create.html
@@ -0,0 +1,2 @@
+
+Please visit http://drupal.org/node/528038 to help provide this documentation page.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-custom-nodes.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-custom-nodes.html
new file mode 100644
index 000000000..d62eb0f32
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-custom-nodes.html
@@ -0,0 +1,2 @@
+
+Please visit http://drupal.org/node/528044 to help provide this documentation page.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-custom-vocabulary.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-custom-vocabulary.html
new file mode 100644
index 000000000..7148cd96a
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-custom-vocabulary.html
@@ -0,0 +1,2 @@
+
+Please visit http://drupal.org/node/528046 to help provide this documentation page.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-members.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-members.html
new file mode 100644
index 000000000..87b21227c
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-members.html
@@ -0,0 +1,2 @@
+
+Please visit http://drupal.org/node/528040 to help provide this documentation page.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-page-list.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-page-list.html
new file mode 100644
index 000000000..d60bea4ad
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started-page-list.html
@@ -0,0 +1,2 @@
+
+Please visit http://drupal.org/node/528036 to help provide this documentation page.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started.html
new file mode 100644
index 000000000..6a75a3706
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/getting-started.html
@@ -0,0 +1,15 @@
+
+Note: this page is currently very preliminary. Please visit http://drupal.org/node/528034 to help provide this documentation page!
+
+This is a quick summary:
+
+
+
Visit administer >> structure >> pages to get to the primary page manager interface.
+
You can add custom pages for your basic landing pages, front pages, whatever you like for normal content display.
+
You can use the system pages to create finer control of how taxonomy vocabularies, nodes and user profiles are displayed.
+
When you add your first custom page, do not bother with the optional features. You will not need these until you get to more advanced tasks.
+
The selection rules are the key to creating node displays for just one node type.
+
Everything in this system is pluggable. A little PHP knowledge and exploration of the plugins directories can take you a long way.
+
+
+
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/page-task-type.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/page-task-type.html
new file mode 100644
index 000000000..c382c76ff
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/page-task-type.html
@@ -0,0 +1,4 @@
+
+Additional 'task' keys support:
+
+operations -- a list of operations suitable for theme('links')
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/ctools/page_manager/help/variants.html b/frontend/drupal/sites/all/modules/ctools/page_manager/help/variants.html
new file mode 100644
index 000000000..48cf9c397
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/ctools/page_manager/help/variants.html
@@ -0,0 +1,2 @@
+
+Please visit http://drupal.org/node/528078 to help provide this documentation page.
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/modules/views/help/about.html b/frontend/drupal/sites/all/modules/views/help/about.html
new file mode 100644
index 000000000..b03d1fcb3
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/about.html
@@ -0,0 +1,62 @@
+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 Node view type), content revisions (a Node revisions view type) or users (a User view type). A view may be restricted to members of specific user roles, and may be added, edited or deleted at the views administration page.
+
+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:
+
+
+
Fields, or the individual pieces of data being displayed. Adding the fields Node: Title, Node: Type, and Node: Post date to a node view, for example, includes the title, content type and creation date in the displayed results
+
+
Relationships, or information about how data elements relate to one another. If relationship data is available, like that provided by a CCK nodereference field, items from a related node may be included in the view
+
+
Arguments, or additional parameters that dynamically refine the view results, passed as part of the path. Adding an argument of Node: Type 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 "http://www.example.com/content/page" displays all posts of the type "page", the path "http://www.example.com/content/story" displays all posts of the type "story", and "http://www.example.com/content" displays all posts regardless of type)
+
+
Sort criteria, which determine the order of items displayed in the view results. Adding the sort criteria Node: Post date (in descending order) to a node view, for example, sorts the displayed posts in descending order by creation date
+
+
Filters, which limit items displayed in the results. Adding the filter Node: Published (and setting it equal to "Published") to a node view, for example, prevents unpublished items from being displayed
+
+
Displays, 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 page display, which gives a view a path and allows it to be the primary content of a page, or the block display which allows it to appear as secondary content on other pages.
+
+
Header, which allow you to add by default one or more text area above the views output.
+
+
Footer, which allow you to add by default one or more text area beneath the views output.
+
+
The Emtpy Text content will be displayed, when you choose in the Arguments Section "Action to take if argument is not present" the option "Display empty text".
+
+
+
+
+Parallels between the components in the Views interface and an sql query:
+
+
+
+
+
Sql Query
+
Views Component
+
+
+
+
SELECT n.title, u.name
+
fields
+
+
+
FROM {node} n base table
+
view type
+
+
+
INNER JOIN {users} u ON n.uid = u.uid
+
relationship
+
+
+
WHERE n.status = 1
+
filter
+
+
+
AND u.uid = arg(1)
+
argument
+
+
+
ORDER BY n.changed DESC
+
sort
+
+
diff --git a/frontend/drupal/sites/all/modules/views/help/advanced-settings.html b/frontend/drupal/sites/all/modules/views/help/advanced-settings.html
new file mode 100644
index 000000000..6a1685900
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/advanced-settings.html
@@ -0,0 +1,43 @@
+In the category Other you have different options to set Advanced configurations in your View.
+
+Machine Name:
+You can change the default machine name of the view.
+
+Comment: No comment
+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
+
+Use AJAX: No
+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.
+
+Hide attachments in summary: No
+
+Use aggregation: No
+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
+
+Query settings: Settings
+
+Here can you set advanced Settings for the SQL Settings
+
+
Disable SQL rewriting
+
+
Distinct: No
+ 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.
+
+
Use Slave Server
+
+
Query Comment
+
+Field Language: Current user's language
+
+Caching: None
+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."
+
+Link display: Page
+
+CSS class: None
+You can define some own CSS Classes for your View
+
+Theme: Information
+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 "Theme information" Page
diff --git a/frontend/drupal/sites/all/modules/views/help/advanced-style-settings.html b/frontend/drupal/sites/all/modules/views/help/advanced-style-settings.html
new file mode 100644
index 000000000..9c90c0f71
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/advanced-style-settings.html
@@ -0,0 +1,30 @@
+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.
+
+
+
+
Customize field HTML
+With Customize field HTML you can generate html tags around the field.
+
+
Customize label HTML
+Here you can generate html tags around the label of a field.
+
+
Customize field and label wrapper HTML
+Here you can generate html tags around the wrapper of the label and field
+
+
+
+
+Usage example
+
+In a view with a field:
+
+
Configure the field. (Click on the field.)
+
+
In the modal that opens, scroll down to Style Settings.
+
+
Choose one or more of the three Customize 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.
+
+
Decide if you want to keep the Views default classes. Unchecking this box means your markup is *it*.
+
+
+In Views 2 you needed for Style Settings the Semantic Views 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 this issue.
diff --git a/frontend/drupal/sites/all/modules/views/help/aggregation.html b/frontend/drupal/sites/all/modules/views/help/aggregation.html
new file mode 100644
index 000000000..83ad880d8
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/aggregation.html
@@ -0,0 +1 @@
+See: Group by
diff --git a/frontend/drupal/sites/all/modules/views/help/alter-exposed-filter.html b/frontend/drupal/sites/all/modules/views/help/alter-exposed-filter.html
new file mode 100644
index 000000000..ff3e9b6fc
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/alter-exposed-filter.html
@@ -0,0 +1,32 @@
+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:
+
+
+
+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():
+
+
diff --git a/frontend/drupal/sites/all/modules/views/help/analyze-theme.html b/frontend/drupal/sites/all/modules/views/help/analyze-theme.html
new file mode 100644
index 000000000..290dc0749
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/analyze-theme.html
@@ -0,0 +1,24 @@
+
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.
+
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.
+
+
The display 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.
+
+
The style 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.
+
+
The row style controls each individual row; not all styles utilize the row style (notably the table), but most others do.
+
+
Finally, field 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 bold.
+
+
+
+
+A breakdown of View output
+
+
+
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). 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.
+
+
Important note: You place your custom template files in your theme directory, not views/theme. This is always true of theming with Drupal.
+
+
In addition to this tool, the very useful devel 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.
+
+
Also, this feature will only work properly with Drupal 6.3 and later; prior to Drupal 6.3 this patch will be required.
diff --git a/frontend/drupal/sites/all/modules/views/help/api-default-views.html b/frontend/drupal/sites/all/modules/views/help/api-default-views.html
new file mode 100644
index 000000000..f676ed86f
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/api-default-views.html
@@ -0,0 +1,103 @@
+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 highly 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.
+
+
Creating a module
+First, create a directory in sites/all/modules for your new module. Call it whatever you like, but for this example we will call it mymodule.
+
+In this directory, create a mymodule.module file. It can be empty for now, but it should at least contain an opening PHP tag:
+
<?php
+
+
+It should not contain a closing ?> tag, as the closing ?> 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:
+
+
function mymodule_views_api() {
+ return array('api' => 2.0);
+}
+
+
+For other uses you may well add additional functions.
+
+Second, you need to create a mymodule.info file:
+
+
name = My module
+description = My site specific module.
+core = 6.x
+
+
+Once you have these two files set up, you should be able to activate your new module at the Administer >> Modules page.
+
Exporting your views
+
+The easiest way to do this is to activate the 'views_export' module, and navigate to Administer >> Structure >> Views >> Tools >> Bulk export 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 hook_views_default_views() 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:
+
+
$views[$view->name] = $view
+
+To place this into your hook_views_default_views() you will need to place that after the view, and make sure the function returns $views at the end.
+
+
Placing your exported views into your module
+Cut and paste the entire output of the bulk export tool into mymodule.views_default.inc -- and be sure to put a <?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 Overridden on the view list page. If you revert these views, they will be removed from the database, but will remain in code.
+
+
Theming your views in your module
+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 hook_theme() in your module:
+
+
+There are a small number of gotchas in doing this that you must be aware of.
+
+
+
When referring to a template filename, you always use dashes in the name. i.e, views-view--viewname--displayid.tpl.php. However, when referring to the hook or function names, you use underscores instead of dashes. i.e, views_view and views_view__viewname__displayid
+
+
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 views_view. Here are the possibilities:
+
+
+
+Be sure to use the right arguments line or the theme system will not properly translate.
+
+
The 'template' line should never include the extension, so drop the .tpl.php from it.
+
+
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:
+
+
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:
+
function mymodule_install() {
+ db_query("UPDATE {system} SET weight = 11 WHERE name = 'mymodule'");
+}
+
+ If you use this method, the base hook 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'.
+
+
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:
+
+
+ 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 api.drupal.org 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 views-view-list.tpl.php then that preprocess function would be named template_preprocess_views_view_list.
+
+ 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.
+
+
+
+
+ If you leave the path blank the template file will be searched for in "./" which is the Drupal install base path.
+
+
diff --git a/frontend/drupal/sites/all/modules/views/help/api-example.html b/frontend/drupal/sites/all/modules/views/help/api-example.html
new file mode 100644
index 000000000..819d65f59
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/api-example.html
@@ -0,0 +1,179 @@
+
+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
+
+
+<?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
+ );
+}
+?>
+
+
+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.
+
+
+<?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(
+ 'handler' => 'views_handler_field_numeric',
+ 'click sortable' => TRUE,
+ ),
+ 'filter' => array(
+ 'handler' => 'views_handler_filter_numeric',
+ ),
+ 'sort' => array(
+ 'handler' => 'views_handler_sort',
+ ),
+ );
+
+ // Color
+ $data['node_example']['color'] = array(
+ 'title' => t('Color'),
+ 'help' => t('Color of item.'),
+
+ 'field' => array(
+ 'handler' => 'views_handler_field',
+ 'click sortable' => TRUE,
+ ),
+ 'filter' => array(
+ 'handler' => 'views_handler_filter_string',
+ ),
+ 'argument' => array(
+ 'handler' => 'views_handler_argument_string',
+ ),
+ 'sort' => array(
+ 'handler' => 'views_handler_sort',
+ ),
+ );
+
+ return $data;
+}
+
+?>
+
+
+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.
+
+
Type/relationship extension
+
+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;'
+
+
+<?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 ****
+
+?>
+
+
+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.
diff --git a/frontend/drupal/sites/all/modules/views/help/api-forms.html b/frontend/drupal/sites/all/modules/views/help/api-forms.html
new file mode 100644
index 000000000..27729091d
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/api-forms.html
@@ -0,0 +1,88 @@
+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.
+
+
Implementation
+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().
+
+ function render($values) {
+ return '<!--form-item-' . $this->options['id'] . '--' . $this->view->row_index . '-->';
+ }
+
+ function form_element_name() {
+ // Make sure this value is unique for all the view fields
+ return $this->options['id'];
+ }
+
+ function form_element_row_id($row_id) {
+ // You could use values from $this->view->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->view->result)) {
+ return;
+ }
+
+ $field_name = $this->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->view->result as $row_id => $row) {
+ $form_element_row_id = $this->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
+ }
+
+
+The form is multistep by default, with one step: 'views_form_views_form'.
+A "form_example" module could add a confirmation step by setting:
+
+in form_example_views_form_submit().
+Then, views_form would call form_example_confirmation($form, $form_state, $view, $output) to get that step.
+
+Important: You can fetch the Views object in form_alter and validate / submit hooks from the form state:
+
+ $view = $form_state['build_info']['args'][0];
+
+
+
Relevant Views functions
+
+
template_preprocess_views_view()
+
views_form()
+
views_form_views_form()
+
views_form_views_form_validate()
+
views_form_views_form_submit()
+
theme_views_form_views_form()
+
+
+
Hooks
+
+
hook_views_form_substitutions()
+
diff --git a/frontend/drupal/sites/all/modules/views/help/api-handler-area.html b/frontend/drupal/sites/all/modules/views/help/api-handler-area.html
new file mode 100644
index 000000000..16c5e5c89
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/api-handler-area.html
@@ -0,0 +1,46 @@
+In Views areas (header, footer, empty-text) are pluggable, this means you can write your own php logic to place whatever you want.
+
+
Requirements
+You should have read API and Tables API to get a basic knowledge
+how to extend views.
+
+
Create your own area handler
+
+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:
+
+
+function yourmodule_views_data() {
+ $data['views']['collapsible_area'] = array(
+ 'title' => t('Collabsible Text area'),
+ 'help' => t('Provide collabsible markup text for the area.'),
+ 'area' => array(
+ 'handler' => 'yourmodule_handler_collapsible_area_text',
+ ),
+ );
+ return $data;
+}
+
+
+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:
+
+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' => 'fieldset',
+ '#title' => t('Title'),
+ '#value' => $render,
+ );
+ $output = theme('fieldset', $element);
+ return $output;
+ }
+ }
+}
+
+
+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 :)
diff --git a/frontend/drupal/sites/all/modules/views/help/api-tables.html b/frontend/drupal/sites/all/modules/views/help/api-tables.html
new file mode 100644
index 000000000..c80d29a28
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/api-tables.html
@@ -0,0 +1,265 @@
+Tables are described to Views by implementing hook_views_data(). This should be placed in MODULENAME.views.inc and it will be autoloaded (see Views' API). 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:
+
/**
+ * Implements hook_views_data().
+ */
+ function MODULENAME_views_data() {
+ $data = array(
+ 'foo' => array(
+ // ...info about the table named 'foo'...
+ ),
+ 'bar' => array(
+ // ...info about the table named 'bar'...
+ ),
+ 'baz' => array(
+ // ...info about the table named 'baz'...
+ ),
+ );
+ return $data;
+ }
+
+
+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:
+
+
$data['foo'] = array(
+ 'table' => array(
+ // ... info about the table, described later ...
+ ),
+ 'bar' => array(
+ // ... info about the field named 'bar', i.e, foo.bar,
+ ),
+ 'baz' => array(
+ // ... info about the field named 'baz', i.e, foo.baz,
+ ),
+);
+
+
+Once you get down to an array that contains actual data, that piece of the array will often be referred to as the definition.
+
+
The 'table' section
+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:
+
+
group
+
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.
+
title
+
The actual name of the field; it should be concise and descriptive.
+
help
+
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.
+
+
+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':
+
+
+ $data['foo']['table']['group'] = t('Foo');
+
+
+The other items in the 'table' section are described in the following sections.
+
+
'base': Base table
+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:
+
+ // Advertise this table as a possible base table
+ $data['node']['table']['base'] = array(
+ 'field' => 'nid',
+ 'title' => t('Node'),
+ 'help' => t("Nodes are a Drupal site's primary content."),
+ 'weight' => -10,
+ );
+
+
+The following items are available in the base section:
+
+
field
+
The primary key field for this table. For Views to treat any table as a base table, it must have a primary field. For node this is the 'nid', for users this is the 'uid', etc. 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. If your table does not have a primary key field, it is not too difficult to just add a serial field to it, usually.
+
title
+
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.
+
help
+
A short piece of text to describe what object this table contains.
+
database
+
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 it must be the same database type as your Drupal database. 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:
+
+ // 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';
+
+Then when you are describing the external database in your base table you would write something like this:
+
'join': Linking your table to existing base tables
+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.
+
+
+
+How taxonomy_term_data joins to node
+
+
+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:
+
+
+
+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.
+
+
+
+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:
+
+
handler
+
The name of the handler object to use. Defaults to 'views_join'. You may create custom join handlers that may or may not use any of the data below, as they see fit.
+
table
+
Table to join. This is optional, and should only be used if the table being referenced is an alias.
+
field
+
Field to join on. This is required.
+
left_table
+
The next step toward the final destination. If this is the final destination it may be omitted.
+
left_field
+
The field to join to on the left side. This is required.
+
type
+
Either LEFT (default) or INNER.
+
extra
+
Either a string that's directly added, or an array of items. Each item is, itself, an array:
+
+
table
+
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"
+
field
+
Field or formula, therein "%alias" can be used to reference the right table.
+
operator
+
Similar to filters, this is the operator, such as >, <, =, etc. Defaults to = or IN.
+
value
+
Must be set. If an array, operator will be defaulted to IN.
+
numeric
+
If true, the value will not be surrounded in quotes, and %d will be used for its placeholder.
+
+
+
extra type
+
How all the extras will be combined. Either AND or OR. Defaults to AND.
+
+
+
Describing fields on tables
+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:
+
+
+$data['node']['nid'] = array(
+ // The item it appears as on the UI,
+ 'title' => t('Nid'),
+ // The help that appears on the UI,
+ 'help' => t('The node ID of the node.'),
+ // Information for displaying the nid
+ 'field' => array(
+ 'handler' => 'views_handler_field_node',
+ 'click sortable' => TRUE,
+ ),
+ // Information for accepting a nid as an argument
+ 'argument' => array(
+ 'handler' => 'views_handler_argument_node_nid',
+ // The field to display in the summary.
+ 'name field' => 'title',
+ 'numeric' => TRUE,
+ 'validate type' => 'nid',
+ ),
+ // Information for accepting a nid as a filter
+ 'filter' => array(
+ 'handler' => 'views_handler_filter_numeric',
+ ),
+ // Information for sorting on a nid.
+ 'sort' => array(
+ 'handler' => 'views_handler_sort',
+ ),
+);
+
+
+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:
+
+
+$data['node']['edit_node'] = array(
+ 'field' => array(
+ 'title' => t('Edit link'),
+ 'help' => t('Provide a simple link to edit the node.'),
+ 'handler' => 'views_handler_field_node_link_edit',
+ ),
+);
+
+
+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:
+
+
+$data['users']['uid_current'] = array(
+ 'real field' => 'uid',
+ 'title' => t('Current'),
+ 'help' => t('Filter the view to the currently logged in user.'),
+ 'filter' => array(
+ 'handler' => 'views_handler_filter_user_current',
+ ),
+);
+
+
+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:
+
+
+
group, title, help
+
As above, these fields are for the UI. If placed here, any of these fields will override a setting on the base table.
+
real field
+
If this field is an alias, the "real field" may be placed here, and the handler will never know the difference.
+
+
field
+
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'.
+
filter
+
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'.
+
sort
+
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'.
+
relationship
+
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.
+
argument
+
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'.
+
+
+For more information about what handlers need/use what data, visit the Views API site and check out the available handlers.
+
+
Support old tabledata
+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
+
+$data['oldtable']['moved to'] = 'newtable';
+
+
+If you have to rename/move a single a field to another table you specify
+
diff --git a/frontend/drupal/sites/all/modules/views/help/api-upgrading.html b/frontend/drupal/sites/all/modules/views/help/api-upgrading.html
new file mode 100644
index 000000000..2ff6bb49a
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/api-upgrading.html
@@ -0,0 +1,226 @@
+In order to take advantage of the changes in Drupal 7, Views has gone through several API changes.
+Here's what you should know.
+
+
Handler registry
+
+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:
+
+name = Example module
+description = "Gives an example of a module."
+core = 7.x
+files[] = example.module
+files[] = example.install
+
+; Views handlers
+files[] = includes/views/handlers/example_handler_argument_string.inc
+
+
+
Removed handlers
+
+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.
+
+
Ctools dependency
+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.
+
+
+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.
+
+
Changed place for display specific settings
+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:
+
Changed filter settings and associated class variables
+'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'.
+
+
Changed argument settings
+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.
+
+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:
+
The introduction of get_value() and sanitize_value()
+The views_handler class got two new functions:
+
+/**
+ * Get the value that's supposed to be rendered.
+ *
+ * @param object $values
+ * An object containing all retrieved values.
+ * @param string $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 string $value
+ * The value being rendered.
+ * @param string $type
+ * The type of sanitization needed. If not provided, check_plain() is used.
+ */
+function sanitize_value($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;
+}
+
+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 sanitize_value() function.
+
+Examples of converting render() field handler implementations:
+
+// 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->sanitize_value($value);
+
+// Since sanitize_value() supports different sanitization functions, this:
+return filter_xss($value);
+// Can become:
+return $this->sanitize_value($value, 'xss');
+
+
+
+
Changed views_get_page_view
+In contrast to 6.x views_get_page_view now does stores the current view, not the current page display.
+
+
Removed views-view-row-node
+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.
+
+
Entity type Key on Base tables
+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'].
+
+
Changed views_plugin_style::render_grouping()
+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().
+
+
New return structure
+
+{grouping value} is the value affected by the new parameter.
+
+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!
+
+ array (
+ {rendered_value of the grouping field} => array({group rows}),
+ );
+
+
+
diff --git a/frontend/drupal/sites/all/modules/views/help/api.html b/frontend/drupal/sites/all/modules/views/help/api.html
new file mode 100644
index 000000000..2b743a757
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/api.html
@@ -0,0 +1,24 @@
+Views allows modules to describe their tables relationships to each other, as well as fields, filters, sort criteria and arguments via hook_views_data(). Whenever Views deems it necessary, this hook is called, the data aggregated together and cached. hook_views_data_alter() 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 hook_views_handlers() and hook_views_plugins().
+
+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, and must be referenced in your module's .info file with the files[] directive.
+
+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.
+
+
hook_views_api()
+In order for your files to be included, your module must first implement hook_views_api() in the main .module file. This module should return array of information. The following items may be returned:
+
+
+
api
+
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.
+
+You may find the current Views API version by calling views_api_version() 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 views_api_version() 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.
+
+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.
+
+
path
+
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'.
+
template path
+
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.
+
diff --git a/frontend/drupal/sites/all/modules/views/help/argument.html b/frontend/drupal/sites/all/modules/views/help/argument.html
new file mode 100644
index 000000000..da67e353d
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/argument.html
@@ -0,0 +1,106 @@
+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.
+
+
When the filter value is NOT in the URL
+
+
+
Display all results for the specified field
+
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.
+
Provide default value
+
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.
+
Hide view
+
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.
+
Display a summary
+
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.
+
Display contents of "No results found"
+
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.
+
+
+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.
+
+
Default contextual filters
+
+The Default contextual filter selection is available only if the action to take is "Provide default value" 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):
+
+
+
Content ID from URL
+
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.
+
Fixed value
+
You may directly enter what the contextual filter will be. This is not a variable, it will always be the same contextual filter.
+
PHP Code
+
Arbitrary php code inserted here will run whenever a contextual filter is not present in the URL.
+
Taxonomy term ID from URL
+
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.
+
User ID from URL
+
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.
+
User ID from logged in user
+
If a user is currently logged in and accessing this view, their user ID will be returned as the contextual filter.
+
Current date
+
This option simply returns today's date.
+
Current node's creation time
+
Select this to return a node's creation time as a contextual filter.
+
Current node's update time
+
Not surprisingly, this filter returns the current node's update time
+
+
+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.
+
+
When the filter value IS in the URL or a default is provided
+
+
+
Override title
+
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.
+
Override breadcrumb
+
This option will allow you to overwrite the view name in breadcrumbs. The same substitution values as in "Override title" may be used.
+
Specify validation criteria
+
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.
+
+
+
Contextual filter validation
+
+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:
+
+
+
Basic validation
+
This validator ensures that the contextual filter is present. A PHP NULL value (from eg. PHP default contextual filter code) will invalidate.
+
Content
+
This validator ensures that the contextual filter is a valid Node ID. You may select which node types the validator will accept.
+
Numeric
+
This validator ensures that the contextual filter is a valid number.
+
PHP Code
+
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.
+
Taxonomy term
+
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.
+
User
+
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.
+
+
+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.
+
+
+
Display all results for the specified field
+
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.
+
Hide View
+
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.
+
Return Summary
+
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."
+
Display contents of "No results found"
+
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.
+
+
+
Adminstrative title
+
+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.
+
+
Grouping of contextual filters
+
+Even though contextual filters do not appear in the "and/or" user interface for sorting and grouping regular filters, contextual filters are always added to the first 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 an effort to add this feature.
diff --git a/frontend/drupal/sites/all/modules/views/help/basic-settings.html b/frontend/drupal/sites/all/modules/views/help/basic-settings.html
new file mode 100644
index 000000000..be2cadc1e
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/basic-settings.html
@@ -0,0 +1,20 @@
+You choose the name of the current display.
+This title 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.
+
+
Display a specified number of items
+
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.
+
Display all items
+
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.
+
Paged output, full pager
+
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 expensive. 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 Exposed options 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.
+
+
Paged output, mini pager
+
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.
+
+Normally, all views are created with unrestricted access. 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.
diff --git a/frontend/drupal/sites/all/modules/views/help/demo-video.html b/frontend/drupal/sites/all/modules/views/help/demo-video.html
new file mode 100644
index 000000000..43c024033
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/demo-video.html
@@ -0,0 +1,5 @@
+
Here are some links to demonstration videos. It will get you started working with Views.
NodeOne's initial screencasts on the Views 3 UI.
diff --git a/frontend/drupal/sites/all/modules/views/help/display-attachment.html b/frontend/drupal/sites/all/modules/views/help/display-attachment.html
new file mode 100644
index 000000000..3dbdf88fa
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/display-attachment.html
@@ -0,0 +1 @@
+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.
diff --git a/frontend/drupal/sites/all/modules/views/help/display-block.html b/frontend/drupal/sites/all/modules/views/help/display-block.html
new file mode 100644
index 000000000..9ac6d315a
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/display-block.html
@@ -0,0 +1,11 @@
+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 administer >> site building >> blocks and selecting it from the list.
+
+Blocks do not 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.
+
+
+
Edit the argument in question; you may want to override this argument if you have multiple displays using it.
+
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".
+
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.
+
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.
+
If you are using a more link 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.
+
diff --git a/frontend/drupal/sites/all/modules/views/help/display-default.html b/frontend/drupal/sites/all/modules/views/help/display-default.html
new file mode 100644
index 000000000..b619981d5
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/display-default.html
@@ -0,0 +1,3 @@
+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 page display or a block display.
diff --git a/frontend/drupal/sites/all/modules/views/help/display-feed.html b/frontend/drupal/sites/all/modules/views/help/display-feed.html
new file mode 100644
index 000000000..beddd0085
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/display-feed.html
@@ -0,0 +1 @@
+A feed display allows you to attach an RSS feed to a view.
diff --git a/frontend/drupal/sites/all/modules/views/help/display-page.html b/frontend/drupal/sites/all/modules/views/help/display-page.html
new file mode 100644
index 000000000..9ab849956
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/display-page.html
@@ -0,0 +1,7 @@
+Page displays have a path and an optional menu 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.
diff --git a/frontend/drupal/sites/all/modules/views/help/display.html b/frontend/drupal/sites/all/modules/views/help/display.html
new file mode 100644
index 000000000..48b2475c9
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/display.html
@@ -0,0 +1,13 @@
+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 basic settings from the default display which all Views must have. For most settings, there is an override 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 'italic'. 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 fields, arguments, sorts, filters and relationships, 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 Reorder button you can organize the order of your displays.
+With the Analysis button the system checks the view and may give you suggestions if something is wrong.
+You can clone a display by using the link in the header of the display.
diff --git a/frontend/drupal/sites/all/modules/views/help/drush.html b/frontend/drupal/sites/all/modules/views/help/drush.html
new file mode 100644
index 000000000..689ff3391
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/drush.html
@@ -0,0 +1,13 @@
+There are some Drush commands available for Views, initially added in Drush command to revert views:
+
+
+
views-dev (vd) - Setup the views settings to a more developer oriented value
+
views-revert (vr) - Revert overridden views to their default state. Make backups first!
+
+
+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]
diff --git a/frontend/drupal/sites/all/modules/views/help/embed.html b/frontend/drupal/sites/all/modules/views/help/embed.html
new file mode 100644
index 000000000..156b1dca8
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/embed.html
@@ -0,0 +1,24 @@
+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 views_embed_view():
+
+/**
+ * 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 string $name
+ * The name of the view to embed.
+ * @param string $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') {
+
+
+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.
diff --git a/frontend/drupal/sites/all/modules/views/help/empty-text.html b/frontend/drupal/sites/all/modules/views/help/empty-text.html
new file mode 100644
index 000000000..0a085938c
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/empty-text.html
@@ -0,0 +1,3 @@
+The Emtpy Text content will be displayed when you choose the option Display empty text under the Arguments labelled Action to take if argument is not present.
+
+By default you can choose one or more text areas.
diff --git a/frontend/drupal/sites/all/modules/views/help/example-author-block.html b/frontend/drupal/sites/all/modules/views/help/example-author-block.html
new file mode 100644
index 000000000..41ff071dd
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/example-author-block.html
@@ -0,0 +1,77 @@
+
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 arguments to dynamically filter a view's contents at display time.
+
+
Before working through this example, enable the Blog module and populate some entries from a few different users.
+
+
Creating the View
+
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 add new view, enter the following properties, and click Next:
+
+
+
View name
+
recent_blog_entries
+
View description
+
List of recent blog entries for a given author.
+
View tag
+
blog
+
View type
+
Node
+
+
+
Generating a list of blog entries
+
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.
+
+
+
In the third column, locate the Fields area. Generally speaking, fields are the pieces of information that you want to display in the view (in this case, node title). Click the + icon to add a field.
+
Scroll down to Defaults: Add fields, below the settings table. A large selection of fields will be available.
+
In the Groups drop-down menu, select Node. This will limit the list to only the default fields exposed by Node module.
+
Scroll down the list, select the Node: Title field, and click Add.
+
You will now be presented with settings for the Node: Title field. Delete the label from the Label field, so that each individual node title is not prefixed with the word "Title." Additionally, check the Link this field to its node box so that visitors who see an interesting title can click directly on it to read the blog entry to which it belongs.
+
When finished, click Update. If you scroll down to the Live Preview 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.
+
In the fourth column, locate the Filters 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 + icon to add a filter.
+
As before, scroll down to the Defaults: Add filters section, select Node from the Groups select box to limit the list of options to only those exposed by Node module.
+
Scroll down and select the Node: Type field and click Add. In the settings page that appears, leave Operator as Is one of and select Blog entry under Node type. Click Update when finished.
+
Now, by scrolling down to Live preview, you'll see that the list only shows blog entries.
+
+
+
Adding context with arguments
+
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 always 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.
+
+
Luckily, there's another way to filter a view's content: arguments. 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.
+
+
Let's walk through adding and configuring an argument to our view so that we can change its contents based on post author.
+
+
+
In the third column, locate the Arguments area. Click the + icon to add an argument.
+
Because we are basing the view around content authors, this time under Groups select User. Check User: Uid and click Add.
+
The Defaults: Configure Argument User: Uid settings page has a lot going on, but only a few things that need our attention.
+
The Title field here, unlike the Title field under Basic Settings, 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.
+
Under Action to take if argument is not present, 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 Provide default argument.
+
Assuming JavaScript is enabled in your browser, you should now get another selection for Default argument type. Select User ID from URL, which will then provide a new option, Also look for a node and use the node author. 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.
+
Validator options provide a useful way to control what kind of arguments your view will accept. Select User as the Validator. 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.
+
Once you have changed the argument's title, default argument, and validator options, click Update to save your changes.
+
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 Arguments box and clicking Preview. You should now see a list of only user 1's blog entries.
+
+
+
Creating the block
+
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 Display.
+
+
+
In the first column, under Defaults, there is a select box containing entries such as Page, Feed, and, yes, Block! Select Block and click Add display.
+
There's not much else to do here as far as Views is concerned. Under Block settings, click the None link next to Admin and fill in a description for the block in the administrative interface, such as: 'Recent blog entries by author.' and click Update.
+
Save your work by clicking the Save button at the bottom of the Views interface. You should receive a message that the view has been saved.
+
Next, navigate to the blocks interface and drag the 'Recent blog entries by author' block to the right sidebar region (or similar) and click Save blocks.
+
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 main blog listing 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.
+
+
+
Finishing touches
+
There are still a few remaining things to do before our view is complete. For example, we said that the block was to show recent 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.
Add an additional filter by clicking the + icon in the Filters section in the fourth column.
+
Change Groups to Node and select Node: Published. Click Add.
+
Under the Published selection, choose Yes and click Update.
+
To handle sorting, locate the Sort criteria area, just above filters, and click the + icon there.
+
Under Groups, again select Node. From the list of options, check Node: Post date and click Add.
+
In the settings page, change Sort order to Descending. This will place the newer posts on top of the older ones. Click Update when finished.
+
Finally, Save the view for your new settings to take effect.
+
diff --git a/frontend/drupal/sites/all/modules/views/help/example-filter-by-current-user.html b/frontend/drupal/sites/all/modules/views/help/example-filter-by-current-user.html
new file mode 100644
index 000000000..b7fdd05d0
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/example-filter-by-current-user.html
@@ -0,0 +1,46 @@
+
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 filters and relationships to dynamically filter the view's contents at display time.
+
+
For this example, we are assuming you have a content type "Blog Post".
+
+
Creating the View
+
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 add new view, enter the following properties, and click Next:
+
+
+
View name
+
content_by_current_user
+
Description
+
List of content authored by the current user.
+
+
+
Choose ShowContentof typeBlog Post. You can choose any way you wish to sort the content.
+
+
Creating the page
+
Tick the box next to Create a page. Enter a page title and a path. For our purposes here, the default settings for the rest of this page are sufficient.
+
+
Click on Continue & edit.
+
+
Creating the relationship
+
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.
+
+
Under Advanced in the right culumn, select add next to Relationships.
+
Select Content: Author and click on Add and configure relationships. Leave the settings as they are and click on Apply (all displays).
+
+
You now have access to the user data related to the content you are viewing.
+
+
Filtering the view
+
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.
+
+
Next to Filter criteria click on add to add a new filter to your view.
+
+
Filter the list of fields by selecting User next to Filter at the top. You now have more fields than before due to the relationship you created.
+
+
Select User: Current from the list and click on Add and configure filter criteria.
+
+
Since this field is only visible due to the relationship you created, author will already be selected under Relationship. This shows that the relationship you created is being used for the filter field.
+
Select Yes under Is the logged in user, and click on Apply (all displays).
+
+
If you have authored content of the type Blog Post, you should now see a list of those posts under the preview section at the bottom.
+
+
Saving & testing the view
+
Click on Save to save the view.
+
You can test the view by going to the path you entered in the first part of this example.
diff --git a/frontend/drupal/sites/all/modules/views/help/example-recent-stories.html b/frontend/drupal/sites/all/modules/views/help/example-recent-stories.html
new file mode 100644
index 000000000..7e21324d3
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/example-recent-stories.html
@@ -0,0 +1,57 @@
+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.
+
+
+
Creating a new view
+
Go to add new view. Give your new view the name 'recent_stories', description 'Recent Stories', tag 'story', type 'Node' and click Next.
+
About the interface
+
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.
+
Selecting the fields to display
+
+
In 3rd column locate the Fields options. Click the + icon to add fields.
+
Scroll down to Defaults: Add fields. In the Groups drop-down menu select 'Node', then check the following two fields: Node: Post date, Node: Title. Then click Add.
+
You will be taken through the fields you added one at a time. Make the changes specified below.
+
+
For the Post date field: Delete the 'Post date' label. Change the Date format to Custom, and the Custom date format to 'F j, Y, g:i a' (do not type the single quotes; for the meaning of these letter codes, click on the PHP docs link under that box to arrive at the explanation). Click Update.
+
For the Title field: Delete the 'Title' label. Select Link this field to its node. Click Update.
+
+
+
Scroll back up to Fields and click the ↑↓ icon to rearrange fields.
+
Drag the four-sided arrow next to Node: Title so that it appears above Node: Post date. Click Update to save the new field order.
+
+
+
Filtering to story nodes only
+
+
Click the + icon next to Filters.
+
In the Groups drop-down menu select 'Node', then check the Node: Published and Node: Type filters, and click Add.
+
Select the Published checkbox. Click Update
+
Select Is one of and check Story in the Node Type field. Click Update.
+
+
+
Sorting to show most recent first
+
+
Scroll up to Sort criteria and click the + icon.
+
In the Groups drop-down menu below, select 'Node', then check Node: Post date, and click Add. Alternatively, you may instead check Node: Last comment time, or Node: Updated/commented date, or Node: Updated date.
+
Select DescendingSort order. Click Update.
+
+
+
Refining the basic settings
+
+
In 1st column under Basic settings locate these options:
+
+
Items to Display setting, click 10. Change the '10' to '4'. Click Update
+
Style setting, click Unformatted. Change to List. Click Update.
+
+
+
+
+
Adding a block display for custom options
+
+
In the dropdown on the left, ensure that Block is selected, and click Add Display.
+
Under Block settings, click the None link next to the Admin setting. Change Block: Block admin description to 'Recent Stories'.
+
+
+
Saving the view
+
Click Save to save your work.
+
Instructing Drupal to show the block
+
Finally, you should tell Drupal to show this block. Configure your block by going to admin/structure/block. Locate the block in the list: it is labeled Recent Stories. Place this block in a region and click Save. You may click Configure 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 '<front>'.
+
diff --git a/frontend/drupal/sites/all/modules/views/help/example-slideshow-thumb-pager.html b/frontend/drupal/sites/all/modules/views/help/example-slideshow-thumb-pager.html
new file mode 100644
index 000000000..1c83984d9
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/example-slideshow-thumb-pager.html
@@ -0,0 +1,54 @@
+
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 Views Slideshow and Image Styles to display images.
+
+
For this example, we are going to display a single image from each content item of the type "Photos", which we assume you have already set up with an image field. We are also assuming that Views Slideshow and at least one plugin is installed and activated.
+
+
Creating the image styles
+
+
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 Image Styles and create the following two styles:
+
+
+
Style name
+
slideshow_image
+
Effects
+
Scale and crop: 600px wide, 400px high
+
+
+
Style name
+
slideshow_thumbnail
+
Effects
+
Scale and crop: 30px wide, 20px high
+
+
+
Creating the View and block
+
+
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 add new view, enter the following properties, and click Next:
+
+
View name
+
Photo Slideshow
+
Description
+
Slideshow of images from Photos.
+
+
+
Choose ShowContentof typePhotos. You can choose any way you wish to sort the content.
+
Untick the box next to Create a page and tick the box next to Create a block. Enter a block title and choose Slideshow from the Display format select box. Select fields from the other select box. Leave the remaining settings as they are.
+
Click on Continue & edit.
+
+
Editing the view settings
+
+
Turn off the pager by clicking on Display a specified number of items in the middle column and selecting Display all items in the next screen, and applying the settings.
+
Enter a Block name by clicking on None at the top of the middle column.
+
Next, remove the Content: Title field from the fields list in the left column by blicking on rearrage under the arrow.
+
Next we have to add the thumbnail image field. Click on Add under the fields section and select your image field from the list. In the next screen, turn off the label, select Exclude from display and select slideshow_thumbnail from the Image Style select box. Under MORE, enter Thumbnail under Administrative Title.
+
Click on Apply (all displays).
+
Now we have to add the image field to display in the slideshow. Clcik on Add under the fields section and select your image field from the list. In the next screen, turn off the label and select slideshow_image from the Image Style select box. Under MORE, enter Display Image under Administrative Title.
+
Click on Apply (all displays).
+
+
Editing the slideshow settings
+
+
Click on Settings next to Format: Slideshow in the first column. In the screen that opens we can choose the options for our slideshow.
+
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 Pager under Bottom Widgets. Select Fields from the Pager Type select box. Select the tick box next to Thumbnail.
+
Click on Apply (all displays).
+
+
Saving & testing the view
+
Click on Save to save the view.
+
You can test the view by adding the block you have created to your theme.
diff --git a/frontend/drupal/sites/all/modules/views/help/example-user-feed.html b/frontend/drupal/sites/all/modules/views/help/example-user-feed.html
new file mode 100644
index 000000000..64b2b42ac
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/example-user-feed.html
@@ -0,0 +1,73 @@
+
In this example you will create a Feed display 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.
+
A feed 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 RSS transmission icon, 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 RSS in plain English.
+
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.
+
+
+
Creating a new view
+
+
Go to add new view. Give it the name 'user_feed', description 'A feed of user nodes.', tag 'users', type 'Node' and click Next.
+
+
+
About the Interface. 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 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.
+
+
Change default display
+
+
Under Basic Settings in the 2nd column, click Row style: Fields
+
A menu loads below, Defaults: How should each row in this view be styled, check the Node option, and click Update.
+
This loads another options menu, Defaults: Row style options click Update.
+
+
+
+
Create the RSS view
+
+
In the 1st column, select 'Feed' in the drop-down menu, and click Add Display.
+
Under Basic Settings in the 2nd column, click Row style:Missing style plugin
+
Note, options appear below the Views Interface, you may need to scroll to see Feed: How should each row in this view be styled
+ tick Node, then Update
+
This loads the next options menu- Display type: select "Use default RSS settings", click Update.
+
+
+
+
Set the path for accessing your feed
+
+
In the 2nd column under Feed settings, click Path: None
+
In options below Feed: The menu path or URL of this view enter in the path with an argument feeds/%/rss.xml
+
Click Update
+
+
+
+
Set up your arguments to say which user's nodes to display
+
+
To the right of Arguments, click the + sign to add and argument
+
In the Feed: Add arguments menu that loads below, select User in the pull-down menu
+
Check the box User: Name, click Add
+
Scroll down to options to find Case in path: select Lower case
+
Check the box Transform spaces to dashes in URL
+
Click Update default display
+
+
+
+
Sort to show most recent at top of feed
+
+
Scroll up to Sort criteria in the right most column and click the + icon.
+
In the Groups drop-down menu below, select 'Node', then check Node: Post date, and click Add.
+
Select DescendingSort order. Click Update.
+
+
+
+
Set filters to hide unpublished entries
+
+
Click the + icon next to Filters. In the options below, select Node under Groups drop-down menu, choose the Node: Published filter, and click Add.
+
Check the box Published. Click Update default display
+
+
+
+
Test
+
+
Click Save
+
Under Live preview type in the name of a user, in lowercase, replacing spaces with dashes, click Preview.
+
You should test and find your feeds at URLs like http://yoursite.com/feeds/user-name/rss.xml
+
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.
+
+
+
diff --git a/frontend/drupal/sites/all/modules/views/help/example-users-by-role.html b/frontend/drupal/sites/all/modules/views/help/example-users-by-role.html
new file mode 100644
index 000000000..f5228be3b
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/example-users-by-role.html
@@ -0,0 +1,47 @@
+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.
+
+
+
Creating a new view
+
Go to add new view. Give your new view the name 'user_list', description 'A simple user listing.', tag 'users', type 'User' and click Next.
+
About the Interface
+
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.
+
Creating a page display; choosing a URL and creating a menu link
+
+
In the 1st column, ensure that 'Page' is selected in the drop-down menu, and click Add Display.
+
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 Page settings in the 2nd column, and click the None link next to the Path setting. In the options editing area that appears below, set the path to 'user_list' (or something Implement you prefer) and click Update.
+
Next to Menu setting, Click the No menu link. In the options which appear below, select Normal menu entry, and set the title to 'User list' and click Update.
+
Scroll up to Basic settings, in that same 2nd column, and click the No link next to Use pager. Below, in the options, select Full pager and click Update default display.
+
+
+
Selecting the fields to display
+
+
In 3rd column locate the Fields options. Click the + icon to add fields.
+
Scroll down to Defaults: Add fields. In the Groups drop-down menu select 'User', then check the following fields: User: Created date, User: Delete link, User: Edit link, User: Last access, User: Name and User: Picture. Then click Add.
+
You will be taken through the fields you added one at a time. Click Update default display to go to each next field. Leave the default options on all fields except Delete link; change that field's label to 'Operations'.
+
Scroll back up to Fields and click the ↑↓ icon to rearrange fields. Down below, drag the Name field, by dragging its four-sided arrow, to the top. Drag the Delete link (Operations) field to the bottom, and the Edit link field just above it. Then click Update.
+
+
+
Seeing what we've done so far
+
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 Preview button; but generally this display updates automatically whenever you finish working in one of the mini forms.
+
Styling the view as a table; combining related fields into columns
+
+
Under Basic settings, in the 1st column, click the Unformatted link next to the Style setting. In the options below, under Page: How should this view be styled, choose Table and click Update default display.
+
You will be taken to a Page: Style options form to edit the table settings. Locate our Edit link field in this mini form, and notice the Column drop-down. Change this drop-down to show Operations. In the Separator column next to the Operations field, type ' | ' (note the spaces around the | symbol). Check all of the Sortable checkboxes, and set Default sort to Name. When finished, click Update default display.
+
+
+
Filtering the user list to exclude unwanted entries
+
+
Click the + icon next to Filters.
+
In the Groups drop-down menu select 'User', then check the User: Name filter, and click Add.
+
Select Is not one of and enter 'Anonymous' in the Usernames box. Click Update default display.
+
+
+
Adding an argument to list users by role dynamically
+
+
Scroll up to Arguments, and click its + icon.
+
Check the User: Roles argument, and click Add. Set the title to '%1' (don't type the quotes), and under Action to take if argument is not present select Summary, sorted ascending. Leave the other settings as they are. Click Update default display, and click Update through the prompts that follow to accept their default values.
+
+
+
Saving the view
+
Finally, click the Save button to save your work. At the very top, click View "Page" to go to your new view!
+
diff --git a/frontend/drupal/sites/all/modules/views/help/exposed-form.html b/frontend/drupal/sites/all/modules/views/help/exposed-form.html
new file mode 100644
index 000000000..ca06e9fba
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/exposed-form.html
@@ -0,0 +1,24 @@
+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".
+
+
Basic
+
When you expose a form and the view is loaded, no filter is selected and all items will displayed.
+
Input required
+
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.
+
+
+You have several options to customize the appearance of the exposed forms:
+
+
Submit button text
+
Text to display in the submit button of the exposed form.
+
Include reset button
+
If checked the exposed form will provide a button to reset all the applied exposed filters
+
Reset button label
+
Text to display in the reset button of the exposed form.
+
Exposed sorts label
+
Text to display as the label of the exposed sort select box.
+
Ascending
+
Text to use when exposed sort is ordered ascending.
+
Descending
+
Text to use when exposed sort is ordered descending.
+
diff --git a/frontend/drupal/sites/all/modules/views/help/field.html b/frontend/drupal/sites/all/modules/views/help/field.html
new file mode 100644
index 000000000..e9d9e609c
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/field.html
@@ -0,0 +1,27 @@
+Fields are the individual pieces of data being displayed. Adding the fields Node: Title, Node: Type, and Node: Post date 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 fields. For example, the 'node' row plugin 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 hook_views_data() hook.
+
+If you do not find a field, consider whether or not you need a Relationship.
+
+You can override the entire field section - see here 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:
+
+
Create a label: when checked, this opens a textbox that can be filled out to label the field.
+
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.
+
Link this field to the original piece of content: overrides any default link set up.
+
+
+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 Output this field as a link 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.
diff --git a/frontend/drupal/sites/all/modules/views/help/filter.html b/frontend/drupal/sites/all/modules/views/help/filter.html
new file mode 100644
index 000000000..cb84f8a8a
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/filter.html
@@ -0,0 +1,35 @@
+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:
+
+
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.
+
The 'Node: Promoted to front page' filter can be used to show only nodes that have the 'promote to front page' turned on.
+
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.
+
The 'User: Current' filter will show only nodes that the logged in user has authored.
+
The 'Node: Post date' filter can be used to show only nodes posted before, after, or between a range of dates.
+
+
+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 Relationship 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 here.
+
+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:
+
+
+
+
What the user see
What views does
+
+
+
Is lower than 10
Operator: Is Lower than. Value: 10
+
Is between 10 and 20
Operator: Is between. Value: 10 and 20
+
Is greater than 20
Operator: Is Greater. Value: 20
+
+
+
+Please note: 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 here for more information.
diff --git a/frontend/drupal/sites/all/modules/views/help/get-total-rows.html b/frontend/drupal/sites/all/modules/views/help/get-total-rows.html
new file mode 100644
index 000000000..623b35fe7
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/get-total-rows.html
@@ -0,0 +1,16 @@
+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.
+
+
diff --git a/frontend/drupal/sites/all/modules/views/help/getting-started.html b/frontend/drupal/sites/all/modules/views/help/getting-started.html
new file mode 100644
index 000000000..e05af40b9
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/getting-started.html
@@ -0,0 +1,23 @@
+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 have 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.
+
+
+
+The Views Edit UI
+
+
+Notes:
+1) Every view has a number of displays 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 default 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) Overrides mean that a particular display is not 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. If you change these values without first overriding them, you will change the default value for all displays that use them.
+
+4) Some items, particularly styles, have additional settings. Ordinarily when you update 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 locked, 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.
diff --git a/frontend/drupal/sites/all/modules/views/help/group-by.html b/frontend/drupal/sites/all/modules/views/help/group-by.html
new file mode 100644
index 000000000..871fb5368
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/group-by.html
@@ -0,0 +1,17 @@
+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.
+
+
+Where to set aggregation to get group settings
+
+
+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.
+
+
+
+Different aggregation possibilities
+
+
+
+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.
diff --git a/frontend/drupal/sites/all/modules/views/help/header.html b/frontend/drupal/sites/all/modules/views/help/header.html
new file mode 100644
index 000000000..bc31b490e
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/header.html
@@ -0,0 +1,3 @@
+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 here for more information.
diff --git a/frontend/drupal/sites/all/modules/views/help/menu.html b/frontend/drupal/sites/all/modules/views/help/menu.html
new file mode 100644
index 000000000..bb818a39b
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/menu.html
@@ -0,0 +1,21 @@
+Page displays can hook into the Drupal menu system and provide menu links that will appear in the Navigation system as well as tabs that can be used to keep Views next to each other.
+
+For simple menu links, 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.
+
+
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'.
+
All tabs must have one and only one default tab; this is usually the same content as the parent.
+
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.
+
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.
+
Drupal only supports 2 levels of tabs, so be careful about trying to put tabs within tabs within tabs. That won't work.
+
+
+For example, if you have two views that you want to be tabs, you could set it up like this:
+
+
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.
+
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'.
+
On the second view, set the path to 'tabs/tab2'; set it to be a 'Menu tab', and set the title to 'Tab 2'.
+
+
+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.
diff --git a/frontend/drupal/sites/all/modules/views/help/misc-notes.html b/frontend/drupal/sites/all/modules/views/help/misc-notes.html
new file mode 100644
index 000000000..8efc1f9e3
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/misc-notes.html
@@ -0,0 +1,11 @@
+
Image Assist & ImageField Assist
+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 this issue for more information
diff --git a/frontend/drupal/sites/all/modules/views/help/new.html b/frontend/drupal/sites/all/modules/views/help/new.html
new file mode 100644
index 000000000..bee52e9f0
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/new.html
@@ -0,0 +1,131 @@
+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):
+
+
+
+
+Everything below this point is subject to change based on the new Views wizard and UI in 7.x.
+
+
Note: Only UID 1 or users with the "Use PHP code" permission from the phpfilter module will be able to import views.
+
+
Admin interface
+The first thing that pops out after you install Views 2 is the radically different admin interface:
+
+
+Views 2 admin interface
+
+
+compared to the old comfy Views 1 interface:
+
+
+
+Views 1 admin interface
+
+
+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 Advanced Help 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 display, when setting style options, and in various editing sections such as path, menu and the like.
+
+Several new attributes of each view are visible in the filter header:
+
+
Tag - 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 Page will give all your views the Page template.
+
Display - 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.
+
Type - Views 2 view types are radically different from Views 1 types. Views 1 types basically defined how the node list displays were styled - you had Full Nodes, Teaser List, Table View, and so on. In Views 2 view display styles have been broken out into the separate Style 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.
+
+
+
+
Adding a view
+So let's jump in and add a view. For this example, we're going to create a user view, which will display a list of users.
+
+
+Adding a view
+
+
+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 User radio button.
+
+
+
+Configuring the new view
+
+
+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:
+
+
+
+Adding fields
+
+
+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 User: E-mail, User: Name and User: Picture fields.
+
+
+
+Adding fields
+
+
+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 update, 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.
+
+
+
+Rearranging fields
+
+
+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.
+
+
+
+Views preview
+
+
+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 Display 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 Default 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.
+
+
+
+Adding a Page display
+
+Let's stick with the Default display and twiddle some settings. We can set the Title to "User View 1" and the Style to Table. As mentioned earlier, view styles in Views 2 correspond more to view types in Views 1 (remember, List, Table, Teasers, Full nodes).
+
+
+
+Selecting a Views 1 View Type
+
+
+In Views 2, view styles 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 style as well as the row style which focus on different parts of the output.
+
+
+
+A breakdown of View output
+
+
+We change the style by clicking on the current style on the left hand side of the View information area.
+
+
+
+Selecting a Views 2 Display Style
+
+
+We're given the style options of Grid, List, Table and Unformatted. Additional display styles can be added by modules which have Views style plugins. 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.
+
+
+
+Selecting and configuring the table style
+
+
+... TODO: Finish this document ...
diff --git a/frontend/drupal/sites/all/modules/views/help/other-help.html b/frontend/drupal/sites/all/modules/views/help/other-help.html
new file mode 100644
index 000000000..a2100f398
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/other-help.html
@@ -0,0 +1,9 @@
+There are many tutorials, podcasts, and a few books on Views that you can turn to for further help.
+
+Books:
+Drupal Building Blocks is the Views' author book; check the Drupal.org books page for a fairly comprehensive list.
+
+Videos:
+See this page.
+
+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.
diff --git a/frontend/drupal/sites/all/modules/views/help/overrides.html b/frontend/drupal/sites/all/modules/views/help/overrides.html
new file mode 100644
index 000000000..08fb356bf
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/overrides.html
@@ -0,0 +1,6 @@
+
+If an item is using defaults then it is using values from the default display. IMPORTANT NOTE: If you modify this value, you are modifying the default display and thus modifying for all displays that are using default values.
+
+If that is not what you intend, you must click the override 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 relationships, arguments, fields, sort criterias, and filters, 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.
diff --git a/frontend/drupal/sites/all/modules/views/help/path.html b/frontend/drupal/sites/all/modules/views/help/path.html
new file mode 100644
index 000000000..eb44de791
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/path.html
@@ -0,0 +1,7 @@
+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 foo/bar and a user visits http://www.example.com/foo/bar/baz/beta, 'baz' and 'beta' will be given as arguments to the view. These can be handled by adding items to the arguments section.
+
+You may also use placeholders in your path to represent arguments that come in the middle. For example, the path node/%/someview would expect the first argument to be the second part of the path. For example, node/21/someview would have an argument of '21'.
+
+Note: Views 1 used $arg for this kind of thing. $arg is no longer allowed as part of the path. You must use % instead.
+
+If multiple displays within the same view 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.
diff --git a/frontend/drupal/sites/all/modules/views/help/performance-views-vs-displays.html b/frontend/drupal/sites/all/modules/views/help/performance-views-vs-displays.html
new file mode 100644
index 000000000..9f02a5a90
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/performance-views-vs-displays.html
@@ -0,0 +1,5 @@
+
Multiple displays in one view is appropriate when they are fundamentally similar and are sharing quite a fair amount of data. 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.
+
+
In the other hand, having multiple displays in one view that contains mostly overrides 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.
+
+
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.
diff --git a/frontend/drupal/sites/all/modules/views/help/performance.html b/frontend/drupal/sites/all/modules/views/help/performance.html
new file mode 100644
index 000000000..e393452e1
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/performance.html
@@ -0,0 +1 @@
+
Views module is optimized for certain practices. To ensure Views has its best performance, please follow these best practices for Views.
diff --git a/frontend/drupal/sites/all/modules/views/help/relationship-representative.html b/frontend/drupal/sites/all/modules/views/help/relationship-representative.html
new file mode 100644
index 000000000..cf7feb5b7
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/relationship-representative.html
@@ -0,0 +1,14 @@
+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 representative node 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.
+
+
Performance
+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 MySQL tutorial on group-wise maximum queries.
diff --git a/frontend/drupal/sites/all/modules/views/help/relationship.html b/frontend/drupal/sites/all/modules/views/help/relationship.html
new file mode 100644
index 000000000..2e3c09ca0
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/relationship.html
@@ -0,0 +1,17 @@
+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 --> 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 not 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 Files 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 overrides for more information.
diff --git a/frontend/drupal/sites/all/modules/views/help/reports.html b/frontend/drupal/sites/all/modules/views/help/reports.html
new file mode 100644
index 000000000..2a6087355
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/reports.html
@@ -0,0 +1,3 @@
+Visit admin/reports/views-fields to see an overview of fields usage across all the views.
+
+It's useful to check for unused or misused fields.
diff --git a/frontend/drupal/sites/all/modules/views/help/select-multple-nids-contextual-filters.html b/frontend/drupal/sites/all/modules/views/help/select-multple-nids-contextual-filters.html
new file mode 100644
index 000000000..433d751ce
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/select-multple-nids-contextual-filters.html
@@ -0,0 +1,28 @@
+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.
+
+
+
In the views administration screen add a new 'contextual filter' using 'add'. You will see a configuration screen appear as a modal.
+
+
In the 'Filter' jump menu that you now see select 'Content'. A list will appear below the jump menu.
+
+
In the list look for 'Content: Nid', and check it.
+
+
Press the 'Add and configure contextual filters' button. You will now get the configuration screen for 'Content: Nid'.
+
+
Under 'When the filter value is NOT in the URL' select 'Provide default argument', and leave it set at 'Fixed value'.
+
+
In the field 'Fixed value' add the Nids of the nodes separated by a '+' that you want to show by default.
+
+
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.
+
+
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
+
+
For the 'Filter value format' select 'Node IDs separated by , or +'.
+
+
Select the MORE link.
+
+
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)).
+
+
+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.
diff --git a/frontend/drupal/sites/all/modules/views/help/semantic-views.html b/frontend/drupal/sites/all/modules/views/help/semantic-views.html
new file mode 100644
index 000000000..ef645c6d1
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/semantic-views.html
@@ -0,0 +1,18 @@
+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 this issue.
+
+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:
+
+
Configure the field. (Click on the field.)
+
+
In the modal that opens, scroll down to Style Settings.
+
+
Choose one or more of the three Customize 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.
+
+
Decide if you want to keep the Views default classes. Unchecking this box means your markup is *it*.
+
+You can override the complete sort criteria section - see here for more information.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-comment-rss.html b/frontend/drupal/sites/all/modules/views/help/style-comment-rss.html
new file mode 100644
index 000000000..5ce1dcd0d
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-comment-rss.html
@@ -0,0 +1 @@
+This row style is only available to RSS styles. It produces XML necessary for an RSS feed for the comment.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-fields.html b/frontend/drupal/sites/all/modules/views/help/style-fields.html
new file mode 100644
index 000000000..4d8d077b0
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-fields.html
@@ -0,0 +1,16 @@
+The fields 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 <div> unless it is selected to be inline. If it is inline, it is put in a <span>. Two items in <div>s will be displayed one after another, with the second one below the first. Two items in <span>s will be displayed on the same line. One item in a <span> next to <div>s is the same as two items in <div>s. This means that for the inline setting to do anything, at least two consecutive items must be set inline.
+
+You may define a separator which will be placed between each item. This separator may be html. You can use 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:
+
+* 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.
+
+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.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-grid.html b/frontend/drupal/sites/all/modules/views/help/style-grid.html
new file mode 100644
index 000000000..463e2bdc0
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-grid.html
@@ -0,0 +1,22 @@
+The grid style will display each row of your view within a grid. You may customize the number of columns, though it defaults to 4. A grid looks like this:
+
+
+
row 1
row 2
row 3
row 4
+
row 5
row 6
row 7
row 8
+
row 9
row 10
row 11
row 12
+
row 13
row 14
row 15
row 16
+
+
+The above uses the horizontal alignment, where rows are added into the grid from left to right.
+
+With a vertical alignment, rows will be placed from top to bottom, like this (your row results will appear as columns):
+
+
row 1
row 5
row 9
row 13
+
row 2
row 6
row 10
row 14
+
row 3
row 7
row 11
row 15
+
row 4
row 8
row 12
row 16
+
+
+You can also choose to group a field 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 row style to determine what each row will look like.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-grouping.html b/frontend/drupal/sites/all/modules/views/help/style-grouping.html
new file mode 100644
index 000000000..8b0c9a7a4
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-grouping.html
@@ -0,0 +1,7 @@
+Many styles can be grouped. 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 grouped 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 $title variable.
+
+Views is very naive about grouping, 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.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-jump.html b/frontend/drupal/sites/all/modules/views/help/style-jump.html
new file mode 100644
index 000000000..dc8532f8f
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-jump.html
@@ -0,0 +1,48 @@
+With the jump menu style can you create selectbox menus for the content of your site.
+
+
+
+The jump menu style will display each row of your view within a jump menu. This style requires that your view's row style is set to fields.
+
+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:
+
+
+
Jump to a node
+
+
Create a new Node view
+
Select the Node: Path and Node: Title fields
+
Configure the Node: Path field to "exclude from display" and check "Use absolute link"
+
Configure the Node: Title field by removing the "Label" and unchecking "Link this field to its node"
+
Set the view style to jump menu
+
In the style settings, set the "Path field" to Node: Path
+
+
+Your view will now display with a select list and a Go button. If you select an item in the list and hit the Go button you will see the selected node's page in the browser.
+
+
Jump to a node's edit page
+
+
Create a new Node view
+
Select the Node: Nid and Node: Title fields
+
Configure the Node: Nid field to "exclude from display" and check "Rewrite the output of this field"
+
In the text field that appears for rewriting the output of this field, enter node/[nid]/edit
+
Configure the Node: Title field by removing the "Label" and unchecking "Link this field to its node"
+
Set the view style to jump menu
+
In the style settings, set the "Path field" to Node: Nid
+
+
+Your view will now display with a select list and a Go button. If you select an item in the list and hit the Go 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.
+
+
Jump to a user profile
+
+
Create a new User view
+
Select the User: Uid and User: Name fields
+
Configure the User: Uid field to "exclude from display" and check "Rewrite the output of this field"
+
In the text field that appears for rewriting the output of this field, enter user/[uid]
+
Configure the User: Name field by removing the "Label" and unchecking "Link this field to its user"
+
Set the view style to jump menu
+
In the style settings, set the "Path field" to User: Uid
+
+
+Your view will now display with a select list and a Go button. If you select an item in the list and hit the Go button you will see the selected user's profile page in the browser.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-list.html b/frontend/drupal/sites/all/modules/views/help/style-list.html
new file mode 100644
index 000000000..86355a51a
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-list.html
@@ -0,0 +1,20 @@
+The List view style will display every row of the view as part of an HTML list construct. For example:
+
+
Row 1
+
Row 2
+
Row 3
+
Row 4
+
+
+You may select whether or not the list is ordered which just means whether or not it uses numbers instead of the bullet:
+
+
+
Row 1
+
Row 2
+
Row 3
+
Row 4
+
+
+The list style also uses a row style 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 list apart guide to styling lists useful.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-node-rss.html b/frontend/drupal/sites/all/modules/views/help/style-node-rss.html
new file mode 100644
index 000000000..7a97bdd56
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-node-rss.html
@@ -0,0 +1 @@
+This row style is only available to RSS styles. It produces XML necessary for an RSS feed for the node record.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-node.html b/frontend/drupal/sites/all/modules/views/help/style-node.html
new file mode 100644
index 000000000..928980f20
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-node.html
@@ -0,0 +1,11 @@
+The node row style will display each item of the view through Drupal's standard node_view() function. Views has very little control over this output, except for the options you see. You can choose from different Build modes. 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 node.tpl.php 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: node--view--VIEWNAME.tpl.php -- 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, the node row style does not utilize fields and the Fields section will not be displayed.
+
+Please note that this row style performs a node_load() for every row, and as such can produce a lot of extra queries. Sometimes this is necessary, but it can have a negative impact on your site's performance!
diff --git a/frontend/drupal/sites/all/modules/views/help/style-row.html b/frontend/drupal/sites/all/modules/views/help/style-row.html
new file mode 100644
index 000000000..a8406d358
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-row.html
@@ -0,0 +1,11 @@
+A row style is an individual style to display only an individual record within a view. You can choose between node or fields. 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 fields, you must have entries in the Fields section to produce an output. To set some options for fields, read here.
+
+Some row styles use fields 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 node the complete node will display through Drupal's standard node_view() function. You can choose some options.
+
+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 here.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-rss.html b/frontend/drupal/sites/all/modules/views/help/style-rss.html
new file mode 100644
index 000000000..e67bd3092
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-rss.html
@@ -0,0 +1,5 @@
+The RSS output style is only available for Feed 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.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-settings.html b/frontend/drupal/sites/all/modules/views/help/style-settings.html
new file mode 100644
index 000000000..63133d811
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-settings.html
@@ -0,0 +1,3 @@
+Views includes many options for theming or styling.
+
+TODO: add more here.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-summary-unformatted.html b/frontend/drupal/sites/all/modules/views/help/style-summary-unformatted.html
new file mode 100644
index 000000000..bd14f249d
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-summary-unformatted.html
@@ -0,0 +1,3 @@
+The unformatted summary style is only available for summary styles, which are when an argument has been set to provide a summary if it was not provided with a value. This summary provides the possible candidates for the argument one after another with no special formatting. If inline is selected, the summary items will be enclosed within <span> tags. Otherwise the items will be in <div> tags.
+
+You can also elect to display the number of matching records for the argument, plus change the number of items per page for the summary. This is often useful because summary views are often quite small, but other views quite space intensive. It is very common to have far more records available in the summary view than in the more normal view.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-summary.html b/frontend/drupal/sites/all/modules/views/help/style-summary.html
new file mode 100644
index 000000000..0c3845fae
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-summary.html
@@ -0,0 +1,3 @@
+The list summary style is only available for summary styles, which are when an argument has been set to provide a summary if it was not provided with a value. This summary provides a list of possible candidates for the argument in a standard HTML list. Like the normal list style, you may set this list to be ordered or not.
+
+You can also elect to display the number of matching records for the argument, plus change the number of items per page for the summary. This is often useful because summary views are often quite small, but other views quite space intensive. It is very common to have far more records available in the summary view than in the more normal view.
diff --git a/frontend/drupal/sites/all/modules/views/help/style-table.html b/frontend/drupal/sites/all/modules/views/help/style-table.html
new file mode 100644
index 000000000..9fc8175e6
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-table.html
@@ -0,0 +1,13 @@
+The table style will display the View results as a table; each row of the table will correspond to a row from the view result.
+
+When setting the table options, each field in the view will be presented with some information next to each field:
+
+
Column
+
By default, each field is its own column. However, you can place multiple fields in the same column. To do this, pick which field you want to represent the column, then pick another field and set the 'column' value to that field. You can place as many fields as you like in a single column, but only the main field in a column can be click-sorted.
+
Separator
+
If you have multiple fields in the same column, the separator will be placed between each one. At the very least, should be used, as without the separator the fields will be placed very close to each other. Common separators are a bullet, the | symbol, and a comma. If there are no other fields in the column, the separator will have no effect.
+
Sortable
+
If checked, the header for the column will be clickable, and the user may re-sort the table by clicking on this to sort by that field. At this time Views does not support click-sorting to sort by multiple columns at the same time.
+
Default sort
+
You may select a column which will be sorted by default when the table is first viewed. This column will be highlighted to the user. You may also select whether the default sort is ascending or descending.
+
diff --git a/frontend/drupal/sites/all/modules/views/help/style-unformatted.html b/frontend/drupal/sites/all/modules/views/help/style-unformatted.html
new file mode 100644
index 000000000..99fa3de7f
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style-unformatted.html
@@ -0,0 +1 @@
+The unformatted output style simply places each row of the view, one after another, with no additional formatting.
diff --git a/frontend/drupal/sites/all/modules/views/help/style.html b/frontend/drupal/sites/all/modules/views/help/style.html
new file mode 100644
index 000000000..d32a2edad
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/style.html
@@ -0,0 +1,15 @@
+The Views' style system is how you customize the output produced by your view. A view style is basically a smart theme template that processes the view data and then outputs it. All styles in Views can be overridden by placing copies of the templates in your theme directory and then modifying them. See the theme: information link available on all views to get hints for which templates a given view is using.
+
+
+
+A breakdown of View output
+
+By default, the style is unformatted, which means that there is very little style actually used; the records are simply displayed one after another, enclosed in a <div> tag so that you can use CSS to manipulate the view.
+
+Some styles use a separate row style to determine how each row of the View looks. This is useful for mixing and matching styles to more readily produce exactly the kind of output you need.
+
+Many styles can be grouped. For styles that can, there will be a 'grouping field' option; pick one of the fields to group by. Please see Grouping in styles for more information.
+
+Each style is its own entity.
+
+If you want your fields to be templatable, you need to use values that are acceptable in function names. That's actually more strict, since that basically limits you to alphanumeric and _. Even though Views may be able to query datastores that use special characters, naming is still important for use in templates.
diff --git a/frontend/drupal/sites/all/modules/views/help/taxonomy-page-override.html b/frontend/drupal/sites/all/modules/views/help/taxonomy-page-override.html
new file mode 100644
index 000000000..f67623477
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/taxonomy-page-override.html
@@ -0,0 +1,41 @@
+NOTE: This page has not been updated for 7.x-3.x
+Views 2 provides a way to override the taxonomy pages of any term. The view is included by default but is disabled. This page covers three minor aspects that some users could use to control the aspect of their taxonomy pages.
+
+
Background
+The Taxonomy module provides a way to organize content through the site. It also presents a page with nodes that belong to some term. The style can't be changed easily and taxonomy only displays node teasers.
+
+
Force All
+When using vocabularies with multiple term levels, a top level won't include the nodes that belongs to the levels inside. Let's clarify this with an example, let's assume the site have this vocabulary:
+
+
+Vocab
+ - Term 1
+ -- Term 2
+ -- Term 3
+ - Term 4
+ -- Term 5
+ -- Term 6
+
+
+If you go to taxonomy/term/1, then you see all nodes in Term 1 listed, but not nodes in Term 2 and Term 3. If you want to see all nodes in Term 1, Term 2 and Term 3 in a single page, you have to go to
+
+
+taxonomy/term/1/all
+
+
+Views 2 allows you to show all terms inside another term.
+
+
Step 1. Enabling taxonomy_term
+The first step we need to do is to enable the "taxonomy term" view that views provides for us. After we've done that we need to edit it.
+
+
Step 2. Changing minor aspects
+On the Display: Page, we can change the Style to any of the styles that views provides for us, it could be a table or a list. If we do this it's necessary to add some fields to the view.
+
+The most important thing we're going to change it's the argument Taxonomy: Term ID: (with depth). At the bottom of the screen, you'll have 2 options, the first one to change it's the depth, if we want to do what the Taxonomy Force All modules does, you'll have to set it up for at least 1.
+
+The next thing you have to do it's check the Set the breadcrumb for the term parents option. This will allow your view to show the breadcrumb with all the term levels in your taxonomy.
+
+Save the changes and try. Next you could do whatever you want, like adding fields, theming, exposing filters, sorting or adding feeds.
+
+
Theme every vocabulary/term independently
+Using TVI: Taxonomy Views Integrator it's possible to theme every vocabulary or term with it's own view. All you have to do is clone the view in Step 1 and set it as the TVI active view in the vocab or term edit pages.
diff --git a/frontend/drupal/sites/all/modules/views/help/theme-css.html b/frontend/drupal/sites/all/modules/views/help/theme-css.html
new file mode 100644
index 000000000..a23d9e556
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/theme-css.html
@@ -0,0 +1,76 @@
+Views uses a wide array of CSS classes on all of its content to ensure that you can easily and accurately select exactly the content you need in order to manipulate it with CSS.
+
+It is possible to enter a custom css class under Style settings. The CSS class names will be added to the view. This enables you to use specific CSS code for each view. You may define multiples classes separated by spaces.
+
+Typically, every view is wrapped in a div with the name of the view as part of its class (for all these examples, we will assume the name of the view is myview), as well as the generic class 'view':
+
+
+<div class="view view-myview">
+...
+</div>
+
+
+In your CSS, you can modify all views:
+
+
+div.view {
+ border: 1px solid black;
+}
+
+
+Or just your view:
+
+
+div.view-myview {
+ background: yellow;
+}
+
+
+By default, the general view template also provides the following classes to easily style other areas of the view:
+
+
.view-header
+
.view-filters
+
.view-content
+
.view-empty (if an "empty" text is used when the view has no results)
+
.view-footer
+
.feed-icon
+
.attachment-before (if using an "attachment" display)
+
.attachment-after (if using an "attachment" display)
+
+
+So for example:
+
+div.view-myview div.view-header {
+ /* make the header stand out */
+ font-size: 120%;
+ font-weight: bold;
+}
+
+div.view-myview div.view-footer {
+ /* Make the footer less important */
+ font-size: 80%;
+ font-style: italic;
+ color: #CCC;
+}
+
+
+In the above example, we whimsically made the header bold and in a bigger font, and the footer smaller, italicized, and greyish.
+
+
Views with fields
+If your view has fields, each field is uniquely tagged with its ID. A field's ID may be gleaned from the Theme: Information page. Note that due to CSS rules, any _ in the id will be converted to - automatically, so if you have a field whose id is 'edit_node' (this is the field used to provide an "edit" link to a node), it will be 'edit-node'. Additionally, to make sure that the view IDs don't conflict with other css classes in the system, they will be pretended with 'views-field-'; thus, the final CSS class for the field with the id 'edit_node' will be views-field-edit-node.
+
+Exactly how this appears is going to depend upon the style you're using. For example, the 'unformatted' style uses div.views-field-edit-node and div.views-label-edit-node to access that particular field, but a table would use td.views-field-edit-node and th.views-field-edit-node to access the table header; or just .views-field-edit-node to affect both.
+
+
+.view-myview th {
+ color: red; /* make all headers red */
+}
+
+.view-myview .views-field-title {
+ font-weight: bold; /* Make the 'title' field bold */
+}
+
+.view-myview td.views-field-body {
+ font-size: 60%; /* Make the text in the body field small */
+}
+
diff --git a/frontend/drupal/sites/all/modules/views/help/top-pager.html b/frontend/drupal/sites/all/modules/views/help/top-pager.html
new file mode 100644
index 000000000..68247af12
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/top-pager.html
@@ -0,0 +1,18 @@
+Copy the views-view.tpl.php from the /views/theme directory to themes/yourtheme/theme directory. Find the following code...
+
+
+
diff --git a/frontend/drupal/sites/all/modules/views/help/ui-crashes.html b/frontend/drupal/sites/all/modules/views/help/ui-crashes.html
new file mode 100644
index 000000000..6c2079493
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/ui-crashes.html
@@ -0,0 +1,25 @@
+
Troubleshooting UI crashes
+
+There are a number of reasons why the Views UI may crash; the most common state or result of a crash is either a white screen (everyone's favorite WSOD), or a screen of what looks like garbage text. This is generally JavaScript crash of some fashion.
+
+To get the most timely and accurate help in the issue queue, please try to gather this information:
+
+Check your JavaScript console. In Firefox, you can hit ctrl-shift-j or use firebug. Copy this information into the issue, or attach it as a text file. Really - this is the single biggest thing you can do to help figure out where the crash is coming from.
+
+
+
JSON prepends data with jQuery, causing editing and preview problems.
+This section originally stems from this issue.
+
+Some modules may add PHP improperly, disrupting normal jQuery operation. Errors may look like
+
+
+{ "default": "default" }
+
+
+This can also be a server configuration issue. In one case, this was solved by commenting out
+
+auto_prepend_file = c:\wamp\www\php.ini.prepend
+
+in the php.ini.
+
+Another page to look at is the drupal.org page on White screens
diff --git a/frontend/drupal/sites/all/modules/views/help/updating-view3.html b/frontend/drupal/sites/all/modules/views/help/updating-view3.html
new file mode 100644
index 000000000..aa2d9770d
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/updating-view3.html
@@ -0,0 +1 @@
+Most views should automatically convert without issue. It's always a good idea and highly recommended that all views be exported for backup purposes before upgrading to Views 3.x.
diff --git a/frontend/drupal/sites/all/modules/views/help/updating.html b/frontend/drupal/sites/all/modules/views/help/updating.html
new file mode 100644
index 000000000..34a1d253f
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/updating.html
@@ -0,0 +1,7 @@
+Views 1 views stored in the database may not convert properly to Views 2. In order to aid with the conversion, a tool is available. In the main Views page, choose Tools -> Convert. Any views you choose will attempt to convert.
+
+Note that converted Views may not match perfectly! Adjustments may be necessary to retain the integrity of your previous views.
+
+Views 1 views may also be exported before upgrade, and then imported through the standard Import tab. Those views will attempt to convert during import. Exporting your views before upgrade has the added benefit of ensuring a backup.
+
+There are no known issues converting views from Views 2 to Views 3 at this time.
diff --git a/frontend/drupal/sites/all/modules/views/help/upgrading.html b/frontend/drupal/sites/all/modules/views/help/upgrading.html
new file mode 100644
index 000000000..b31b8f931
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/upgrading.html
@@ -0,0 +1,8 @@
+
+
Updating templates
+If you have theme files for node-view-$viewname of comment-view-$viewname you have
+to convert them to node--view--$viewname or comment--view--$viewname.
+
+
Updating table templates
+The class variable was renamed to $classes. Additional if you want to add
+classes, you should add it to $classes_array and drupal will automatically convert it to the $classes string.
diff --git a/frontend/drupal/sites/all/modules/views/help/using-theme.html b/frontend/drupal/sites/all/modules/views/help/using-theme.html
new file mode 100644
index 000000000..c4164eb47
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/using-theme.html
@@ -0,0 +1,50 @@
+Views theme templates are straightforward to use with the Drupal theming system. If you are unfamiliar with the theming system at all, you should probably at least read drupal.org theming documentation. That said, these are the important things you need to know:
+
+
+
Copy a base Views template to one of the names provided from the Theme: Information section of the View. Copy this template right into your theme directory.
+
Clear the theme registry. See the instructions for how to do this.
+
Your new template should now operate; assuming you picked a nicely named template that includes the view name, that template should now be active for your view. A good example is views-view-list--foobar.tpl.php which would work for a view named 'foobar'.
+
You can now modify this template all you like.
+
+
+For any template that uses fields, the fields will be in array. In order to use this effectively, you will need to understand enough PHP to fetch data from an array. This is a place where the devel module can really help you, because you can use its dsm() function right in your template to see what variables it uses. There is an alternative to dsm() that works without devel module, but it's a bit longer to use.
+
+For example, I placed the following code inside a loop in views-view-table.php.php:
+ <?php drupal_set_message('<pre>' . var_export($row, true) . '</pre>'); ?>
+
+
+And it produced this output:
+ array (
+ 'nid' => '97',
+ 'title' => 'Scisco Ideo Vicis Feugiat Qui',
+ 'name' => 'luwrepuslan',
+ )
+
+
+My view had three fields:
+Node: Nid
+Node: Title
+User: Name
+
+
+The contents of the $row variable included these fields, in precisely the order that I had arranged them to using the Views rearrange link. Also worth noting, though, is that each field also has an identifier so it can easily be pulled out of the row should I want to display it differently. Using
+<?php print $row['title']; ?>
+
+
+Would print just the title for that row. Please remember that I'm doing this inside the loop, so this will get repeated for every row of the view.
+
+The IDs used to fetch items from the array, id $row['title'] can be quickly and easily looked up on the Theme: Information page. Once a field has been added to the view, its ID will not change, but note that if there are two "title" fields in a view, one will be 'title' and the other will be 'title_1', in order to prevent namespace collisions.
+
+The important thing here is that Views does provide IDs. Views doesn't tell you what these IDs are, but it's easy to get them by dumping the row data and doing a simple visual inspection. Views does guarantee that these IDs will not change, unless you actually add a new field and remove the existing one (in which case 'title', above, would become 'title_1').
+
+
The basic fields template
+
+The most common template people will need to rewrite is the "simple" views-view-fields.tpl.php, which is the template used by the Fields row style and all it does is display a simple list of fields. However, it is not that simple to the user. Because the template can't inherently know what the fields are, it has to go through an array in a loop.
+
+This loop isn't very handy when you really want to have fine control over the template by placing your fields precisely where and how you want. Relax, though; if you know what your fields are, you can rewrite this. If you end up writing your own HTML, the only part that is really important is the content for each field. We know from above that you can get the ID for each field on the Theme: Information page from the view. In the header for the template, we can see that the fields are all in the $fields array, and each field is an object. That leads us to this:
+
+<?php print $fields['some_id']->content; ?>
+
+Assuming you replace some_id with an id found on the theme: information page, this code will print the content for that field. You can also get the label and some other data about the field, as well as the raw information. Complete details for what is available are documented directly in views-view-fields.tpl.php.
+
+Keep in mind that if you rewrite your templates using this, you'll need to maintain this template whenever changes are made to the fields of the view; while this isn't generally recommend, sometimes it's necessary to get the kind of control you might ultimately need.
diff --git a/frontend/drupal/sites/all/modules/views/help/view-add.html b/frontend/drupal/sites/all/modules/views/help/view-add.html
new file mode 100644
index 000000000..619d1b667
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/view-add.html
@@ -0,0 +1,25 @@
+
When you want to create a new view navigate to Structure > Views . There you can see all the views specified. Fresh install has a few examples ready and you can choose "edit" to investigate how the is made. To create a new view press "Add new view".
+
+
+
+All the created Views
+
+
+
You can enter the following information about it.
+
First, you must enter a view name. This is the unique name of the view. It must contain only alphanumeric characters and underscores; it is used to identify the view internally and to generate unique theming template names for this view. If you are overriding a module provided view, the name must not be changed or a new view will be created instead of overriding.
+
You can enter a description of the view. This description will appear on the Views administrative UI to tell you what the view is about. You can enter a view tag. It will be used help sort views on the administrative page.
+You must choose a view type.
+
+
Node
+
Nodes are a Drupal site's primary content.
+
Comment
+
When you want to handle comments and information related to the and information related to them.
+
File
+
When you want to handle files and file information.
+
Node revision
+
When you want to handle node revision information, choose this.
+
Term
+
When you want to handle taxonomy, choose this one.
+
User
+
When you want to handle users and user information, choose this one.
+
diff --git a/frontend/drupal/sites/all/modules/views/help/view-settings.html b/frontend/drupal/sites/all/modules/views/help/view-settings.html
new file mode 100644
index 000000000..906656e19
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/view-settings.html
@@ -0,0 +1,5 @@
+With the Description and Tag you can set the "View description" and the "View tag". The tag help you to organize your views. Only one tag may be entered for a given view. Note that this tag can also be used in themeing, so do not use words already reserved by Drupal for use, such as "Page".
+
+You can clone a view. When you click on the clone link on the upper right, all the options in the current view will copy to a new view, which can be given a new name and edited further.
+
+You can export a view. You can the copy and paste the code from a view into a module or something else. It is a array with all options for that view.
diff --git a/frontend/drupal/sites/all/modules/views/help/view-type.html b/frontend/drupal/sites/all/modules/views/help/view-type.html
new file mode 100644
index 000000000..bdb80fc0c
--- /dev/null
+++ b/frontend/drupal/sites/all/modules/views/help/view-type.html
@@ -0,0 +1,21 @@
+
The view type describes how this view is stored; Views is capable of having Views entirely in code that are not in the database. This allows modules to easily ship with Views built in, and it allows you to create a module to store your views for easy deployment between development and production servers.
+
+
+
Normal
+
Normal views are stored in your database and are completely local to your system.
+
+
Default
+
Default views are stored only in code and are not anywhere in your database. They may be enabled or disabled but you may not completely remove them from your system. You can override the view which will create a local copy of your view. If you do this, future updates to the version in code will not affect your view.
+
+
Overridden
+
Overridden views are stored both in code and in the database; while overridden, the version that is in code is completely dormant. If you revert the view, the version in the database will be deleted, and the version that is in code will once again be used.
+
+
+You may store your views in code with the following procedure:
+
+
Create a module to store the views.
+
Add the function MODULENAME_views_default_views() to this module.
+
Export the view you wish to store in your module in code. Cut and paste that into the abovenamed function. Make sure the last line of the view is: $views[$view->name] = $view;
+
Make sure the last line of the function is return $views;
+
After you make any changes, be sure to clear the Views' cache. You may do this from the Tools menu.
+
diff --git a/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/Pomembne_povezave.html b/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/Pomembne_povezave.html
new file mode 100644
index 000000000..bc24c5108
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/Pomembne_povezave.html
@@ -0,0 +1,143 @@
+
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/footer_povezave.html b/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/footer_povezave.html
new file mode 100644
index 000000000..64264b1fb
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/footer_povezave.html
@@ -0,0 +1,80 @@
+// 4 kolone
+
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/lastna namestitev.html b/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/lastna namestitev.html
new file mode 100644
index 000000000..7ef4bb94a
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/lastna namestitev.html
@@ -0,0 +1,56 @@
+
+
+
+
+
LASTNA NAMESTITEV
+
+
+
+
+
+
+ Aplikacijo 1KA je mogoča namestiti na strežniku 1KA ali na strežniku uporabnika.
+
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/oredje_1ka_uporabljajo.html b/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/oredje_1ka_uporabljajo.html
new file mode 100644
index 000000000..bcd61ddf6
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/oredje_1ka_uporabljajo.html
@@ -0,0 +1,7 @@
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/spletna_uporaba.html b/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/spletna_uporaba.html
new file mode 100644
index 000000000..dddb129cc
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/nova1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/spletna_uporaba.html
@@ -0,0 +1,62 @@
+
+
+
+
+
SPLETNA UPORABA
+
+
+
+
+
+
+ Storitev 1KA je mogoče na domeni 1KA.si uporabljati brezplačno. Potrebna je le registracija (novi
+ uporabniki) oziroma prijava (registrirani uporabniki).
+
For initial start with 1KA, there is an information available for beginners and for advanced users.
+
+
+
+
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/themes/nova1ka/img/.htaccess b/frontend/drupal/sites/all/themes/nova1ka/img/.htaccess
new file mode 100644
index 000000000..7051eb824
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/nova1ka/img/.htaccess
@@ -0,0 +1,15 @@
+# Turn off all options we don't need.
+Options None
+Options +FollowSymLinks
+
+# Set the catch-all handler to prevent scripts from being executed.
+SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
+
+ # Override the handler again if we're run later in the evaluation list.
+ SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
+
+
+# If we know how to do it safely, disable the PHP engine entirely.
+
+ php_flag engine off
+
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/Pomembne_povezave.html b/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/Pomembne_povezave.html
new file mode 100644
index 000000000..9c1fd9daa
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/Pomembne_povezave.html
@@ -0,0 +1,124 @@
+
diff --git a/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/funkcionalnosti.html b/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/funkcionalnosti.html
new file mode 100644
index 000000000..2d57c5dc8
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/funkcionalnosti.html
@@ -0,0 +1,97 @@
+
+
+
+
+
+
+
Bagat nabur vprašanj
+
Uporabniki 1KA imajo poleg osnovnega nabora
+ vprašaj (en odgovor, več odgovorov in tabela)
+ na volje veliko naprednih oblik vprašanj, npr.
+ drsnik, image hotspot, zemljevid.
+
+
+
+
+
+
+
+
Analize in poročila
+
Spremljajte vaše rezultate že med zbiranjem podatkov. V 1KA
+ lahko izdelate sumarne in kontingenčne tabele, prilagodite grafe,
+ definirate segmente, skupine in razbitja, izdelujete poročila po meri ipd.
+
+
+
+
+
+
+
+
Avtomatska prilagoditev na mobilne naprave
+
Vmesnik 1KA za odgovarjanje na anketo je
+ avtomatske prilagojen tudi mobilnim
+ napravam. Prilagojena so vsa osnovna in tudi
+ naprednejša vprašanja.
+
+
+
+
+
+
+
+
Integriran sistem za email vabila
+
Uporabite 1KA sistem za pošiljanje vabil in s tem možnost
+ pošiljanja opomnikov neodzivnim respondentom.
+
+
+
+
+
+
+
+
Prilagojena padaba ankete
+
V 1KA lahko videz ankete popolnoma
+ prilagodite vaši celostni grafični podobi.
+ Spremenite barve in pisave ter naložite vaš
+ logotip.
+
+
+
+
+
+
+
+
Rešitve pa meri
+
Imate specifične oblike vprašanja ali izpisa? Po meri lahko za vas
+ razvijemo različne oblike vprašanj, izpise poročil, napredne
+ module ipd.
+
+
+
+
+
+
+
+
Razvoj vprašalnika
+
Sistem komentarjev nudi podporo za učinkovit
+ razvoj vprašalnika v skupini, avtorji ankete
+ imaje pregled nad komentarji drugih urednikov in respondentov.
+ 1KA vsak vprašalnik tudi avtomatsko preveri, diagnosticira
+ merebitne napake ter pripravi priporočila.
+
+
+
+
+
+
+
+
Večjezične ankete
+
1KA omogoča enostavno izdelavo večjezičnih anket. Standardne
+ besede v anketi (gumbi, naprej, nazaj, opozorila itd.) so prevedene v
+ 43 svetovnih jezikov, pri čemer je avtomatično vklopljena tudi
+ odgovarjajoča pisava. Za pisave v hebrejščini in arabskem jeziku
+ je nastavljen zapis besedia z desne proti levi.
+
+
+
+
diff --git a/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/kv_slider.html b/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/kv_slider.html
new file mode 100644
index 000000000..d7ea72fd2
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/kv_slider.html
@@ -0,0 +1,21 @@
+
Orodje za anketiranje. Zmogljivo, enostavno in varno.
+
+
Izpeljite raziskavo in analizo od začetka do konca. 1KA vam pomaga pri vseh korakih spletnega anketiranja.
diff --git a/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/oredje_1ka_uporabljajo.html b/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/oredje_1ka_uporabljajo.html
new file mode 100644
index 000000000..bcd61ddf6
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/oredje_1ka_uporabljajo.html
@@ -0,0 +1,7 @@
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/spletna_uporaba.html b/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/spletna_uporaba.html
new file mode 100644
index 000000000..0d6e65696
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/pro1ka/bloki-koda-v-kolikor-se-iz-noda-izbrise/spletna_uporaba.html
@@ -0,0 +1,62 @@
+
+
+
+
+
SPLETNA UPORABA
+
+
+
+
+
+
+ Storitev 1KA je mogoče na domeni 1KA.si uporabljati brezplačno. Potrebna je le registracija (novi
+ uporabniki) oziroma prijava (registrirani uporabniki).
+
For initial start with 1KA, there is an information available for beginners and for advanced users.
+
+
+
+
diff --git a/frontend/drupal/sites/all/themes/pro1ka/img/.htaccess b/frontend/drupal/sites/all/themes/pro1ka/img/.htaccess
new file mode 100644
index 000000000..7051eb824
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/pro1ka/img/.htaccess
@@ -0,0 +1,15 @@
+# Turn off all options we don't need.
+Options None
+Options +FollowSymLinks
+
+# Set the catch-all handler to prevent scripts from being executed.
+SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
+
+ # Override the handler again if we're run later in the evaluation list.
+ SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
+
+
+# If we know how to do it safely, disable the PHP engine entirely.
+
+ php_flag engine off
+
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/themes/pro1ka/svg/.htaccess b/frontend/drupal/sites/all/themes/pro1ka/svg/.htaccess
new file mode 100644
index 000000000..7051eb824
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/pro1ka/svg/.htaccess
@@ -0,0 +1,15 @@
+# Turn off all options we don't need.
+Options None
+Options +FollowSymLinks
+
+# Set the catch-all handler to prevent scripts from being executed.
+SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
+
+ # Override the handler again if we're run later in the evaluation list.
+ SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
+
+
+# If we know how to do it safely, disable the PHP engine entirely.
+
+ php_flag engine off
+
\ No newline at end of file
diff --git a/frontend/drupal/sites/all/themes/zen/STARTERKIT/styleguide/index.html b/frontend/drupal/sites/all/themes/zen/STARTERKIT/styleguide/index.html
new file mode 100644
index 000000000..0f7f1ba65
--- /dev/null
+++ b/frontend/drupal/sites/all/themes/zen/STARTERKIT/styleguide/index.html
@@ -0,0 +1,111 @@
+
+
+
+
+ Zen 7.x-6.x Style Guide
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Zen 7.x-6.x Style Guide
+
+
+
+
+
+
KSS Style Guide
+
This style guide documents the designs of this website which are built with component-based styles and Sass variables, functions and mixins. To ensure it is always up-to-date, this style guide is automatically generated from comments in the Sass files.
+
Organization
+
Design components are reusable designs that can be applied using just the CSS class names specified in the component. We categorize our components to make them easy to find.
+
+
Defaults
+
sass/base — The default “base” components apply to HTML elements. Since all of the rulesets in this class of styles are HTML elements, the styles apply automatically.
+
Layouts
+
sass/layouts — Layout components position major chunks of the page. They just apply positioning, no other styles.
+
Components
+
sass/components — Miscellaneous components are grouped together, but feel free to further categorize these.
+
Navigation
+
sass/navigation — Navigation components are specialized design components that are applied to website navigation.
+
Forms
+
sass/forms — Form components are specialized design components that are applied to forms or form elements.
+
+
+
In addition to the components, our component library also contains these folders:
+
+
Colors and Sass
+
sass/init — This Sass documents the colors used throughout the site and various Sass variables, functions and mixins. It also initializes everything we need for all other Sass files: variables, 3rd-party libraries, custom mixins and custom functions.
+
Style guide helper files
+
sass/style-guide — files needed to build this automated style guide; includes some CSS overrides for the default KSS style guide
All HTML headings, <h1> through <h6>, are available. %h1 through %h6
+classes are also available, for when you want to match the font styling of a
+heading but still want your text to be displayed inline.
+
+
+
+
+
+
+
+ Example
+
+
+
+
Heading Level 1 (h1)
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
Heading Level 2 (h2)
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
Heading Level 3 (h3)
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
Heading Level 4 (h4)
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
Heading Level 5 (h5)
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
Heading Level 6 (h6)
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
+
A Heading Level 1 (h1) with enough text to wrap to another line
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
Heading Level 2 (h2) with enough text to wrap to another line; Heading Level 2 (h2) with enough text to wrap to another line
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
Heading Level 3 (h3) with enough text to wrap to another line; Heading Level 3 (h3) with enough text to wrap to another line
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
Heading Level 4 (h4) with enough text to wrap to another line; Heading Level 4 (h4) with enough text to wrap to another line; Heading Level 4 (h4) with enough text to wrap to another line
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
Heading Level 5 (h5) with enough text to wrap to another line; Heading Level 5 (h5) with enough text to wrap to another line; Heading Level 5 (h5) with enough text to wrap to another line
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
Heading Level 6 (h6) with enough text to wrap to another line; Heading Level 6 (h6) with enough text to wrap to another line; Heading Level 6 (h6) with enough text to wrap to another line
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.
+
+
+
+
+
+
<h1 class="">Heading Level 1 (h1)</h1>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+<h2 class="">Heading Level 2 (h2)</h2>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+<h3 class="">Heading Level 3 (h3)</h3>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+<h4 class="">Heading Level 4 (h4)</h4>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+<h5 class="">Heading Level 5 (h5)</h5>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+<h6 class="">Heading Level 6 (h6)</h6>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+
+<h1 class="">A Heading Level 1 (h1) with enough text to wrap to another line</h1>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+<h2 class="">Heading Level 2 (h2) with enough text to wrap to another line; Heading Level 2 (h2) with enough text to wrap to another line</h2>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+<h3 class="">Heading Level 3 (h3) with enough text to wrap to another line; Heading Level 3 (h3) with enough text to wrap to another line</h3>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+<h4 class="">Heading Level 4 (h4) with enough text to wrap to another line; Heading Level 4 (h4) with enough text to wrap to another line; Heading Level 4 (h4) with enough text to wrap to another line</h4>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+<h5 class="">Heading Level 5 (h5) with enough text to wrap to another line; Heading Level 5 (h5) with enough text to wrap to another line; Heading Level 5 (h5) with enough text to wrap to another line</h5>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+<h6 class="">Heading Level 6 (h6) with enough text to wrap to another line; Heading Level 6 (h6) with enough text to wrap to another line; Heading Level 6 (h6) with enough text to wrap to another line</h6>
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.</p>
+
The default font-size and line-height properties are applied to the
+<body> element and all paragraphs. In addition, <p> (paragraphs) receive
+a top and bottom margin.
+
+
+
+
+
+
+
+ Example
+
+
+
+
Nullam quis risus eget urna mollis ornare vel eu leo. Cum sociis natoque
+penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nullam id
+dolor id nibh ultricies vehicula.
+
+
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur
+ridiculus mus. Donec ullamcorper nulla non metus auctor fringilla. Duis mollis,
+est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec
+elit. Donec ullamcorper nulla non metus auctor fringilla.
+
+
Maecenas sed diam eget risus varius blandit sit amet non magna. Donec id elit
+non mi porta gravida at eget metus. Duis mollis, est non commodo luctus, nisi
+erat porttitor ligula, eget lacinia odio sem nec elit.
+
+
+
+
+
+
<p class="">Nullam quis risus eget urna mollis ornare vel eu leo. Cum sociis natoque
+penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nullam id
+dolor id nibh ultricies vehicula.</p>
+
+<p class="">Cum sociis natoque penatibus et magnis dis parturient montes, nascetur
+ridiculus mus. Donec ullamcorper nulla non metus auctor fringilla. Duis mollis,
+est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec
+elit. Donec ullamcorper nulla non metus auctor fringilla.</p>
+
+<p class="">Maecenas sed diam eget risus varius blandit sit amet non magna. Donec id elit
+non mi porta gravida at eget metus. Duis mollis, est non commodo luctus, nisi
+erat porttitor ligula, eget lacinia odio sem nec elit.</p>
+
+
+
+
+ Source: base/grouping/_grouping.scss, line 155
+
The <dl> element is a list of terms with their associated descriptions.
+
+
+
+
+
+
+
+ Example
+
+
+
+
+
Description lists
+
A description list is perfect for defining terms.
+
Euismod
+
Vestibulum id ligula porta felis euismod semper eget lacinia odio sem nec elit.
+
Donec id elit non mi porta gravida at eget metus.
+
Malesuada porta
+
Etiam porta sem malesuada magna mollis euismod.
+
+
+
+
+
+
+
<dl class="">
+ <dt>Description lists</dt>
+ <dd>A description list is perfect for defining terms.</dd>
+ <dt>Euismod</dt>
+ <dd>Vestibulum id ligula porta felis euismod semper eget lacinia odio sem nec elit.</dd>
+ <dd>Donec id elit non mi porta gravida at eget metus.</dd>
+ <dt>Malesuada porta</dt>
+ <dd>Etiam porta sem malesuada magna mollis euismod.</dd>
+</dl>
+
The <blockquote> element is for quoting blocks of content from another
+source within your document. Wrap the <blockquote> around any HTML as the quote. For straight
+quotes, we recommend a <p>.
+
Optionally, add a <footer> to identify the source of the quote, wrapping
+the name of the source work in <cite>.
+
+
+
+
+
+
+
+ Example
+
+
+
+
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer posuere
+ erat a ante.
+
+
+
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer posuere
+ erat a ante.
+
+
+
+
+
+
+
+
<blockquote class="">
+ <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer posuere
+ erat a ante.</p>
+</blockquote>
+
+<blockquote class="">
+ <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer posuere
+ erat a ante.</p>
+ <footer>J. Smith in <cite title="Source Title, 2nd Edition">Source
+ Title</cite></footer>
+</blockquote>
+
The <hr> element represents a paragraph-level thematic break, e.g. a scene
+change in a story, or a transition to another topic within a section of a
+reference book.
+
+
+
+
+
+
+
+ Example
+
+
+
+
Nullam quis risus eget urna mollis ornare vel eu leo. Cum sociis natoque
+penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nullam id
+dolor id nibh ultricies vehicula.
+
+
+
+
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur
+ridiculus mus. Donec ullamcorper nulla non metus auctor fringilla.
+
+
+
+
+
+
<p>Nullam quis risus eget urna mollis ornare vel eu leo. Cum sociis natoque
+penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nullam id
+dolor id nibh ultricies vehicula.</p>
+
+<hr class="">
+
+<p>Cum sociis natoque penatibus et magnis dis parturient montes, nascetur
+ridiculus mus. Donec ullamcorper nulla non metus auctor fringilla.</p>
+
+
+
+
+ Source: base/grouping/_grouping.scss, line 136
+
The <strong> element or the <b> element is for emphasizing a snippet of
+text with a heavier font-weight.
+
Feel free to use <b> in HTML5. <b> is meant to highlight words or phrases
+without conveying additional importance.
+
+
+
+
+
+
+
+ Example
+
+
+
+ The following snippets of text are rendered as bold
+text. Bold text nested inside italic text shouldstill be
+bold.
+
+
+
+
+
+
The following snippets of text are <strong class="">rendered</strong> as <b class="">bold
+text</b>. Bold text nested inside <i>italic text <b>should</b></i> <em>still be
+<strong>bold</strong></em>.
+
The <em> element or the <i> element is used for emphasizing a snippet of
+text with italics.
+
Feel free to use <i> element in HTML5. <i> is meant to convey voice,
+technical terms, etc.
+
+
+
+
+
+
+
+ Example
+
+
+
+ The following snippets of text are rendered as italic text.
+Italic text nested inside bold text shouldstill be
+italic.
+
+
+
+
+
+
The following snippets of text are <em class="">rendered</em> as <i class="">italic text</i>.
+Italic text nested inside <b>bold text <i>should</i></b> <strong>still be
+<em>italic</em></strong>.
+
The <abbr> element makes the meanings of abbreviations and acronyms visible
+on hover.
+
+
+
+
+
+
+
+ Example
+
+
+
+ An abbreviation of the word attribute is attr.
+And HTML is an acroynm.
+
+
+
+
+
+
An abbreviation of the word attribute is <abbr class="" title="attribute">attr</abbr>.
+And <abbr class="" title="HyperText Markup Language">HTML</abbr> is an acroynm.
+
The <code> element represents a fragment of computer code. The <var>
+element represents a variable. The <samp> element represents (sample)
+output from a program or computing system. The <kbd> element represents
+user input (typically keyboard input.)
+
+
+
+
+
+
+
+ Example
+
+
+
+
The code element represents a fragment of computer code.
+
+
There are n flavors of ice cream to be available for purchase!
+
+
The computer said Too much cheese in tray two but I didn't know
+what that meant.
+
+
To make George eat an apple, select File | Eat Apple…
+
+
+
+
+
+
<p>The <code class="">code</code> element represents a fragment of computer code.</p>
+
+<p>There are <var class="">n</var> flavors of ice cream to be available for purchase!</p>
+
+<p>The computer said <samp class="">Too much cheese in tray two</samp> but I didn't know
+what that meant.</p>
+
+<p>To make George eat an apple, select <kbd class="">File | Eat Apple…</kbd></p>
+
The <dfn> element represents the defining instance of a term.
+
+
+
+
+
+
+
+ Example
+
+
+
+
The GDO is a
+device that allows off-world teams to open the iris.
+
+
Teal'c activated his GDO
+and so Hammond ordered the iris to be opened.
+
+
+
+
+
+
<p>The <dfn class="" id="gdo"><abbr title="Garage Door Opener">GDO</abbr></dfn> is a
+device that allows off-world teams to open the iris.</p>
+
+<p>Teal'c activated his <a href="#gdo"><abbr title="Garage Door Opener">GDO</abbr></a>
+and so Hammond ordered the iris to be opened.</p>
+
The <q> element represents an inline quote from another source. Longer
+quotes should use the <blockquote> element.
+
+
+
+
+
+
+
+ Example
+
+
+
+ The
+q element represents some phrasing content quoted from another
+source.
+
+
+
+
+
+
<q class="" cite="http://www.w3.org/TR/html5/text-level-semantics.html#the-q-element">The
+<code>q</code> element represents some phrasing content quoted from another
+source.</q>
+
A Drupal block is often styled as a box. However, this design component is
+not applied to any blocks by default; it is used as an example of how to
+build and document a CSS component.
+
"box" is the name of our component, so we define a .box class that we can
+apply to any HTML element that needs the box styling. We also provide a
+%box placeholder selector so that we can easily extend the basic box
+component with @extend %box;.
+
Take a look at the source code for this component for more information about
+building a good component.
+
+
+
+
+
+
+
+ Examples
+
+
+ Default styling
+
+
+
+
+
Box title
+
+ Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
+
+
+
+
+
+
+ :hover
+
+
+ The hover/focus styling.
+
+
+
+
Box title
+
+ Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
+
+
+
+
+
+ .box--highlight
+
+
+ The "highlight" box variant.
+
+
+
+
Box title
+
+ Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
+
+
+
+
+
+
+
<div class="box [modifier class]">
+ <h2 class="box__title">Box title</h2>
+ <div class="box__content">
+ Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
+ </div>
+</div>
+
Conventio facilisis nutus. Distineo lucidus olim ut. Huic illum olim quadrum usitas. Bene ex pecus pneum uxor. Brevitas diam hos persto tincidunt virtus. Consequat dignissim distineo eros exerci huic ludus sino turpis.
Conventio facilisis nutus. Distineo lucidus olim ut. Huic illum olim quadrum usitas. Bene ex pecus pneum uxor. Brevitas diam hos persto tincidunt virtus. Consequat dignissim distineo eros exerci huic ludus sino turpis.
Conventio facilisis nutus. Distineo lucidus olim ut. Huic illum olim quadrum usitas. Bene ex pecus pneum uxor. Brevitas diam hos persto tincidunt virtus. Consequat dignissim distineo eros exerci huic ludus sino turpis.
+
+
+
+
+
+
+
<div class="comment__section">
+ <article class="comment [modifier class]">
+ <header>
+ <p><a href="#">Jane A. User</a> replied on <time>Wed, 08/19/2015 - 17:51</time>
+ <a href="#" class="comment__permalink">Permalink</a>
+ </p>
+
+ <h3 class="comment__title">
+ <a href="#">The comment's title</a>
+ </h3>
+ </header>
+
+ <p>Conventio facilisis nutus. Distineo lucidus olim ut. Huic illum olim quadrum usitas. Bene ex pecus pneum uxor. Brevitas diam hos persto tincidunt virtus. Consequat dignissim distineo eros exerci huic ludus sino turpis.</p>
+ </article>
+</div>
+
+
+
+
+ Source: components/comment/_comment.scss, line 1
+
Can be used as an <hr>, an empty <div> or as a container.
+
+
+
+
+
+
+
+ Example
+
+
+
+
+
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
+
+
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
+
+
+
+
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
+
+
+
+
+
+
<div class="divider "></div>
+
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
+
+<div class="divider ">
+ <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
+</div>
+
+<hr class="divider ">
+
+<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
+
+
+
+
+ Source: components/divider/_divider.scss, line 1
+
Hide elements from all users. Compare to the visually-hidden component.
+
Used for elements which should not be immediately displayed to any user. An
+example would be a collapsible fieldset that will be expanded with a click
+from a user.
+
For anything you want to hide on page load when JavaScript is enabled, use
+the .js-hidden class.
+
+
+
+
+
+
+
+ Example
+
+
+
+
+ This content is hidden.
+
+
+
+
+
+
+
<div class="hidden ">
+ This content is hidden.
+</div>
+
+
+
+
+ Source: components/hidden/_hidden.scss, line 1
+
The "new" or "updated" marker. This is a very thin component. A front-end
+developer may choose to delete this component and just style the <mark>
+element directly.
+
+
+
+
+
+
+
+ Example
+
+
+
+ New
+
+
+
+
+
+
<mark class="highlight-mark">New</mark>
+
+
+
+
+ Source: components/highlight-mark/_highlight-mark.scss, line 1
+
An element that needs to appear inline with the content that follows.
+
+
+
+
+
+
+
+ Example
+
+
+
+
A Heading
+
A normal paragraph. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
+
+
+
+
+
+
<h4 class="inline-sibling ">A Heading</h4>
+<p>A normal paragraph. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
+
+
+
+
+ Source: components/inline-sibling/_inline-sibling.scss, line 1
+
Removes an element from the print version of the web site.
+
By importing these CSS rules in a file marked as media "all", we allow these
+print rules to be aggregated with other stylesheets, for improved front-end
+performance.
+
+
+
+
+
+
+
+ Example
+
+
+
+
+ This item will not be printed.
+
+
+
+
+
+
+
<p class="print-none">
+ This item will not be printed.
+</p>
+
+
+
+
+ Source: components/print-none/_print-none.scss, line 1
+
Using a wrapper div, embedded videos can be made responsive so that their
+intrinsic aspect ratio is preserved at any screen width. The
+responsive-video__embed class is optional if the embed is an iframe.
+
+
+
+
+
+
+
+ Examples
+
+
+ Default styling
+
+
+
+
+
+
+
+
+
+
+ .responsive-video--4-3
+
+
+ A video with a 4:3 aspect ratio instead of the default 16:9 one.
+
Make the element appear beneath sibling elements, like a watermark.
+
+
+
+
+
+
+
+ Example
+
+
+
+
+ Unpublished
+
+
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
+
+
+
+
+
+
+
<div>
+ <mark class="watermark ">Unpublished</mark>
+
+ <div>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</div>
+ </div>
+
+
+
+
+ Source: components/watermark/_watermark.scss, line 1
+
Buttons built with the <button> element are the most flexible for styling
+purposes. But <input> elements with type set to submit, image,
+reset, or button are also supported.
+
Below is the default button styling. To see variations on the button styling
+see the button component.
The <input> element is mostly used for text-based inputs that include the
+HTML5 types: text, search, tel, url, email, password, date,
+time, number, range, color, and file.
The <label> element represents a caption of a form field. The label can be
+associated with a specific form control by using the for attribute or by
+putting the form control inside the label element itself.
+
+
+
+
+
+
+
+ Example
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
<div>
+ <label class="" for="lableInputText">A label for a text input</label>
+ <input type="text" id="lableInputText" placeholder="Enter some text">
+</div>
+
+<div>
+ <label class=""><input type="checkbox"> A label wrapped around a checkbox</label>
+</div>
+
In addition to the default styling of <button> and
+<input type="submit|image|reset|button"> elements, the .button class and
+its variants can apply buttons styles to various elements (like an <a>
+link).
Fieldsets with optional entry fields can be hidden with collapsed fieldsets.
+
+
+
+
+
+
+
+ Examples
+
+
+ Default styling
+
+
+
+
+
+
+
+
+ .is-collapsed
+
+
+ The collapsed fieldset.
+
+
+
+
+
+
+
+
<fieldset class="collapsible-fieldset [modifier class]">
+ <legend>
+ <span class="collapsible-fieldset__legend">
+ A collapsible fieldset
+ <span class="collapsible-fieldset__summary">A summary of the form state</span>
+ </span>
+ </legend>
+ <div class="collapsible-fieldset__wrapper">
+ Place the form elements to hide inside this wrapping div.
+ </div>
+</fieldset>
+
+
+
+
+ Source: forms/collapsible-fieldset/_collapsible-fieldset.scss, line 1
+
Checkboxes and radios require slightly different markup; their label is after
+their widget instead of before. Uses the .form-item--radio class variant of
+the normal form item and is placed on each of the nested form items.
+
+
+
+
+
+
+
+ Examples
+
+
+ Default styling
+
+
+
+
+
+
+ Form group description.
+
+
+
+
+
+
+ Form item description.
+
+
+
+
+
+
+ Form item description.
+
+
+
+
+
+
+
+
+ .is-error
+
+
+ Highlight the form elements that caused a form submission error.
+
A textarea that can be resized with a "grippie" widget.
+
+
+
+
+
+
+
+ Example
+
+
+
+
+
+
+
+
+
+
+
<textarea class="resizable-textarea " rows="5">
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
+
+Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
+</textarea>
+<div class="resizable-textarea__grippie"></div>
+
+
+
+
+ Source: forms/resizable-textarea/_resizable-textarea.scss, line 1
+
The layout styling for major parts of the page that are included with the
+theme. Note: some Panels layouts are included in other parts of the system
+and are not documented.
All other layouts should be nested inside this centered layout to ensure that
+content does not get too wide on very large screens.
+
Applying a .layout-* class to the same HTML element as .layout-center
+would cause that element's grid to mis-align with the rest of the grid on the
+page, but this component will automatically detect the other .layout-*
+class and automatically use the .layout-center--shared-grid variant
+instead.
+
+
+
+
+
+
+
+ Examples
+
+
+ Default styling
+
+
+
+
+ This is layout center that has content is centered on larger screens.
+
+
+
+
+
+ .layout-center--shared-grid
+
+
+ If .layout-center is applied to the same div as another .layout- class, then this variant should be used to prevent the shared layout's grid from mis-aligning. Note: Each time a new .layout- component is created, this component will need to be modified.
+
+
+
+ This is layout center that has content is centered on larger screens.
+
+
+
+
+
+
<div class="layout-center [modifier class]">
+ This is layout center that has content is centered on larger screens.
+</div>
+
+
+
+
+ Source: layouts/layout-center/_layout-center.scss, line 5
+
.layout-3col__col-3 : 1-column wide grid item spanning column 3; starts a
+new row on tablet screens
+
.layout-3col__col-4 : At tablet sizes, the __col-x grid items will form
+an irregular layout of 2 items in the first row and 1 item in the second
+row. The __col-4 is a "hidden" item that does not appear on the
+large-screen 3-column grid, but is a 1-column wide grid item spanning
+column 2 on tablet screens.
+
.layout-3col__col-x : 1-column wide grid item spanning column 1; when
+several of these are used inside a .layout-3col__grid-item-container or
+.layout-3col, the first one is positioned like __col-1, the
+second like __col-2, etc.
+
+
There are 2 ways to do a nested grid:
+
+
Place a grid container div inside a grid item. Just apply the normal
+classes to the nested grid container and its grid items.
+
The grid item's div is also the grid container for the nested grid. In
+this case, the .layout3-col__grid-item-container class should be added
+to the div to ensure its nested grid items align with the parent grid.
+
+
+
+
+
+
+
+
+ Example
+
+
+
+
+
+ The .layout-3col__full grid item.
+
+
+ The .layout-3col__left-content grid item.
+
+
+ The .layout-3col__right-sidebar grid item.
+
+
+ The .layout-3col__right-content grid item.
+
+
+ The .layout-3col__left-sidebar grid item.
+
+
+ The .layout-3col__right-content grid item.
+
+
+ The .layout-3col__first-left-sidebar grid item.
+
+
+ The .layout-3col__second-left-sidebar grid item.
+
+
+ The .layout-3col__col-1 grid item.
+
+
+ The .layout-3col__col-2 grid item.
+
+
+ The .layout-3col__col-3 grid item. Don't forget to look for the .layout-3col__col-4 grid item at tablet sizes.
+
+
+ The .layout-3col__col-4 grid item.
+
+
+
+ The first .layout-3col__col-x grid item in this nested grid.
+
+
+ The second .layout-3col__col-x grid item in this nested grid.
+
+
+ The third .layout-3col__col-x grid item in this nested grid.
+
+
+ The fourth .layout-3col__col-x grid item in this nested grid.
+
+
+ The fifth .layout-3col__col-x grid item in this nested grid.
+
+
+ The sixth .layout-3col__col-x grid item in this nested grid.
+
+
+
+
+
+
+
+
+
<div class="layout-3col ">
+ <div class="layout-3col__full">
+ The <code>.layout-3col__full</code> grid item.
+ </div>
+ <div class="layout-3col__left-content">
+ The <code>.layout-3col__left-content</code> grid item.
+ </div>
+ <div class="layout-3col__right-sidebar">
+ The <code>.layout-3col__right-sidebar</code> grid item.
+ </div>
+ <div class="layout-3col__right-content">
+ The <code>.layout-3col__right-content</code> grid item.
+ </div>
+ <div class="layout-3col__left-sidebar">
+ The <code>.layout-3col__left-sidebar</code> grid item.
+ </div>
+ <div class="layout-3col__right-content">
+ The <code>.layout-3col__right-content</code> grid item.
+ </div>
+ <div class="layout-3col__first-left-sidebar">
+ The <code>.layout-3col__first-left-sidebar</code> grid item.
+ </div>
+ <div class="layout-3col__second-left-sidebar">
+ The <code>.layout-3col__second-left-sidebar</code> grid item.
+ </div>
+ <div class="layout-3col__col-1">
+ The <code>.layout-3col__col-1</code> grid item.
+ </div>
+ <div class="layout-3col__col-2">
+ The <code>.layout-3col__col-2</code> grid item.
+ </div>
+ <div class="layout-3col__col-3">
+ The <code>.layout-3col__col-3</code> grid item. Don't forget to look for the <code>.layout-3col__col-4</code> grid item at tablet sizes.
+ </div>
+ <div class="layout-3col__col-4">
+ The <code>.layout-3col__col-4</code> grid item.
+ </div>
+ <div class="layout-3col__full layout-3col__grid-item-container">
+ <div class="layout-3col__col-x">
+ The first <code>.layout-3col__col-x</code> grid item in this nested grid.
+ </div>
+ <div class="layout-3col__col-x">
+ The second <code>.layout-3col__col-x</code> grid item in this nested grid.
+ </div>
+ <div class="layout-3col__col-x">
+ The third <code>.layout-3col__col-x</code> grid item in this nested grid.
+ </div>
+ <div class="layout-3col__col-x">
+ The fourth <code>.layout-3col__col-x</code> grid item in this nested grid.
+ </div>
+ <div class="layout-3col__col-x">
+ The fifth <code>.layout-3col__col-x</code> grid item in this nested grid.
+ </div>
+ <div class="layout-3col__col-x">
+ The sixth <code>.layout-3col__col-x</code> grid item in this nested grid.
+ </div>
+ </div>
+</div>
+
+
+
+
+ Source: layouts/layout-3col/_layout-3col.scss, line 1
+
Uses absolute positioning and selective padding to make 2 elements appear to
+swap places in the visual order while maintaining their original HTML source
+order.
+
+
+
+
+
+
+
+ Example
+
+
+
+
+
This element comes first in the HTML source order.
+
This element comes second in the HTML source order.
+
+
+
+
+
+
+
<div class="layout-swap">
+ <div>This element comes <strong>first</strong> in the HTML source order.</div>
+ <div class="layout-swap__top">This element comes <strong>second</strong> in the HTML source order.</div>
+</div>
+
+
+
+
+ Source: layouts/layout-swap/_layout-swap.scss, line 4
+
To make it easier to use all variables and mixins in any Sass file in this
+project, each .scss file has a @import 'init'; declaration. The _init.scss
+file is in charge of importing all the other partials needed for the
+project.
+
The initialization partial is organized in this way:
+
+
First we set any shared Sass variables.
+
Next we import Sass modules.
+
Last we define our custom mixins for this project.
For older versions of browsers, some Sass relies on the support-for() to
+control whether extra CSS is needed to be output. The support-for()
+function and the $support-for variable are documented on the support-for
+homepage.
Font styling and line heights are controlled by the several variables that
+used by mixins like type-layout(), margin-top(), and margin-bottom().
+These variable and mixins are documented on the Typey
+homepage.
$indent-amount controls the amount lists, blockquotes and comments are indented.
+
$include-rtl controls whether RTL styles are output. Rather than include a separate *-rtl.css file, Zen 6 uses Drupal 8's standard [dir="rtl"] selector for RTL language support.
If you include your images next to your component Sass files, you need to
+specify a url() to point from the generated CSS to the Sass source like this:
With the image-url() function the path to all your components is assumed to
+start with ../sass/components/ and you just need to give it the last, short
+bit of the path in your Sass code like this:
+
content: image-url(is-quite/short.svg);
+
+
If you want to point at an image that is not in the components sub-directory
+of your sass directory, you can override the default $subdirectory by
+passing it in as the first parameter of image-url() like this:
Includes Right-To-Left language support by adding a parent selector of
+[dir="rtl"]. Since the dir attribute is usually defined on the html element
+of a page, using this mixin on a ruleset that matches the html element won't
+work.
+
Can be turned off globally by setting $include-rtl: false;.
+ Maecenas id porttitor Ut enim ad minim veniam, quis nostrudfelis.
+ Laboris nisi ut aliquip ex ea.
+
+
+
+
+
Lorem ipsum dolor
+
+
+ Sit amet, consectetur adipisicing elit, sed do eiusmod tempor
+ incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
+ nostrud exercitation ullamco laboris nisi ut aliquip ex ea
+ commodo consequat. Maecenas id porttitor Ut enim ad minim veniam, quis nostr udfelis.
+
+
+
+
+
+
+
+
diff --git a/frontend/payments/cebelica/predracuni/.htaccess b/frontend/payments/cebelica/predracuni/.htaccess
new file mode 100644
index 000000000..22b9ed252
--- /dev/null
+++ b/frontend/payments/cebelica/predracuni/.htaccess
@@ -0,0 +1,2 @@
+Order Allow,Deny
+Deny from all
\ No newline at end of file
diff --git a/frontend/payments/cebelica/racuni/.htaccess b/frontend/payments/cebelica/racuni/.htaccess
new file mode 100644
index 000000000..22b9ed252
--- /dev/null
+++ b/frontend/payments/cebelica/racuni/.htaccess
@@ -0,0 +1,2 @@
+Order Allow,Deny
+Deny from all
\ No newline at end of file
diff --git a/function/.htaccess b/function/.htaccess
new file mode 100644
index 000000000..b0e37d7d9
--- /dev/null
+++ b/function/.htaccess
@@ -0,0 +1 @@
+RewriteEngine Off
\ No newline at end of file
diff --git a/lang/.htaccess b/lang/.htaccess
new file mode 100644
index 000000000..b0e37d7d9
--- /dev/null
+++ b/lang/.htaccess
@@ -0,0 +1 @@
+RewriteEngine Off
\ No newline at end of file
diff --git a/main/.htaccess b/main/.htaccess
new file mode 100644
index 000000000..b0e37d7d9
--- /dev/null
+++ b/main/.htaccess
@@ -0,0 +1 @@
+RewriteEngine Off
\ No newline at end of file
diff --git a/main/survey/app/.htaccess b/main/survey/app/.htaccess
new file mode 100644
index 000000000..05cd49a11
--- /dev/null
+++ b/main/survey/app/.htaccess
@@ -0,0 +1,3 @@
+# Ne dovolimo direktnega dostopa do tega direktorija
+
+deny from al
diff --git a/resources/.htaccess b/resources/.htaccess
new file mode 100644
index 000000000..14249c50b
--- /dev/null
+++ b/resources/.htaccess
@@ -0,0 +1 @@
+Deny from all
\ No newline at end of file
diff --git a/utils/.htaccess b/utils/.htaccess
new file mode 100644
index 000000000..b0e37d7d9
--- /dev/null
+++ b/utils/.htaccess
@@ -0,0 +1 @@
+RewriteEngine Off
\ No newline at end of file
+ 
+ 
+ 
+ 
+ 
+ 
+ Add our app to your home screen?
+ 
+ 
+ 
+ 
+ 
then 
+ 
+ 
Apollo 11
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
that is inline with other text.
+
Jane A. User replied on + Permalink +
+ ++ The comment's title +
+Conventio facilisis nutus. Distineo lucidus olim ut. Huic illum olim quadrum usitas. Bene ex pecus pneum uxor. Brevitas diam hos persto tincidunt virtus. Consequat dignissim distineo eros exerci huic ludus sino turpis.
+