MarkE

I'm afraid I am on a shared server so I only get error logs. 8.1 Actually, I realise it is not as simple as that because all the database settings will be wrong. If I can't use duplicator, I may as well set up a new PW site, ftp the code and restore the database manually. It would be nice to get Duplicator working, though because it is really neat 🙂.

I am moving the site from one web hosting service to another. I have full access via cPanel. The duplicator log indicates that everything was normal: 2024-09-08 18:18:31: - job finished in 372.169112sec 2024-09-08 18:18:31: - package saved in local folder: 2024-09-08_18-12-25-{........}.co.uk.package2.zip 2024-09-08 18:18:31: - package built successfully in 372.167747sec 2024-09-08 18:12:19: - Backup using standard mode 2024-09-08 18:12:19: Backup Database The built package was not openable in windows (including by 7zip) so it seems the fault is in the package not the installation. I tried that - just including wire. No package was built. That didn't fix my problem. Interestingly, the package was twice as big. I think that the problem may be due to the source installation being multi-site. There are two sites - site-ncog and site-music. I only want to duplicate and move site-ncog. There is no /site/ folder. The duplicator doesn't seem to cater explicitly for this (I thought it might duplicate both sites and then I would need to remove one). I see that Duplicator.module has const DUP_SITE_FOLDER = 'site'; I tried changing that to site-ncog, but no package was built. I have a dev site that just has the one site (in a folder called /site/). I haven't tested it fully, but the package was built and was readable in Windows. So one option might be to fully replicate the live site on my dev environment and then duplicate that. This would have some complications with file names, which might be resolvable by renaming /site/ to /site-ncog/ after the duplication.

Hi @flydev. Just running this module for the first time, so excuse any stupid questions. I created the zip (big - over 500mb, but the database itself is only 58mb) and put it and the installer in my new web root I then ran the installer - all the checks were OK but I got an error: [08-Sep-2024 19:14:26 Europe/London] PHP Fatal error: Uncaught ValueError: Invalid or uninitialized Zip object in /home/............./installer.php:736 Stack trace: #0 /home/............../installer.php(736): ZipArchive->extractTo() #1 /home/............../installer.php(105): Installer->extractPackage() #2 /home/............../installer.php(2255): Installer->execute() #3 {main} thrown in /home/.........../installer.php on line 736 I then tried to use the 'native' method, but got exactly the same error. Any ideas?

WireMailRouter was set to use WireMailSmtp as primary method, but (if a from and to is specified in verbose settings) WireMailSmtp ignores the test attempt if it is not the WireMail class name: $mail = wireMail(); if($mail->className != 'WireMailSmtp') { $dump = "<p>Couldn't get the right WireMail-Module (WireMailSmtp). found: {$mail->className}</p>"; } else { So basically the full test will not work if WireMailRouter is installed - only the plain connection test. My suggestions are: The config screen should make it clear that verbose debug settings will not work if WireMailSmtp is not the WireMail class and need to be empty to test the connection only, or that the test should temporarily set the WireMail class to be WireMailSmtp - something like: if($from && $to) { // do a verbose debugging if(!$subject) $subject = 'Debug Testmail'; if(!$body) $body = 'Debug Testmail, äöüß'; $mail = wireMail(); $dump = ''; if($mail->className != 'WireMailSmtp') { $wireMailClass = $mail->className; $this->config->wireMail('module', 'WireMailSmtp'); $mail = wireMail(); $dump .= "<p>Currently installed WireMail class is $wireMailClass. Testing with WireMailSmtp, then reverting to $wireMailClass.</p>"; } $mail->from = $from; $mail->to($to); $mail->subject($subject); $mail->sendSingle(true); $mail->body($body); $dump .= $mail->debugSend(3); if(isset($wireMailClass)) $this->config->wireMail('module', $wireMailClass); } else { // only try a testconnection Personally I'm more inclined to (2), but does anyone else have a view?

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?

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?

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.

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

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.

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.

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.

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?

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

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); });

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.

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

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.

...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.