MarkE

@TomPich I think the decision re the PW back-end is quite critical in terms of time estimation. Using it will save a lot of coding for an app like this. But a custom CRUD interface, if well-designed, might be easier to use. For my membership app, I went with a highly-constrained PW backend provided through modals (my "AdminInModal" module), in a front-end wrapper, which limits users to just their data for specific pages. The system has about 200 non-techy users who have no problem with the interface. +1

I am currently redeveloping a ProcessWire app I wrote a few years back. The app provides integrated website and admin system for a membership organisation and has worked very well. I have other potential users for a similar system, so I am making it more generic and portable, as well as enhancing maintainability and appearance. The system uses quite a large number of custom modules (mostly Process modules but some Lister Page Actions) plus templates and custom Page Classes. I am now writing a ‘wrapper’ module which will hold settings in its config and include all the init and ready scripts. My question is what is the best practice for structuring the directories? I am pretty clear that it would be a good idea to bundle all the custom process modules in the directory for the ‘wrapper’ module. I could also put all the Page Classes there, but is it better to leave them in a separate classes directory? If anyone has done something similar, I would be interested to know how you structured it, and any related thoughts you might have. Thanks

Hi @adrian, @Pete & @tires and anyone else interested in this module. As I said above, I was using this on one site and am now looking at using it more widely as it is very useful for sending emails to a group: the email is saved to a page then forwarded (via LazyCron) to a list, a record thus being maintained of all such emails. Generally it has worked well without the suggested imap upgrade. However, I recently encountered a problem. The email import is triggered by a hook on Page render. My new pagebuilder module (not released) uses multiple PW pages per displayed page. I think the rapid-fire execution caused the emails to be picked up multiple times without the server deleting them. I tried replacing the hook, without success, with a LazyCron hook. Instead I have just added a session var so that the import cannot happen more than once a minute. I'm afraid my technical understanding of the cause of this problem is (very) limited, but I wonder whether it would also be an issue with imap...

Great addition @ryan Had you thought about dealing with hierarchies in the same way as repeaters? Then there would be almost no need to use the separate children tab.

It works for me too in a similar context - i.e. when calling it to output: i.e in {$page->foo()} - but not when called in a variable declaration - ie. {var $foo = $page->foo()} That's when I seem to need {var $foo = $page->ProcessWire\foo()}. Odd. EDIT - Correction: The issue occurs not with page classes but just with functions defined in init.php (which is in the ProcessWire namespace.

I do love Latte, but one little thing is puzzling me at the moment: namespaces. I am using custom page classes for all my 'business logic' - e.g a method getEmailHash() in the custom page class called in the Latte script with $page->getEmailHash(). The class has the namespace ProcessWire. It seems that I always need to specify the namespace in the method - i.e. $page->ProcessWire\getEmailHash(). Is there a way of avoiding this?

I've only just spotted this but, in my ddev environment, if I modified a page the modified date was always recorded as one hour earlier. So appears on the settings tab immediately after doing a modification (at 14:55). The production environment was OK. I have $config->timezone = 'Europe/London'; throughout in config.php. It seems that you also need to set the timezone (in my case 'timezone: Europe/London') in the ddev config.yaml

Thanks @Robin S - I think that's an improvement (although I'm not sure if it may be slightly less efficient). However, it doesn't really solve my problem: I realise after sleeping on it that my code is actually setting both sides of the pair anyway and so may be conflicting with ConnectPageFields. I changed my code to save the page with 'noHooks' => true and it all works fine. It also fixes the earlier problem, so I'll update your issue for that as it was proving difficult to tie down the source of the null page. 'noHooks' may have side effects, however, and I'm wondering if I can just temporarily turn off ConnectPageFields. EDIT: not updated issue as the issue description perfectly explains the problem outside my context

Hi @Robin S. I'm still investigating this. However, in the course of my investigations, I discovered another problem I was having with the ConnectPageFields::updateConnectedFields($page, $field) method. What I understand happens is that the entire array of connected fields which pair with the field on the page is run through and an update occurs if the page passes the 'isValidPage' test for the other field. Unfortunately, 'isValidPage' also sets an _isValidPage attribute (error message) which then seems to 'stick' on the page. In my particular usage, this seemed to prevent the valid 'other field' (which occurred later in the connected fields array) from updating. I'm probably being a bit thick (it is a bit late here) but I don't see why fields are attempted to be updated when they don't exist on the page. I added if(!$page->hasField($other_fname)) continue; after line $other_fname = $other_field->name; and everything seemed to update fine. I can provide more background to the situation if required. EDIT: Actually that last bit is not the right solution, but I need to sleep on it!

Hi @adrian. I just tried to use this module for the first time and hit a snag. If a config field references a page, then the module uses the page id as the value. Fair enough, but it does not work if the target environment has different page ids (which may be the case if your development database is not an exact clone of the production database - in which case you probably don't need this module anyway). In my ProcessDbMigrate module, I get round this by converting ids to paths (and providing a mapping if the paths have changed - which is far less likely). I was going to add a module migration component to ProcessDbMigrate, but then came across this module which I thought would do the trick. Is it possible to modify ModuleSettingsImportExport, or am I best to go ahead with my original plan and extend ProcessDbMigrate, in which case, can I 'borrow' a bit of code from your module (with accreditation)?

Interesting topic and also interesting to compare the various CMSs at https://openalternative.co/categories/cms. Unfortunately it is not possible at-a-glance to see what is a pure CMS and what is more of a framework. The initial attraction of ProcessWire to me was that it combines the ease of use / UI of a CMS with the power and flexibility of a framework. This means that you can build a fully functional custom app but still enable non-technical editors to access the content they need. Which of the “ProcessWire-like” CMSs do that?

I'll investigate. I suspect it may be connected with an export method that never seemed to have been completely finished although part of the core.

Thanks @Robin S. I also got this error (after the fix), which might be related: As you can see, it seems to be caused by a null item being included in an implode. I'm seeing if I can fix that too. Update: Added this after line 125, which seems to fix it: // Remove any null pages and continue if the new value is empty if(!$new_value) continue; if($new_value instanceof PageArray) { foreach ($new_value as $valueItem) { if ($valueItem instanceof NullPage) { $new_value->remove($valueItem); } } if($new_value->count() == 0) continue; if($new_value->count() == 1) { $new_value = $new_value->first(); $this_is_multi = false; } } else { if($new_value instanceof NullPage) continue; } I'm not sure how the null pages were getting in there - probably something specific to my set-up - but hopefully the above code doesn't have any side-effects.

Hi @Robin S, I just had the following error message: I'm not sure exactly what caused it, but changing line 144 to if(!$item->fields || !$item->fields->get($other_fname)) continue; seemed to do the trick

Have you tried giving the editor role page-sort permission on the parent template?