Robin S

@ryan, thanks for creating this cool module! A couple of questions: 1. Do the subfields have an ID of some sort separate to the name, such that a subfield can be renamed without losing the existing data stored for the subfield? 2. What happens to stored data if a subfield is removed from the defining file? Does the existing data for the subfield persist in the database, or does the fieldtype detect the removal and do some cleanup to remove the stored data? Also, I think there's a typo in the blog post. // multi-selection foreach($page->custom_field->countries as $value) { $label = $page->field->label('countries', $value); echo "<li>$value: $label</li>"; // i.e. "USA: United States" } ...should be... // multi-selection foreach($page->custom_field->countries as $value) { $label = $page->custom_field->label('countries', $value); echo "<li>$value: $label</li>"; // i.e. "USA: United States" }

LogsJsonViewer doesn't do any truncating, and doesn't get involved in the saving of log data at all - it just formats what is already in the log. Your problem might be due to $maxLineLength in FileLog. There's a FileLog::setMaxLineLength() method, but I'm not sure how you could practically use this unless you write to your log file using FileLog::save() instead of the more convenient WireLog::save(). Instead you probably just have to try and avoid going over $maxLineLength if you are saving JSON, perhaps by doing your own truncation on individual values if they are long, before you save the data.

Process Render File A Process module that renders markup from files in /site/templates/ProcessRenderFile/. This provides an easy way to create simple admin screens where it might be overkill to create a dedicated Process module for the purpose. Process page When you install the module a page with the name "render-file" and the title "Render File" is created under Setup. To change the page name or title, expand Page List to Admin > Setup > Render File and open the page for editing. Tip: if you create a new text field with the name "page_icon" and add it to the core "admin" template you can set a custom menu icon for the page by entering the icon name into the field. E.g. enter "smile-o" to use a smiley icon for the page. If you want to use ProcessRenderFile for more than one Process page you can create a new page under Setup. Select "admin" for the template, enter a title for the page, and in the next step choose ProcessRenderFile in the Process dropdown. Render files for URL segments On install the module will create a "ProcessRenderFile" folder in /site/templates/. Any .php files you save to this folder will be rendered as the output of a matching URL segment for Process pages using ProcessRenderFile. For example, if you create a file foo.php containing code... echo "This is the output of foo.php"; ...then you'll see this output when you visit /processwire/setup/render-file/foo/ (assuming the default ProcessWire admin page name and the default ProcessRenderFile page name). In the render file you can use all the ProcessWire API variables like $pages, $input, etc, as you would in a template file. If you create foo.js and foo.css (or foo.scss if you have ProCache installed) then those assets will be automatically loaded when you visit /processwire/setup/render-file/foo/. When a file is rendered the filename will be converted into a capitalised format that's used as a browser title and a headline. If you want to set a custom browser title and/or headline you can do this in your render file: $this->wire('processBrowserTitle', 'Custom browser title'); $this->wire('processHeadline', 'Custom headline'); Render file for the Process page If you create a render file that has the same name as the ProcessRenderFile Process page then this file will be rendered when the Process page is viewed without any URL segment. So for the default ProcessRenderFile page name you would create render-file.php. Note that this will override the default list output described below. Configuration The module configuration screen lets you select URL segment render files to appear as menu items. The selected render files will appear in the flyout menu for the Process page, and also as a list when the Process page is viewed without any URL segment. The list is only shown if you haven't created a render file for the Process page as described above. If you've created more than one ProcessRenderFile Process page then you'll see menu options for each page in the module configuration. https://github.com/Toutouwai/ProcessRenderFile https://processwire.com/modules/process-render-file/

Possible solutions as discussed in this thread... Add a <datalist> to a text field: Text Input Awesomplete: https://processwire.com/modules/text-input-awesomplete/

@Christophe, I can't follow what you're doing so if you have a question specifically about Custom Inputfield Dependencies rather than the core show-if features then please rephrase it and include some screenshots. For now what I can say is: Custom Inputfield Dependencies uses the $pages->find() selector syntax as described in the PW docs. This is a different syntax than the core show-if selectors, so you can't just copy/paste selectors from one to the other. Syntax like "parent.id=1314 || id=1250" and "parent.id=1314 | id=1250" is not valid for $pages->find(). If you want to match one field/value combination OR a different field/value combination then you need to use OR-group syntax: https://processwire.com/docs/selectors/#or-groups And InputfieldSelector (the inputfield used by Custom Inputfield Dependencies for "Show only if page is matched by custom find") doesn't support OR-groups so you would have to use a selector string in "Show only if page is matched by selector". (parent.id=1314), (id=1250)

@soyerH, calling deleteAll() on a single image field is also working for me, so something unusual is going on for you. A couple of ideas... 1. Is the page a "normal" page or is it a User page that involves the alternate template/parent for users feature? Your page path and field name made me wonder this. If it is an alternate user parent/template and you can identify the steps to reproduce the problem please create a GitHub issue for it. 2. Does it work if you set the field value to null instead of calling deleteAll()?

You can use Ryan's ProcessDatabaseBackups module to do this. Export: Import: Without ProcessDatabaseBackups you could use PhpMyAdmin or Adminer to do something similar. If your Hanna codes reference external files (I prefer to use files for my Hanna codes so I can edit them in my IDE) then you would need to copy those to the other site too.

@Christophe, glad you find it useful. Technically you don't need Custom Inputfield Dependencies if you want to show/hide a field according to the parent page ID. The PW core includes a "Parent" field in Page Edit on the "Settings" tab. This field is named "parent_id" so you can do something like this:

