Modx filters. Using if else conditions in MODx

Today useful article about phx filters and their modifiers MODX Revo with which you can manipulate the value of various tags right inside the templates.

Why are they needed?

phx modifiers make life easier for modx developers. Let's say we have a website with an image carousel (or a banner) that we need output only to home page . To do this, just put it in a separate chunk and then display it in the template using this construction

Where: 1 — home page id,
$carusel— a chunk with the carousel (banner) code.
Only full teapots are created new template, for the sake of a few lines of carousel code. I was like that too, in general, we don’t despair and implement phx into development.

Let's look at the above structure in more detail:

[[*id:is=`1`:then=`[[$carusel]]`]]

*id— displays id current page;

:is=`1`:then=

- checks if it is equal *id == 1? and if equal, then the contents are output then;
$carusel— displays the carusel chunk.

Instead of *id, you can use other fields, for example *template - will display the currently used template. Or you can check whether the TV field is filled in or not (let it be *keywords) and if it is filled, then display it. Let's look at this case in more detail. The standard markup is given:

Task: do not display this line if TV keywords are empty.
Solution.

[[*keywords:!empty=` `]]

Loads

You need to monitor the processing of modifiers; their thoughtless use will cause unnecessary loads. Let's go back to the carousel, this entry is read from left to right and MODH executes all nested conditions, regardless of whether the condition is true or not, whether the contents are displayed on the current page [[$carusel]], in any case, its contents will be processed. In this regard, it is more appropriate to rewrite the entry:

[[$caru[[*id:is=`1`:then=`sel`]]]]

In this case, the contents of the chunk $carusel, will be processed if the condition is met

*id:is=`1`

because running

[[*id:is=`1`:then=`sel`]]

and if the id of the current page is 1, the last thing that is processed is [[$carusel]], if id is not equal to 1 then − [[$caru]]. And if chunka $caru- if not in the elements, then there will be no load.

In general, the ideal output would look like this.

[[$[[*id:is=`1`:then=`carusel`]]]]

About how to properly integrate layout into modx revo I recommend reading here.

Note! You can combine as many modifiers as you like to suit the operating logic of the site components, but the main thing to remember is that their main essence is make development easier, and not complicate already complex tasks. Usually the most effective and effective way- this is the simplest, since the simpler and clearer the design, the easier it will be to work with it in the future. Below are the main modifiers that you can use for any MODH Revo tag.

Modifier chains

A good example chaining will format the date string to a different format, like this:

[[+mydate:strtotime:date=`%Y-%m-%d`]]

Direct access to the "modx_user_attributes" table in the database using output modifiers instead of a snippet can be done simply by using a modifier userinfo. Select the appropriate column from the table and specify it as an output modifier property, for example, like this:

Internal user key: [[!+modx.user.id:userinfo=`internalKey`]] Login: [[!+modx.user.id:userinfo=`username`]] Full name: [[!+modx.user .id:userinfo=`fullname`]] Role: [[!+modx.user.id:userinfo=`role`]] E-mail: [[!+modx.user.id:userinfo=`email`]] Phone: [[!+modx.user.id:userinfo=`phone`]] Mobile phone: [[!+modx.user.id:userinfo=`mobilephone`]] Fax: [[!+modx.user.id :userinfo=`fax`]] Birthday: [[!+modx.user.id:userinfo=`dob`:date=`%Y-%m-%d`]] Gender: [[!+modx.user .id:userinfo=`gender`]] Country: [[!+modx.user.id:userinfo=`country`]] State: [[!+modx.user.id:userinfo=`state`]] Zip code : [[!+modx.user.id:userinfo=`zip`]] Photo: [[!+modx.user.id:userinfo=`photo`]] Comment: [[!+modx.user.id:userinfo =`comment`]] Date last login: [[!+modx.user.id:userinfo=`lastlogin`:date=`%Y-%m-%d`]] Number of logins: [[!+modx.user.id:userinfo=`logincount`] ]

Pay special attention to the exclamation mark [[ ! +modx.user.id]]. It allows DO NOT cache output contents. Why should you not cache? Let's imagine it like this: there are 5 users on the site. The first user visited the page with the challenge:

