Robin S

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

@ryan, would you consider making the top-level item in the AdminThemeUikit user nav configurable and/or hookable? I'd like to have the option to make this top-level link a "View site" link rather than an edit profile link, as per the default admin theme. It's much more common for me to want to quickly launch a front-end tab than to edit my profile.

It's working for me (with Markdown/Parsedown Extra textformatter - didn't try the other). Do you have any other textformatters enabled for the field besides the markdown textformatter? Anything unusual about how you are getting the field value in your template (something that might cause output formatting to be off)? Edit... ...that sounds like a CSS issue actually. Maybe you have list-style:none and no margin/padding on your ol element?

Try this in /site/ready.php $wire->addHookAfter('ProcessPageAdd::getAllowedTemplates', function(HookEvent $event) { // Get keys (IDs) of returned templates array $template_ids = array_keys($event->return); // Implode for use in a selector string $template_ids_str = implode('|', $template_ids); // Get TemplatesArray of those templates, sorted by label $templates = $this->templates->find("id=$template_ids_str, sort=label"); // Convert to plain array and return $event->return = $templates->getArray(); });

v0.0.4 released - adds support for the new password field option that requires the old password to be entered.

If you and your site editors have fixed IP addresses you could use mod_rewrite to redirect away from the Admin page based on IP address. In .htaccess, after RewriteEngine On # Define allowed IP addresses RewriteCond %{REMOTE_ADDR} !^111\.111\.111\.111 RewriteCond %{REMOTE_ADDR} !^222\.222\.222\.222 # Adjust to suit the name of your Admin page RewriteCond %{REQUEST_URI} ^/processwire/ # Redirect to home page. Use 302 redirect until finished testing. RewriteRule ^ / [L,R=301]

I think this Gist by @Soma may be of some help. My point about pagination was really that if you have a large number of authors you cannot apply a limit and must load all results into memory and loop over them to apply the sort. The options for "pseudo-pagination" don't get around this problem unfortunately. The thing with that approach is that you would have to use a hook and loop over all author pages every time a new author is added or an author's name is edited. Sounds like that wouldn't be a big deal in your situation, but would be a problem if there were thousands of authors. Thinking about a solution for large numbers of pages, I had an idea about generating a value for a hidden sort field based on the first letter of the author's name. It would go something like this... In /site/config.php // Prefixes for sort field $config->sortChars = [ 'č' => 'czzzz', // sort after 'c' 'đ' => 'daaaa', // sort before 'd' // etc ]; In /site/ready.php $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template != 'author') return; // Assuming author's last name is in Title field $initial = mb_strtolower(mb_substr($page->title, 0, 1)); if(isset($this->config->sortChars[$initial])) { // If the initial letter matches a key in the sortChars array // add the prefix to the title and set to the sort field $page->sort_field = $this->config->sortChars[$initial] . $page->title; } else { // Otherwise use the title for the sort field $page->sort_field = $page->title; } }); Then use sort=sort_field in the $pages->find() selector, and limiting/pagination is also possible.

Sounds interesting, looking forward to that.

Cool to have a dedicated option for these, but 3 and maybe 4 have been possible for a while now via the "No Debug Bar in Selected Templates" feature (the Form Builder iframe was what prompted my request for that feature ).