MarkE

Friday at 10:40 PM

Minor request. Is it possible to use the 'test' function when wireMailRouter is installed? I get "Couldn't get the right WireMail-Module (WireMailSmtp). found: WireMailRouter"

If I set $config->wireMail('module', 'WireMailSmtp'); temporarily then it works, but I wonder if it is possible for the module to supply that as an override when testing?

August 29

Nice module @Robin S. I have just one problem - if the string is too long, it gets truncated in the log and then doesn't conform to the json format so the module doesn't transform it. Any ideas?

August 18

On 7/14/2024 at 11:30 AM, bernhard said:

Does it have a feature to auto-close the modal after page save (without errors) and then reload the page?

Hi @bernhard. I have now a 'close on save' feature as an option.

    *   'close-on-save' => 'no',  // "no": no close-on-save, "":  allow, but any error, warning or message will prevent close-on-save,
                                  // "messages": allow close if there are only messages, "errors warnings messages": always close regardless of notices
                                  // If "add" is included in the list, then the popup will close on save if it is a page add operation, otherwise it will remain open to edit

There was already an option to reload/redirect the page on close:

    *   'redirect' => '.', // url to redirect to after closing the modal - default is to reload the current page (use redirect => '' to suppress). 
                              Use '#divid' to scroll to a specific div on current page

All defaults can be changed in the module config.

August 17

Does this help? https://github.com/MetaTunes/CustomDependSelects

August 13

17 hours ago, Jonathan Lahijani said:

take an existing non-RM PW project and start using RM in its entirety

Apologies if this is slightly off-topic, but it was one of the reasons I took a different approach with ProcessDbmigrate. That creates and reads json files and can be used on any existing database. Since I first built it, RockMigrations has moved on quite a bit, but I still like my module. I recently used it to create a skeleton site from an existing project, for example - just the fields, templates and pages I wanted. I have for some time been considering making it more interoperable with RockMigrations - e.g. to create the migrate code from the json file. I don’t know whether that would help, and haven’t really started looking at in detail, but it’s a thought.

August 2

Solution?

I do think the InputfieldSelector module needs enhancing.

What I have done is to add the following:

after line 841:

if($settings['limitFields']) $this->set('limitFields', $settings['limitFields']);

after line 915 (line numbers are assuming line inserted as above):

if($name === 'parent' && isset($limitSubfields['parent'])) {
					$name = 'parent.';
				}

after (now) line 1516:

$limitSubfields = array();
			if(is_array($this->limitFields)) {
				foreach($this->limitFields as $limitField) {
					if(strpos($limitField, '.') === false) continue;
					if(strpos($limitField, $fieldName) !== 0) continue;
					list($limitField, $limitSubfield) = explode('.', $limitField);
					if($limitField) {
					} // ignore
					if($limitSubfield) $limitSubfields[$limitSubfield] = $limitSubfield;
				}
			}

(the above is a copy from elsewhere in the script so would probably be better as a new method)

after (now) line 1535:

'limitFields' => $limitSubfields,

If anyone wants to play with that and let me know what they think, then that would be great. Otherwise, I'll just post it as an issue.

August 2

Still struggling with this. It seems like just including 'parent.' (notice the dot) in the limitFields will show parent as an option. HOWEVER, the subfield options are then the same (main) field names as those that are in limitFields, which obviously makes no sense in the context of the parent. Using parent.subfield has no effect.

August 1

The InputfieldSelector module documents the property 'limitFields'. This property is very useful as it enables you to present the user with only the fields you want them to use. Not documented (as far as I can see) is that you can also limit subfields by use of a dot - e.g. 'field.subfield'. This is also really useful. However, it does not seem to operate with parent, which is where it would be really really useful.

There is a subtle line in the module (line 915 in my version 3.0.239):

if($name === 'parent' && empty($selected)) continue; // we only show "parent." unless "parent" it was somehow already selected

It looks like it is trying to prevent the use of parent in limitFields UNLESS it has a subfield. I'm not quite sure why, but in any case in practice it seems to eliminate both 'parent' and 'parent.xxx' (presumably the dot got stripped somewhere - I haven't investigated closely). If I comment out the line then parent will be included in the field selection, but subfield selection is not possible, so clearly something else is going on as well).

Is this a bug, or am I missing something?

July 31

32 minutes ago, MarkE said:

It has additional functionality

I should also say that FEEL has some additional features, such as autoclose on save, which I am looking into.

July 31

8 minutes ago, zoeck said:

Does the module actually do the same thing as the ‘FEEL module’ or are there big differences?

I wrote it as an alternative to FEEL, which I had problems with - in particular it didn't work properly on a iPad. It has additional functionality. It can be used in the back end as a replacement for pw-modal, as well as in the front end and has a range of configurable options.