Welcome, [[!+modx.user.id:userinfo=`username`]]!

As planned, this page displays a welcome message to the user. So, if the result is cached, then the first time you enter this page, the name of the user who just entered will be saved, and everyone else will be shown not their name, but the name of the user who entered this page first. To avoid this, we simply do not cache this tag using exclamation point before calling [[ ! +modx…

P.s.: Don't forget turn off caching tags where needed! To do this you need GET RID from exclamation marks ( ! ) . The results of most snippets can easily work from the cache. We'll look at it in the next lesson.

Filters in Revolution allow you to manipulate how certain tags are processed. They allow you to change values ​​right inside your templates.

Input filters

Currently, input filters are used in preparation for processing output filters. They are usually only used inside the MODX engine.

Output filters

In Revolution, output filters behave the same way as PHx in Evolution, only the filters are now built directly into the MODX engine. The syntax looks like this:

[]

Filters can be applied sequentially. To do this, write them in a row (from left to right):

[]

Filters can also be used to modify the output of snippets. The filter must be specified before all parameters (before the question mark):

[]

Output modifiers

The table shows some modifiers and examples of their use. In the examples, modifiers are applied to placeholders, but you should remember that they can be applied to any MODX tags. Make sure the tag you use outputs at least something that the modifier will process.

Conditional output modifiers

Modifiers for working with strings

Modifiers for working with users must be called uncached so that each user sees the latest data.

Using Output Modifiers with Parameters

If a tag has parameters, then they must be written immediately after the modifier:

[[!getResources:default=`Sorry, nothing found`? &tplFirst=`blogTpl` &parents=`2,3,4,8` &tvFilters=`blog_tags==%[[!tag:htmlent]]%` &includeTVs=`1` ]]

Creating a Custom Modifier

Any snippet can be used as an output modifier. To do this, simply specify the snippet name instead of the modifier. For example, let's create a snippet [] that adds a certain number of exclamation points to the output:

[[*pagetitle:makeExciting=`4`]]

Such a tag call will pass the following parameters to the makeExciting snippet for processing:

Good health to all. In this article I will tell you how to make a document filter based on TV parameters on a website running Modx Revolution. We will use the snippet tagManager2 from Andchir. This snippet can work with several TVs at once, as well as with numerical data (in the form of a price) and a multiple list. We will analyze each of these examples further.

1. First you need to install tagManager2

To do this we go to Applications/Installer/

press the button "Download add-on" and enter in the search bar tagManager2

You also still need to install the snippet getPage and getProducts. Thus section "Package Management" should look like this (the translit snippet, by the way, is responsible for transliterating aliases into Latin)

Download, install packages and go to "System Settings"

2. Set up the tagManager2 snippet

IN System settings select the tag_manager2 section

We will see the filter settings options

Everything there is quite simple and clear, but still:

• IN "Top Level Directory Resource ID" specify the id of the catalog template or category where products or pages will be filtered
• IN "Additional multiple list delimiter" put the # sign. Below you will find out why it is needed
• IN "TV or multiple list field names" register TV with a multiple list. I will show you how to create them below.
• "Names of TV or fields with numerical values» - here you need to specify TV parameters, which will contain numbers. This is usually a price parameter. This filter will be displayed as a slider “from and to”
• IN “Product Template IDs” we write down the ids of the pages that need to be filtered and to which the TV parameters specified above are attached
• IN "Name of parameter set used for filtering" register catalog_filters. This template we will use in parameter templates getPage And getProducts
• Register in “Snippet associated with a set of parameters” the name of the snippet that will display and paginate pages or products. Usually this getPage.

3. Create a set of catalog_filters parameters in getPage

Let's go to the getPage snippet

Go to the tab "Options" and press the button "Add parameter set". You can, of course, edit the existing one, but then there is a chance of overwriting the parameters that we will now create when updating getPage. If you are not going to update, you can just edit.

Edit existing parameters and assign values:

Create new parameters and assign values

The edited parameters will be displayed green, created - purple

4. Create or edit TV parameters for the filter

I created 3 TV parameters for example

I would like to draw special attention to the fact that you need to specify the Name (Title) of the TV parameter, otherwise it may simply not be displayed in the filter control module

​5.Create a chunk filtr_tpl

This chunk is responsible for outputting each individual result in getProducts

6. Create a structure in the document tree

For me it looks like this:

Our main page has ID 1, and products have template ID 1 (we have this in the tag_manager2 settings, if you have other values, don’t forget to change it in the settings)

7. Edit filters.js

Let's go to the address /assets/components/tag_manager2/js/web/filters.js and instead

Multitags: ["tags"],//Additional names. fields with multiple values

insert the code with our substituted values

Multitags: ["filtr1", "filtr2"],//Additional names. fields with multiple values

Everything here is extremely simple and clear. We inserted our tv fields with multiple values. In general, this is a config of all settings (but it’s better not to touch them without the permission of big guys, I mean the advice of the creators of the module)

8. Display the filter and filtering results

The filter itself

Displaying results with pagination

[[!+page.nav]]

Sorting results

9. Activate the filter

Now we just need to activate our filter. To do this we go to Applications/Filter Management.

Here you need to check the boxes next to each filter and click the button"Save" .

If you did everything correctly, the filter should work. That's all. If you have any questions, ask in the comments, I will try to answer. In general, here is the documentation for tagManager2 . Good luck in development. IN "Demo" one of my sites that implements a filter using tagManager2

Yes, another way to implement an Ajax filter on a website =)

Let's start with a simple display of a regular list of resources on the page. Be sure to ensure that AJAX pagination works properly, because we will not write our own mechanisms for working with AJAX, but will use the AJAX methods that are in pdoPage.

For filters I will use this layout. But layout doesn’t play a special role here - the main thing is to specify the correct classes in the JS code.

$(document).on("change keyup", "#filters input", function())( // Check that pdoPage is connected if (typeof(pdoPage) == "undefined") return; // Collect the values ​​of all filters in single array var fields = (); $.each($("#filters").serializeArray(), function())( // If the parameter is not an array (checkbox), then everything is simple if (this.name.indexOf( "")<= 0) { fields = this.value; } else { // Для чекбоксов посложнее var name = this.name.replace("",""); if (typeof(fields) == "undefined") { fields = ; } fields.push(this.value); } }); // И отправляем этот массив на сервер. $.post(document.location.href, { action: "filter", fields: fields, // Параметр hash - обязательный (он содержит настройки pdoPage) hash: pdoPage.configs.page.hash }, function(data) { // Просим pdoPage загрузить новый список ресурсов var tmp = document.location.href.split("?"); pdoPage.keys.page = 0; pdoPage.loadPage(tmp, pdoPage.configs.page); }); });
Already now, when you change the value of the filters, the list of resources will be updated. Now all that remains is to “explain” how to process filters. To do this, create a plugin for the event OnHandleRequest:

context->key == "mgr" || empty($_SERVER["HTTP_X_REQUESTED_WITH"]) || $_SERVER["HTTP_X_REQUESTED_WITH"] != "XMLHttpRequest") return; switch ($_POST["action"]) ( case "filter": $output = array("success" => false, "message" => ""); // Check that the hash has been received and the pdoPage parameters exist if ( isset($_POST["hash"]) && !empty($_POST["hash"]) && isset($_SESSION["pdoPage"][$_POST["hash"]]) && !empty($_SESSION[" pdoPage"][$_POST["hash"]])) ( $hash = (string) $_POST["hash"]; // Specify only TVs available for filtering $tvs = array("height","weight" ,"speed_type"); // Fill in the selection condition $where = array(); switch ($tv) ( case "price": // Example of processing checkboxes if (isset($_POST[ "fields"]["price"]) && !empty($_POST["fields"]["price"])) ( $where_price = ; foreach ($_POST["fields"]["price"] as $range ) ( $value = explode("-", $range); if (count($value) != 2) ( continue; ) $min = (int) $value; $max = (int) $value; $where_range = "CAST(`TVprice`.`value` AS DECIMAL(13,3)) >= " . $min; if ($max) ( $where_range .= " AND CAST(`TVprice`.`value` AS DECIMAL( 13.3))<= " . $max; } $where_price = "(" . $where_range . ")"; } $where = "(" . implode(" OR ", $where_price) . ")"; } break; default: if (isset($_POST["fields"][$tv]) && $_POST["fields"][$tv] !== "") { $where[$tv] = $_POST["fields"][$tv]; } break; } } // Добавляем это условие в параметры pdoPage "на лету" $_SESSION["pdoPage"][$hash]["where"] = $where; $output["message"] = $where; $output["success"] = true; } else { $output["message"] = "Error"; } echo $modx->toJSON($output); die(); break; default: break; )
Now our filters are working. The only thing is that pdoPage "doesn't know" what to show when no results are found. To take this case into account, let's create a file pdopage.custom.js and specify it in the parameter frontend_js:

("!pdoPage" | snippet: [ "ajaxMode" => "default", "frontend_js" => "/assets/components/pdotools/js/pdopage.custom.js", "parents" => 0, "limit" => 3, // ... )
In the standard code we will only add the condition else in case the response from the server is empty:

// ... pdoPage.loadPage = function (href, config, mode) ( // ... $.post(config["connectorUrl"], params, function (response) ( if (response && response["total" ]) ( // ... ) else ( // Add a condition else wrapper.find(rows).html("Nothing found"); wrapper.find(pagination).html(""); wrapper.removeClass(" loading"); wrapper.css((opacity: 1)); if (config["mode"] == "default") ( $("html, body").animate((scrollTop: wrapper.position(). top - 50 || 0), 0); // ...
This completes the simple AJAX filter.

In this article I would like to tell you about filters (modifiers) in MODx.

In principle, you can live without them, but knowing how and where they are used, the developer receives a powerful tool with which you can add small, but sometimes very useful logic to your site.

In this article I will talk about MODx Revolution. The ability to apply filters exists thanks to the PHx snippet, which by default is already built into the MODx Revolution core, but PHx is not included in the Evolution core, so it must be installed separately on Evo.

So, filters allow you to manipulate the data that is obtained as a result of parsing placeholders and tags. They provide an opportunity modify data directly in your templates.

The syntax for filters is as follows:

It’s very convenient that they can be arranged in chains:

At the same time, it is also possible to pass parameters to snippets. The main thing is that the filter is written between the snippet name and the question mark:

The following table lists some of the filters and example showing them application. Although the examples use a placeholder, filters can be applied to any MODx tag. Make sure that the placeholder actually returns something.

Conditional modifiers

String modifiers

Creating custom modifiers

Snippets can be used as modifiers. To do this, simply replace the name of the filter with the name of the snippet. For example, we have a snippet called "makeDownloadLink"

[[+file:makeDownloadLink=`notitle`]]

This call will pass the following parameters to the snippet:

The result will be what will be returned snippet.

Examples of use

Here is an example where the filters are called one after another. This example formats a date from a string to another format:

[[+mydate:strtotime:date=`%Y-%m-%d`]]

Direct access to the modx_user_attributes table from the database from the snippet can be replaced by simply using the userinfo modifier. To get the required field, you need to pass the name of the column from the database to the modifier parameters.

Internal key: [[!+modx.user.id:userinfo=`internalKey`]]

Username: [[!+modx.user.id:userinfo=`username`]]

Full name: [[!+modx.user.id:userinfo=`fullname`]]

Role: [[!+modx.user.id:userinfo=`role`]]

E-mail: [[!+modx.user.id:userinfo=`email`]]

Phone: [[!+modx.user.id:userinfo=`phone`]]

Mobile: [[!+modx.user.id:userinfo=`mobilephone`]]

Fax: [[!+modx.user.id:userinfo=`fax`]]

Date of birth: [[!+modx.user.id:userinfo=`dob`:date=`%Y-%m-%d`]]

Gender: [[!+modx.user.id:userinfo=`gender`]]

Country: [[+modx.user.id:userinfo=`country`]]

Region: [[+modx.user.id:userinfo=`state`]]

Postal code: [[+modx.user.id:userinfo=`zip`]]

Avatar: [[+modx.user.id:userinfo=`photo`]]