MarkE

Sorry - I misunderstood the original comment. However it did cause me to investigate the other issue... That was exactly what I was thinking - and that 'getFresh' might fix it. Based on a bit of testing, it seems like your 2 changes do the job 😀

Just been playing with this. If I edit a field in a child (in a modal) and click 'save' within the modal, then re-edit the child in a modal without saving the parent, then it seems like the change is not saved, regardless of any viewing that might or might not have taken place. In detail: If I edit the child, change a field, save it and close the modal, then save the parent without re-opening the child edit then the change works. If I edit the child, change a field, save it and close the modal, then re-open the child for editing or viewing (in modal or new tab), sometimes* the change has not been made. If I close it again without changing anything, then save the parent then the change is seen not to have worked. *"Sometimes": It seems that if this is the first time I have edited a child then the change does not persist without saving the parent before opening the child again. However, if I have previously edited a child in a table (and saved the parent) then edit it again, it seems like the change does persist after saving the child, without re-saving the parent, regardless of any viewing activity. I'm not sure what is going on here, but it doesn't seem to be anything to do with whether viewing is in a modal or new tab. PS. Sometimes, in situation 2, I get a 'do you want to leave' message when trying to save the parent, but I haven't worked out exactly which combination of circumstances gives rise to that.

I guess that makes sense but is not fully consistent with page list which would require a long click for modal edit too. I'm not sure I understand that - I can't replicate it. In what circumstances is it a problem?

Hi @adrian. Is there any reason why, in the batch child editor, 'edit' opens in a modal but 'view' opens with a new tab. I would prefer consistency (with view opening in a modal) and have done a simple hack to replace the link (target="_blank") with a modal link (class="pw-modal") but obviously that is not a good answer. I appreciate that changing it might upset others (and there may be a good reason why you did that way). Perhaps it could be configurable (panel, modal , new) as in the main page edit?

Done.

Hi @adrian. Thanks for the comments. That was the intention, but I missed it in one important place - hopefully now fixed. I think my new version handles this. Ditto. My code only replaces config items which have page, field, template, role, or user in the key name (case insensitive) and where the value is numeric and is a valid id for the related type. Hopefully this avoids the problem you mention. If someone builds a module with a type name included in the config key with numeric values which are valid ids, but where the values are not intended to refer to ids of that object type, then it won’t work, but that just seems really perverse to me! I have uploaded the new code to my GitHub and have incremented the version and amended the ReadMe. Obviously it is pretty hard to test it on all modules, certainly as regards importing, but it seems ok so far. Let me know if you find any exceptions. One module that causes problems is (deprecated?) ProcessEmailToPage but it is a problem even without my changes. That is because the configdata is wrong - it self-overwrites - so not something that your module can fix, I think.

Hi @adrian (and @Robin S if interested). I have forked your module and added a config field to use names/paths rather than ids. Fork is here: https://github.com/MetaTunes/ModuleSettingsImportExport, if you would like to have a look/play. I have tested it with some modules (but not all) and you can easily see the results in the multiple module settings box. Note that it deliberately gives some warning/error messages at the moment. They are not really necessary but do highlight where some modules are not perfectly constructed. Enjoy 😀

Slightly improved version that also caters for when the module uses a static getModuleConfigInputfields: // $module is the module we are interested in (check it is configurable) // $fieldName is the name of the config inputfield $moduleClass = get_class($module); $methodChecker = new \ReflectionMethod($moduleClass,'getModuleConfigInputfields'); if($methodChecker->isStatic()) { $wrap = $module->getModuleConfigInputfields([]); } else { $wrap = new InputfieldWrapper; $module->getModuleConfigInputfields($wrap); } $field = $wrap->get($fieldName); // $field is the inputfield object for $fieldName

This is not really a tutorial, but simply a little trick. I was trying to work on an enhancement for @adrian's module ModuleSettingsImportExport but hit a slight roadblock. For a configurable module I wanted to get the class of an inputfield (set in getModuleConfigInputfields). However I could only see how to get its value, not any way to get the object itself. I did a lot of searching without any result. Then I realised that you could do it like this: // $module is the module we are interested in (check it is configurable) // $fieldName is the name of the config inputfield $wrap = new InputfieldWrapper(); $module->getModuleConfigInputfields($wrap); $field = $wrap->get($fieldName); // $field is the inputfield object for $fieldName Might be of use to someone (if only me when I come across it again 😉)

