Jump to content

kongondo

PW-Moderators
  • Posts

    7,374
  • Joined

  • Last visited

  • Days Won

    139

Everything posted by kongondo

  1. Hi all, Dynamic Selects Next/008 Sorry I haven't posted here in a while. I am currently thinking about the next version of Dynamic Selects. It will part be refactoring and part be some new (some requested) features. 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. A number of conversations with some of you has led me to realise that DS although useful, is somewhat limiting. Other than the current lack of flexibility to render different types of content, I think there are two fundamental shortcomings of this module. The first is the concept of relationships. The approach I took when creating the module assumed that selects/columns had to be related, i.e. parent > child; page > field, etc. Whilst this was powerful enough, it didn't always represent real world scenarios. It limited the module to 'relationships' and perhaps forced developers who wanted to use this module to structure their sites in the mold of DS. This is not the ProcessWire way, at least not in terms of flexibility. Consider the following example. Let's say we have a site about buildings. There are some things buildings have in common, e.g. windows, doors, etc. However, some features are peculiar to certain types of buildings. For instance, skyscrapers will have lifts whilst bungalows will not. If we wanted to model this in the frontend, i.e. choose type of buildings, then show what features it has, it would mean we need to use a page reference field for the DS to work. The question is, does it have to be this way? Perhaps this is a contrived example but I think we need to decouple the relationships between columns/selects in DS. Enter actions. ACTIONS The next DS will do away with the concept of relationships. Instead, we will adopt the concept of actions. In other words, IF ACTION > THEN do THIS (OR even THESE...see below) > ELSE. This will make the module more flexible and more powerful. User defined action > consequence are much more versatile than the current strict relationship between 'entities' approach. This will allow for setups such as if user selects 'people' [ACTION], THEN get content related to 'people'. ELSE IF [ACTION] 'buildings', THEN get things related to 'buildings', ELSE get some default content. Related to this is the current restriction to only populate the next column/select after a selection in the preceding column. We will change this in the next version, making it configurable and more flexible. For instance, If I select make of a car in the first column, the second and third columns could be populated with brands and year, respectively. DEFINING ACTIONS The current method of creating dynamic selects is very confusing and a bit complex. Personally I also struggle to remember the relationship types and naming conventions ๐Ÿ˜„. This has to change. I haven't yet firmed up any ideas but I'd want something this is visually easy to understand and clearly shows the 'IF ACTION THEN THIS ELSE THAT'. Maybe a drag and drop? I am thinking something similar to visual data model builders. Any ideas anyone? Planned work includes: New Features New approach to model selects using 'ACTIONS'. Easier to use 'DS Builder'. Trigger change in 1 or more dependent selects. Partial templates to render different types of content. These can be overridden by user defined templates, allowing for customisation as needed. Any other thoughts...? Refactor Configurable sorting of results (title, modified, sort, etc.)
  2. True. I remember watching this in the early days. I think this is when I found out his other project Livewire.
  3. Hear, hear! For htmx, BugBytes has some neat htmx stuff. Although backend is Django, theory is the same. Most (at least it used to be that way) htmx stuff out there is related to Python stuff. BugBytes also has some Alpine.js tuts. Perhaps my favourite tutor of them all, Brad at Traversy Media has this Alpine.js crash course too.
  4. I suppose I find them quite easy to grasp because I found htmx and Alpine after I'd been using Vue, Nuxt, etc. Have you seen the htmx demos? I have been thinking about a series of tuts on htmx + alpine + tailwind for ProcessWire. But then again, I have been thinking about a lot of things for years ๐Ÿ˜. I forgot to mention that sometimes some alpine stuff don't work because they are out of scope. Inner/nested x-data takes precedence over outer ones, for instance. I'll try put something simple together. Even something generic (not Padloper related) I suppose would do. This would cover events; bounce; waiting; doing things after other events; toggling state, oob, etc.
  5. Hi @Pete, Hard to tell without seeing all the relevant bits. Here's a few thoughts. As an aside, I am wondering why you need to use HTMX to render the modal. From what I can see, you already have the product title and price in the product card in the products grid with the buy now buttons. Unless prices change constantly (like stocks), which I don't think they do in your case, the only thing that htmx should be doing in the modal is to listen to the 'add to basket' and optionally, to the increase/decrease in basket. After that, it renders the response (success or fail to add to basket, i.e. the greenish text). Otherwise, I'd have Alpine JS open and close the modal and optionally render the modal markup. If Alpine JS is not rendering the markup, it would mean modal markup for each product is already done but hidden and their visibility controlled by Alpine, e.g. :class. Either way, I don't see why htmx should be rendering the modal. It also leads to extra hits on the server that you probably don't need. I don't think it has to do with x-init. Think of x-init like ProcessWire _init or Process modules init(). It allows you to hook into the lifecycle and do stuff before the DOM is updated. I could be wrong about this with respect to your use case though. This and... this...suggest it could be a race condition. Again, without seeing the modded code, it is hard to tell. There are various options including: use $nextTick (but not sure it applies to this case). Have alpine listen to a custom event, i.e. @mycustomevent='handleCustomEvent()'. You can send a custom event after htmx swap, settle, etc. Use htmx on load event to talk to Alpine. 'on load' is called every time an element is loaded to the DOM Great! Not at any stage please! ๐Ÿ˜. Just because of this, I can try put together a simple demo for you. But first, clarify why you need htmx to render (instead of just update) the modal ๐Ÿ˜€.
  6. Hey @gornycreative, Great write-up, insights and suggestions! This is very inspirational! It is going to be very helpful, thanks!
  7. Agreed! Great thoughts! I've thought about this before. I am keen to work on it. A $mediaManager variable will make it very easy to interact with MM in the frontend. This will make it easier to directly use media items in the frontend. For instance, directly build a photo gallery using images from the library without the need to add these to a page first. It will also make it easier to manage media items using the API, import items into the library, etc. I have updated the the MM Next plans post.
  8. Hi @alexm, Sir, that's a great suggestion! That's exactly it. Good idea. I'll have a think where to slot the extra email field in the GUI. Thanks.
  9. For reference: https://processwire.com/docs/modules/types/
  10. Hey @Guido, Sorry, still no ETA. The 'easiest' workaround (if not requiring a GUI). is to hook into price. Please see this example in the docs.
  11. Thanks @csaggo.com. Will be sorting this out in the next update.
  12. Hi @alexm, Yes it does. But that's because at that point it is dealing with an order session, so it doesn't know what the order page is. Hence, the order page is retrieved from the session and passed to it. In your case, since you are creating a dashboard, this is decoupled from any session and you can just retrieve any order you want directly (using their ID). Been there, done that...๐Ÿ˜. Naah, you are good. NP. Thanks for the offer. I am currently favouring video docs. Been working on this (slow though!) and hope to start releasing soon (although tempted to ask chatGPT do it for me! ๐Ÿ˜)
  13. Hi @alexm, This wont work (as you found out ๐Ÿ˜€). getOrderLineItemsPages() only works with a current order session. It won't work in the backend. They are right there in front of you ๐Ÿ˜„. They are children of $order. So: <?php namespace ProcessWire; /** @var PageArray $orderLineItemsPages */ $orderLineItemsPages = $order->children("check_access=0"); ๐Ÿ™‚
  14. Hi @hansv, Yes. Some custom work will be required though as mentioned below. This is easy enough. You create 10 products in the backend, unless they are related in which case you can create product with 10 variants. I am not sure I understand this bit. Does it mean your website will only allow orders to be placed on these days or does it mean you only deliver the food on these days? Either way, this is something you would have to control in the frontend using code, e.g. the code would check what day it was and if it was one of the 'allowed' days, it would display the products for sale or it will allow the products to be orderable (add to basket, checkout, etc). Padloper gives you total control over the frontend. For this, I would create a simple dependent select that would require selection of the month, then a multi checkbox of the four days. You would need to save this information to a session to track it. There are two examples here and here of a using custom form input to capture, process and store extra order information. Demo 2 linked to above shows how you can amend single order views in the backend. Depending on when you want to do this (e.g. after order confirmation, after full payment, manually, etc.), you have a number of options including hooks, custom addons, etc. Hope this clarifies things. Please let me know if you have further questions. Happy to discuss this some more via PM or email.
  15. Hi @dotnetic. Thanks for the purchase. No; 008 has been delayed. I hit a number of technical design issues so I had to go back to the drawing board. Apologies, I should have updated my post. It is not possible in 007. I am wondering if a quick fix would be for me to make the render method hookable. You can then swap it in your markup. We could do this on your custom install. Please let me know. Otherwise I still don't have an ETA for 008, sorry.
  16. Thanks for the feedback. I'll have a think about this @David Karich. It does sound like something that could be accomplished via a Hook. Very interesting idea. So, the images themselves (the pages in MM library) would be language-unaware but the MM Inputfields would be language aware (perhaps configurable) and fall back to default language media if no media in 'other language'. I am not good with GUIs so any mock-up for this that I can get would be appreciated. Although, for consistency, it should perhaps mimick the current image fields language tabs. Lots to think about for me but thoroughly exciting! ๐Ÿ˜„
  17. 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).
  18. 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'.
  19. 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!
  20. Thanks for reporting @csaggo.com. Massive relief for me as this was a very tricky one!
  21. @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.
  22. 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.
  23. 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.
  24. 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.
ร—
ร—
  • Create New...