MarkE

...you can instead do... has_parent!=/foo/|/bar/|/baz/ Long time ago, but another gem from @Robin S!

I have a site with a large number of Hanna codes which I want to use on another site. How can I do this without manually exporting and importing each one?

Funny that - the code itself is working fine. I'll look into alternatives. Ta.

HI @Soma. Is this module being maintained? I have a reported warning (PHP8.1): PHP Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated in .../modules/FieldtypeColorPicker/InputfieldColorPicker.module:65

Hi @Robin S. I've been using this successfully for many years but have come across a problem with nested hanna codes. For instance, I have [[link_from_outside link_text="My Group" page_path="?email=[[login_email]]&hash=[[login_hash]]&open=membership"]] When I double click on that, the text box for page_path is blank. If I double click on [[login_email]] or [[login_hash]] then it opens the dialog box for those codes, but it doesn't seem to like them nested in page_path (which works fine if there are no nested codes). Is this fixable or do I just have to live with it and edit it manually (which is a bit awkward as the 'widget' interferes)? PS This image sort-of illustrates the problem with the broken shading:

Interesting module. Historically, I have achieved a similar result by hijacking TextformatterHannaCode, but this looks like it might be a better way.

Until it is in the modules library, you can get it here https://github.com/MetaTunes/AdminInModal EDIT: Now in the library, Also I have released v0.3.0 which allows the defaults to be configurable.

No. You have to click the close box. It will reload the launching page (configurable). I could look at adding that.

I thought I would share this as I am finding it increasingly useful and am often using it to replace the standard PW modal. It allows display and customisation of admin page in front end as well as back end via a modal. In the modules library at https://processwire.com/modules/admin-in-modal/ . Also here https://github.com/MetaTunes/AdminInModal This module provides a Page hook method ($page->aim($array)) for front-end use and a similar Inputfield hook (for back-end use) to render a link to a lightbox modal containing an admin page. Optionally, class styling can be passed, otherwise default button styling is supplied. Full list of options and defaults for the array is : 'href' => null, // the url for the linked page (including any required GET params) 'text' => '##', // the text that will appear in the link 'class' => "uk-button uk-button-primary", // any suitable styling for an <a> tag 'width' => '90%', // size for iframe 'height' => '95%', 'header-text' => 'Save required changes before closing -->', // Text to appear above top left of modal 'save-head-button' => '1', // Adds a save button at the top of the modal. Set to '0' to omit. 'suppress-notices' => 'messages', // e.g. null/[]: no suppression, 'messages': suppress messages, 'warnings messages': suppress warnings & messages, 'errors': suppress errors 'close-button' => '1', // set to '0' to remove close button (but you'd better be sure you know how the modal will be closed!) 'redirect' => '.', // url to redirect to after closing the modal - default is to reload the current page (use redirect => '' to suppress) (From v0.3.0, these defaults can be configured in the module settings). For front-end use, the lightbox will only be rendered if the page is editable by the current user. Configure editability of the page by calling a hook after User::hasPagePermission The lightbox is provided by the Magnific popup, which is in the PW core. Although I have used it quite a lot, I cannot say that it has been fully tested, so is alpha at this stage and should be used with care. It is the user's responsibility to check that it suits their needs. Because it allows access to the admin back-end, particular care should be taken to restrict page-edit access.

Absolutely. I have one app where I have separaate sites for the public website and the admin website. I did it this way because the confusion of templates and fields would be too great otherwise, but the two sites need to interact (booking availability for holiday lettings). However I encountered a number of problems as a consequence and a neater way of doing it would be great, as well as fitting in with the suggested move to a more (or even more) 'app-capable' approach.

Hmm. I have a lot of sympathy with this, having created a number of quite complex apps, but wonder whether it can be done while maintaining what currently makes ProcessWire so distinctive. Would it lead to a more direct comparison with competitor “full frameworks” and possible future compromises? I have managed to accomplish quite a bit of @Robin S’s objectives using process modules and my AdminInModal module. A more core way of doing it would be nice, however.

