Search the Community

Hi to everybody, In my backend I have a markup table that lists some information via a Runtime Markup field. Now I would like that on click on of the items the details appear on a modal. I succeded to open the modal an to display a complete page, but how do I only display the content of another runtime markup field on that modal? Thanks as always, Bernhard

Thx for the additions ? That would be a great use case for using $page->meta() ! It's already there without doing anything and it's also a lot easier to manipulate meta data from within a hook than updating a hidden field's content. Everything needed is doable with just a few lines of code without any modules. The modules do not help here. Quite the contrary, they make things more complicated and less robust. To add a runtime markup field to page edit: <?php $wire->addHookAfter("ProcessPageEdit::buildForm", function (HookEvent $event) { /** @var InputfieldForm $form */ $form = $event->return; $page = $event->process->getPage(); // custom rules where to add the field // eg add it only to pages with template "home" // otherwise exit early and do nothing if ($page->template !== 'home') return; $form->insertAfter([ 'type' => 'markup', 'name' => 'mymarkup', // we need that later ;) 'value' => '<h1>I am a custom markup field</h1>', ], $form->get('title')); }); In this markup field you can show any HTML/PHP markup you want. Now we can also add dynamic selects - also just a single and quite simple hook: <?php $wire->addHookAfter("ProcessPageEdit::buildForm", function (HookEvent $event) { /** @var InputfieldForm $form */ $form = $event->return; $page = $event->process->getPage(); // custom rules where to add the field // eg add it only to pages with template "home" // otherwise exit early and do nothing if ($page->template != 'home') return; // data coming from your file $races = ['foo', 'bar', 'baz']; // add all options $f = new InputfieldRadios(); $f->label = 'Choose your race'; $f->name = 'myrace'; foreach ($races as $race) { $f->addOption($race, "Use Race '$race' for something"); } // now add it after our markup field: $form->insertAfter($f, $form->get('mymarkup')); }); And finally we save the data: Another small hook ? <?php $wire->addHookAfter("Pages::saveReady", function (HookEvent $event) { // get the selected race from the radio input // we sanitize the input to make sure it is a string $race = $this->wire->input->post('myrace', 'string'); if (!$race) return; // save selected race to page meta data $page = $event->arguments(0); $page->meta('myrace', $race); }); Of course we have now two hooks for the same process, so we can combine those two to one and we end up with two hooks which should all you need: <?php $wire->addHookAfter("ProcessPageEdit::buildForm", function (HookEvent $event) { /** @var InputfieldForm $form */ $form = $event->return; $page = $event->process->getPage(); // custom rules where to add the field // eg add it only to pages with template "home" // otherwise exit early and do nothing if ($page->template != 'home') return; $race = $page->meta('myrace'); $time = $page->meta('chosenat') ?: ''; if ($time) $time = date("Y-m-d H:i:s", $time); $form->insertAfter([ 'type' => 'markup', 'name' => 'mymarkup', 'value' => '<h1 class=uk-margin-remove>I am a custom markup field</h1>' . "<p>Last Chosen Race: $race (@$time)</p>", ], $form->get('title')); // data coming from your file $races = ['foo', 'bar', 'baz']; // add all options $f = new InputfieldRadios(); $f->label = 'Choose your race'; $f->name = 'myrace'; foreach ($races as $race) { $f->addOption($race, "Use Race '$race' for something"); } // now add it after our markup field: $form->insertAfter($f, $form->get('mymarkup')); }); $wire->addHookAfter("Pages::saveReady", function (HookEvent $event) { // get the selected race from the radio input // we sanitize the input to make sure it is a string $race = $this->wire->input->post('myrace', 'string'); if (!$race) return; // save selected race to page meta data $page = $event->arguments(0); $page->meta('myrace', $race); $page->meta('chosenat', time()); }); No modules, no rocket science. Just ProcessWire awesomeness ?

