kongondo

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.

I'll see if I can include his in the next version of Media Manager. My current thinking is that I'd add an extra column/subfield to FieldtypeMediaManager.

Hi @fruid, I am totally confused by this 😄. When editing a media item (i.e. inside media manager), you are editing the page where the media item lives. In the case of an image, the image is in a normal ProcessWire image field. So, the description, tags, cropping, etc are all native ProcessWire inputs and functions. Yes it is.

Thanks @nurkka I am working on showing preview thumbnails actually. But I still get your point about long filenames. I agree. There will be a list view. However, I cannot guarantee that the filenames would not be cropped, i.e., we cannot control for how long a filename will be, especially in some non-English languages. However, we'll try and get in as much text as we can. The current plan is to have the meta data in a sidebar to the right (like GDrive). I'll consider this. Maybe make it configurable. @fruid, Yes, exactly. Please see the docs: Accessing Media Manager Objects Properties Media Manager Objects

@fruid. Sorry for the delay in getting back to you. Long weekend here. Please change the relevant code to: <?php namespace ProcessWire; $importedUsualPages = $pages->find("your-selector"); $arrayOfConnections = [ 'my-usual-page' => [ 'id' => 1876, 'imported_mm_pages_ids' => [2035, 2036, 2038, 2056] ] ]; foreach($importedUsualPages as $importedUsualPage){ $importedUsualPage->of(false); $mmField = new MediaManagerArray(); $importedMMPagesIDs = $arrayOfConnections[$importedUsualPage->name]; foreach($importedMMPagesIDs as $importedMMPageID){ $mmFieldItem = new MediaManager(); $mmFieldItem->id = $importedMMPageID; $mmFieldItem->type = 3;// 1-audio; 2-document; 3-image; 4-video // add MM item to MediaManagerArray $mmField->add($mmFieldItem); } // ----- // populate mm_field of page $importedUsualPage->set('mm_field', $mmField); $importedUsualPage->save('mm_field'); } Let me know how it goes.

Would it be technically possible and would there be major benefits to decouple 'read' caches versus 'write' caches? I.e., when reading, we use the file system but when writing we use the database system. Perhaps configurable via $config. Just wondering.

Hi @MrSnoozles, Thanks for the feedback. Yes, a breadcrumb navigation is planned. I haven't started work on it yet. It will be very similar to Google Drive (i.e. like the demo.filerun). True. And the 'green' is just for testing. So, no decision made there yet. The browser for the recording was zoomed in at around 175% so that could be the reason but I've note this, thanks. Thanks! Hi @fruid. No. As mentioned in the post with the video demo, the next MM will not be available until after the summer at the earliest. I have also just noticed this. It must be related to a newer version of ProcessWire. I am only noticing it in 'All media' view. Pagination is working fine if viewing a single media type. It shouldn't show twice and yes, I have also seen this if in 'All media' view. That footer is not inserted by Media Manager. It is inserted by ProcessPageLister which is the class that ProcessMediaManager extends. The next version of MM will not be extending ProcessPageLister so this error won't occur. Good idea. I'll add this. Sorry about that. I'll have a look. Will do. Totally! Thanks for all the feedback!

@bernhard Have you searched for a dedicated library, e.g. on npm? I have seen a number of libraries in the past such as this one. There is also this conversation on SO.

@Juergen. Thanks for this. I think @bernhard is talking about JavaScript perhaps, for use before the form is even submitted to the server.

Hi @Boost. Yes, Media Manager is a paid (pro/commercial) module. Are you perhaps talking about the free Media Library module versus Media Manager (the pro module)?

As both you and @elabx have alluded to, it is a tricky one. For MM specifically, since we are using Lister (will change in the next version, most likely, to htmx), it could also point to an error about a particular image on a particular page. The [object Object] is most likely the text of the error that ProcessWire is returning. Like @elabx pointed out, have a look at the Network tab. A 500 error would mean a server error. Some of the possible causes are a very large image that MM did not finish resizing, or there was an error uploading it, hence clogging up stuff. I have received a number of suggestions about handling such stuff, especially from @gebeer. I'll include this in the next updates. Back to your issue, I know 800 images is lot because it means 800 pages, but if you are able to narrow this down to some possible 'big' images, you can sort out the issue manually by editing the relevant (MM) page. However, this too can make the system hang. So, you might want to resort to the API in that case. Let me know how it goes

Uploads: Three way (all upload to the current category): DnD Via right click which pops open a contextual dialog and you select 'upload' Via the 'New' button, which pops open a contextual dialog and you select 'upload' New Button: Opens a dialog/dropdown from which you can choose : 'new folder', 'file upload' or 'folder upload' [this latter one will also create the virtual folder, i.e. category] By default, yes, it is the entire library. However, there will be advanced search, accessible by clicking some icon within the search box. It will open a dialog within which you can set search parameters such as type, name, date, category, etc.

Like ProcessWire page reference fields. Yes. Media pages are not nested. They reference 'categories' (folders) which themselves can be nested. To the user, they look like 'folders' in everyday computing (sort of). Conceptually, they are virtual folders. Technically, they are like page reference fields. This means that a media item can belong to more than one category. This is achieved simply by it referencing multiple 'category pages' (like page reference fields). So, technically, we don't nest media items. Instead, we nest the categories and the media items follow that, virtually. Categories are nestable pages. For instance, in the demo, People is a top level category (folder) page. It has two (ProcessWire) page children, Men and Women. If we wanted to, we could further sub-divide this, e.g. Men > Sports Men > Martial Arts > Etc... These are all 'category' pages. It is not shown in the video but from the screenshot below, you can see the category 'Fruits' is deeply nested. Deep Nesting Back to the demo, for example, the images (media items) you see when viewing 'Men' have the category 'Men'. Definitely. This is because as explained above, we don't nest the media items themselves. Their paths are fixed. For instance, to move some media from the category 'Berries' into 'Apples', behind the scenes, we will just change its category (reference) to 'Apples' (or 'Green', to be more specific). The media itself doesn't move. I am still working on the 'move' from the UX point of view but it will most likely be via both drag and drop and using menu (context) options.