Как формируется css в october cms

Как формируется css в october cms

Import Export Behavior is a controller modifier that provides features for importing and exporting data. The behavior provides two pages called Import and Export. The Import page allows a user to upload a CSV file and match the columns to the database. The Export page is the opposite and allows a user to download columns from the database as a CSV file. The behavior provides the controller actions import() and export() .

The behavior configuration is defined in two parts, each part depends on a special model class along with a list and form field definition file. To use the importing and exporting behavior you should add it to the $implement property of the controller class. Also, the $importExportConfig class property should be defined and its value should refer to the YAML file used for configuring the behavior options.

Configuring the Behavior

The configuration file referred in the $importExportConfig property is defined in YAML format. The file should be placed into the controller’s views directory. Below is an example of a configuration file:

The configuration options listed below are optional. Define them if you want the behavior to support the Import or Export, or both.

Option Description
defaultRedirect used as a fallback redirection page when no specific redirect page is defined.
import a configuration array or reference to a config file for the Import page.
export a configuration array or reference to a config file for the Export page.
defaultFormatOptions a configuration array or reference to a config file for the default CSV format options.

Import Page

To support the Import page add the following configuration to the YAML file:

The following configuration options are supported for the Import page:

Option Description
title a page title, can refer to a localization string.
list defines the list columns available for importing.
form provides additional fields used as import options, optional.
redirect redirection page when the import is complete, optional
permissions user permissions needed to perform the operation, optional

Export Page

To support the Export page add the following configuration to the YAML file:

The following configuration options are supported for the Export page:

Option Description
title a page title, can refer to a localization string.
fileName the file name to use for the exported file, default export.csv.
list defines the list columns available for exporting.
form provides additional fields used as import options, optional.
redirect redirection page when the export is complete, optional.
useList set to true or the value of a list definition to enable integration with Lists, default: false.

Format Options

To override the default CSV format options add the following configuration to the YAML file:

The following configuration options (all optional) are supported for the format options:

Option Description
delimiter Delimiter character.
enclosure Enclosure character.
escape Escape character.
encoding File encoding (only used for the import).

Import and Export Views

For each page feature Import and Export you should provide a view file with the corresponding name — import.htm and export.htm.

The import/export behavior adds two methods to the controller class: importRender and exportRender . These methods render the importing and exporting sections as per the YAML configuration file described above.

Import View

The import.htm view represents the Import page that allows users to import data. A typical Import page contains breadcrumbs, the import section itself, and the submission buttons. The data-request attribute should refer to the onImport AJAX handler provided by the behavior. Below is a contents of the typical import.htm view file.

Export View

The export.htm view represents the Export page that allows users to export a file from the database. A typical Export page contains breadcrumbs, the export section itself, and the submission buttons. The data-request attribute should refer to the onExport AJAX handler provided by the behavior. Below is a contents of the typical export.htm form.

Defining an Import Model

For importing data you should create a dedicated model for this process which extends the Backend\Models\ImportModel class. Here is an example class definition:

The class must define a method called importData used for processing the imported data. The first parameter $results will contain an array containing the data to import. The second parameter $sessionKey will contain the session key used for the request.

Method Description
logUpdated() Called when a record is updated.
logCreated() Called when a record is created.
logError(rowIndex, message) Called when there is a problem with importing the record.
logWarning(rowIndex, message) Used to provide a soft warning, like modifying a value.
logSkipped(rowIndex, message) Used when the entire row of data was not imported (skipped).

Defining an Export Model

For exporting data you should create a dedicated model which extends the Backend\Models\ExportModel class. Here is an example:

The class must define a method called exportData used for returning the export data. The first parameter $columns is an array of column names to export. The second parameter $sessionKey will contain the session key used for the request.

Custom Options

Both import and export forms support custom options that can be introduced using form fields, defined in the form option in the import or export configuration respectively. These values are then passed to the Import / Export model and are available during processing.

The form fields specified will appear on the import/export page. Here is an example fields.yaml file contents:

The value of the form field above called auto_create_lists can be accessed using $this->auto_create_lists inside the importData method of the import model. If this were the export model, the value would be available inside the exportData method instead.

Integration with List Behavior

There is an alternative approach to exporting data that uses the list behavior to provide the export data. In order to use this feature you should have the Backend.Behaviors.ListController definition to the $implement field of the controller class. You do not need to use an export view and all the settings will be pulled from the list. Here is the only configuration needed:

If you are using multiple list definitions, then you can supply the list definition:

Как формируется css в october cms

Every website serves up at least one page and in October CMS, a page is represented with page template. Page template files reside in the pages directory in your theme. Page file names do not affect the routing, but it’s a good idea to name your pages according to the page’s function. The files should have the htm extension.

The Configuration and Twig template sections are required for pages, but the PHP section is optional. Below, you can see the simplest home page example:

Page Configuration

Page configuration is defined in the Configuration Section of the page template file. The page configuration defines the page parameters, required for the routing and rendering the page and its Components, which are explained in another article. The following configuration parameters are supported for pages:

Parameter Description
url the page URL, required. The URL syntax is described below.
title the page title, required.
layout the page layout, optional. If specified, should contain the name of the layout file, without extension, for example: default .
description the page description for the back-end interface, optional.
hidden hidden pages are accessible only by logged-in back-end users, optional.

URL Syntax

The page URL is defined with the url configuration parameter. URLs should start with the forward slash character, and can contain parameters. URLs without parameters are fixed and strict. In the following example, the page URL is /blog .

Note: The page URL is case-insensitive by default.

