Robin S

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 ).

I think this is totally justified. The amount of data that is being stolen these days is just crazy, and it has real impacts on real people. One of the worst incidents to date is the Equifax hack: https://en.wikipedia.org/wiki/Equifax#May.E2.80.93July_2017_data_breach John Oliver did a good piece on it: Automatic encryption just has to become the new normal, and I'm confident it won't be that big a deal to implement once the code wizards out there turn their minds to the challenge.

Are you sure you are comparing apples with apples here? In your screenshot, is the original image being viewed in the context of a browser, or is it viewed in some other application? There are so many things that can come into play when you are dealing with colour management - whether the image has a colour profile embedded, what the colour profile is (sRGB is probably the safest option), the colour management support within the application you are viewing the image in, etc. To verify that the colour loss has anything to do ProcessWire's resizing you should insert the original image next to a resized version of that image in a template file and view them in your browser. <img src="/path/to/original-image.jpg" alt=""> <img src="<?= $page->image->size(854,0)->url ?>" alt="">

When I create a new Hanna Code tag I am always creating a PHP tag (I don't think I've ever had a need to create a text or Javascript tag). And I prefer to edit my tag code in my IDE rather than in the code field within the Hanna Code module. Because of this my Hanna codes always consist of... <?php include $config->paths->templates . "hannas/{$hanna->name}.php"; ...which just includes a file named the same as the Hanna tag from a "hannas" folder in /site/templates/ Always on the lookout for efficiencies, I had a go at automating the process of setting up new Hanna tags and come up with the following. Maybe it's useful to someone. In /site/ready.php: // Pre-fill code for new Hanna tags and create file $wire->addHookBefore('ProcessHannaCode::executeEdit', function(HookEvent $event) { $id = (int) $this->input->get('id'); // Include code for later use $file_include_code = '<?php include $config->paths->templates . "hannas/{$hanna->name}.php";'; if(!$id) { // A new Hanna tag is being added // Set type to PHP $this->addHookBefore('InputfieldRadios(name=hc_type)::render', function(HookEvent $event) { $inputfield = $event->object; $inputfield->value = 2; }); // Set code to include file of same name as tag $this->addHookBefore('InputfieldTextarea(name=hc_code)::render', function(HookEvent $event) use ($file_include_code) { $inputfield = $event->object; $inputfield->value = $file_include_code; }); } else { // An existing Hanna tag is being edited (the new tag has been saved) // Get the data for this tag /* @var \PDOStatement $query */ $query = $this->database->prepare("SELECT name, type, code FROM hanna_code WHERE id=:id"); $query->bindValue(':id', $id); $query->execute(); if(!$query->rowCount()) throw new WireException("Unknown ID"); list($name, $type, $code) = $query->fetch(\PDO::FETCH_NUM); // If it's a PHP tag and the tag code matches the include code... if($type == 2 && $code === $file_include_code) { $filename = $this->config->paths->templates . "hannas/{$name}.php"; // Check if there is an existing file and if not... if(!file_exists($filename)) { // Define the contents of the file // Just the namespace and API variables for IDE code-completion // Some of this is PhpStorm-specific so adjust as needed $contents = '<?php namespace ProcessWire; //<editor-fold desc="API variables"> /** * @var Config $config * @var Fieldgroups $fieldgroups * @var Fields $fields * @var Languages $languages * @var Modules $modules * @var Page $page * @var Pages $pages * @var Paths $urls * @var Permissions $permissions * @var ProcessWire $wire * @var Roles $roles * @var Sanitizer $sanitizer * @var Session $session * @var Templates $templates * @var User $user * @var Users $users * @var WireCache $cache * @var WireDatabasePDO $database * @var WireDateTime $datetime * @var WireFileTools $files * @var WireInput $input * @var WireLog $log * @var WireMail $mail * @var \ProCache $procache * @var \FormBuilder $forms * **/ //</editor-fold> '; // Create a file and insert the contents above file_put_contents($filename, $contents); } } } });

I think it does make sense to say that the superuser role is a role without any restrictions and that therefore permissions are not something that can be granted or not granted to a superuser. The comment (from Ryan in the GitHub issue) that I don't agree with is: Why should there be the presumption that there is never any scenario where a non-superuser could be trusted to add or edit a field or template? Depending on the user and the project there could be quite valid cases for this. I think it ought to be possible to elevate a role right up to the point where they are virtually a superuser. One way this could perhaps be implemented is by adding a permission for each core Process module.

Sorry, it's due to my browser autofilling the download URL with the wrong data when I edit the module in the modules directory. Please try again now and it should work.