This week there are a few updates on the dev branch. Since I'm short on time today, I'll just briefly cover the most interesting ones. Support for OR-groups, sub-selectors, and match same (1) @item groups (see last example at that link) have been added to ProcessWire's in-memory page matching selectors, as used primarily by the $page->matches() method. Previously these features were supported only by the database selectors from $pages->find() and methods that delegated to it. The $page->matches() method that gained these features is used by the core in various places for runtime matching of pages, such as when finding/filtering in a PageArray, for example. Support has also been added for OR-groups to the base Selectors class, which makes it possible to use OR-groups on non-Page objects too. These database-specific selector features were added because there's been a recurring request to support OR groups in places that currently use memory selectors, so this should do that. Though it'll remain just on the dev branch until it's had more thorough testing. While there will always be some differences between database and memory selectors, this does narrow the gap a bit. Thanks for reading and have a great weekend!

ProcessWire Concatenate Fieldtype Fieldtype that concatenates the values from one or more other fields at runtime. The value can contain additional formatting and/or words as needed, which you define in your Concat field settings. Example Problem: Your system has a first_name and last_name field, and you want to have a separate full_name field composed of first_name and last_name, without redundancy. Solution: You would create a new Concat field, click the details tab, and enter "first_name last_name" (the fields you want to concatenate) in the settings. Other Potential Uses Having a field that combines the value of two or more others, without the redundancy of separately stored data. Defining a custom “label field” for select boxes, like those used with the Page field. Defining a custom label for your Page List that includes your own formatting. Defining an alternate variation of a text field that uses a different text formatter. Considerations The value for this fieldtype is generated at runtime and thus no data is stored in the database. This is good because there is no duplication. However, it also means that you cannot directly query a Concat field from $pages->find(), for example. If you happen to change the name of a field being used in a Concat field, you will have to update the name in your Concat field settings as well. By design, Concat fields do not inherit the text formatters of the fields they concatenate. You define these separately with the Concat field. Because this is a runtime-generated field, there is no Inputfield associated with it. How to Install Install the module by placing FieldtypeConcat.module in /site/modules/. Check for new modules on the Modules screen in the ProcessWire admin. Click Install for the Concat Fieldtype. How to Create a Concat Field Under Setup and Fields create a new field using type Concat. After entering the new field name and label, click Save. Click the Details tab and enter one or more field names. Separate them with whatever spacing and punctuation is appropriate. Optionally choose one or more Text Formatters. If you are not sure which, “HTML Entity Encoder” is a good default to use. Save. Add your new field to one or more Templates. How to access the value of a Concat field This is no different than accessing the value of any other field. If your Concat field has the name “full_name” then you would output its value like this: echo $page->full_name; Download PW Modules Site: http://modules.proce...eldtype-concat/ GitHub: https://github.com/r...FieldtypeConcat

I know I'm sort of preaching to the choir here, but it's a shame you cannot add images in SF. I think what many devs, me included ,want to use this module for is for global settings which includes things like logo(s). It just makes so much more sense to have these things defined in a separate page rather than by adding fields to the home template but maybe I'm just being too neurotic. Please forgive me if this is a dumb question, but since I have to create a page under the admin page tree to get SF to work, why can't I add images to this very site's /assets/files/ folder? But I guess the answer does something like because the fields I create on the required php or json file don't really exist in the system and are create at runtime?

I'm rendering some markup in page edit UI with help of hook ProcessPageEdit::buildFormContent (example here: https://processwire.com/talk/topic/10539-how-to-render-runtime-markup-custom-php-snippet-in-page-edit-interface/) It works OK until you decide to use ajax-driven Fieldsets. Q1: how to render runtime markup in page edit interface if markup is inside of ajax-driven Fieldset? Q2: how to "ajax"-inize custom Inputfields/Fieldtypes?

