elabx

Do you have the regions configuration set to true?? In site/config.php $config->useMarkupRegions = true;

I'd need to do a dig in my repositories but I remember doing something like this hooking into InputfieldPage::processInput and updating the parent_id property of the InputfieldPage object before processing the page to be saved, so that it would make it valid.

Aha! gotcha! Do you mean the Stripe webhooks part or how FormBuilder handles the process?

Could you debug if the webhooks are correctly setup and working?? It's the first thing I'd think of, if i remember correctly, the entries will only show on successful payment.

About URL hooks Not sure it has change but once happened to me that I couldn't do optional segments, example: /get-images/{page}/{field}/ Request wouldn't reach if I tried to get to: /get-images/{page}/ Then I think the concept of middleware is not present? So say you want to block unauthenticated calls, check CSRF, etc, you'd have to make that check on every route hook. Probably AppApi is still the way to go, feature wise? Project seems very alive! Edit: Just reading AppApi actually uses path hooks to bootstrap its endpoints.

Ok so the second part of the code, in the template needs a hook to actually work! If you debug $processor variable, it is most likely null! So, in the head.php set this up: <?php wire()->addHookBefore("FormBuilderProcessor::emailFormReady",function($e){ /** @var InputfieldForm **/ $form = $e->arguments(0); /** @var FormBuilderEmail **/ $email = $e->arguments(1); // is this the form where we want to change the behaviour? if($form->name !== "the_form_in_question") return; $page_id = $form->getChildByName('page_with_contact_email'); if($page_id){ $page_with_contact_email = wire('pages')->get($page_id); if($page_with_contact_email->id){ $email->to = $page_with_contact_email->contact_email; } } // Not really sure if this is necessary so try putting it on and off $event->arguments(1, $email); }) $form = $forms->render('kontakt', [ 'form_page' => $page->parent->title . " " . $page->title , 'page_with_contact_email' => $page->parent->id ]); The hook code is a bit different from the previous one I posted since I realised that the contact_ Then on your template: echo $form; Let me know how it goes!

Me neither haha just thought it would be the most simple way to extend RocKMigrations. Install the plugin module and just assume now you can do this in migration code: $rm = $modules->get('RockMigrations'); $rm->migrate([...]); $rm->fooPluginNewMethod();

Like this: https://processwire.com/docs/modules/hooks/#how-can-i-add-a-new-method-via-a-hook I just feel it might make sense for it to be decoupled like because @bernhard might not use some modules and would probably be better if the "migration utilities" of modules he doesn't use are maintained on the side. This comment was targeted more at a thought of a "plugin system".

Wouldn't it be enough to add methods to the class through hooks?? And have like: RockMigrationsProfieldsUtilities, instead of refactoring the main module?

Hi @brandy! Could I take a look at a complete version of the hook code you are trying? If you feel like sharing the whole project with me you can DM me and maybe we'll sort it out with the real install.

Maybe this is a PHP version compatibility issue? Does the OVH version matches your development environment version?

Oh I see! I guess that could work! Did you try?? I hadn't noticed that property was set on the Processor object.

Thanks crew for jumping in! I know this situation is really really odd and I want to dive into what might be happening because I reproduced the same behaviour in live and on my local ddev environment. And went back and forth between 3.0.215 and 3.0.228 to confirm, it also caused issues in other parts where certain results where expected, so I'll dig in those too. Actually the issue is with 3.0228! Is this the moment where I learn not to upodate/deploy on friday? haha Will definitely do some detective work and come back to report.

Is anyone having issues with selectors on the last few updates? I just had to rollback a big site which was showing issues in multiple parts. Unfortunately I don't have time right to make a clean install to reproduce the scenarios but just wanted to communicate in case someone else is having issues. For instance, I have this selector: 'template=ad, parent=1082, ad_status=1, sort=-verified, sort=-created, city_id|cities=11669,created_users_id!=41,title!=test|Test' Which worked just fine, but when updated the same find operation returned 0 pages found. I was able to debug this because the title field in the selector was only used with guest users so that the admin users copuld see these Test pages created, but guests do not. I had to change the selector to the following to make it work again: 'template=ad, parent=1082, ad_status=1, sort=-verified, sort=-created, city_id|cities=11669,created_users_id!=41' Notice that I removed: title!=test|Test So you can imagine my confused face on how would this cause an issue to not find any page at all. The site is on 3.0.215 and and important detail might be that it is using multilanguage.

I think this might be related to: https://github.com/processwire/processwire-issues/issues/1611 And it should be solved at least from 3.0.204 onward.

You know what, I misread your issue. What could probable work is placing a hook in emailFormReady https://processwire.com/store/form-builder/hooks/#where-to-place-hooks wire()->addHookBefore("FormBuilderProcessor::emailFormReady",function($e){ /** @var InputfieldForm **/ $form = $e->arguments(0); /** @var FormBuilderEmail **/ $email = $e->arguments(1); if($form->name !== "the_form_in_question") return; $page_id = $form->getChildByName('form_page_id'); if($page_id){ $contact_email = wire('pages')->get($page_id)->contact_email; $email->to = $contact_email; } }) form_page_id would be a hidden field in the form where you save the page_id, not sure if there is a nicer way to do this! That is, without this hidden field to pass on the id info.

I think you'd have to customize the autoresponder template from FormBuilder. Check the instructions in site/modules/FormBuilder/email-autoresponder.php, in the comments at the top of the file.

I think that as long as the field keeps the Hanna code text formatter, you shouldn't have any issues. About Hannah code insertion in the field, take a look at this: https://github.com/BitPoet/InlineCompleteTinyMCE

I'm also very interested in this answer! I feel I'll never leave compiling SCSS/Less in PHP, even it means using an outdated subset of Less, it's just so convenient! I'm very sold on HTMX + AlpineJS, main reason being it saves me from the build step.

Amazing answer ? proof here

If you want to save the data using the Page object I see no other way than this or the meta object. I do understand it can get troublesome to manage all the custom fields, but I've seen a few module authors handle it like this! I'm not sure if my explanation will be completely correct but I'll give it a shot haha So if you take a look at the Templates class, you'll see that if actually extends WireSaveableItems, which is where persistence to the database is implemented. See how $some_template->save() (Template, no "s") actually calls the $templates->save method (Templates = global $templates). If you take a look at the actual database through phpmyadminer or Adminer and see the templates table, you'll find one row per template and a column named data that holds the template config. This is all thanks to WireSaveableItems! The Page object is different, it doesn't have a data column and it doesn't implement persistence of fields like this. What happens is that each field's Fieldtype implements its own persistence mechanism. So, when you are adding that InputfieldCheckboxes, the Page doesn't know anything about it and later when you assign the Inputfield's value as a property of the Page object it also doesn't know anything about how it should be saved either, this is all delegated to different classes decoupled from the Page class, the Fieldtypes. Check how the PagesEditor class ends up calling savePageField, a method from the Fieldtype abstract class. So when you are adding these properties dynamically these are just set as regular properties, the further process of saving the pages doesn't really know that this property is a field since it's not in the template/fieldgroup assigned to the page and there is no default 'save to the data column on the page table' behaviour.

What if you use the meta() function? Then on adding the field, checking for the state of the data and set the field's checked state accordingly. On the save, instead of saving to the page, use the meta() API.

From what I am understanding there is no "menus" field on the pages your are running this module on, so this won't get saved anywhere when you set it on the $page object. So yes you can add properties to the page, but that doesn't mean that property represents a Field/Fieldtype within the Page, which holds the actual persistence mechanism of the fields. Why not create the "menus" field from the start? Maybe explain a bit further what are you trying to solve with the module?

I very much agree it seems complicated! I am very knew to composer packages myself and this is just the first thing I figured out and it felt ddev made it also really easy to make it "ergonomic" for daily use. It's at least a way that makes sense to me haha and I end up with one extra command ( ddev composer-local {$@} ) that just works when I want to work with my local versions and another command to go back on live/latest.

Yes! This actually has nothing to do with ProcessWire itself So, regularly, you just want to load the composer dependencies and that's it! But what if you want to test a library you are developing, that has it's own dependencies defined through composer. Ideally too, you want this installed on an existing local project. And you wanna do this with composer itself! Composer has of course has this in mind and it has the symlink flag so that composer knows it should load a local copy where you can have a repository checked out on any branch. { "repositories": [ { "type": "path", "url": "../../packages/*", "options": { "symlink": true } } ] } In my long gone and not missed non-ddev days this worked great with just having my repos checked out in a folder above my project's. I just had to include the local path as repositories, and it symlinked the libraries from the upper packages directory. This wasn't perfect, since when working on the local version, the composer.json and composer.locked got edits that I didn't want in the main branch of the project's repo, so on every change I had to rollback updates in this two files, then install again if I wanted to test "live" versions locally, but more on this later. With ddev this is not so straightforward since the container's volume is isolated from the system. So it threw an error regarding not finding the path to that repo. Of course, there is no "../packages" in the container's volume! Hence, we use the first config to enable a path that is reachable by the composer path configuration within the container. The second config for the .env variable of the path is really unnecessary but thought it would be nice to handle this type of thing in a variable, since each developer might place their repositories in whatever other place within their filesystem. .ddev/docker-compose.composer-packages.yaml: services: web: volumes: - "${COMPOSER_PACKAGE_DIRECTORY}:/packages" .ddev/.env COMPOSER_PACKAGE_DIRECTORY="../packages" And the composer.json configuration for the local repo, see how on this case it is defined from the root, since it's where the volume is mounted from the previous instruction. { "repositories": [ { "type": "path", "url": "/packages/*", "options": { "symlink": true } } ] } And this is is like 80% of of the problem solved! The shell script wrapped in the ddev command is a way to not mess with the regular lockfile which is the one I use to deploy to production. So it creates an "alt" composer.json and lockfile to work in a different composer setup on parallel to the one that is your "production" one.