camaliga for TYPO3

Most lists in TYPO3 do not need a custom extension

One company wants to showcase its clients on the website: logo, client name, industry, short description. Another wants to list its staff: photo, name, department, phone. A third needs a product overview: image, title, price, link to the detail page. Three different requirements, one common pattern: structured lists with configurable fields. camaliga covers this pattern as a generic list extension, so you do not have to build a custom extension for every type of list.

The extension by quizpalme has been available in the TYPO3 Extension Repository for years and is actively maintained. Its advantage: one record type with flexible fields covers 80% of all list requirements. The downside: if you need very specific data models (nested relations, multilingual content at field level, complex validation), you will hit its limits.

Typical use cases

Client and project showcases. The most common use: logos and descriptions of clients or projects displayed in a grid. camaliga ships with ready-made layouts: grid, carousel, accordion, tabs. The data is maintained as records in the TYPO3 backend, and the output is controlled through Fluid templates. For one client with 120 references, the camaliga-based showcase page went live in 3 days, including filtering by industry.

Team and staff pages. Photo, name, position, contact details and, optionally, a short bio. camaliga covers this with its standard fields: title, subtitle, image, description, link. Additional fields (phone number, department) can be added as custom fields via a TCA override. The alternative would be EXT:tt_address, but it specializes in address data and often offers both too much and too little for team pages.

Simple product overviews without shop functionality. Companies that want to present products but not sell them online do not need a shop. camaliga delivers a product list with image, title, price field and a link to the data sheet. Filtering by category works through the built-in category assignment. For 50-200 products without a shopping cart, this is more efficient than Aimeos or bernetshop.

Technical architecture

camaliga is built on Extbase/Fluid and follows the MVC pattern. The central record type is tx_camaliga_domain_model_content, with fields for title, subtitle, description, short description, image, link, category and several custom fields. The fields are defined in the TCA and can be extended or reduced via a TCA override in the sitepackage.

Output is handled by a frontend plugin with a configurable layout. In the plugin’s FlexForm, the editor chooses which category to show, which layout to use, how many entries to display per page and whether pagination is active. The layouts are Fluid templates that you override in the sitepackage. camaliga ships with around 15 ready-made layouts, from a simple list to a filtered grid with Isotope animation.

Category filtering uses TYPO3’s system categories. Each camaliga record can be assigned to one or more categories. In the frontend, the extension generates a filter menu that filters either via JavaScript (Isotope or CSS filters) or via a page request. The JavaScript variant is faster; the page request variant is more SEO-friendly.

For sorting, camaliga offers several options: by title, by creation date or manually (drag and drop in the backend). Manual sorting uses the sorting field in the database and works through TYPO3’s standard sorting mechanism in the List module.

Common problems and solutions

Layouts look different than expected. camaliga’s bundled layouts rely on specific CSS frameworks (Bootstrap 3/4) or JavaScript libraries (Isotope, Masonry). If the website uses a different framework, the styles collide. The fix: never use the default templates; create your own Fluid templates in the sitepackage instead. A custom template takes 1-2 hours, after which the output is fully under your control.

Performance with more than 500 records. By default, camaliga loads all records of a category and filters them in the frontend via JavaScript. With 500+ entries, the initial load time becomes noticeable (3-5 seconds for 1,000 records with images). The fix: enable pagination and limit each page to 20-50 entries. For JavaScript-based filtering, enable lazy loading for images and load further data on demand via AJAX.

Multilingual content requires a workaround. camaliga supports TYPO3’s language handling, but translating every single record becomes laborious once you have 200+ entries. The fix: for purely visual lists (logos without text), one record per language is enough. For text-heavy lists, speed up translation with TYPO3’s inline translation workflow, or write a migration script that imports DeepL API translations into the language versions.

Migration and version compatibility

camaliga is actively maintained and supports TYPO3 v11, v12 and, according to the current roadmap, v13 as well. The extension follows the TYPO3 release cycle with a short delay. It can be installed via Composer from Packagist or from the TER.

Moving from a custom extension to camaliga means transferring the data from the custom table into tx_camaliga_domain_model_content. That is an SQL job that can be done in under a day in most cases. In the other direction, if you move from camaliga to your own Extbase extension, you can use its data structure as a template.

For more complex requirements (nested records, relations between lists, workflow control), a custom Extbase extension or EXT:mask is the better choice. Gosign advises on the right solution and implements both quick camaliga-based solutions and bespoke extensions.