Search the Community

Hi, Could someone please direct me to how should I go about using `addFlag` on a field in a fieldgroup context? Setting contexts through API is pretty new to me, however I managed to set all other necessary settings through `setFieldContextArray()` function. But the access flags are only applied through `$field->addFlag(128)` (when not inside fieldgroup context) - https://processwire.com/api/ref/field/add-flag/ I have tried (in a module install function): // Create a new fieldgroup $fieldGroup = new Fieldgroup(); $fieldGroup->name = static::NAME; $fieldGroup->add('title'); // trying to set flag to this 'title' // ...Adding other few fresh fields to fieldgroup $fieldGroup->save(); // Works fine. $field_title = wire('fields')->get('title'); $fieldGroup->setFieldContextArray( $field_title->id, array( 'columnWidth' => 50, 'useRoles' => true, 'accessFlags' => [64,128], // Doesn't work. 'addFlag' => 128, // Doesn't work. )); //$fieldGroup->getField('title',true)->addFlag(128)->save(); // Doesn't work with field->save() nor without. $fieldGroup->saveContext(); // Works fine with above setFieldContextArray() settings. // Adding it to a new template and saving. Works fine. $template = new Template(); $template->name = static::NAME; $template->fieldgroups_id = $fieldGroup->get('id'); $template->save(); The API docs seem a bit lacking in this department, very hard to figure out the whole flow ? Any ideas? Thanks in advance!

Based on this forum post, I wanted to find a more elegant solution for changing a field's settings per template. Hooking the page editor after it generates the form works and may still be needed for more complex modifications. But using field & template context, it's easier to modify the field settings and it greatly reduces the need for creating an almost identical field just to adjust a few things. In my blog post, I've written on how to extend contextual options to allow any fieldtype / inputfield settings to be changed depending on the template. Hope you find it useful, and if you have any questions or comments, feel free to post them here. https://abdus.co/blog/doing-more-with-fewer-fields-in-processwire/

I'm trying to add a new option to InputfieldTextarea. Depending on that option, I want to change how the input is rendered. I also want to change this option depending on different templates and repeaters, meaning it can have different values for different fieldgroups. I hooked into three methods: $this->addHookBefore('InputfieldTextarea::render', $this, 'hookInputRender'); $this->addHookAfter('InputfieldTextarea::getConfigInputfields', $this, 'hookInputSettings'); $this->addHookAfter('InputfieldTextarea::getConfigAllowContext', $this, 'hookInputContext'); In hookInputSettings, I build the additional option protected function hookInputSettings(HookEvent $e) { /** @var InputfieldTextarea $field */ $wrapper = $e->return; $field = $e->object; /** @var InputfieldSelect $font */ $font = $this->modules->get('InputfieldSelect'); $font->label = $this->_('Font'); $font->name = 'fontFamily'; $font->addOptions(self::fontOptions); $font->attr('value', $field->fontFamily); $wrapper->add($font); $e->return = $wrapper; } It shows up in field settings with no problem When I pick an option and save, it even shows up in the database. However, I cannot get the properties of that field in that fieldgroup context. Most other inputfields can get their inputfield settings because are inside a class that extends Inputfield, so $this->myOption works. If I hook into FieldtypeTextarea::getConfigInputfields, it works too, because getConfigInputfields method is called with $this as its argument, inside hooks it's possible to access fieldgroup specific settings. But for Inputfield, it's not given any arguments, so hooking Inputfield::getConfigInputfields, you won't be able to get any information about the context. // /wire/core/Field.php public function ___getConfigInputfields() { // ... if(!$fieldgroupContext || count($allowContext)) { // ... try { $fieldtypeInputfields = $this->type->getConfigInputfields($this); // ... } // ... } $inputfields = $this->wire(new InputfieldWrapper()); // ... if($inputfield) { if($fieldgroupContext) { $allowContext = array('visibility', 'collapsed', 'columnWidth', 'required', 'requiredIf', 'showIf'); $allowContext = array_merge($allowContext, $inputfield->getConfigAllowContext($this)); } // ... $inputfieldInputfields = $inputfield->getConfigInputfields(); // ... } // ... } So, as a solution I gave it $this as a parameter // $inputfieldInputfields = $inputfield->getConfigInputfields(); $inputfieldInputfields = $inputfield->getConfigInputfields($this); Now everything works without any hacks. It works in field settings, templates, repeaters just fine. protected function hookInputSettings(HookEvent $e) { // ... $field = $e->arguments(0); // ... $font->attr('value', $field->fontFamily); // WORKS! // ... } I wanted to write this post because it drove me mad last night. I guess the next step is to make a pull request.

Hi, I'm working on a homepage template where I loop over some pages, check if they have children, and print their children; if not, print the page itself where I employ page->render function. Inside template files of these parent pages, I use $config->scripts->[foot|head]->add() to enqueue scripts and and when creating markup I print the contents of these FilenameArrays using simple foreach loops. With parents that have children, which don't require rendering a part of page (as opposed to rendering whole html document), there's no problem using $config->scripts, using PHPStorm's debugger I can track the scripts up until where the execution comes to parents with no children. When used with $parentPage->render(array('renderPartial' => true)) these pages get rendered from beginning using their own context, completely ignoring the previous one, and resulting in flushing $config->scripts->[foot|head].After many hours of fiddling with here and there, I'm lost and I don't know how else I can tackle with this problem. The question I have is if there's a way to manually render a page without losing the context? Or, in which variable I can store FilenameArrays? // The code I have can be paraphrased as // Homepage sections foreach $section as $parent if $parent->hasChildren foreach $children as $child renderChild() else $parent->render(partial=true) // In each parent's template $config->scripts->head->add("head.js") $config->scripts->foot->add("foot.js") // both foot and head initialized at _init.php // After using $parent->render(partial=true) // $config->scripts gets flushed loop_over_and_write_scripts('foot') // returns nothing, $config->scripts->foot is empty Thanks in advance.

Currently to change the 'summary' description in context of 'basic-page' we would have to do this: // get the template $t = $templates->get('basic-page'); // get the field in context of this template $f = $t->fieldgroup->getField('summary', $useFieldgroupContext = true); // value of the field $f->description = "'basic-page' summary description"; // save new setting in context $fields->saveFieldgroupContext($f, $t->fieldgroup); What I'd like is something like this // get the field $f = $fields->get('summary'); // value of the field $f->set('description', "'basic-page' summary description", $context = 'basic-page'); // save new setting, perhaps optional, because behind // the scenes `saveFieldgroupContext` has been called already? $f->save(); Similar for getting in context: $f->get('description', $context = 'basic-page'); Not only is it more intuitive, but less verbose, in my opinion. What do you think?

Hi, I've got the following issue: I'm renaming the title field on the team pages of a website. Basically, it's confusing to enter the name of a member of the team in the title field… (specially when there's another field right underneath it called 'name'). So I've used the "context" function to change the field name, which works fine as soon as you've saved the new page. Before that, the field is still called 'title'. (see screenshots) Any ways around this? Suggestions? Also, is it possible to rename the 'name' field? I'd rather call it something like "URL Name", or something similar, to avoid confusion from the client. Thanks! David