Fieldtype and Inputfield ImageMarker As of 02 January 2018 ProcessWire versions earlier than 3.x are not supported Version: Stable Project Page: Github Modules Directory: http://mods.pw/Bk OR http://modules.processwire.com/modules/fieldtype-image-marker/ Requires: ProcessWire 2.4 or greater ######################## About This module allows you to easily 'place markers' on an image. Each placed marker's position/coordinates (x and y) are saved in the field as well as the ID of the ProcessWire page the marker refers to. In the backend markers are placed on a specified base image. In the frontend, using each saved page ID you can then retrieve any information you want about the pages being referenced and display that on your website over the same base image you used in the backend. The module is useful for a diverse number of uses including: Product demonstration: place markers on various parts of your product to showcase its features. Using a bit of CSS and/or JavaScript you can create pop-up boxes displaying more information about that feature of the product. The information (in this case, feature), would be information you've stored in some field (e.g. a text field) in the page marker (i.e. the page being referenced by the coordinates). Office locations: place markers on a map showing global offices of a multinational company Points-of-Interest: place markers showing points of interest on a map or location or anything. The coordinates are saved as percentages. This means they will scale well with the image being marked. This module came about as a result of this request. @credits Ryan Cramer: This code borrows from his FieldtypeEvents. @credits Helder Cervantes: Module concept, HTML, CSS, JavaScript. @credits Roland Toth: CSS, Inspiration. API In the frontend, the field returns an array of ImageMarker objects. Each of these has the following properties info (integer): The page ID of the marker (i.e. the page being referenced by the marker. Using this, you can get the referenced page and have access to all its data. infoLabel (String): The title of the page (above) referenced by the marker (runtime only). x (Integer): The x-coordinate of the marker (%). y (Integer): The y-coordinate of the marker (%). You grab the properties as in any other PW field, e.g. $out = '<img src="'. $page->base_image->url . '" alt="">';// image to place markers on 'base_image' is the name of the file field foreach ($page->marker as $m) { // do something with the following properties $m->id;// e.g. $pages->get((int) $m->id); $m->x; $m->y; $m->infoLabel; } // the CSS and HTML are up to you but see InputfieldImageMarker.module for examples Frontend implementation is left to you the developer/designer

I'd like to create field that renders runtime markup (=custom PHP snippet) in page edit interface. E.g. smth like combination of FieldtypeConcat (for runtime calc) with Inputfield (that holds PHP snippet). My own attempts to do this failed so far.) Being new in module development I can't figure out how&where to save PHP snippet and how to load it... w/o damaging smth...) E.g. should I create table? or dbScheme? where field settings are saved? please help. Thanks! Pleae have a look at what I've coded so far: https://github.com/valieand/FieldtypeRuntimeMarkup