URLs with parameters are more flexible. A page with the URL pattern defined in the following example would be displayed for any address like /blog/post/something . URL parameters can be accessed by October components or from the page PHP code section.

This is how you can access the URL parameter from the page’s PHP section (see the Dynamic pages section for more details):

Parameter names should be compatible with PHP variable names. To make a parameter optional, add a question mark after its name:

Parameters in the middle of the URL cannot be optional. In the next example, the :post_id parameter is marked as optional, but is processed as required.

Optional parameters can have default values which are used as fallback values in case the real parameter value is not presented in the URL. Default values cannot contain any asterisks, pipe symbols, or question marks. The default value is specified after the question mark. In the next example, the category_id parameter would be 10 for the URL /blog/category .

You can also use regular expressions to validate parameters. To add a validation expression, add a pipe symbol after the parameter name, or a question mark, and specify the expression. The forward slash symbol is not allowed in these expressions. Examples:

It is possible to use a special wildcard parameter by placing an asterisk after the parameter. Unlike regular parameters, wildcard parameters can match one or more URL segments. A URL can only ever contain a single wildcard parameter, cannot use regular expressions, or be followed by an optional parameter.

Wildcard parameters themselves can be made optional by preceding the asterisk with the ? character however.

For example, a URL like /color/:color/make/:make*/edit will match /color/brown/make/volkswagen/beetle/retro/edit and extract the following parameter values:

  • color: brown
  • make: volkswagen/beetle/retro

Note: Subdirectories do not affect page URLs — the URL is defined only with the url parameter.

Dynamic Pages

Inside the Twig section of a page template, you can use any functions, filters, and tags provided by October. Any dynamic page requires variables. In October, variables may be prepared by the page, layout PHP section, or by Components. In this article, we describe how to prepare variables in the PHP section.

Page Execution Life Cycle

There are special functions that can be defined in the PHP section of pages and layouts: onInit , onStart , and onEnd . The onInit function is executed when all components are initialized and before AJAX requests are handled. The onStart function is executed during the beginning of the page execution. The onEnd function is executed before the page is rendered and after the page components are executed. In the onStart and onEnd functions, you can inject variables into the Twig environment. Use array notation to pass variables to the page:

The next example is more complicated. It shows how to load a blog post collection from the database, and display on the page (the Acme\Blog plugin is imaginary):

The default variables and Twig extensions provided by October are described in the Markup Guide. The sequence that the handlers are executed in is described by the Dynamic layouts article.

Sending a Custom Response

All methods defined in the execution life cycle have the ability to halt the process and return a response — simply return a response from the life cycle function. The example below will not load any page contents, and instead return the string Hello world! to the browser:

A more useful example might be triggering a redirect using the Redirect facade:

Handling Forms

You can handle standard forms with handler methods defined in the page or layout PHP section (handling the AJAX requests is explained in the AJAX Framework article). Use the form_open() function to define a form that refers to an event handler. Example:

The onHandleForm function can be defined in the page or layout PHP section, like so:

The handler loads the value with the post function and initializes the page’s lastValue attribute variable which is displayed below the form in the first example.

Note: If a handler with the same name is defined in the page layout, the page, and a page component, October will execute the page handler. If a handler is defined in a component and a layout, the layout handler will be executed. The handler precedence is: page, layout, component.

If you want to refer to a handler defined in a specific component, use the component’s name or alias in the handler reference:

404 Page

If the theme contains a page with the URL /404 , it is displayed when the system can’t find a requested page.

Error Page

By default, any errors will be shown with a detailed error page containing the file contents, line number, and stack trace where the error occurred. You can display a custom error page by setting the configuration value debug to false in the config/app.php script, and creating a page with the URL /error .

Page Variables

The properties of a page can be accessed in the PHP code section, or Components by referencing $this->page .

They can also be accessed in the markup using the this.page variable. For example, to return the title of a page:

More information can be found at this.page in the Markup guide.

Injecting Page Assets Programmatically

If needed, you can inject assets (CSS and JavaScript files) into pages with the controller’s addCss and addJs methods. It could be done in the onStart function defined in the PHP section of a page or layout template. Example:

If the path specified in the addCss and addJs method argument begins with a slash (/), it will be relative to the website root. If the asset path does not begin with a slash, it is relative to the theme.

Injected assets can be combined by passing them as an array:

LESS and SCSS assets can be injected and compiled using the combiner:

The second argument of addCss and addJs allows you to provide additional attributes to your injected assets:

In order to output the injected assets on pages or layouts, use the and tags. Example:


Функция counter() имеет две формы записи: ‘counter( имя )’ или ‘counter( имя , стиль )’. Сгенерированный текст — это значение самого вложенного счётчика с заданным именем в области видимости данного элемента. Он отформатирован в указанном стиле (по умолчанию decimal ).

Функция counters() также имеет две формы записи: ‘counters( name , string )’ или ‘counters( name , string , style )’. Сгенерированный текст — это значение всех счётчиков с заданным именем в области видимости данного элемента, от крайнего к вложенному. разделённых указанной строкой. Счётчики отображаются в указанном стиле (по умолчанию decimal ).

attr(x) Значение атрибута x элемента в виде строки. Если атрибут x отсутствует, вернётся пустая строка. Чувствительность к регистру в названии атрибута зависит от языка документа. open-quote | close-quote Эти значения заменяются соответствующей строкой из свойства quotes (en-US) . no-open-quote | no-close-quote Не вводит никакого содержимого, но увеличивает (уменьшает) уровень вложенности для кавычек.



Заголовки и двойные кавычки

В этом примере вставляются кавычки вокруг кавычек а добавляет слово "Глава" перед заголовками.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *