Robin S

In /site/ready.php: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { $lister = $event->object; $lister->nativeDateFormat = 'd.m.y'; }); See here for the format options: https://processwire.com/api/ref/datetime/date/

Inputfield Dependencies seem to work okay with front-end editing, but you need both fields to be present in the editor window... Field 1: The field that has the dependency applied to it Field 2: The field whose value Field 1 is dependent on So you would need to use front-end editing option C or D with both fields specified: <edit field="field_1,field_2"> ... </edit> <div edit="field_1,field_2"> ... </div>

I don't think there is going to be an satisfying solution for this. Front-end editing is nifty for simple needs but there are many situations where it is a poor substitute for editing a page within the dedicated Page Edit environment in admin. I think dealing with empty fields might be one of those situations. The simplest thing would be just to train your editors to reload the page if they accidentally save an empty field. If you want to try other things, you'll have to approach it via Javascript because there isn't any hookable method in PageFrontEdit.module that will be useful here. You could give this a go: $('body').on('pw-reloaded', 'span[data-name="informations"] .pw-edit-copy', function() { if(!$(this).html().length) $(this).siblings('.pw-edit-orig').html('<p>No infos.</p>'); });

The module has been approved for the directory now, and the link is in the first post.

@kongondo, @gmclelland, I think @dragan is referring to pasting the URL in the OS dialog you get after clicking "Choose file":

Yes, I think so. The method comment says... ...so it should be possible to get the field. E.g. public function renderReady(Inputfield $parent = null, $renderValueMode = false) { $field = $this->hasField; if($field) { //... } //... }

@ryan, in the blog post you give an example of the need for the image actions feature: What do you think about adding an interface that allows multiple images to be selected and then an action applied to those selected images? There was a question in the forums a while back about how tags could be applied to multiple images: I bookmarked this in my "to do" list because it's something that would be useful to implement. If there was an interface for selecting multiple images then maybe the new image actions feature could be a solution to this. Also, do you think it would be possible to create actions that, in a first step, open a dialog where options could be selected? So for example, if the action was "Move image to field" there could be a dropdown to select image fields on the page? This would be better than needing to have separate actions for each option. Maybe you could give a tutorial on creating image actions in a future blog post?

Love the image actions feature, thanks! Especially looking forward to this one... ...as I had a need for this recently. I don't intend to give users access to the "special effect" options (B&W and sepia) for the same reason I wouldn't give users the ability to change fonts or text colours - there's always some editor who considers themselves an "artist" and will take a carefully designed site and turn it into a dogs breakfast. In case anyone else feels the same, it's simple to remove these with a hook in /site/ready.php: $wire->addHookAfter('InputfieldImage::getFileActions', function(HookEvent $event) { $actions = $event->return; unset($actions['bw']); unset($actions['sep']); $event->return = $actions; });

If you add a renderReady() method to your inputfield module and load the dependencies there then they should be available for all inputfield usages including repeaters. Check out the Inputfield class, and the AsmSelect inputfield as an example.

This is most likely caused by a Javascript error. Open the JS console in your browser dev tools and you should see an error message that sheds some light on the problem. Looking at your Extra Plugins screenshot, it looks like you have not included the required dependencies for the Widget plugin:

@nickngqs, a few more options for executing API code: Tracy Debugger's Console panel Tracy Debugger's Snippet Runner panel Admin Actions module

@Macrura, I'm intrigued by the "Flagged Works" section in your dashboard screenshot. Is that some kind of automatic pre-flight that checks user edits for possible errors? Could you explain about it?

Access for Process modules is managed using the 'permission' item in the getModuleInfo() array. You can also create the permission and the page for the Process via getModuleInfo(). You'll need to uninstall then reinstall your module for the settings to take effect. See Ryan's ProcessHello demo module. And the comments in the Process class.

For the "Selector string" option I think the correct syntax is: has_parent=page.parent

It looks like the JS and CSS dependencies for InputfieldPageListSelectMultiple are not included in the page. Probably because ProcessPageLister::renderResults is called via AJAX after the page has already loaded, at which time it is too late to tell PW that the dependencies are needed in the <head>. You could try forcing the dependencies to be loaded in a hook to ProcessPageLister::execute... $wire->addHookAfter('ProcessPageLister::execute', function(HookEvent $event) { if($this->config->ajax) return; // not needed for AJAX-loads $inputfield = $this->modules->get("InputfieldPageListSelectMultiple"); $inputfield->renderReady(); // load JS/CSS dependencies });

@tpr, I've been having a look at getting the field edit links working inside repeaters. The solution is pretty simple. At line 2342... if ($field = $inputfield->hasField) { //... And because of the suffix added to the name of inputfields inside a repeater I think it would be good to make this change at line 2354... $editFieldTooltip = '<em class="aos_EditField">' . $field->name . '<i class="fa fa-pencil"></i></em>'; ...to use $field->name instead of $inputfield->name.

Hi @adrian, Not a major, but the Console panel layout is a bit messed up when the panel is opened as a window.

We are getting off-topic here, but... If @mindplay.dk is not actively maintaining the module then I think it would be good to update it. It would be cool to have as an option in Tracy, or the module could be forked. I found that the module isn't working in PW3 where a namespace is declared at the top of template files. I had to modify the module code to add the namespace to stubs.php because the FileCompiler does not compile this file. Also, I'm probably overlooking something but I can't see why the module needs to rebuild the stubs file after every Session::redirect and every ProcessPageView::finished. I think that comment is due to a misunderstanding of what the module is for. The module only adds code completion to $page for field names in the current template - it isn't intended to provide code completion for all API variables (for that you have to add a DocBlock in every template file with tags for each API variable).

@Vigilante, please use code blocks for your code examples. If you really need to do it this way then you could do... <?php foreach($parents as $parent): ?> <?php $children = $parent->children("id=$everything"); // PageArray dereferenced as string of pipe-separated IDs ?> <?php if(count($children)): ?> <section> <h2><?= $parent->title ?></h2> <ul> <?php foreach($children as $child): ?> <li><?= $child->title ?></li> <?php endforeach; ?> </ul> </section> <?php endif; ?> <?php endforeach; ?> ...but it's not very efficient. Instead, I suggest you don't need the $parents PageArray and should just work on sorting the $everything PageArray. For example: // Sort by parent in the selector for $everything $everything = $pages->find("template=basic-page, sort=parent"); // Initialise $parent_title $parent_title = ''; foreach($everything as $one) { // By default, this is not a new section $new_section = false; if($one->parent->title !== $parent_title) { // If the parent title of $one is different to the existing $parent_title // then this is a new section $new_section = true; // Set $parent_title $parent_title = $one->parent->title; } // If this is a new section and $one is not the first item in $everything // close ul and section from previous section if($new_section && $one !== $everything->first) echo "</ul></section>"; // If this is a new section, add the open section, heading and open ul if($new_section) echo "<section><h2>$parent_title</h2><ul>"; // Output the li echo "<li>$one->title</li>"; // If $one is the last item in $everything then close the ul and section if($one === $everything->last) echo "</ul></section>"; } If you need some custom sort of the parents then you could loop through $everything and add a custom sort property to each item, then sort $everything by the custom property. Not exactly the same, but this post shows the general idea:

What version of PW are you using? Ryan fixed a redirect issue on the dev branch in early November. Does clearing your browser cookies resolve the issue?

I'm wondering about this part... If these options (checkboxes) are added dynamically, are all the options also defined in the selectable options for the Select Options field? You cannot save an option to a Select Options field if it is not one of the pre-configured selectable options. If you want to dynamically add to the selectable options then this reply has some example code:

When you can find a setting in admin and you want to know what the property name will be in API, a handy trick is to hover the collapse toggle of the setting. When $config->debug = true you will see the name of the input appear, and 99% (all?) of the time that will be the property name in the API. And Tracy will give you the whole shebang:

@Federico, I'm not sure I completely understand your question, but if you want to know what inputfield type is used for a Page Reference field you can get that from the "inputfield" property. The type setting in admin: Getting the type via InputfieldPage using the API: // $inputfield is InputfieldPage object $inputfield = $pages(1234)->getInputfield('YOUR_PAGE_REFERENCE_FIELD'); // $type is 'InputfieldSelect' $type = $inputfield->inputfield; P.S. Are you using Tracy Debugger? Things are a lot easier once you start using this module. You can dump an object (e.g. an inputfield) and explore all its properties.

Hi @tpr, AOS has a stylesheet rule... html.noFilenameTruncate i.fa-file-image-o, html.noFilenameTruncate .InputfieldFileInfo i { left: -21px !important; top: 3px; float: left; } ...but this is too broad and affects the FontAwesome icon 'file-image-o' outside of the image inputfield when the noFilenameTruncate option is active (e.g. in the icon picker or in the module listing if that icon is used for a module).

Well, you could say that PW has a gap when it comes to front-end anything. I don't know if there's a good authoritative document explaining this anywhere, but I think it's fair to say that part of the PW philosophy is that the core does not get involved with the front-end of your site. Depending on how experienced you are with front-end development this is either something that makes your job easier or more difficult. So you have all the freedom (likewise, responsibility) to do whatever you want with your front-end and PW will never mess it all up for you (likewise, help build your front-end for you).