kongondo

Thanks @David Karich, @nurkkaand @gebeer for the great insights and suggestions! Thanks for confirming. I now see how displaying all items from nested folders in the parent folder view can be problematic. I have been thinking of this (as a 'simple search') that is always visible and underneath that a link to click to reveal the 'advanced search'. This could either be a 'toned down' lister (e.g. some system settings not visible as clients perhaps don't use this) or a (configurable?) custom filter/lister that has only the most relevant features such as date, title, etc? Yes, can work this in. Either cookies, local storage or session. I agree about the need for compactness and even make this configurable. A visual to mockup to get more going would be great if you could show me one, thanks. Agreed. I am leaning toward how it is done in GDrive, with the 'view details' icon opening the details pane on the right. Yes, agreed. Good idea. Definitely agree. Tagging process should be as easy as possible for editors. In terms of the DB layer, I thought a bit about using the inbuilt image tags but now I am leaning toward saving these separately as 'categories', one per page. Although I am still thinking about this, one page per category has many advantages, including: Management: Managing all categories in one place: e.g., categories 'animal', 'dog', 'cat' are easier managed in one place rather than in image/file tags. Editors wouldn't have to know or worry about these pages. Their only interaction would be creating, managing (editing, deleting, etc.) categories. Editing: Edit once, edit everywhere: If we wanted to change 'dog' to 'Canis lupus familiaris' for instance, we can do it easily in one place just by editing the category 'dog' instead of updating image/file tags. Inputfield Control: Per template category control of available media (suggested by Nurrka) Using pages would make this implementation much easier, e.g. if people is a category, and an MM inputfield is limited (at template level) to only allow media in people category, we would only allow selection and storage of people children, i.e. categories 'men' and 'women', for instance. Category Tree: This will help with building the tree on the left. It is easier than to fish for tags saved in media. It is easier to work with what is referenced (the categories) instead of the 'referrer' (the media themselves) in this case. Nesting: It is also easier to nest categories (folders) if the are pages instead of image/file tags. Multilingual: Page titles (category titles) can be multilingual; image/file tags are not. Customisation: Pages allow one to scale as much as they need to. Say, in future, you want your categories to have a description or some other field, developers can easily add extra fields to the MM categories template. Agreed. In my thinking above, this would be a new 'Manage Categories' MM view. Predefined categories will force editors to only pick from these categories. We can perhaps use the details pane on the right (like GDrive) that I am thinking of as mentioned above for this. Editors could then apply categories to a selected media. Choices would be in a Selectize input. In this details pane, just like GDrive, if one media is selected, we show you its details, plus have the input for categories. If multiple media are selected, we don't show details, just manage/add categories input. I'll have a think about whether to retain the current MM bulk apply/remove 'tags'. Also, whether to retain this feature at all (i.e., the current 'tags'.) given that 'categories' are a more powerful feature (at least that's what I think). Thanks for the feedback. Maybe my suggestion for a 'simple' default search and an 'advanced' one would help with this issue? Good point, maybe even add a configurable threshold, e.g. if 20 or more items, grab first 20 then show text like '+ 150 more' or similar. Another great suggestion! We can make this configurable. No, the preview min/max are just for the upload (They are jQuery File Upload options).

Hi @nurkka, Thanks for chiming in. Yes. Perhaps my question wasn't clear. I am all for this folder structure. What I was referring to in my question about inputfield selector is whether we could also simplify that. So, yes, I definitely love the folder structure and will definitely prioritise that. This is a very interesting suggestion, thanks! I really like it as well! I think it would tie in nicely with the request to make it easier to use profiles in inputfield media manager. @David Karich (or any other person who knows), in the WP Media Lib, if the user clicked on the folder 'People', would that then display media for both 'Men' and 'Women' but if they clicked on 'Women' that will only show 'Women' media? I can't tell because the counts are not showing for some 'parent' folders such as 'People' and 'Office'.

Hi @David Karich, Excellent! Keep them coming please! ? . I think I could incorporate this in the FieldtypeMediaManager as well. It would have to cater for multilingual texts as well. The challenge would be the GUI. I'll have a think. I really love this idea! In a sense this is what I meant by 'Album/grouping of media' but you have articulated it way much better, so thanks! I agree; there is no need to make them 'real folders'. We just need to create a relationship at the DB level and show the virtual representation of that in the 'tree'. The more I think about it the more I think we need to 'get rid' of the uploads page. It seems to me like an extra step that we don't need. Certainly many modern apps (that our clients could be used to) don't separate the 'upload' from the 'view'. It is a single view for both. Yes, we can have a setting for 'default' category, maybe even separate for the 4 media types (just brainstorming here!). Otherwise, if one drag and drops whilst viewing a certain category, that media will be assigned to that category. Can a media belong to more than one category? Either way is doable; I am just curious about your experience and/or the WP plugin. Virtual folders would provide the best of both worlds. Clients get to see their folders but behind the scenes we continue to use the ProcessWire/MM way. By tags, do you mean the inbuilt ProcessWire image/file fields tags? A question to you all, how does the powerful but potentially confusing inputfield selector work for your clients? Do they use it or would you prefer a simpler interface such as the WP one in the screenshot shown above by @David Karich? Thanks!

Thanks for reporting @csaggo.com. Massive relief for me as this was a very tricky one!

Exactly.

@alexm. Customer details live in the field 'padloper_order_customer'. Example: <?php namespace ProcessWire; /** @var Page $orderPage */ $orderPage = $padloper->get("id=3207");// order page ID /** @var WireData $orderCustomer */ $orderCustomer = $orderPage->padloper_order_customer; $out = ""; $out .= $orderCustomer->firstName; $out .= $orderCustomer->middleName; $out .= $orderCustomer->lastName; $out .= $orderCustomer->email; $out .= $orderCustomer->isTaxExempt; // PRIMARY ADDRESS $out .= $orderCustomer->shippingAddressFirstName; $out .= $orderCustomer->shippingAddressMiddleName; $out .= $orderCustomer->shippingAddressLastName; $out .= $orderCustomer->shippingAddressPhone; $out .= $orderCustomer->shippingAddressCompany; $out .= $orderCustomer->shippingAddressLineOne; $out .= $orderCustomer->shippingAddressLineTwo; $out .= $orderCustomer->shippingAddressCity; $out .= $orderCustomer->shippingAddressRegion; $out .= $orderCustomer->shippingAddressCountry; echo $out; // ------ // ETC @see: https://docs.kongondo.com/api/order.html#padloper-getordercustomer for full list of properties. Note that getOrderCustomer() cannot be used in this case. That is only available during an order session. However, the customer properties remain the same, i.e. firstName, billingAddressPostalCode, etc.

Hey @alexm, I see your point. I'll need to have a think. Padloper currently has a number of statuses for payment, order and shipment. Not all are currently in use/editable but we'll work them in in the future. There is a status for 'shipped' which would equate to your 'despatched', i.e. on its way. Delivered is exactly that; 'someone received the shipment' {unless....don't get me started about Evri, Amazon and you-know-who-stole-your-parcel'} ? I'll add to my TODO list. Good catch, ta.

Hi @alexm, Nope, it's not you, it's me :-). This is by design. I cannot recall what my thought process was then but now that you mention it, I think it makes sense to show the full shipping address. Unless others have a strong opinion, I'll change it to that. If there are strong opinions otherwise, then we can make it configurable or hookable. Will add to my TODO. Meanwhile, if you really must change it now, gimme a shout.

Hi @David Karich, I would have to look into this since I haven't worked with focus points before. My guess is that they are saved with the image, in which case they will be saved with the record for the original image in the MM page (i.e., not the page where the MM image is referenced in an MM Inputfield). I'll see if/how I can extend FieldtypeMediaManager to store focus information (and perhaps other info developers might be interested in) which you will be able to access via the MM object. I am hoping there will be no need for breaking changes. However, until I finish building it, I cannot promise. If such changes are inevitable, I'll provide code for migration. However, with the minimal progress I've made so far, I haven't encountered any breaking changes.

Tight! Perhaps I could start with a soft upgrade/update that includes a hook that will allow you to retain names but not sure how this would work at the moment. Having said that, you can achieve what you need manually (not ideal, I know)....by opening the media for editing (in MM), uploading your new image and deleting the old one. Save and you are done. In future I'll think of how one can drag and drop over an existing media to replace it.

Hi all, Media Manager Next/013 Sorry I haven't posted here in a while. I am currently working on the next version of Media Manager. It will part be refactoring and part be some new (some requested) features. I have been having some very helpful conversations with a number of you. Below are the current plans for the next version. Any other thoughts and/or ideas I should consider? It is a bit of work so I might have to stretch this into several updates (versions). Thanks. New Features Upload from external sources (Amazon, Google, etc.). Point media to external resource (e.g. to a video in YT, Vimeo, etc.). Independently set media title on upload Improve/extend media filter/profiles to MM Inputfields (possibly pick and apply a profile from a list) (thanks @gebeer) PDF thumb preview (thanks @gebeer) Upload and replace media (for single media MM inputfields). API (thanks @MrSnoozles) Any other thoughts.....? Refactor Remove dependency on JqueryFileUpload Remove dependency on jQuery -> use htmx and alpine JS instead. Easier to maintain for me as well as more flexibility. Improved preview of media and their properties. Better preview of media before upload. Redesigned GUI - Intuitive (like GDrive(?)), do away with media menus (use filters instead), need oMedia is just media. Remove/reduce use of modals. Allow grouping of media (link an album) <- not yet confirmed if will be implemented Implement hookable methods to allow easier developer control for those who need advanced/custom control of their MM. A number of reported bug fixes as well. ETA? I cannot give a firm date about this, sorry.

Great work! Thanks @gebeer. I wonder if sanitizer name has something to do with this? Thanks for the suggestion. Noted for the next version. They are meant to show after bulk actions such has publishing, deleting, etc. as well as when uploads are done via drag and drop (in single or all media pages and when uploading directly to an MM Inpufield). In my testing now, I see the notifications in the GUI (upper right) except for when uploading via drag and drop in the single or all media pages in MM. I'll look into this in the next version.

Hi @Jim Bailie, Apologies for the delay in responding. Thanks for the interest in MM. There is a setting for what to do when an attempt is made to upload a media whose filename matches one that already exists in the Media Library. The current options are skip / rename / replace. This currently does not cover your use case. This is because currently the media page is automatically created (on upload) off of the file name. Hence, in your case, lion.jpg would create a new media page title Lion. A similar request to yours has been made with respect to replacing the media in a Media Manager inputfield that stores only one image. In order to replace the media, one has to first delete the existing single media. It would be more intuitive and easier to (similar to PW) to just delete the existing media by the new one. I am currently working on a new version of Media Manager that amongst other things will have an option to give uploaded media custom names instead of grabbing this from the file name. I can add your scenario usage to the TODO list for this next version.

I am hoping very soon. I am currently working on a 'Gift Cards/Vouchers' feature after which I'll work on 'Discounts'.

Hi @Spinbox, The usual ProcessWire page view, edit, add, etc. permissions apply. The generic 'padloper-shop' permission will not cover all use cases especially since Padloper pages are live under admin in the pages tree. I suggest you create a role(s) for your use case and apply the appropriate permissions to this role. Please see roles and permissions docs for detailed information Please note that although those docs also detail how to use the API, you can use the ProcessWire GUI to accomplish this task. This: might be handy. Perhaps you can target the top most parent page with a padloper template, i.e. /shop/padloper/. It uses the template 'padloper' Hope this helps, otherwise let me know if you get stuck.

Glad you got it sorted! Would love to see some screenshots if that's possible, just as a showcase of addons, thanks ?.

Hi @alexm, Fixed in Padloper 008 released today.

Hi @alexm, Finally, fixed in Padloper 008 released today!

Fixed in Padloper 008 released today.

Fixed in Padloper 008 released today.

Fixed in Padloper 008 released today.

Fixed in Padloper 008 released today.

Hey @joe_g, Removing a product requires the ID of the item in the cart. Here's an example: <?php namespace ProcessWire; // ================== // Just an example; you might be getting your product using a different approach $product = $padloper->get("template=product,id=1190"); bd($product, __METHOD__ . ': $product at line #' . __LINE__); /** @var array $cartItems */ $cartItems = $padloper->getCart(); // ALL CART ITEMS bd($cartItems, __METHOD__ . ': $cartItems at line #' . __LINE__); // FILTER CART ITEMS TO get the one product you want // PHP 8.X /** @var array $productInCart */ $productInCart = array_filter($cartItems, fn ($item) => $item->product_id === $product->id); bd($productInCart, __METHOD__ . ': $productInCart - at line #' . __LINE__); if (!empty($productInCart)) { // get first matched item FROM ARRAY /** @var stdClass $productInCart */ $productInCart = reset($productInCart); bd($productInCart, __METHOD__ . ': $productInCart - RESET - at line #' . __LINE__); } else { // HANDLE THIS PRODUCT NOT FOUND IN CART } ?> <form method="post" class="padloper-cart-add-product flex ml-auto" action="<?= $config->urls->root ?>padloper/add/"> <?= $session->CSRF->renderInput() ?> <input type='hidden' name='product_id' value='<?= $product->id ?>' /> <input type="submit" value="Add"> </form> <!-- @NOTE: we need the ID of the item in the cart --> <form method="post" class="padloper-cart-remove-product flex ml-auto" action="<?= $config->urls->root ?>padloper/remove/"> <?= $session->CSRF->renderInput() ?> <input type='hidden' name='product_id' value='<?= $productInCart->id ?>' /> <input type="submit" value="Remove"> <?= $productInCart->id ?> </form> Please let me know if you need further assistance with this.

<?php namespace ProcessWire; // empty the whole cart $padloper->cart->emptyCart();

Yes, that link is only about adding. The argument you pass here should be the ID of the cart item, not the product ID, i.e., <?php namespace ProcessWire; // ================== /** @var array $cartItems */ $cartItems = $padloper->getCart(); bd($cartItems, __METHOD__ . ': $cartItems at line #' . __LINE__); foreach ($cartItems as $cartID => $cartItem) { /** @var stdClass $cartItem */ echo "The ID of the cart item is: {$cartID}<br>"; // OR // echo "The ID of the cart item is: {$cart->id}<br>"; // REMOVE CART ITEM $padloper->cart->removeProduct($cart->id); // OR // $padloper->cart->removeProduct($cartID); }