Robin S

This is a test for if only a single template may be used for the new page. PW uses a hidden field for template in this case.

Despite Soma helpfully telling us we are all wrong, the code I suggested in that thread works for me: So you set up a field in each PageTable template to hold some reference to the container page - in the example below I use an integer field for the page ID, but you could use a Page Reference field instead. You would set the field to hidden so users do not see or change it. But for demonstration purposes I have left the field visible and also show the value in the PageTable columns. Note that the value is only set when the PageTable field does the AJAX reload (when the modal closes), so the value is not available when adding a new page to the PageTable until the modal is closed. In /site/init.php $wire->addHookBefore('InputfieldPageTableAjax::checkAjax', function($event) { $field_name = $this->input->get('InputfieldPageTableField'); // Just for this PageTable field if($field_name !== 'test_pagetable') return; $page_id = (int) $this->input->get('id'); $item_id = (int) $this->input->get('InputfieldPageTableAdd'); if($page_id) $page = $this->pages->get($page_id); // $page is the container page if($item_id) $item = $this->pages->get($item_id); // $item is the PageTable item // Set integer field to $page->id $item->setAndSave('container_page_id', $page->id); });

It just so happens that there is... Templates: Child Pages You could use this in conjunction with the hook below, which will use the template context for title label, description and notes if the number of allowed templates has been restricted to one: $wire->addHookAfter('ProcessPageAdd::buildForm', function(HookEvent $event) { $form = $event->return; $template_field = $form->getChildByName('template'); if($template_field->type == 'hidden') { // Only one template is allowed for this new page // Get the template $template = $this->templates->get($template_field->value); // Get the title field in the context of this template $title = $template->fieldgroup->getFieldContext('title'); if($title) { // Set the properties of the 'title' inputfield $title_field = $form->getChildByName('title'); $title_field->label = $title->label; $title_field->description = $title->description; $title_field->notes = $title->notes; } } $event->return = $form; });

For some inputfield visibility constants it is too late to set them at inputfield render. For Inputfield::collapsedHidden, Inputfield::collapsedNoLocked and Inputfield::collapsedYesLocked these are handled by the InputfieldWrapper class. I've found that a good method to hook for setting the visibility of fields in Page Edit is Field::getInputfield. This example is for /site/ready.php but easy to adapt to a module context: $wire->addHookAfter('Field::getInputfield', function(HookEvent $event) { // Only for ProcessPageEdit if($this->page->process !== 'ProcessPageEdit') return; $field = $event->object; $inputfield = $event->return; if($field->name == 'proj_code_folder') { $inputfield->collapsed = Inputfield::collapsedNoLocked; } });

Are you sure this is necessary? When adding a new page under a parent that allows only a single template for children, I find that any changes made to the title field in template context (e.g. changing label or description) are automatically applied.

Another option: set $config->debug = true in /site/config.php (which is a good idea in general while developing a site) and then hover the inputfield collapse/expand icon in Page Edit.

Ah, good find, thanks. Fixed in v0.0.8.

Yes.

Hi @jaro, I've been having a look at the Repeater issue and the BreakRepeaterFields demonstration. Interestingly, the issue is not that fields are copied from one repeater to another. It is that the module interferes with the listing of fields when the repeater field settings are viewed in ProcessField, causing the fields of one repeater to appear in the AsmSelect of another repeater. So if you check the database the fields associated with each repeater is actually correct despite the incorrect listing shown in ProcessField. But if the user then saves the field in ProcessField it is at this point that the associated fields become incorrect. Could you explain why the module needs to hook ProcessPageView::finished? This method fires on every page view, front-end and back-end. But most of these page views will have no connection to field settings or template settings changing. Instead of hooking this method, couldn't you hook only methods that are related to field and template settings? So some method in ProcessField and ProcessTemplate? And also, the module is looping over all fields on every page view. Could you focus in on just the field that is being edited? So when field1 is edited in ProcessField, just export the data for field1 rather than looping over every field. This would avoid the situation where the data for repeater2 becomes involved when editing repeater1. I should say that I've just had a brief look at the issue so far, so there might be good reasons why the module does what it does.

It would be good if PW did this by default on module installation. Maybe there is some downside but I can't think of any situations where you want the module config data to look populated (by setting default inputfield values) but not actually be populated. Default values could/should still be set in the construct method so there wouldn't be any notices necessarily. But if the config data was removed from the DB then the config page would appear empty despite default values still being used, which is a different kind of misleading I guess. I'll ponder it some more.

You don't have a proper PHP opening tag here: <? // ==== Processwire Multi Instance ===== // $pwpath = "/path/"; $pwurl = "https://url.example"; $pw = new ProcessWire($pwpath , $pwurl); ?>

@Federico, the module seems to be working for me as expected. So I will leave the module as is for now unless I hear of others having problems with fieldsets. It sounds like you have your own solution that is working for you.

Your original image has an AdobeRGB colour profile. Because support for colour profiles is going to vary in PHP/GD/ImageMagick and from browser to browser it would be a good idea to convert and save your images with the sRGB profile which is the mostly widely supported. This was discussed recently on the forums here: More reading: https://fstoppers.com/pictures/adobergb-vs-srgb-3167

I was actually thinking of just manually removing the variations in Page Edit, but removeVariations() should also work (it works for me). What about using the forceNew option? Is that working for you?

I will certainly contribute any actions that would be useful to others, but I only have two so far (the ones you see in my screenshot) and one is a work in progress. The first just an interface for uploading a CSV file, but I don't think this is useful as an action to bundle with the module because the action doesn't do anything by itself - it requires code to process the CSV lines, which would depend entirely on what the user wanted to do. The second is part of an exploration of how to resize existing images to save on disk space. I have a lot of older sites from before client-side resizing was introduced, and users have uploaded massive images that waste a lot of disk space. I'd like to upgrade PW on these sites and then loop through all the oversized images and replace them with smaller versions. I've worked out how to do this, but again I don't think it makes for a useful action to share. Firstly, for a large list of images this should be broken into smaller jobs that run on a LazyCron (or maybe the new Tasker module) to avoid a timeout. And secondly this is a destructive process that has the potential to do a lot of harm if used incorrectly, so I wouldn't want to put this out there and maybe contribute to a disaster. Yes, that's what happened. No need to change from using the module config data to populate the table - I can understand why it wouldn't be good to parse all the files every time the list is loaded. But as a more general issue I think that perhaps module developers should rethink how values are populated to the module config page. Currently nearly all modules, mine included, set default/fallback values for config inputfields by just setting the value for the inputfield as it is added to getModuleConfigInputfields() (or one of the many equivalent methods for defining config inputfields). There is probably a tutorial somewhere that started this practice. The problem with doing this is that when viewing the module config page, there is no way for the user to distinguish between values that are actually saved to the config and values that will be saved to the config if the config form is submitted. I'm sure I'm not alone in expecting that when I view the module config page I am seeing the config values that do exist, not ones that will exist if I submit the form. Each time I think about this I get different ideas about what the best solution would be. Currently I'm thinking that we module developers should be saving the config values that we want to be the default config as part of the module install method. Then we don't set any default/fallback/other values in getModuleConfigInputfields() besides those coming from the saved module config. That way the user can have confidence that whatever they see in the module config page is data that actually exists in the saved config. And if the module does display config values that are not actually saved yet these should be highlighted in some way. Any thoughts on this?

Most likely the problem is that you already have an image variation at that size that was created with different quality, sharpening, gamma, etc. Settings like that do not form part of the variation file name so you receive the existing variation rather than a new variation being created. I made a wishlist item long ago requesting better handling of this. So you have to clear the image variations, or use the forceNew option in the $options array (just once, then remove it so you are not creating the new variation over and over again).

Thanks Adrian, I have sussed it out now. It's because changes to any of the things that make up the actions info don't get applied until the user revisits the module config page and saves. What makes it confusing (and this is not a criticism of anything you have done - it's just the way PW treats module config values) is that the updated values are shown in the module config screen, they are just not actually applied. It's the same thing I was whinging about above. I think the PW module config system needs some way to visually indicate which values displayed on a module config screen are saved values and which are not. Because otherwise the expectation is that when you view the module config screen you are viewing actual applied values.

@dragan, you can add the inputfield like this: $wire->addHookAfter('ProcessPageAdd::buildForm', function(HookEvent $event) { $form = $event->return; // If adding page under particular parent if($this->input->parent_id === '1234') { // Add inputfield to form after existing title field // If you name the inputfield the same as the field you want to populate // then the entered value will be saved automatically $f = $this->modules->InputfieldText; $f->name = 'vertec_code'; $f->label = 'Vertec-Code'; $f->required = true; $f->attr('required', 1); // use HTML required attribute too $title_field = $form->getChildByName('title'); $form->insertAfter($f, $title_field); $event->return = $form; } }); Because of this section in ProcessPageAdd::processInput, if you name the inputfield the same as the corresponding field in the template of the new page then the entered value will automatically be saved to the page.

Looking at the hookable methods in ProcessPageAdd it looks like this would be possible. But what are the circumstances where you would want to do this? Remember that no template for the page has been selected at this point (unless the page is being added under a parent that allows only a single child template) so in general you don't know if a given field is going to be present in the newly saved page. If you can explain a bit more about what you are wanting to do I'll post some example code.

This is a really minor issue so no hurry at all. No, it affects all actions. I dumped the $info array in the getActionTitle() method and it seems there is no 'title' item present when the actions table is rendered at Setup > Admin Actions.

Hi @adrian, I noticed that in the datatable that lists the actions (at Setup > Admin Actions) the title is not being taken from the $title variable. In the module config datatable it is working. Config: Setup > Admin Actions:

Hi @Martijn Geerts This module does not upgrade cleanly from earlier versions. For instance, in earlier versions the Dependencies field was a textarea with each dependency separated by newline. In more recent versions, JSON data is expected for this field value. So after upgrading the module config page doesn't render properly due to a JS error when attempting to decode the field data. To fix this I have to edit the module config data directly in phpMyAdmin. Could you please add an upgrade() method to the module to translate module config values from earlier versions to the current format?

v0.0.7 released: Adds support for FieldtypeFieldset, FieldtypeFieldsetGroup and FieldtypeFieldsetTab. @Federico, hopefully this update works for your use case.

A handy trick for dealing with the suffix added to inputfield names inside a repeater is to use the name of the associated field object instead, which you can get via the hasField property of an inputfield. In this case it looks like you want the Field object anyway so it could be: //$pageField = $this->wire('fields')->get($this->name); $pageField = $this->hasField; (not tested)

Interesting. @Federico, if you are wanting an integer field that auto-increments across the whole site then there is a module for that: https://modules.processwire.com/modules/integer-auto-increment/ I haven't used it myself.