Robin S

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.

It would be a good idea to fix the typo in the method name... $this->addHooKBefore("Inputfield::render", $this, "renderField"); // should be a lowercase k in addHookBefore ...but surprisingly it seems to work regardless, so probably not the cause of the problem.

Required fields work fine in a repeater. From what I have tested, "required if" dependencies also seem to work fine in a repeater. What problem do you get if you make the url_link field required in your repeater?

This is a better way to go than your later examples. It's more efficient to use the GET tags as part of the $pages->find() selector than to find a larger number of pages and then filter it.

It doesn't really. But for that matter it doesn't make a lot of sense under the wrench icon on the default theme either. It's just something you discover by using it. The advantage as I see it in the default theme is that you can quickly go to the front-end just by clicking the wrench - you don't have to actually find and click the "View site" link in the dropdown. Like "View site", this doesn't really belong under the user profile menu. But I don't mind much because like you I don't use it. I think you're right. But my main concern is just for my own use - I use the "View site" link so often that I would like it to be easy to find and click. An icon on either on the left or the right of the masthead would be fine.

What workaround are you referring to here? Do you mean this... I don't see how this can work, because a user can open a closed inputfield, and also this module forces the visibility to hidden when the "show if" conditions are not met which would overwrite a "closed" setting.

A URL segment can include any characters that are valid in a page name. So you could separate your category names with an underscore or period perhaps, then explode on that character and match each category to pages. But you'd be sort of fighting against the workings of URL segments so why not use a GET variable instead? Then you can separate your categories with any character you want... http://yourdomain.com/your-page/?categories=one|two ...and support for arrays is actually built-in... http://yourdomain.com/your-page/?categories[]=one&categories[]=two

Try: $matches = $pages->find("testo|pagina_blocco.testo~=$q");

Thanks for the report @Federico. I believe the issue you are seeing is caused by problems in the PW core rather than being specific to the Custom Inputfield Dependencies module. I found problems with several of the inputfield visibility options when used with fieldset inputfields, and created a GitHub issue here: https://github.com/processwire/processwire-issues/issues/441 This is deliberate. It would be pretty easy for the module to hide inputfields via CSS, but by not rendering the inputfields the module allows for cases where it is critical that the inputfields not be seen or modified. The core inputfield dependencies feature works in response to other field values entered in Page Edit and hides/shows inputfields immediately. Therefore the core feature can only hide/show fields via JS and CSS, which may be manipulated by the user using their browser dev tools, or may fail if a JS error occurs. But the Custom Inputfield Dependencies module applies the dependencies via PHP before Page Edit is rendered, so I think it is an advantage to not render hidden fields at all. Hopefully the core inputfield visibility problems with fieldsets will be fixed, however I will also look at whether a workaround is possible within the module. In the meantime, I don't think the visibility dependency you want to set up requires Custom Inputfield Dependencies. You can achieve this using only the core inputfield dependency feature by setting the following for "Show this field only if": proj_code_valid=1