kongondo

Hi @alexm, I have tested and it works for me with hook, hookBefore and hookAfter, i.e. all the below work (in ready.php): <?php namespace ProcessWire; // $this->addHookBefore('Padloper::updateCart', null, 'updateCartHook'); $this->addHookAfter('Padloper::updateCart', null, 'updateCartHook'); // $this->addHook('Padloper::updateCart', null, 'updateCartHook'); However, it is not clear to me how hooking into Padloper::updateCart helps with what you are trying to achieve. 676 in the example above is the cart_row_id of some product and 6 is the quantity of the product in the cart. What information about the cart are you after in relation to your discount?

Amazing! I'm so happy for Carson!

Others have mentioned how to do it in the Markup or in $config. If you wanted to do it using JS, this is how: document.body.addEventListener("htmx:configRequest", (event) => { // add XMLHttpRequest to header to work with $config->ajax event.detail.headers["X-Requested-With"] = "XMLHttpRequest" }) https://htmx.org/events/#htmx:configRequest Not meaning to hijack this thread and I haven't read through everything and I don't know how Markup Regions work...just want to mention that I have set up a GitHub repo for htmx + Alpine.js + Tailwind CSS + ProcessWire demos. It is early days but I am hoping to add all sorts of demos there, from basic to advanced ones, including backend and frontend examples. I'll create a thread for this work at a later time. Meanwhile (and I have nothing against the OP wish), I am happy to take on a challenge like 'how would you build this complex page using htmx' . OK, maybe not as complex as this app: From React to htmx on a real-world SaaS product ?: (too much todo, etc.). Edit First two demos are discussed in this thread:

Glad it worked! That's strange. Are the options definitely sent to the browser? That's line #138 here in /demos/demo_alpine_renders_modal/products-alpine-renders-modal.php . If you dump $allProductsVariants here in line #96, do you get anything?

@Pete, This is now ready. I have done two demos. In the first one, Alpine.js populates the modal with values that have been passed to its $store. These include details about a product's variants, client-side calculation of total price, etc. htmx adds to cart and displays success message. In the second demo, htmx populates the modal with values it fetches when the modal opens (via 'buy now'). It then passes the values (via the returned markup + x-init) to Alpine.js $store. After this, it is the same as the first demo...and htmx updates the cart and displays success notice. I was hoping to do a video demo + tut but run out of time. I'll do a better explanation here (or in a different thread) or in a video later. For now, the most important things to note are: I was hoping to do some very basic examples but got carried away with these demos. I hope to do very basic examples with very minimal markup in future. daisyUI is used here for its Tailwind CSS components (e.g. the buttons, modals, etc.). Stating the obvious here, but it is not needed in a final project. Note the folder structure in /templates/. Demos are in their respective folders in /templates/demos/. Although I would have wanted a simpler folder structure so as not to confuse, it wasn't easy to pull that off given that this repo will host various demos. I didn't want to create multiple templates that display the same thing. Hence, the demos .php files do the rendering and the handling of the htmx request for their own demos. This means the template 'products.php' remains clean and just loads the current demo's .php file (a render file, so to speak). The folder /templates/data/ has JSON of the fields and templates used in the demo, in case you want to test in a separate site. _func.php has a number of utility functions including one which can fetch dummy products from the Fake Store API, and use these to create products and categories. Selecting a demo automatically reloads the page. This is achieved via a redirect passed to htmx. Viewing the frontend will greet you with this, very colourful shop! I went wild with all the available daisyUI themes. The current theme can be changed using the select at the top left. This is persisted using a plugin by Alpine.js called persist. It plays very nicely with $store and x-data. Whereas it is very easy to use things like x-data with local data within a component itself (e.g., <div x-data="{ open: false }">), given the size of the demos project as a whole (now and in future), I decided to handle and store most of the Alpine.js stuff in a main.js file. This separation of concerns helps in the long run. All libraries are pulled from their respective CDNs. There are lots of comments in the demo files. Whilst this makes the files longer, hopefully you also get to understand what's going on. Most things are necessarily named verbosely. Things should be very clear. The demo site itself is not finished. E.g. currently, we only have a very basic template if viewing a single product. There is very little attempt to hide my ineptitude with respect to CSS ?. Any questions, just holla.

Here's an earlier lecture on YouTube by Tristan and Aza. And, in other news: Italy temporarily blocks ChatGPT over data privacy concerns https://www.cshub.com/executive-decisions/news/italy-bans-chatgpt-over-data-privacy-concerns

Hi @Pete, I have started working on this. I have created a repo to demo usage of my 3 amigos - htmx + Alpine.js + Tailwind CSS - in ProcessWire. Stuff there will not necessarily be related to Padloper. I thought a repo like this gives everyone an opportunity to see what is achievable, and perhaps submit PRs as well. It is still early days so I haven't committed much. The first demo will be your htmx + Alpine products modal. Will let you know when that drops.

Yep. Remember there are a number of price-related properties., e.g. unit_price, unit_price_with_tax, total_price, total_price_with_tax, total_price_discounted, etc. Pick one that is most suitable for your needs. Also, remember that orders are permanent records. Prices, title, etc, reflect the state of the corresponding product at the time of purchase.

Hi @szabesz, Thanks for chiming in! Great idea! I like the mixed approach idea. I'll have a think. I'll have a look, thanks!

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.)

True. I remember watching this in the early days. I think this is when I found out his other project Livewire.

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.

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.

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 ?.

Hey @gornycreative, Great write-up, insights and suggestions! This is very inspirational! It is going to be very helpful, thanks!

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.

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.

For reference: https://processwire.com/docs/modules/types/

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.

Thanks @csaggo.com. Will be sorting this out in the next update.

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! ?)

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"); ?

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.

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.

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! ?