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 ?