PHPackages wdb/wdb-content-conditions - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Utility & Helpers](/categories/utility) 4. / 5. wdb/wdb-content-conditions ActiveTypo3-cms-extension[Utility & Helpers](/categories/utility) wdb/wdb-content-conditions ========================== This extension adds two different TypoScript conditions to check if content elements with special values on a page exist. v1.0.5(2y ago)05GPL-2.0-or-laterPHP Since May 19Pushed 2y ago1 watchersCompare [ Source](https://github.com/DavidBruchmann/wdb-content-conditions)[ Packagist](https://packagist.org/packages/wdb/wdb-content-conditions)[ Docs](https://github.com/DavidBruchmann)[ RSS](/packages/wdb-wdb-content-conditions/feed)WikiDiscussions main Synced 3w ago READMEChangelog (5)Dependencies (1)Versions (7)Used By (0) TYPO3 extension "WDB Content conditions" ======================================== [](#typo3-extension-wdb-content-conditions) This extension adds a TypoScript condition to check if content elements with special values on a site exist. Included are two conditions, **`ttContent()`** and **`tt_content[]`**: 1. A functional condition This is verifying all content elements on a page The syntax is: **`ttContent([fieldname], [expected value], [type of value])`** **return value: bool / array** **Parameters:** - **`fieldname`**: the field to verify. - **`expected value`**: the value that shall be checked, optional. - **`type of value`**: the datatype of the value, optional. Due to the return value, and the limit of available operators, it's NOT useful to combine it with further comparisons like `a > b`. Nevertheless several conditions can be used together concatenated with `||` (OR) or `&&` (AND). **Important** to understand is that no content elements are returned, but that the new condition is doing most often a boolean check. That means that above any condition the content elements have the same amount and properties like below, **content elements are not filtered** by the condition. **Note that all queries exclude deleted or hidden records without exception.** 2. An array condition to a verify single content element This can be used to check properties of single elements and even combine several to check several properties of single elements. The syntax is: **`tt_content[uid][fieldname]`** **return value: string / integer** Return values are just what is saved in the database, this doesn't respect any relations to files or other records. **Array Keys:** - **`uid`**: the unique id for the `tt_content` record to verify. - **`fieldname `**: the field to verify. Use case for the additional condition: -------------------------------------- [](#use-case-for-the-additional-condition) Checking for values in content elements allows to include special CSS, JS or to configure other page- or config-related values only if it's required. **Example:** ``` [ttContent("list_type", "tx_myextension_pi1", "str")] page.includeCSS.mySlideshow = EXT:my_extension/Resources/Public/Css/mySlideshow.css page.includeJSFooter.mySlideshow = EXT:my_extension/Resources/Public/JavaScript/mySlideshow.js [global] ``` **Explanation:** - **`ttContent()`** is the name of the condition and according to the database-table with the same name. For beginners it might be confusing that there still exists a variable in TypoScript with the same name too. Nevertheless, the usage of `ttContent()` as condition is the only one with round brackets, because it's a function. - The first parameter **`"list_type"`** is the name of the field that shall be checked. Naming conventions for this field name are defined by the database and must not include spaces, minus, brackets or many other characters. - The second parameter **"tx\_myextension\_pi1"** is the value that is supposed to be found as value for a content element in the field **`"list_type"`**. Naming conventions for this value are defined by TYPO3 and must not include spaces, brackets or many other characters. - The third parameter is the data type of the value and used to assign a constant for DBAL (the framework to access the database). It can be `"int"`, `"str"`, `"bool"` or more. Important is that this should be `"int"` for integer values, everything else is not so important and can be `"str"`. For some fields with boolean values like `hidden` as example, the value `"int"` for this parameter can be used too, as TYPO3 stores boolean values usually as integers (0 or 1). ### Special use case: manipulating content rendering [](#special-use-case-manipulating-content-rendering) Certainly it's also possible to change definitions for rendering of content elements based on properties of one (perhaps even unreleated) content element. This could be menus but also other content elements. Nevertheless, as neither the content elements nor the rendering definitions of a page are filtered, those changes would relate to all content elements on the page. **Example:** The condition `[ttContent("header_layout", 3, "int")]` checks in all content elements on a page if the value 3 is saved in the field `header_layout`. Imagine there is one record, that has this value and this record's headline shall be wrappedd additionally to the h3-tag with the em-tag. But the code `tt_content.header.stdWrap.wrap = '|'`would wrap the headlines of all content elements, no matter which value they have assigned. @TODO: whats about operators like &&, xor, etc.? @TODO: whats about FlexForm values? @TODO: test null-values @TODO: update examples below, `ttContent(field, value, type)` example: `[ ttContent("tx_webcan_st_bt_element", 5, "int") ]` Examples for the functional condition: -------------------------------------- [](#examples-for-the-functional-condition) **`[ttContent("colPos", 1, "int")]`** Checks if the field `colPos` of a `tt_content` record on the page has the value 1. **`[ttContent("subheader")]`** Checks if the field `subheader` of any `tt_content` record on the page is filled. **`[ttContent("header", "Home", "str")]`** Checks if the field `header` of a `tt_content` record on the page has the value "Home". **`[ttContent("header", "Home", "str") || ttContent("header", "Homa", "str")]`** Checks if the field `header` of a `tt_content` record on the page has the value "Home" or "Homa". **`[ttContent("header", "Home", "str") && ttContent("header", "Homa", "str")]`** Checks if the field `header` of a `tt_content` record on the page has the value "Home" and another `tt_content` record the value "Homa". This example might explain that the data are coming from a pool of records and that a conclusion if these are coming from the same record is usually not possible. If the requested fields are the same, combined by an AND (&&), surely they can't come from the same record. So it's impossible with this condition, to check if two different properties (field values) belong to the same record. Examples for the condition in array form: ----------------------------------------- [](#examples-for-the-condition-in-array-form) **`[tt_content[15]["colPos"] == 1]`** Checks if the field `colPos` of the `tt_content` record with the `uid` 15 on the page has the value 1. **`[tt_content[15]["subheader"]]`** Checks if the field `subheader` of the `tt_content` record with the `uid` 15 on the page is filled. **`[tt_content[15]["header"] == "Home"]`** Checks if the field `header` of the `tt_content` record with the `uid` 15 on the page has the value "Home". **`[tt_content[15]["header"] == "Home" || tt_content[15]["subheader"] == "Welcome"]`** Checks if the field `header` of the `tt_content` record with the `uid` 15 on the page has the value "Home" OR the field `subheader` the value "Welcome". **`[tt_content[15]["header"] == "Home" && tt_content[15]["subheader"] == "Welcome"]`** Checks if the field `header` of the `tt_content` record with the `uid` 15 on the page has the value "Home" AND the field `subheader` the value "Welcome". This example shows that the data are coming from the same record and it can be be useful to have the `uid`of a distinct record to verify something. String comparisons like in this example might be useful to combine with a 3rd condition of the same kind, verifying the field `sys_language_uid` for the record-language: **`[tt_content[15]["header"] == "Home" && tt_content[15]["subheader"] == "Welcome"] && tt_content[15]["sys_language_uid"] == 1]`** ### Health Score 23 — LowBetter than 26% of packages Maintenance20 Infrequent updates — may be unmaintained Popularity4 Limited adoption so far Community7 Small or concentrated contributor base Maturity53 Maturing project, gaining track record Bus Factor1 Top contributor holds 100% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~135 days Recently: every ~169 days Total 6 Last Release 827d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/2cd8989c5c9dc55b469d80c9e51c58fa9064eb72271d7610d278f6aed5fb52f7?d=identicon)[David Bruchmann](/maintainers/David%20Bruchmann) --- Top Contributors [![DavidBruchmann](https://avatars.githubusercontent.com/u/999146?v=4)](https://github.com/DavidBruchmann "DavidBruchmann (14 commits)") --- Tags conditionstypo3-cms-extensiontypo3-extensiontyposcripttyposcript-conditionsextensiontypo3TypoScriptconditioncustom condition ### Embed Badge ![Health badge](/badges/wdb-wdb-content-conditions/health.svg) ``` [![Health](https://phpackages.com/badges/wdb-wdb-content-conditions/health.svg)](https://phpackages.com/packages/wdb-wdb-content-conditions) ``` ### Alternatives [friendsoftypo3/content-blocks TYPO3 CMS Content Blocks - Content Types API | Define reusable components via YAML 103519.9k51](/packages/friendsoftypo3-content-blocks)[wazum/sluggi TYPO3 extension for URL slug management with inline editing, auto-sync, locking, access control, and redirects 40529.5k](/packages/wazum-sluggi)[friendsoftypo3/tt-address Displays a list of addresses from an address table on the page. 461.8M44](/packages/friendsoftypo3-tt-address)[friendsoftypo3/visual-editor TYPO3 CMS Visual Editor - Brings a modern WYSIWYG editing experience to TYPO3 CMS. 576.1k2](/packages/friendsoftypo3-visual-editor)[quellenform/t3x-iconpack Provides an iconpack-registry for custom iconpacks. 1552.6k26](/packages/quellenform-t3x-iconpack)[t3brightside/pagelist TYPO3 CMS extension to create news, events, vacancies and products or just page lists. Demo: microtemplate.t3brightside.com 1121.5k1](/packages/t3brightside-pagelist) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)