elabx

@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:

1 hour ago, ryangorley said:

So I would imagine that the best way to handle categories would be to create sub pages of the blog page for each category and then create the posts themselves as children of the relevant categories, right?

I'd say the best way is the one that fits your use case and in that sense ProcessWire has no rules about categorization.

1 hour ago, ryangorley said:

The big question is how do I go about automatically generating archives of all the blog posts that share each tag? Tags need to be shared across categories, so the sub page method wouldn't work as a fallback. Someone must have figured this out, but I can't find anything documented.

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. 

1 hour ago, ryangorley said:

Publish Date:

So I get that I can add a date field and build some logic into the queries to not show pages if today is prior to that value. I imagine I would use the $user ->isLoggedin() method to display the page content if today is prior to that date value as well. I don't love doing things this way because my sitemap (generated by SEOMaestro) is going to list these pages, and they are going to get indexed by crawlers as empty. I'm wondering if there is some better method for handling this functionality.

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.

9 hours ago, Mohit said:

Actually I had htpassword ON so it was not saving information after stripe success neither was sending mail.

Aha! gotcha!

9 hours ago, Mohit said:

Still not sure what's the logic behind that. Would be great to know that also.

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!

2 minutes ago, bernhard said:

But I'm not sure how useful that would be compared to calling the module directly:

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

4 hours ago, bernhard said:

I don't understand 🙂 

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.

6 hours ago, ryan said:

In any case, if using 3.0.215 you probably want to update to 3.0.228. 

Actually the issue is with 3.0228! Is this the moment where I learn not to upodate/deploy on friday? haha

6 hours ago, ryan said:

Other parts of your selector to look at would be the created_users_id!=41, since that would exclude all pages created by the original superuser. Also city_id|cities=11669 seems like it might be worth removing temporarily to test as well,

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

9 hours ago, Ivan Gretsky said:

@Jonathan Lahijani, would you mind elaborating on this a bit? How do you manage your frontend without node based build chain? I am very interested as I am moving along a similar path, having ditched gulp. Now I do not even concatenate my js leaving it to http2. The only thing i still compile is scss) How do you do it nowadays?

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

13 hours ago, fruid said:

I'm not sure if creating adding a field and adding it to a fieldgroup and template is necessary (also this approach is quite prone to errors, I have to consider __install() and __uninstall() etc.),

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.