kongondo

Thanks for this @Robin S. Maybe this technique can be used to achieve a non-blocking SSE? @bernhard, what do you think? I haven't thought it through; just wondering ATM. For reference:

Hi @nabo, Many thanks for the purchase! I'll work on these; the fixes seem straightforward enough. I'll send you the updated files for testing and look to make an official release for later in the year. I hope this is OK. Thanks!

Very! I have tested your code (verbatim) with both Stripe and Invoice payments and emails are sent in both cases! Maybe your first one (Invoice) ended up in the ether? I am assuming you checked your junk folder.

Hi @Jan Fromm, I can confirm that this is a bug. I have it fixed in my current dev version. I am hoping to make that the next release of Padloper. I hope to do this pretty soon. Hopefully it isn't too late for your needs. Please let me know if it is. Thanks.

Hi @alexm, Exactly. An example: <?php namespace ProcessWire; public function setAddonPage(Page $page, string $addonSettingsFieldName) { // here we assign these variables to class properties for convenience // you don't have to do that // you can use $page directly to get your settings using 'addonSettingsFieldName' $this->addonPage = $page; $this->addonSettingsFieldName = $addonSettingsFieldName; // -------- // EXAMPLE $addonSettingsJSON = $page->get($addonSettingsFieldName); bd($addonSettingsJSON, __METHOD__ . ': $addonSettingsJSON at line #' . __LINE__); if(!empty($addonSettingsJSON)){ $addonSettingsArray = json_decode($addonSettingsJSON,true); // do something with $addonSettingsArray } } I thought I had a hello world addon example in the demo projects. Looks like I don't. I'll add that to my TODO.

1 means that $mail sent 1 message. So, we know that that succeeded. Hmm. I am at a loss about this one. Given that the hook is called an an email is sent, I have no reason to suspect that the hook is perhaps being called late. Do you know if the customer is getting the email being sent by Padloper for this same order? Secondly, just for testing could you please test with Hooking before? Are you able to please test the exact same Hook function but by hooking to another method, e.g. ___saveOrder()? Thanks.

Hey @alexm, the value of that would have to be 'custom'. All non-payment addons must be of type 'custom'. Yes. Sorry about that. I need to state that in the docs. Does this mean your question above about 'getType()' is now sorted? Thanks.

Hey @alexm, Please clarify this. Does it mean the hook is not getting called or does it mean it is returning early (e.g. no $orderPage->id) or email not getting sent or email not getting received ?. If you did $sent = $mail->send(); and dumped $sent, what do you get back?

Morning @alexm, Apologies for the confusing docs (and perhaps naming issues). All non-payment addons must return 'custom' for getType(). Payment addons, even custom ones, are not defined as 'custom' addons. They are defined as payment addons and must return 'payment' for getType(). So, the idea of 'custom' does not mean 'third-party' or 'non-core'. Instead, it means the addon does something that is not necessarily a feature of Padloper, i.e. it does something custom. Since 'payment' is something that is a feature of Padloper, even third-party payment modules are not considered 'custom' since their function/role is to do something that is part of the core function of Padloper, i.e. payments. Hope this makes sense. Will revise docs.

@alexm. Sorry, my bad! I get you now. I'll add this to the settings together with your other idea about a 'from email address'. I'll make a variable, $storeDetails or something like that available to invoice-content-html.php. This will give you access to the bank details saved in the store config. Do you need more than these three pieces of info? Cheers.

Hi @Spinbox. This is coming in the next version (hopefully next week, there are quite a number of changes to it, so it is taking a bit of time). Meanwhile, do you mind using a Hook? I can show you how. Thanks.

@Spinbox. Glad you got it sorted! Things look sanitized correctly. Did you see this topic as well? The docs state that InputfieldPassword::isValidPassword() (https://processwire.com/api/ref/inputfield-password/is-valid-password/: This means that it will use the password requirements set in the backend for ProcessWire users. If that suits your needs, then you could use the method as described in the post I have linked to above. If not, i.e. if you have a different set of requirements, you might have to roll out your own validation. An example is shown in the post I have linked to above. I think you should be fine with matching the requirements sent in the backend (i.e., use InputfieldPassword::isValidPassword() as is). You would need to handle cases where the password is found to be invalid (per your requirements). Hope this helps.

What a gem of a conversation going on here! Thanks @FireWire, @wbmnfktr, @bernhard, etc. Some of stuff mentioned here reminds me of the time I was researching stuff for Padloper. To some extent, I'd put WP and Shopify in the same basket. A massive marketplace of plugins that inevitably leads to ...you know where.. not to mention the backend! No pressure, but I bet that would be helpful to some folk here; much appreciated. From a moderator perspective, I'm happy to split the 'new' conversation here into its own thread if we feel it is tangential to the OP.

Hi @Jan Fromm, Thanks for reporting. Looks like an omission on my part. I'll have a look.

OK. I will re-enable this in a future Padloper version. Meanwhile, I'll send you a PM with a suggestion for an interim solution. Thanks.

Hi @Jan Fromm, Yes. This is currently used for orders created manually (in the backend). What's your use case? I cannot remember why I disabled the saving of the value for frontend use.

@Spinbox. Glad you got it sorted. What @netcarver said is very important. You should never trust user input. Sanitize their inputs (except for passwords; these need to be validated though). Padloper does not involve itself directly with $input->post->email in this case; @Spinbox, you will need to sanitize that yourself since Padloper does not save users on your behalf. However, Padloper cleans the values for the order customer. In your case, you could just get the customer email from the order. Something like below (amendment of your code): untested (but sanitized) - e.g. I don't know how your current $user is getting shippingAddressFirstName. <?php namespace ProcessWire; function processOrderSaveCustomer(HookEvent $event) { $input = $event->input; $user = user(); $users = users(); // $sanitizer = wire('sanitizer'); $currentUser = Null; /** @var Page $orderPage */ $orderPage = $event->arguments('orderPage'); if ($user->isLoggedin()) { $currentUser = $user(); } else { // $currentUserName = $sanitizer->email($input->email); # ---- OR ---- /** @var WireData $orderCustomer */ $orderCustomer = $orderPage->get('padloper_order_customer'); $email = $orderCustomer->email; // ++++++++++++ if($email){ // IF WE HAVE A USER NAME $currentUser = $users->add($email); $currentUser->email = $email; $users->setCurrentUser($currentUser); } } if ($currentUser) { $currentUser->of(false); // @NOTE IF WE HAVE A USER FROM ABOVE, THEY WILL ALREADY HAVE AN EMAIL SO THIS CHECK IS REDUNDANT // $currentUser->email = !empty($currentUser->email) ? $currentUser->email : $sanitizer->email($input->post->email); $currentUser->pass = !empty($currentUser->pass) ? $currentUser->pass : $input->post->pass; $currentUser->newsletter = $currentUser->newsletter != 1 ? $currentUser->newsletter : (int) $input->post->newsletter; $currentUser->addRole('login-register'); $currentUser->save(); } if ($currentUser->newsletter != 1) { // load module into template $mc = modules()->get("SubscribeToMailchimp"); // add merge_fields to fill out user data, based on your audience MERGE_FIELD options // You need to setup the fields at "Settings > List fields and *|MERGE|* tags" first! $mc->subscribe($currentUser->email, ['FNAME' => $currentUser->shippingAddressFirstName, 'LNAME' => $currentUser->shippingAddressLastName]); } } That's right. A user ID is only added to the order customer if they are logged in. The user ID is saved in the $orderCustomer (which is the value of $orderPage->padloper_order_customer). Below pseudo code assumes you already have a logged in user and the $orderPage: <?php namespace ProcessWire; /** @var WireData $orderCustomer */ $orderCustomer = $orderPage->get('padloper_order_customer'); $orderCustomer->userID = $user->id; $orderPage->save('padloper_order_customer'); Hope this helps.

Thanks for these @wbmnfktr. I haven't had a look but I wonder if it is about the JS build hell.

Hi @xportde and @Grzegorz, I have split your posts from the old long thread and merged them into this new topic. I haven't yet started testing TinyMCE. I have added this to my TODO. Thanks for reporting.

This thread is for me to relay bug fixes about Media Manager (until I find a better way to do it). Please don't post your bug reports on this thread; unless it is about a fix that doesn't work for you. Thanks.

This thread is for me to announce Media Manager releases (until I find a better way to do it). Please use your download link (sent to your email) to get the latest Media Manager version. Please don't post your bug reports on this thread. Instead, create a new thread for that in this support forum. Thanks. Releases TBD

This forum is the new support forum for Media Manager. The old thread was becoming a behemoth hence this new forum. This will allow to split issues into several threads, making it much easier to manage and find things. Thanks Pete and Ryan for this! Where it is beneficial, I will split older posts into their own threads in this new forum. I will also lock the old long topic to avoid confusion. Thanks!

Hi @fruid, Just to be clear, "media_manager_image" is an internal native ProcessWire field of type FieldtypeImage used by media manager to store media items that are of type image. Its value is a Pageimages object. Back to your issue, mmfield should be a Media Manager field of type FieldtypeMediaManager. Its value is a MediaManagerArray. A MediaManagerArray contains one or more MediaManager objects. This is analogous to a WireArray can contain several objects of type WireData. All these work for me. The value of $image here is a single object of type MediaManager. What do you get when you dump $image using Tracy? Screenshots test_1_media_manager is equivalent to your mmfield.

Hi @Spinbox, Please see the example in demo-2 of the Padloper 2 Starter Site repository. This is for when you want to save the extra form inputs at the checkout form stage. In summary: Add your extra fields to your checkout form In ready.php use a hook to listen to PadloperProcessOrder::orderSaved as shown here in demo-2. In the hook function, process the newsletter signup checkbox. It should be in $input->post('name_of_your_checkbox') Save that to your backend field where you are saving customer signups. In this hook you have access to $orderPage. This will give you access to $orderPage->padloper_order_customer. You can grab the customer details from there if you need them for your signup. Given that you might have repeat customers, you might not want to save the customer signup details with the order itself since this will mean saving the same information with each order for this one customer. Secondly, you might want to check if the current customer has already signed up for the newsletter. You can do this in the checkout form using htmx (ajax). I.e, after they enter an email address, htmx sends ajax request to your server. In the backend you check your signup records. If customer already signed up, do nothing. Else send back html with checkbox markup for htmx to insert in your checkout form. If you instead want to do the signup request in the next step when collecting payment, let me know and I'll tell you where to hook. This only works for the current order in the session and only for the customer details that Padloper knows about, i.e. not your custom ones.

Hey @alexm, Cool idea. Given that people will have different needs on what extra information to capture for invoice payments (or indeed other payments or just general customer info), I am inclined to let devs implement this per their needs. The implementation would be similar to the custom fields example in demo-2. Thus: Display inputs for bank details in your checkout form. If only accepting invoice payments, always show the fields and make them required. If accepting other payment options, toggle-show the bank details inputs (e.g. using Alpine.js) In ready.php listen to PadloperProcessOrder::orderSaved as shown here in demo-2. Use that to save capture and save your bank details. Save those to some field(s) you have added to the template padloper-order. You have several choices here, e.g. multiple text fields, or a repeater matrix or a multiplier text field, etc. You could even get away with a single textarea since this is not a field you will need to query in the frontend. If user continues to shop after the first checkout attempt, you can use $order-your_bank_details_field to show them the bank details they entered when they first attempted checkout. It would be best to check if there is a valid Padloper session before doing this. Perhaps best just to let them re-enter the bank details though. To display the bank details in the backend, there are several places you can hook into in the single order view depending on where you want to display the info. To show the bank details on the invoice, copy /site/modules/Padloper/templates/invoice-content-html.php to /site/templates/padloper/invoice-content-html.php and edit per your needs. This template will receive the Page $order. That will give you access to $order-your_bank_details_field. Would this work for you? Lemme know.