v0.3.3 includes an ability to reload the host page after closing, with the addition of a specified hash target. I am using this, for example, to scroll to the location of a newly-added block (aka page) within a display page (built with my home-made page builder). So for example (in Latte), this code in the host page/block:

    {var $motifResourceItemId = $templates->get('name=Motif-resource-item')->id}
    {var $addPage =  $urls->admin . "page/add/?parent_id=$page->id&template_id=$motifResourceItemId?modal=1"}    

	{* Use the AdminInModal module if installed as it reloads on close *}
    {var $ids = $pages->findIDs("id>0")} {* Get the biggest ID so that we can anticipate the next ID with the redirect*}
    {if ProcessWire\wire()->modules->isInstalled('AdminInModal')}
        {$page->aim([
        'href' => $addPage,
        'text' => "Add new resource item",
        'save-head-button' => 0,
        'header-text' => "Publish (at bottom of modal) to add the new resource item, or save it as a draft before closing with x ------>",
        'class' => "bg-[var(--motif-links)] text-white p-3 text-l uppercase w-fit h-fit",
        'redirect' => '#resource-item' . array_pop($ids) + 1,
        ])|noescape}
    {else}
        <a class="bg-[var(--motif-links)] text-white p-3 text-l uppercase w-fit h-fit pw-modal"  href="{$addPage}">Add new resource item</a>
    {/if}

with this js to open a containing <details> element and scroll to the target:

// Purpose: Open the target details element when the page is loaded with a hash.
// Source: https://stackoverflow.com/questions/37033406/automatically-open-details-element-on-id-call#37033774/
document.addEventListener('DOMContentLoaded', function() {
    function openTarget() {
        // console.log('openTarget');
        const hash = location.hash.substring(1);
        // console.log('Hash:', hash); // Debugging line
        if (hash) {
            const target = document.getElementById(hash);
            // console.log('Target:', target); // Debugging line
            if (target) {
                const details = target.closest('details');
                // console.log('Details:', details); // Debugging line
                if (details) {
                    details.open = true;
                    // console.log('Details opened'); // Debugging line
                    // Scroll the target element into view as it does not always seem to happen automatically
                    requestAnimationFrame(() => {
                        target.scrollIntoView({ behavior: 'smooth', block: 'nearest' });
                    });
                }
            }
        }
    }

    openTarget(); // onload
    window.addEventListener('hashchange', openTarget);
});

July 28

10 minutes ago, Robin S said:

You can use Ryan's ProcessDatabaseBackups module to do this.

Aha! Always something more to learn... I use that module a lot, but never explored individual tables. I guess it's fine where the tables are 'stand-alone' as in this case, but otherwise it might get a bit scary.

No matter, the module was quite quick and fun to write and hopefully carries less risk of screwing up the database ?

EDIT: Plus I can integrate it into my migrations module if I want to.

July 27

No replies to the above and no solutions I could find, so I built my own module. See here

July 27

See my query here:

My solution was to bulid my own module - HannaMigrate. Basically it exports or imports all Hanna codes in a database.

It was built to use along with my migration module ProcessDbMigrate, but should operate without it (but not tested).

It provides 2 methods exportAll() and importAll()

Simple usage:

Install the module.
Use TracyDebugger console in the source database to:
$hannaMig = $modules->get('HannaMigrate'); $hannaMig->exportAll('optional_migration_name');
where optional_migration_name is a name of a related migration, if you are using ProcessDbMigrate. Otherwise leave blank and the code will be in assets/migrations/hanna-codes/.
Then use TracyDebugger console in the target database to:
$hannaMig = $modules->get('HannaMigrate'); $hannaMig->importAll('optional_migration_name');
(Do this while on the Hanna Codes page, then refresh the page to see the results and any error messages).

You could also use the methods in your own code. I may look to integrating it more fully in ProcessDbMigrate.

July 26

On 8/7/2021 at 9:05 AM, Robin S said:
So rather than needing anything like...

On 8/7/2021 at 8:04 AM, SwimToWin said:

path^!=/foo/|/bar/|/baz/

...you can instead do...
has_parent!=/foo/|/bar/|/baz/

Long time ago, but another gem from @Robin S!

July 26

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?

July 23

17 hours ago, Robin S said:

I tried it just now without HannaCodeDialog installed and TextformatterHannaCode didn't successfully replace the nested tags.

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

July 23

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

July 22

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:

July 20

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

July 14

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.

July 14

8 minutes ago, bernhard said:

Does it have a feature to auto-close the modal after page save

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

July 14

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.

July 13

46 minutes ago, bvfbarten said:

Something that would be nice is an easier way to handle multisites

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.

July 13

7 hours ago, Robin S said:

I'd like to second this. It would be great if the new/improved admin theme was built with maximum customisability in mind. One use case is so that we can more easily offer a "mostly-frontend" user an admin experience that's radically different to what a superuser or site administrator gets in the uncustomised admin.

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.

July 10

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!

Sign In

Profiles

Forums

Store

Posts posted by MarkE