Hi @adrian. Just coming back to this - after a while as it is a particular issue with ListerPro is you have a lot of listers (I do). This is discussed specifically here: I haven't tried @Kiwi Chris's module but it and ModuleSettingsImportExport (for ListerPro) have the same issue (with template ids as well as page ids). My only solution so far is to paste the json into a file and display it in a neatly nested form so that the id references are obvious. It is then a simple matter (for a human) to manually change the ids to match those in the target database and paste the result into the target module. But, while it may be obvious to a human, it is a bit tricky to devise a reliable algorithm. The best I can come up with so far is: In the source environment, find all occurrences in the config json of words like xxx=yyy (possibly with leading quote and trailing quote or comma) where yyy is an integer If xxx is 'template' then replace yyy with the template name of template id yyy (similarly with field=yyy) Otherwise assume xxx is a page reference and replace yyy with the page path. (It might be possible to be more sophisticated here and check that xxx is the name of a page reference field - or if xxx is of the form www.zzz that zzz is a page reference field. If not, is it a page reference type of selector, e.g. has_parent? Otherwise assume it is just an ordinary integer field - maybe check that too and give an error message if not). Then in the target environment, perform the above in reverse to create the config json. This could perhaps be done as a separate module with export and import methods that just reads and writes json files which can be sourced from and entered into the config fields provided by ModuleSettingsImportExport. Or perhaps it could optionally be included via config setting - 'Convert ids to/from names or paths' - in ModuleSettingsImportExport? What do you think?

Hmm. I can't replicate either of those. I'm not sure exactly what you are trying to do and would really need more details and a backtrace (from Tracy) to see what is going on. While I am happy to try and debug what I can remotely, I wonder if you actually need ProcessDbMigrate at this time. Your comment seems to indicate that it is early days for you with ProcessWire. You don't need ProcessDbMigrate to copy a whole database from one environment to another. The ProcessDatabaseBackups module does this for you (or you can just use phpMyAdmin, but the module is easier). You only need something like ProcessDbMigrate to selectively update parts of a database in one environment from elements in a database in another environment. Typically this is the case with web apps rather than simple websites. The full description of what it does is available here.

What were you trying to do?

v2.0.23 now available should fix that. Just upgrade from the module config (backup first just in case..). At the moment the only 'migration' you will have is the bootstrap to install the module. Please read the help file to understand how to use the module.

That's odd. This is where it is really helpful to install TracyDebugger! It really is 100% recommended when trying to debug. 'Compile error' would normally indicate a problem with just the file in question (WireDebugInfo.php). Are you sure it hasn't been corrupted? What does your IDE show for that file?

Have you got a clean backup?

There should be a link under setup.

Hmm. Not sure why that is. I tested it on a clean site and it all worked smoothly. Do you have any more details? Did you keep a backup before the installation - if so, were there any pages/fields/templates from previous failed ProcessDbMigrate installation attempts? (Check system templates and fields and pages in /admin/ and /admin/setup/)

Hi @Flashmaster82, v2.0.22 released which I hope finally addresses your issue. Please let me know how it goes (and remember, it's still alpha, so take backups at all key points, such as before installing new versions and before installing migrations).

Hmm. I thought I had fixed that.... Bear with me 😁

v2.0.21 released, which I hope fixes your problem @Flashmaster82. Let me know how it goes. Many other bug fixes are included and particular thanks to @Jonathan Lahijani for many of these.

Looks like I forgot to take out a debugging statement and that gives an error if TracyDebugger is not installed. I am planning a new release shortly which should fix that and a few other bugs. Meanwhile @Flashmaster82, if you took a database backup before the installation, you may wish to revert to it so that next time you get a clean install. It may be a couple of days before the next version, so bear with me. BTW, I really do recommend TracyDebugger (but it shouldn't be a requirement!).

Hi @horst. As I suspected your one-liner doesn't work because: Method WireMailRouter::sendSingle does not exist or is not callable in this context Do you have any objection to my suggested change?

I'll do that later this evening @horst. However, the reason I chose to make the change I did, rather than the one you suggest, is because different mail modules permit slightly different methods so the WireMailSmtp methods may not work without changing the class. Also, my suggestion will work as a standalone test of WireMailSmtp even if the current class is something completely different (e.g. WireMailMailgun) and the developer is using a different method from WireMailRouter to switch classes.

I’m not familiar with the SkipInputfieldLabel module, which is the source of the error. It looks like there is some sort of interaction with ProcessDbMigrate, but I think that there should be some error checking in SkipInputfieldLabel. Perhaps @teppo can help? You could try temporarily uninstalling SkipInputfieldLabel but I’m not sure if that would cause a problem with that module.

The only log I have with entries at the relevant time is the error_log created by duplicator which I quoted in my OP at Edit - that is from the target host. There was no relevant log on the source host.