Search the Community

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

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

You can use https://processwire.com/modules/fieldtype-runtime-markup/ for that.

I didn't want to say that this is a limitation. Actually it is an enhancement to have this functionality at runtime ? Just wanted to make sure that I'm on the right track with defining fieldsets and their fields in my migrations. Will definitely give the runtime approach a try. Thank you.

Hey @gebeer working with fieldsets in migrations has always been a bit of a pain for me. That's why I'm using them only at runtime in all of my projects. I don't see any drawback with this. Using MagicPages it is as simple as doing this: <?php ... public function editForm($form) { ... $rm->wrapFields( // current form wrapper $form, // fields inside the fieldset [ 'foo' => ['columnWidth'=>33], 'bar' => ['columnWidth'=>33], 'baz' => ['columnWidth'=>33], ], // fieldset settings [ 'label' => 'Your Runtime Fieldset', 'icon' => 'bolt', ] ); } This is a lot quicker than messing around with fields, field order, moving the ending field to the correct place etc. I only place the fields on the correct template, which is necessary for the fields to be queryable by selectors etc and all the rest is done in code in the pageclass. That also makes it possible to switch layouts based on the user's role for example. So the approach is very powerful. I don't see that as a limitation. Or are there any things that I'm missing?

I'm not sure I understand ... For one request you can store your variable wherever you want (and where it is allowed), for example you can set $config->foo = "Foo!" somewhere and later you can access that runtime property. On the next request $config->foo will be null again unless you set it somewhere. Until PHP8.2 it was possible to use $wire for that as well, eg $wire->foo = "Foo!", but since PHP8.2 setting dynamic properties is deprecated.

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

I've done some searching for an answer on this as I can't believe it has not come up before: My problem is that I would like to use a "selector" field (i.e. the interactive selector builder) to compare, for example, a datetime field with 'today'. The issue is that I want it to operate dynamically, so the comparator needs to be stored as 'today' and only converted when the selector is run. This works fine if I just use a text field instead of the selector field and allow the user to input a selector string - e.g. "myDatetime>today", but in the selector builder the comparison field requires an absolute date - a string entry of a relative date is impossible. However, for many reasons, I would prefer not to have a user attempting to enter a selector string. Has anyone tried something similar? If not, I'm toying with the idea of writing a module to extend InputfieldDatetime. That would permit the storing of a valid string as well as an actual date. The string would be only converted to a date at runtime. This would allow entering a date as, for example, 'last month' such that when the field is formatted it would be displayed as a date one month before the execution date. This contrasts with the present module where, although you can default to 'today', I think that is converted to a timestamp at the time of entry and stored as such. Any thoughts on that?

On the dev branch this week we have a good collection of issue fixes and feature requests. The dev branch commit log has all the details. One feature added this week which I think could come in very handy is #520 (via @Jonathan Lahijani) which adds the ability to hide individual images in an images field. When an image is hidden, you can see and work with it in the admin, but it gets removed from the field value on the front-end of the site at runtime, effectively hiding it. I know I'll use this a lot, particularly on photo galleries where I may want to remove an image or two from appearing in the grid of photos, but don't necessarily want to delete them. Images can be hidden (or unhidden) from the Actions select of each image, where you'll see a "Hide" option (or an "Unhide" option if the image is already hidden). Hidden images are also dimmed out when viewing the images field in the admin. On the API side, you can hide or unhide images and files using $image->hidden(true) to hide, $image->hidden(false) to unhide, and $image->hidden() to get a true or false as to whether or not the image is hidden. Though this will only be useful on unformatted field values, since hidden images are automatically removed from formatted field values. The same can be used with regular file fields, but we don't currently have a UI/interface for hiding or unhiding items from regular (non-image) file fields. Likely we'll add one soon, but I figured it's likely to get more use with image fields than file fields, so figured we'd start there. More next week. Thanks for reading and have a great weekend!