thanks @bernhard, yes I noticed that later on. I managed to get the module to serve my needs, it's here: https://github.com/dtjngl/MenuAllocator I (re)watched your hook-tutorial, it's interesting but I doubt it can help me in this very use-case since I do not really populate fields on the page and the fields in question are rendered at runtime (by a another hook), so I had a hard time saving the values to the page (luckily there's ->meta). I'm not sure if this is the best approach but it works. @everyone, please give it a try, I'd love to get feedback.

Hi @Robin S apparently i'll need some more knowledge from you, running into a new little issue i have a template to generate a block, let's call it a push there is again an image depending of the type of push and i call it this way (the way you teached me ? ) $image = $page->getFormatted('square_fr'); if i put an image in the field, everything goes fine if ever i save the page forgetting to fill this field, impossible to add it afterwards and save again, the field stays desesparatly empty and doesn't save my image, no matter the type of condition i try before getting this image if i remove the runtime field from the template, i can put an image and save it again it works; i'm sure i've missed something but honesty i can't find out what, i looks like the runtime field has also an impact on the whole admin page and prevents the image field from working once the page is saved with an empty field any idea would be very welcome ? have a nice day

As far as I know (and I haven't used this feature yet!) this should be possible (found here: https://processwire.com/modules/rock-frontend/) You can make use of the addIf() function to load a script only under special circumstances. Adding assets to your site (JS or CSS) While you can always add custom <script> or <link> tags to your site's markup it is recommended that you use RockFrontend's AssetsArray feature: $rockfrontend->scripts() ->add('/path/to/your/script.js') // you can add any custom flags to your $rockfrontend variable at runtime! ->addIf('/path/to/foo.js', $rockfrontend->needsFooScript) ->addIf('/path/to/slider.js', $page instanceof HomePage) ->addIf('/path/to/blogscript.js', $page->template == 'blogitem') ; $rockfrontend->styles() ->add(...) ->addIf(...) ; There are several reasons why this is preferable over adding custom script/style tags: addIf() keeps your markup file cleaner than using if / echo / endif It automatically adds timestamps of files for cache busting You can inject scripts/styles from within other files (eg PW modules) RockFrontend itself uses this technique to inject the styles and scripts necessary for frontend editing (ALFRED). Have a look at the module's init() method!

Oh, specifically for the console. I believe I experienced this once as well. Will try to be more attentive. Hasn't happened since. I am not using any Rock modules currently, though since it's only happened once to me I would lean more toward PC performance over module in my instance. Have you tried a different browser just to see if it's primarily a Chrome (on Mac?) thing? Safari / Firefox... If you have access to a Windows or ChromeOS box, maybe try Chrome there too? Chrome has a task manager. When you notice the issue - assuming you've reduced your Chrome tabs to just the one (?), does the task manager give any additional insight? Similarly, Chrome's DevTools offers a runtime performance monitor (not the same thing as is shown in the above photo)... Just some things to look into.

The biggest difference is that Robi's module uses php files while Kongondo's module saves the php code into the database so you need to code in the admin. I used them both, so I recommend Robi's module. I have already switched sites from Runtime Markup to Runtime Only. These are possibilities for sure (BWT, I do not think Ivan is afraid of writing code so why the sarcasm?), but what a simple buildFormContent hook will not do for us is being able to use the rendered output anywhere where an Inputfiled can be used (in a Lister or a ProField Table, etc, for example). So we are comparing apples to bananas if we compare inputfields to code running in hooks. ;) Both can be valid options, we decide what to use depending on the requirements, of course.

I need several fields that will be calculated at runtime like Concat but (a) based on PHP code (b) it should be visible & locked in admin UI. I'd also use this filed in custom Listers. Example - "total price" which is calculated based on some logic and fields inside "order" page as well as fields outside of the page. Should I develop new Fieldtype? Or there is something ready to use in PW 2.5?

Q: see topic title As far as I understand there should be at least two ways: - kind of locked Textarea/CKEdit field that is filled with markup being generated from PHP snippet when page is opened in edit mode - some kind of hook that injects markup into the edited page in right place I've checked available modules but haven't found the answer. If this kind of Q has been addressed somewhere before, I would be glad to hear about it!

@da² This way of processing a form with the process() method was introduced in PW 3.0.205, so 3.0.210 would have been the first main/master version to support it. The method wasn't present in 3.0.200, so I'm thinking most likely you were using the processInput() method instead? (example here). But it may not matter, as the process() method is just a front-end to the processInput() method to provide a more convenient API usage, as it returns a true or false as to whether the form was processed without errors. But that distinction is significant for your example. It assumes processing the form is a one-time thing and that you aren't going to manually add errors to the form once it has successfully processed, as identifying errors is part of processing. In your case, you are doing a secondary validation manually, adding errors after the form has processed. That's new to me, but if you find it useful then I'm all for supporting it. With regard to "forever cache", the cache is a request cache, not a forever cache. It is a runtime memory-only cache for the one current request, as presumably the same exact form instance won't be processed multiple times in the same request (or at least shouldn't be). The reason for the cache value is that it has to recursively iterate through every single Inputfield in the form to ask each whether it had any errors. For a large form, it can be enough overhead to warrant caching that information, as the method may get called multiple times in the request and have to repeat the same task. But is it worthwhile enough? Maybe not, given your use case. I'll look into dropping it. When you set an error, it will remain in the session until it is displayed. This is because redirects are often involved in forms, in order to prevent re-post by re-load. Form errors would be lost if they weren't remembered until used. This is because the process() method determines if there are errors and returns true (no errors) or false (errors). The processInput() method does not tell you that information and so you'd have to check for errors manually afterwards. So your first example is checking for errors BEFORE you have manually added an error to it (which is what the process method does, and sets that cache), while your second example checks for errors AFTER you have manually added an error. This is why the results are different. Unrelated, but I recommend putting "<?php namespace ProcessWire;" (or any namespace) at the top of your template file, OR setting $config->templateCompile = false; in your /site/config.php file, just so that PW doesn't attempt to unnecessarily compile your template files. Maybe you are already doing this, but just mentioning it just in case.

So I guess you are calling $page->save() somewhere in that endpoint, right? In that case you can just add whatever runtime property you want to that page and then use that as a flag in your hook: <?php // api endpoint ... $page->isFrontendSave = true; $page->save(); // hook, eg in init.php $wire->addHookAfter("Pages::saveReady", function($event) { $page = $event->arguments(0); if($page->isFrontendSave) { // do something } else { // do something else } });

Hi all, I am listing a gallery of products and each product, there is the possibility of seeing a rapid or enter the product and see it in detail view. I have the following structure /products/product-a and would like to pass on to the product in a segment to display quick view /products/product-a/quick-view There any way to use another template in runtime? Thanks

Runtime-only fields and/or the dashboard module may also be helpful.

I'm glad you asked this! This should be pretty much a drop in replacement. The only thing you'd have to do to upgrade to the new version would be setting the language associations again and transfer any settings (like global excluded strings and API key) in the module config. Upgrading later will not cause any loss of website content and the work for developers should be minimal. The new features are implemented behind the scenes, so you just get more cool stuff ?. ProcessWire makes it possible to change editors between TinyMCE and CKEditor without re-creating the field, so using CKEditor editor now and then switching to TinyMCE later shouldn't cause any headaches. It really should be as easy of a transition as you can get with how well TinyMCE is concurrently being implemented (props to @ryan). As for the module, Fluency doesn't care what field/editor you use or if it's changed at any time because fieldtypes are detected and initialized by JS at runtime when the UI loads, not on the back end. So good news- I don't believe that there is anything that keeps you from using Fluency now and upgrading later. I've been working regularly on the module lately, my goal is this month or next. I think a wildcard will be testing but I'll be requesting help from the community here when it's time. I want this version to be the one that breaks out of alpha. Many thanks and I'll report back here when I have updates.

I use RockFinder together with runtimemarkup-module https://processwire.com/modules/fieldtype-runtime-markup/ to display various page-data in the backend for the content-superusers. There are also some tables in the database that are non-processwire-tables, which I would like to display with RockFinder (if it is possible?). There is my code in the markup-field (it is working): $modules = $this->wire()->modules; $rockfinder = $modules->get("RockFinder3Master"); $rf = $rockfinder->find("template=categories")->addColumns(['id', 'title', 'created']); ob_start(); $rf->dump(); $result = ob_get_clean(); return (string)$result;

Media Manager Released 31 March 2016 https://processwireshop.pw/plugins/media-manager/ Documentation http://mediamanager.kongondo.com/ As of 10 May 2019 ProcessWire versions earlier than 3.x are not supported ******************************************************* ORIGINAL POST ******************************************************* API Example (frontend; will be added to documentation site) Accessing and outputting the contents of the MediaManager field(s) in your template is quite simple. The fields are accessed like many other ProcessWire fields. The fields return an array of type MediaManagerArray that need to be looped to output each media within. Assuming you created a field of type MediaManager named 'media', you can loop through it for a given page as shown below. @note: Each MediaManager object has the following 5 basic properties: DATABASE (saved properties) 1. id => pageID of the page where the media lives (hidden in admin and not important to know about) 2. type => integer denoting media type (1=audio; 2=document; 3=image [for variations this will be 3x, where x is the number of the variation of an original image]; 4=video) RUNTIME 3. typeLabel => user friendly string denoting media type (audio, document, image, video) 4. media => a ProcessWire Image/File Object including all their properties (ext, filesizeStr, height, width, description, tags, filename, basename, etc.) 5. title => title of media (@note: this is the title of the page where the media lives; may or may not be the same as the name of the media file itself). This can be used as a user-friendly name for your media $media = $page->media;// returns a MediaManagerArray. Needs to be looped through foreach ($media as $m) { echo $m->id;// e.g. 1234 (hidden page in /admin/media-manager/media-parent/) echo $m->type;// e.g. 3 (a media of type image) OR 1 (a media of type audio) echo $m->typeLabel;// e.g. 'document' (i.e. type would be 2) echo $m->title;// e.g. 'My Nice Trip' (whose media file could be my-nice-trip.mp4) /* @note: - $m->media returns an object; either a ProcessWire Image (for image media) or File object (for audio, document and video media) - This means you have access to all the properties of that object, e.g. ext, tags, description, url, filename, basename, width, height, modified, created, filesize, filesizeStr, etc as well as associated methods, e.g. size() */ echo $m->media->tags; } // only output images foreach ($media as $m) { if($m->typeLabel =='image') { echo "<img src='" . $m->media->size(100,75)->url . "'><br>"; } } // There's also a toString() method so you can do: echo $page->media; /* All your media will be output wrapped in appropriate HTML tags, i.e.: audio: <audio></audio>; document: <a></a>; image: <img>; video: <video></video>; */ ******************************************************* ORIGINAL POST ******************************************************* The topic of a central media manager feature for ProcessWire has come up several times: https://processwire.com/talk/topic/4330-get-image-from-other-pages-via-images-field/ https://processwire.com/talk/topic/4330-get-image-from-other-pages-via-images-field/?p=42578 https://processwire.com/talk/topic/4330-get-image-from-other-pages-via-images-field/?p=42582 https://processwire.com/talk/topic/425-file-manager/ https://processwire.com/talk/topic/425-file-manager/?p=13802 https://processwire.com/talk/topic/425-file-manager/?p=13861 https://processwire.com/talk/topic/10763-asset-manager-asset-selector/ More recently, regarding my Visual Page Selector module, I have been asked several times why the module does not have an in-built feature to upload images. There's two camps on the topic of a central media manager: those who like them (especially those coming in to PW from other CMSes) and those who don't like them (primarily because of the chaotic way some CMSes (dis)organise their media management) . I think that we can have our cake and eat it too! If done the right way, closely following the principles of and harnessing the power of ProcessWire, we can have a well-implemented, organised, feature-rich, site-wide media manager. Introducing Media Manager: (a commercial module) Alongside a number of modules I am currently working on (both free and commercial), I have been developing a centralised Media Manager for ProcessWire. Before you cast the first stone, no, this is not going to be a one-large-media-bucket as in other CMS where it gets very messy very quickly . In the backend things are neatly stored away, yes, in pages. However, those are pages you will not see (just like repeater pages). Before anyone has a go at pages, remember a page is not that thing you see on the ProcessWire Tree (that's just its visual representation); A page is a record/row in the database . For the end-user of Media Manager, all they will see is the 'familiar media bucket' to select their media from. As long as it works efficiently, I don't think they care about the wizardry behind the scenes . The module allows for the comprehensive management of several media types: Audio Video Images Documents Each media type will be handled by its own sub-module so the user can pick and install/choose the type of media management they want. Features include: Access controls Centralized uploads of media Bulk management of media: tag, delete, describe, replace, etc. Bulk upload: zip; scan, single Quick upload in page edit mode Usage stats across pages (maybe?) Etc.. Would love to hear your thoughts and any feature suggestions. I think there's enough demand for such a module. If not, please let me know so that I can instead focus on other things , thanks. How other CMS do it The more efficient (PW) way of doing it

I always start from scratch when it comes to creating the fields and templates, and basic site structure, but rarely when it comes to the pages/content. On previous conversions I've gone into WP’s database and exports to migrate content. This new case is a little bit unique in that WordPress couldn't do everything they needed, at least not in a manner that was affordable or reasonable to implement, from what I understand. While some of the content is in WP, other content is coming from authenticated web services. Lots of the pages have some content, custom fields and repeatable blocks in WP, but there are also custom fields with IDs for external services that it pulls other content from at runtime. They are paying a couple other companies quite a bit of money every month to host their content through these web services and make it searchable. They pull from those services at runtime and output it all from the WP templates. It strikes me as really inefficient, but it all works fine and you'd never know it from the front-end. But it's also expensive for them and fragile to have these kinds of external dependencies, not to mention a pain to have to manage content (even for the same page) across different services. This is all stuff that ProcessWire does well on its own, so none of those external services are needed on the new site. Since the front-end of the site is already compiling them all into single-page output, I built a scraper to pull it directly from the existing site and put it into the right places in ProcessWire. Scraping might seem like a last resort, but in this case it was the fastest, most direct way to pull everything out since the content is split among different databases and services. Basically using WP as an adaptor for the services it is pulling from. Luckily I can edit the WP templates to modify the markup (adding wrapping tags or custom html id attributes, etc.) where needed make the scraper relatively simple. @MarkE

Hi y'all! ? long time no hear (and it's all my fault - I haven't been to the forums for quite a while). Anyway, I got a complex question that as of right now, feels way above my skills. But I'll try to describe it, and I'm hoping to describe things in a way that's comprehensible: As it reads in the title, what's in front of me is a complex situation and a codebase I inherited. In its core, its about dynamic sorting. With dynamic sorting I mean two things: The field being sorted by is depended on user input AND a programmatical determined decision. More details follow below It's not as simple as sorting by `created_at`, for example. So I got a collection of templates in a PageArray. All of the items are being output using a loop (paginated, and so on). So far, so simple. Every item of this collection is of the same template. This template has a bunch of fields associacted with it, with numeric values. Let's simplify the situation for the sake of explaining and say that these fields can be grouped into certain clusters. In a template, a user can filter for certain (by using selects, which, upon change, change the URL). So that every filtered state is accessible unter its own URL. A user also has the opportunity to sort, and this is kind of where the field clusters come into play. Also, the selected sort mode is persisted in the URL, by a get parameter, for example ?sort=cluster1. Of course, both filter states and sort states are "mirrored" in the URL, so that every of these states can be accessible under its own URL. Going back to point 3: for all of the fields (in the clusters) there is a field counterpart which stores the inverted value of the field (in reality, this isn't the inversion but something more complicated - but for the sake of explaining, I'll describe it that way) Now, based on both sorting and filter settings (see 4. and 5.) a decision must be made whether the non-inverted or the inverted field should be used for sorting the whole connection. My questions: How would you solve this? My plan for today is to do a little proof of concept with runtime fields: Right after I got the user data regarding sorting and filtering I have all the data I need to decide whether to use a field or its inverted counterpart for sorting. I'm planning to create runtime fields in which I store the "decision" I'm now able to make (which value, the original or inverted field value I should use for sorting). The central query of getting the PageArray, filtering and sorting it is a rather complex one. In the code I inherited this query is built by modifying a large string that consists of data from the interface (regarding filtering and sorting). Only after every user settings is "read" this string gets passed as a rather sophisticated selector into a $page→find($complexQuery) API call. While experimenting I found out that it appears that runtime fields are not really considered in this approach (but maybe I'm doing things wrong). Should I instead leave the approach of trying to build it with the API and go for building a raw DB query instead? Is there an simple and obvious solution to the problem I described that I'm not able to see? Anyway, thanks a bunch! marcus