See https://github.com/MetaTunes/GoCardlessConfig I built this little module to hold some API keys for GoCardless as I wanted them to be accessible by superuser but without having access to underlying files and code. I'd be interested in views regarding the security of this approach. I realise that there are more secure ways of holding API keys, but a balance has to be struck between usability and security. To avoid inadvertent disclosure or amendment, it requires the superuser to re-enter their password to access the keys. It could easily be amended to hold other types of keys, if that is useful to anyone. Any improvements are also welcome!

This is not really a question or a tutorial, but merely an observation in case it helps anyone else. I have a site which I built before the custom page classes became available in the core, using a similar approach to this: https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/ To achieve this, I set the pageClass property of the relevant templates to be the same as the template name. I have now refactored the site to use the core custom page class functionality. I didn't change the pageClass property. Until then, I hadn't realised that $template->pageClass and $template->getPageClass() would yield different results, but they do. For instance, if the template name is 'Collection' and the pageClass property is set on the system tab to be 'Collection': $template->pageClass is 'Collection' $template->getPageClass() is: 'Collection' if that class exists (this was the case in my initial implementation - hence why I didn't realise the difference between pageClass and getPageClass() ) 'Page' if the Collection class does not exist and $config->usePageClasses is not set 'CollectionPage' if that class exists, the Collection class does not exist and $config->usePageClasses = true 'Page' if the Collection and CollectionPage classes do not exist and $config->usePageClasses = true In the last two cases, getPageClass() will output a warning "Template '$template' page class '$pageClass' is not available" Removing the pageClass property from the template results in: $template->pageClass is '' $template->getPageClass() is: 'Page' if $config->usePageClasses is not set 'CollectionPage' if that class exists and $config->usePageClasses = true 'Page' if the CollectionPage class does not exist and $config->usePageClasses = true In this case, no warnings are output. Bottom line: if you are migrating from the 'old' approach to the use of core custom page classes, beware of any instances of $template->pageClass as you may need to change them to $template->getPageClass().

Thanks @BitPoet. I can't get that to work, but this does work: $this->wire()->addHookAfter('ProcessPageEdit::buildForm', function(HookEvent $event) { $form = $event->return; foreach($form->getAll() as $f) { // Check if this is the repeater field you want to modify if($f instanceof InputfieldRepeater && $f->name == 'motif_image_component') { foreach($f->value() as $repeaterItem) { $toggleField = $repeaterItem->getField('motif_toggle_position'); $value = $repeaterItem->motif_toggle_position; if($toggleField) { $yesLabel = $repeaterItem->fieldgroup->getField($toggleField, true)->yesLabel; $noLabel = $repeaterItem->fieldgroup->getField($toggleField, true)->noLabel; $otherLabel = $repeaterItem->fieldgroup->getField($toggleField, true)->otherLabel; $toggleField->set('yesLabel', $yesLabel); $toggleField->set('noLabel', $noLabel); $toggleField->set('otherLabel', $otherLabel); } } } } }); I guess it would be nice to make it generic - which your hook tries to be. I can't see how to do that with a buildForm hook. However, I wonder whether it is worth raising an issue here, since surely all labels for a repeater field should be in the repeater field template context?

That's exactly what I've now done and it works fine. It was a bit of a hassle refactoring it, but worth it. Thanks to all ?

That's pretty much exactly what I am doing. I thought the permission would only apply to the page as well, but it seems that I am wrong. That doesn't work as it needs the permission to load the module with noPermissionCheck ?. It just results in "You do not have permission to execute this module..." without even any debugging! ?but it was a bit late last night Yeah I thought about that, but it was going to be a bit of a hassle compared with my little hack. Undoubtedly this is the right answer given that I (together with@Robin S, so I am in good company) was wrong in my assumption as to how the permissions work. I note that 'Process module king' @bernharddid a little module "RockHitCounter" where he adopted this approach, presumably for the same reason - so that the page is in a separate Process module with the permission, which is installed by the main module which has no permission.

Perhaps I should have elaborated more: the methods (and static functions) are entirely called within the API from Page Class scripts, so the requests are not coming directly from the front end. Perhaps that gives me a clue - to assign the permission before making the calls? EDIT: So I added this around the main include script for the rendering using the module and it seems to work well without having to manually set (or save) permissions: //Assign the required permission to access the ProcessMotif module temporarily $guest = $roles->get('guest'); $guest->addPermission('admin'); $guest->addPermission('admin-motif'); // NB the permissions are not saved include_once(wire('config')->paths->siteModules . 'ProcessMotif/include/_motif_include.php'); //Remove the temporary permission to access the ProcessMotif module $guest->removePermission('admin-motif'); $guest->removePermission('admin');

I have built a custom page-builder module 'ProcessMotif' (to be released if I ever get it working to my satisfaction!) and have hit a small snag with permissions. The module is a process module and has a page that I want to appear on the main menu and be available to certain roles. The only way I can seem to get it to appear like that is to set the permission 'admin-motif' in the module info and assign it to the relevant roles. Without that permission set, the page is only visible to superusers. However, the module also has a whole bunch of methods that need to be executed by guest and other users to navigate the site. If I give the module a permission, then I need to assign that permission to the guest role otherwise they can't see anything. I don't want to have to do that. I get the feeling that I'm missing something obvious and basic here, but I've read all the stuff about process modules (especially the excellent stuff by @bernhard here and here) but am none the wiser on this point. Anyone got any ideas? Ta.

Repeater fields allow you to customise the labels - eg '#n {title}' where title is a field within the repeater field. One of my repeaters includes a (3 position) toggle field 'motif_toggle_position': the base field has just 'Yes', 'No' and 'Other' labels for the three positions, but I have modifield this in the repeater field template context to be 'Left', 'Centre' and 'Right'. It is those context-dependent labels that I want to appear in my repeater field labels. '#n {motif_toggle_position}' gives me the base field labels, not the context-dependent labels; how do I achieve that? My friendly AI suggests using a hook on ProcessPageEdit::buildForm (hooks with subtle syntactical errors seem to be its solution to most problems ?) but I was hoping there would be a more 'natural' way. In fact, given that the repeater label is within the repeater field template context, I don't understand why the base field labels are given in preference to the context ones anyway.

At the moment it is for my own use, but if I like it I will probably tidy it up and release it.

Another issue for anyone else using this module: Line 625 of ProcessEmailToPage.module has $attachment['filename'] = $this->sanitizer->pageName($attachment['filename'], true); I don't know why the pageName sanitizer is being used to sanitize a file name, but this gives an incorrect result if the file name has brackets in it. In my version, I have changed pageName to fileName.

Hi @joshua. I'm developing a little Matomo module myself, which will also have a 'dashboard' in PW to embed various widgets. The plan is to do it so that it is GDPR compliant without any 'unnecessary' cookies. Your code is very similar to what I have done so far. I hope it's OK to borrow some of your code (with credits!). ?

That’s great @ryan. You may call it a “simple” module, but it think it will be an important addition to ProcessWire’s capabilities.

Thanks @adrian. There's so much in Tracy that I still haven't fully explored. That actually seems a really useful feature. Now I understand why it's called 16 times - because my site has 16 roles (which needs a bit of rationalisation, I think!).

Sorry - maybe I confused things by providing the context: that was just an explanation as to why I added a bd to the hook (to try and understand how it was being triggered). I was then puzzled that Tracy appears to call it multiple times - in my case 16 exact same repetitions. Try this in ready.php wire()->addHookBefore('Page::moveable', function(HookEvent $event) { $page = $event->object; bd($page, 'page'); bd(Debug::backtrace(), 'backtrace'); }); Then open the page tree. Tracy appears to call the hook multiple times for page id 3 ('page'), but I don't understand why. In my case I got 16 of the dumps illustrated in my OP.