This is my approach to combining CSS files for improved page speed. The implementation is straightforward; you only need to add one PHP file to your server and make a few tweaks. My setup: -site/ -templates/ - inc/ - styles/ _init.php Include the CombinedCSS.php file at the top of my _init.php: include_once('./inc/CombinedCSS.php'); _main.php Add the following to the <head> section: <?php $cssFiles = [ paths()->templates . 'styles/uikit.min.css', paths()->templates . 'styles/uikit.ext.css', paths()->templates . 'styles/main.css' ]; echo CombinedCSS::CSS($cssFiles); ?> CombinedCSS.php <?php namespace ProcessWire; /** * Import the RuntimeException class for throwing runtime exceptions. */ use RuntimeException; /** * Class CombinedCSS * * A class for combining and minifying CSS files and generating a link tag for the combined CSS. */ class CombinedCSS { /** * @var string|null The output directory for saving the combined CSS file. */ private static $outputDirectory; /** * @var string|null Hash of the concatenated content of CSS files. */ private static $filesHash; /** * Initializes the output directory if it is not already set. */ private static function initOutputDirectory() { if (!isset(self::$outputDirectory)) { self::$outputDirectory = paths()->templates . 'styles/'; } } /** * Checks if a directory is writable. * * @param string $directory The directory path to check. * @return bool True if the directory is writable, false otherwise. */ private static function isWritableDirectory($directory) { // Check if the directory exists if (!is_dir($directory)) { return false; } // Check if the directory is writable if (!is_writable($directory)) { return false; } return true; } /** * Combines and minifies an array of CSS files. * * @param array $files An array of CSS file paths. * @return string The combined and minified CSS content. */ private static function combineAndMinifyCSS(array $files): string { $combinedCss = ''; foreach ($files as $file) { // Read the content of each CSS file $cssContent = file_get_contents($file); // Minify the CSS content (you can replace this with your preferred minification logic) $minifiedCss = self::minifyCSS($cssContent); // Append the minified CSS to the combined CSS content $combinedCss .= $minifiedCss; } return $combinedCss; } /** * Minifies CSS content. * * @param string $css The CSS content to be minified. * @return string The minified CSS content. */ private static function minifyCSS(string $css): string { // Replace this with your preferred CSS minification logic // Example: removing comments, extra whitespaces, etc. $minifiedCss = preg_replace('/\/\*.*?\*\//s', '', $css); $minifiedCss = preg_replace('/\s+/', ' ', $minifiedCss); return $minifiedCss; } /** * Generates a unique filename for the combined CSS file based on the provided file paths. * * @param array $files An array of CSS file paths. * @return string The generated combined CSS filename. */ private static function generateCombinedFilename(array $files): string { return md5(implode('', $files)) . '.css'; } /** * Saves the combined CSS content to a file. * * @param string $filename The filename for the combined CSS file. * @param string $content The combined CSS content to be saved. * * @throws RuntimeException If there is an error writing the file to disk. */ private static function saveToFile(string $filename, string $content): void { // Save the combined CSS content to the specified file $filePath = self::$outputDirectory . DIRECTORY_SEPARATOR . $filename; if (file_put_contents($filePath, $content) === false) { $error = error_get_last(); $errorMessage = isset($error['message']) ? $error['message'] : 'Unknown error'; throw new RuntimeException('Failed to write the combined CSS file to disk. Error: ' . $errorMessage); } } /** * Generates a link tag for the combined CSS file based on the provided file paths. * * @param array $files An array of CSS file paths. * @return string The link tag for the combined CSS file. * @throws RuntimeException If the output directory is not writable. */ public static function CSS(array $files): string { // Initialize the output directory self::initOutputDirectory(); // Ensure the output directory is writable if (!self::isWritableDirectory(self::$outputDirectory)) { throw new RuntimeException('The output directory is not writable.'); } // Combine and minify CSS files $combinedCss = self::combineAndMinifyCSS($files); // Check if the files have changed by comparing their hash $currentFilesHash = md5($combinedCss); $combinedFilename = ''; if ($currentFilesHash !== self::$filesHash) { // If the files have changed, generate a unique filename for the combined CSS file $combinedFilename = self::generateCombinedFilename($files); // Save the combined CSS content to a file self::saveToFile($combinedFilename, $combinedCss); // Update the files hash self::$filesHash = $currentFilesHash; } else { // If the files have not changed, check if the file exists on disk $combinedFilename = self::generateCombinedFilename($files); $filePath = self::$outputDirectory . DIRECTORY_SEPARATOR . $combinedFilename; if (!file_exists($filePath)) { // If the file doesn't exist, save the combined CSS content to a file self::saveToFile($combinedFilename, $combinedCss); } } // Return the link tag return '<link rel="stylesheet" href="' . urls()->templates . 'styles/' . $combinedFilename . '">'; } } Notes: Ensure that you have writing permissions for the $outputDirectory location. The combined CSS file will be generated and saved only if the files have changed or if the file doesn't exist on disk. The order of the combined file will adhere to the sequence specified in the array. Modify the hardcoded paths based on your requirements. Any suggestions for improvements are welcome! Cheers!

Hi all, I have a situation in which a user can upload a file that's any one of a number of formats (pdf, mpg, jpg, etc.). If the file is an image, I want to do some resizing. However, when I call ->size(###,###) on the file field when an image is in it, I get an error. Makes sense. I'm hoping there's an easy way to solve this without needing to create a separate field for image uploads. I tried following @Soma's advice from this thread, but kept getting an error from ImageSizer saying I was passing in invalid format. I know the file in there is an image as it's getting displayed in the browser. So, is there a standard way to convert a File field to an Image field? Thanks.

Fieldtype modules Not really a tutorial, but a bunch of stuff I learnt in building a fieldtype module (FieldtypeMeasurement). That module is used as a starting point for many of the examples. Happy to take corrections and improvements ? Basics For a (full-featured) module, you actually need two module files: FieldtypeModuleName.module; and InputfieldModuleName.module The Fieldtype module defines the general settings for the fieldtype (how it appears in the setup->field page), together with how it interacts with the database, while the Inputfield module defines how the field appears when editing it in a page. In addition, for complex fields, you can define a class to hold your field values in an object. This allows you to provide custom methods for use in the API. Otherwise you can store field values as any existing type or ProcessWire object The chart below summarises the interactions of these elements and the subsequent sections describe the methods in more detail. Fieldtype Module The important methods are described below. __construct() Generally not much is required here (apart from parent::__construct();). If you have a php script with the field object then include it (require_once() ). SQL database interaction getDatabaseSchema(Field $field) This is essential. It states what data will be saved to the SQL database (via the sleepValue function - see below). An example is: public function getDatabaseSchema(Field $field) { $schema = parent::getDatabaseSchema($field); $schema['data'] = 'double NOT NULL'; // value in base units $schema['magnitude'] = 'varchar(64)'; // value in current units - needs to be text to store composite values $schema['unit'] = 'text NOT NULL'; $schema['quantity'] = 'text NOT NULL'; return $schema; } 'data' is required and is a primary key field which means that 'text' cannot be used, although varchar(64) is OK. Often (as here) it would be a numeric field of some type. Other items can be defined as required. ___sleepValue(Page $page, Field $field, $value) This determines how the ProcesssWire field object is mapped to the SQL schema. You need to return an array where the keys are the elements defined in the schema, e.g.: $sleepValue = array( 'data' => $data, 'magnitude' => $magnitude, 'unit' => $value->unit, 'quantity' => $value->quantity ); return $sleepValue; ___wakeupValue(Page $page, Field $field, $value) This is basically the inverse of sleepValue - mapping the array from the database into the field object. In the example below, the field object (Measurement) extends WireData. Properties in WireData objects can be stored in the 'data' property via 'get' and 'set' methods. getBlankValue() (see next section) performs the initial setting of these - config values for the field (see below) can be set, but otherwise the settings are just placeholders. Properties set to a WireData object can also be set or accessed directly, like $item->property or using array access like $item[$property] public function ___wakeupValue(Page $page, Field $field, $value) { // if for some reason we already get a valid value, then just return it if($value instanceof Measurement) return $value; // start a blank value to be populated $measurement = $this->getBlankValue($page, $field); // if we were given a blank value, then we've got nothing to do: just return a blank Measurement object if(empty($value) || !is_array($value)) return $measurement; // create new Measurement object $measurement->quantity = $value['quantity']; // ... custom processing ... $measurement->baseMagnitude = $value['data']; if($value['unit']) { $measurement->unit = $value['unit']; $units = $measurement->getUnits(); if(array_key_exists($value['unit'], $units) && isset($value['magnitude'])) { $measurement->magnitude = explode('|', $value['magnitude']); } else { $measurement->magnitude = $measurement->baseMagnitude; $measurement->unit = $measurement->units->base; $this->error('... error msg ...'); } } else { //... } if(!is_array($measurement->magnitude)) $measurement->magnitude = [$measurement->magnitude]; return $measurement; } getBlankValue(Page $page, Field $field) This should return an empty item of the appropriate type. For instance, if your field object is an array, just return array(); If the field type is an object then you will need to return a 'new ObjectClassName()'. Pre-fill any config values from the Fieldtype settings but leave blank those which are set in the Inputfield, In the above example, the field object data was set as follows: public function getBlankValue(Page $page, Field $field) { /* @var $field FieldtypeMeasurement */ $measurement = new Measurement($field->quantity, null, []); if ($field->quantity) $measurement->set('quantity', $field->quantity); $measurement->set('magnitude', []); $measurement->set('shortLabel', null); $measurement->set('plural', null); return $measurement; } If your object has configurable fields that can be modified according to context (as defined in getConfigAllowContext() - see below), then you will need to deal with this in getBlankValue too, e.g. : public function getBlankValue(Page $page, Field $field): Measurement { //NB Field details may differ between templates so we need to get the field in context $context = ($page && $page->id) ? $field->getContext($page->template) : $field; ... $measurement = new Measurement($context->quantity, null, []); ... return $measurement; } But note that this does not completely deal with the situation where the field is in repeater matrix items where the types might have different contexts - there you might need: public function getBlankValue(Page $page, Field $field): Measurement { //NB Field details may differ between templates so we need to get the field in context $context = ($page && $page->id) ? $field->getContext($page->template) : $field; ... // if($page instanceof RepeaterMatrixPage) { // This does not always work - see edit note if($page->template->pageClass == 'RepeaterMatrixPage') { if($page->getField($field->name)) { $context = $page->fieldgroup->getFieldContext($field, "matrix$page->repeater_matrix_type"); } } ... $measurement = new Measurement($context->quantity, null, []); ... return $measurement; } See this post for more details. Configuration ___getConfigInputfields(Field $field) This defines how the Details tab in the field setup page will look. The best thing to do here is to find a fieldtype module that is similar to the one you want if you are uncertain. Broadly the process is: define the config object - $inputfields = parent::___getConfigInputfields($field); for each config item, use the appropriate input field, e.g . $f = $this->modules->get("InputfieldSelect"); assign the relevant attributes. $f->name = $f_name; is important as it enables the item to be subsequently referred to as $field->f_name in, for example, getBlankValue(). append each item ($inputfields->append($f);) and return $inputfields; ___getConfigAllowContext(Field $field) This determines if the above input fields are allowed to have unique values per Fieldgroup assignment enabling the user to configure them independently per template in the admin, rather than sharing the same setting globally. E.g. public function ___getConfigAllowContext(Field $field) { $a = array('quantity', 'units', 'hide_quantity', 'show_update'); return array_merge(parent::___getConfigAllowContext($field), $a); } In this example the settings 'quantity', 'units', 'hide_quantity' and 'show_update' can be varied in different template contexts. Link with the Inputfield module This is done with getInputfield(Page $page, Field $field) e.g.: public function getInputfield(Page $page, Field $field) { $inputfield = $this->wire('modules')->get('InputfieldMeasurement'); $inputfield->setField($field); return $inputfield; } If you want to reference the current page in the inputfield, you will also need to include $inputfield->setPage($page); If your fieldtype is an object and you want full context flexibility including for different repeater matrix item types, then you may need to use this: public function getInputfield(Page $page, Field $field): Inputfield { $inputfield = $this->wire('modules')->get('InputfieldMeasurement'); if($page->template->pageClass == 'RepeaterMatrixPage') { if($page->getField($field->name)) { $field_in_context = $page->fieldgroup->getFieldContext($field, "matrix$page->repeater_matrix_type"); if($field_in_context) { $field = $field_in_context; } } } $inputfield->setField($field); $inputfield->setPage($page); return $inputfield; } Inputfield Module __construct() Generally not much is required here (apart from parent::__construct();). If you have a php script with the field object then include it (require_once() ). Configuration ___getConfigInputfields() This is pretty much exactly the same construction as the similar method in the Fieldtype class. The only difference is that these settings will appear in the 'input' tab of the fieldtype settings, rather than the 'details' tab. ___getConfigAllowContext(Field $field) This is the equivalent to the Fieldtype::getConfigAllowContext() method, but for the "Input" tab rather than the "Details" tab. Input and output The key methods for this module are to render it from the fieldtype and database and to process the user inputs. ___render() $field = $this->field will have the field config settings from the fieldtype module. $this->attr('value') will have the current values for the field. If there is no current values then, if using a field object, you will need to create a new object, e.g.: if($this->attr('value')) $value = $this->attr('value'); // Measurement object else { $value = new Measurement(); } You can then use $field and $value to display the inputfield (which might be a fieldset) as required using the appropriate pre-existing inputfield modules. (Again, find an existing module that is similar, if you are uncertain). renderValue() This is required where the field is locked (not editable) and therefore render() does not apply. Get the value with $value = $this->attr('value'); and then apply the required formatting, returning the output string. ___processInput(WireInputData $input) Here you take the inputs and update the field values. As in render(), set $value = $this->attr('value') ; and then modify $value for the inputs. For example, set $name = $this->attr('name'); and then assign the inputs thus: $input_names = array( 'magnitude' => "{$name}_magnitude", 'unit' => "{$name}_unit", 'quantity' => "{$name}_quantity", 'update' => "{$name}_update" ); You can then loop through the inputs and carry out the required updates. The example below is slightly convoluted but illustrates this: foreach($input_names as $key => $name) { if(isset($input->$name) && $value->$key != $input->$name) { if($key == 'magnitude') { $input->$name = trim($input->$name); if(!is_numeric($input->$name)) { $magnitude = explode('|', $input->$name); $magnitude = array_filter($magnitude, 'is_numeric'); $value->set($key, $magnitude); } else { $value->set($key, [$input->$name]); } } else { $value->set($key, $input->$name); } $this->trackChange('value'); } } When all is done, return $this; Custom classes As mentioned earlier, for complex field types it may be useful to set up custom classes to hold the data. Typically a custom class would extend WireData, which is ProcessWire's class designed for runtime data storage. It provides this primarily through the built-in get() and set() methods for getting and setting named properties to WireData objects. The most common example of a WireData object is Page, the type used for all pages in ProcessWire. Properties set to a WireData object can also be set or accessed directly, like $item->property or using array access like $item[$property]. If you foreach() a WireData object, the default behaviour is to iterate all of the properties/values present within it. Do not declare any such properties in your class (or declare properties with the same name) otherwise you will end up with two properties, one in the 'data' array and one outside it and endless confusion will result. It is advisable to put any such classes in your own namespace. In that case, you will need to include 'use' statements in your script - e.g. use ProcessWire\{FieldtypeMeasurement, WireData}; use function ProcessWire\{wire, __}; and also include use statements in your module scripts, e.g. use MetaTunes\MeasurementClasses\Measurement;

Hi @Robin S. The module is really neat and I've forked and hacked it a couple of times to simplify it for use in my own modules (with accreditation!). I came across an interesting feature of PW recently regarding Page Table fields. If I create a Runtime field and include it as a column in a PageTable field, I do not need to include it in any of the templates managed by the Page Table field (assuming it is only needed to display in the Page Table field). This is a really handy way of providing useful information in the Page Table listing and saves a bit of effort, especially if there are lots of templates. However, the js and css is not then automatically picked up. I fixed this by moving the code in InputfieldRuntimeOnly::renderReady() to FieldtypeRuntimeOnly::renderMarkup() and also moving getPath() and getUrl(). Everything seems to work like this in both the normal (field in template) and novel use. I wondered whether there was a particular reason for putting it in renderReady(), as it would seem more usable in renderMarkup()?

Hi @Robin S, autoload module and init() method doesn't work. I disabled FileCompiler, but still not works. Because it's redirected to http404 before the existing template is set inside of the module. public function init() { $this->log->message("ServiceWorkerJS module autoload"); $template = $this->page->template; $this->log->message("TEMPLATE CURRENT: {$template}"); $file = $this->config->paths->siteModules . $this . '/templates/ServiceWorker.php'; $this->log->message("NEW RUNTIME FILE: {$file}"); $template->filename = $file; $this->log->message("CHECK TEMPLATE RUNTIME FILE: " . $template->filename); //$this->log->message("CHECK PAGE URL: " . $this->page->url()); // DISABLED BECAUSE IT FAILS WITH AUTOLOAD! } The log shows the template change runtime works fine, but it's to late to get the correct and expected page. URL is changed to http404. 2018-06-30 09:23:45 admin http://localhost/pw/serviceworker.js ServiceWorkerJS module autoload 2018-06-30 09:23:45 admin http://localhost/pw/serviceworker.js TEMPLATE CURRENT: 2018-06-30 09:23:45 admin http://localhost/pw/serviceworker.js NEW RUNTIME FILE: C:/xampp/htdocs/pw/site/modules/ServiceWorkerJS/templates/ServiceWorker.php 2018-06-30 09:23:45 admin http://localhost/pw/serviceworker.js CHECK TEMPLATE RUNTIME FILE: C:/xampp/htdocs/pw/site/modules/ServiceWorkerJS/templates/ServiceWorker.php 2018-06-30 09:23:47 admin http://localhost/pw/serviceworker.js ServiceWorkerJS module autoload 2018-06-30 09:23:47 admin http://localhost/pw/serviceworker.js TEMPLATE CURRENT: 2018-06-30 09:23:47 admin http://localhost/pw/serviceworker.js NEW RUNTIME FILE: C:/xampp/htdocs/pw/site/modules/ServiceWorkerJS/templates/ServiceWorker.php 2018-06-30 09:23:47 admin http://localhost/pw/serviceworker.js CHECK TEMPLATE RUNTIME FILE: C:/xampp/htdocs/pw/site/modules/ServiceWorkerJS/templates/ServiceWorker.php Autoload module is loaded twice during one page (re-)load, but page is redirected before the autoload module changes the template. FileCompiler is off (namespace in files, site/assets/cache/FileCompiler/site/modules/* is empty). Correct page should be instead of "serviceworker.js" instead of "http404". So how to prevent redirect to http404 with my autoload module? Where change the template to be early enough to prevent the redirect to http404? Example module need to deliver a serviceworker file to the browser from the root directory. Autoloaded with condition of template works fine. So initial the template is set, module is autoloaded, but page is redirected to http404. 'autoload' => 'template=ServiceWorker', There was a module->get() inside of basic-page. Conditional autoload based on template doesn't work. So I changed it to 'autoload' => true,

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

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.

As part of site development I somethings need to change crop sizes / settings in the codebase after the client has started to add content. This means I can end up with a lot if image variations having been created (and still being used) but with old settings. A good example might be an image variation that was created using a quality of 50 but now the code is set to 100. A new variation is not created under these situations, only if the variation size is changed. So, is there a way to purge all variations leaving the original uploaded image so new variations can be created at page runtime? I have tried the 'PageimageRemoveVariations' module (later v4 version) but that doesn't seem to remove images that are in repeater fields or RepeaterMatrix fields. I'm guessing a solution might have to work at a file level rather than field level? Any help here would be appreciated!

Hello, Maybe this can be a good starting point: https://processwire.com/talk/topic/21756-field-access-on-runtime/?do=findComment&comment=187094

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

Hey @Robin S this is working great so far ? I have one issue when using RockMigration's filesOnDemand feature. That feature hooks into Pagefile::url and Pagefile::filename and if the image does not exist it tries to grab it from the remote server. This is extremely handy when using "rockshell db:pull", because then you have a copy of the remote database on your local dev environment which could have several references to images in the database that do not exist on the filesystem. RockMigrations then downloads those images from the remote server as soon as you visit a page with images that do not exist. This feature can be enabled at runtime by setting $config->filesOnDemand = false; Do you think you can add this to your module to make it work with RockMigrations? Or do you see another way to make it work out of the box? Maybe I can check if the item is in the queue before trying to download it from the remote. See the code here https://github.com/baumrock/RockMigrations/blob/9d9609904647e7b2cfc14a81b2da411edfdca814/RockMigrations.module.php#L2536-L2583 Thx for your thoughts!

Yes. myrace is just an inputfield that we added during runtime. It is not a field of the page, so $page->myrace will not work. But it is an inputfield of the form that is submitted, so the input post data will have that information available and we can use it for our further processing.

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!

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

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?