@Christophe a module that will help with this:

A module to work around a few shortcomings of Fieldset and FieldsetPage fields. Not submitted to the modules directory because I'm hopeful that most if not all of this will be handled in the core eventually. https://github.com/processwire/processwire-issues/issues/1953 https://github.com/processwire/processwire-requests/issues/533 https://github.com/processwire/processwire-requests/issues/534 Fieldset Helper Adds some visibility features to fields of type FieldtypeFieldsetOpen and FieldsetPage, and adds a helper method to get the child fields of a FieldtypeFieldsetOpen field. Visibility The module adds support for the following visibility settings to FieldtypeFieldsetOpen and FieldsetPage fields: Open when populated + Closed when blank Open when populated + Closed when blank + Load only when opened (AJAX) * Open when populated + Closed when blank + Locked (not editable) Open when blank + Closed when populated "Blank" in the context of a fieldset means that all the child fields within the fieldset are blank. * The AJAX part of this option doesn't currently work for FieldsetPage. Get the child fields of a fieldset If you've ever wanted to get the child fields that are within a fieldset you will have noticed that the ProcessWire API doesn't provide a direct way of doing this. Although they appear indented in Edit Template, the child fields are actually all on the same "level" as the other fields in the template. The module adds a FieldtypeFieldsetOpen::getFieldsetFields() method that you can use to get the child fields of a fieldset for a given page. Example: $field = $fields->get('my_fieldset'); $template = $templates->get('my_template'); $fieldset_fields = $field->type->getFieldsetFields($field, $template); First argument: the fieldset Field, i.e. a Field whose type is an instance of FieldtypeFieldsetOpen (this includes FieldtypeFieldsetTabOpen). Second argument: the Template that the fieldset field is part of. Return value: a FieldsArray of child fields. If there is a nested fieldset inside the fieldset then the child fields of the nested fieldset are not included in the return value, but of course you can use the method again to get the child fields of that fieldset. https://github.com/Toutouwai/FieldsetHelper

@ttttim, as a test you could try $page->getUnformatted('field_name') and see if that is also empty. That will tell you if the issue relates to the formatValue() method or not. It's just a guess, but the saved value might be failing the test at FieldtypeDynamicOptions::sanitizeValue(). This checks the saved value against the allowed values as defined in your hook to FieldtypeDynamicOptions::getSelectableOptions(). If you temporarily change that method so that it doesn't do any sanitizing... public function sanitizeValue(Page $page, Field $field, $value) { return $value; } ...and find that you are then able to get the field value via AppApi then it means that something about AppApi is causing your hook to not return the expected selectable options. Like, maybe $page and $field are not what you would expect them to be inside the hook. You should be able to use Tracy to debug what is going on inside your hook when AppApi is involved.

I've never heard of anyone using nested Hanna tags before and I don't think TextformatterHannaCode itself supports it. I tried it just now without HannaCodeDialog installed and TextformatterHannaCode didn't successfully replace the nested tags. It's too fringe for me to want to spend time on for HannaCodeDialog but seeing as your nested tags don't have any user-editable attributes you can probably use some alternative token replacement for those like wirePopulateStringTags()/WireTextTools::populatePlaceholders(). Or maybe you could play around with manually setting the dialog field value in a HannaCodeDialog::buildForm() hook. Not sure if that would work or not.

@Alpina, the OP is asking how to output the field values of a page in the order that the fields are positioned in the page's template. To get the fields in order you can use $page->fields, and you can then iterate over those fields to get the field values from $page via the name of each field. As developer you generally have control over both the template within the PW admin and the template file that outputs markup. So if you have a template with fields "title", "body" and "gallery" then I think the normal way to control the order of these fields is by structuring the markup you want within the template file and then getting each field value individually by name. <h1><?= $page->title ?></h1> <div class="text"> <?= $page->body ?> </div> <div class="gallery"> <?php foreach($page->images as $image): ?> <img src="<?= $image->url ?>" alt="<?= $image->description ?>"> <?php endforeach; ?> </div> If later there is a decision to place the gallery before the body text then you change the order of the markup in the template file. You might also change the order of the fields within the template in the PW admin so that it reflects the order that fields are output in the frontend, but that's a separate decision and moving the fields in the PW admin doesn't actually define the order of output. Alternatively you could have no fixed order of output within the template file and use the order of the template fields as defined in the PW admin. <?php foreach($page->fields as $field): ?> <?php $value = $page->get($field->name); ?> <?php if($field->name === 'title'): ?> <h1><?= $value ?></h1> <?php elseif($field->name === 'body'): ?> <div class="text"> <?= $value ?> </div> <?php elseif($field->name === 'images'): ?> <div class="gallery"> <?php foreach($value as $image): ?> <img src="<?= $image->url ?>" alt="<?= $image->description ?>"> <?php endforeach; ?> </div> <?php endif; ?> <?php endforeach; ?> I just think this is a less practical approach and makes the template file harder to understand.

foreach($page->fields as $field) { $value = $page->get($field->name); // Now output the value or process it as needed for output... } Seems rather impractical to me though, as you would no doubt need to do a lot of if() tests to output the right markup based on the field type and what wrapping markup is needed, etc. Much simpler to get your specific field values individually in your template file and control the order of markup there.

Use the main menu to go to Modules > Configure > FieldtypeFile In the "Allowed Fieldtype modules for custom fields" field, tick the checkbox for URLLanguage. It says it may not be 100% compatible with custom fields but it seems to work fine for me.