elabx

It seems this got updated in the last few versions: Check this thread: https://github.com/processwire/processwire-issues/issues/1791 And also this commit which has new $config options: https://github.com/processwire/processwire/commit/013231acdabd7b42640c1a9975c9e54ecf366b45

@ryan Out of curiosity, and of it's possible to share publicly, were you working in something in particular in the PW admin where you needed to add custom attributes?

Hi @ryangorley! Not sure if you've taken at this old but still very relevant post: I'd say the best way is the one that fits your use case and in that sense ProcessWire has no rules about categorization. The tags can exist under their own parent separate from the "News > Blog Item 1" tree branch: /tags/tag-1 And be linked through the tags inputfield, it's pretty much the same case for categories. To my own personal taste I always tend to go with an structure like this: - 📑 News -- 📋 Tags ---- 📗 Tag 1 ---- 📗 Tag 2 -- 📋 Categories ---- 📗 Category 1 ---- 📗 Category 2 -- 📘 News Item 1 -- 📘 News Item 2 I like this because it keeps everything in the context of the "News" for the editors, and also the following URL structures which makes sense to me (not so sure about SEO but have had no complaints lol): /news/tags/tag-1 /news/categories/category-1 /news/news-item-1 The only part I'm not a huge fan of is that it requires a bit of code using hooks to keep the right sort underneath the "News" page, since the actual news items share a parent with the tag/categories parent, sorting the News children by published reversed, will (most likely) send the Tags and Categories to the bottom. But it ain't that big of a deal and if the problem arises to you I'll gladly share my solution. Also, to my own taste, I use a custom field for publish date, this lets me have more control over it and handle the visibility of the actual post with the hidden/unpublished status depending on what I want to achieve. Now for archive pages i'd suggest you take a look at what @ryan did in this old but also still relevant blog profile: https://github.com/ryancramerdesign/BlogProfile/blob/master/site-blog/templates/archives.php In all fairness this is not the clearest example and it's one of those part you'd expect to be built by default in a CMS, but I always think these details are worth the effort as a sacrifice for the flexibility PW gives you in terms of data structure/relation.

Maybe this part should be: $form = $forms->render('kontakt', [ 'form_page' => $page->parent->title . " " . $page->title , 'page_with_contact_email' => $page->parent("contact_email!="); ]); So this part: $page->parent("contact_email!="); Should traverse upwards from the page where the form is rendering until it finds a page with the contact_email fileld.

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.