kongondo
-
Posts
7,379 -
Joined
-
Last visited
-
Days Won
139
Posts posted by kongondo
-
-
On 3/27/2023 at 8:34 AM, diogo said:
On a less positive note, this is a very interesting, and a bit scary, talk https://www.humanetech.com/podcast/the-ai-dilemma
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
-
1
-
-
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.
-
2
-
-
4 hours ago, alexm said:
Got it
$orderItem->padloper_order_line_item
Yep.
4 hours ago, alexm said:but what would be the easiest way of outputting the price for each line item?
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.
-
1
-
-
Hi @szabesz,
Thanks for chiming in!
10 hours ago, szabesz said:Another idea is that you might want to consider not to build any visual aid for the actions based approach but implement a programming library for that. After all, your target audience is developers.
Sure, visual building makes it easy for newcomers to produce results fast, but it will be limiting in the long run. And there is the option to mix the two approaches. Since you are planning to work on the module in iterations, you might want to start with the programming library approach as that should be the bases of the visual aid anyway.
Great idea! I like the mixed approach idea. I'll have a think.
10 hours ago, szabesz said:How about using some node graph libs? See for example: https://github.com/wbkd/awesome-node-based-uis I have no experience with any of them, but a decent JS library like that might do the trick.
I'll have a look, thanks!
-
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.)
-
3
-
44 minutes ago, bernhard said:
This is imho a great video from the creator of Alpine.js:
True. I remember watching this in the early days. I think this is when I found out his other project Livewire.
-
14 minutes ago, Pete said:
Yes even a generic demo would be good, and I hear you on the list of things you intend to do - I've got about 10 years' worth I've not got round to at this point 😄 although after a long while if theyre still not done then maybe they're no that important?
Hear, hear!
58 minutes ago, Pete said:If there's a good source of HTMX and Alpine (combined) video tuts out there that folks could recommend I'd love to check them out.
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.
-
1
-
-
30 minutes ago, Pete said:
I find the docs for both HTMX and Alpine confusing and a little inaccessible for me at least - I have real trouble learning without lots of real-world examples and the docs probably aren't the best place to find those.
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.
36 minutes ago, Pete said:you're up for doing a simple demo that would be great
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.
-
1
-
-
Hi @Pete,
Hard to tell without seeing all the relevant bits. Here's a few thoughts.
9 hours ago, Pete said:I've got a Buy Now button on a product grid that renders a modal via HTMX.
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.
9 hours ago, Pete said:The code returned via the HTMX request that loads the modal looks like this, so I suspect it's that initVariants() code that just needs to be changed to not be x-init? Or something else needs re-triggering somewhere along the line - I'm not sure.
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.
9 hours ago, Pete said:But for a product with variations, because the modal content being loaded via HTMX contains alpine x-init that is being added to the DOM after the original page has loaded, the Alpine code won't work so the popup looks like this (it should say "Select an option")
This and...
9 hours ago, Pete said:Then funnily enough if you close the modal and open it again (or click a "Buy Now" button for another product with variations) it seems to work:
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
9 hours ago, Pete said:I'm having a lot of fun learning Alpine and HTMX
Great!
9 hours ago, Pete said:and don't want to rebuild it all in jQuery at this stage
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 😀.
-
1
-
Hey @gornycreative,
Great write-up, insights and suggestions!
4 hours ago, gornycreative said:Not saying that you need to duplicate anything here, but I saw others posting about things that clients have liked from a UX perspective and so here ya go!
This is very inspirational! It is going to be very helpful, thanks!
-
1
-
-
8 hours ago, MrSnoozles said:
The functionality of the current version is great, it's just a bit unpolished compared to file managers from other CMS.
Agreed!
8 hours ago, MrSnoozles said:Also easier API access to render media in the frontend would be a nice to have. If I remember correctly it was a bit more complicated to use than the usual ProcessWire API.
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.
-
2
-
-
Hi @alexm,
Sir, that's a great suggestion!
4 hours ago, alexm said:It could be that I believe you are sending emails as the "store email address"
That's exactly it.
4 hours ago, alexm said:So it might be a good idea to have to fields. One for "store email" and one for "send emails from" so you can choose an email address that is managed by the local mail exchanger.
Good idea. I'll have a think where to slot the extra email field in the GUI. Thanks.
-
On 3/20/2023 at 1:36 PM, robert said:
Valid point, I have to admit I never really noticed this was the reason for the ›Process‹ in the modules names. Thanks for the hint!
For reference:
-
1
-
-
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.
-
1
-
-
Thanks @csaggo.com. Will be sorting this out in the next update.
-
Hi @alexm,
22 hours ago, alexm said:Oh, looking at the code, I thought you code pass it an order page!!
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).
22 hours ago, alexm said:How embarrassing that it's that obvious. I genuinely want to bury my head!!!
Been there, done that...😁. Naah, you are good.
22 hours ago, alexm said:Sorry for wasting your time bro.
NP.
22 hours ago, alexm said:Can I help with your documentation perhaps? I could add to it and you could correct my solutions as you go? 😬
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! 😁)
-
1
-
-
Hi @alexm,
On 3/19/2023 at 1:25 PM, alexm said:// where $order is the $order page object $orderLineItems = $padloper->getOrderLineItemsPages($order);
This wont work (as you found out 😀). getOrderLineItemsPages() only works with a current order session. It won't work in the backend.
On 3/19/2023 at 1:25 PM, alexm said:I can't seem to get orderLineItemsPages.
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,
18 hours ago, hansv said:Is it possible to realize this e-commerce with Padloper 2
Yes. Some custom work will be required though as mentioned below.
18 hours ago, hansv said:I want to sell 10 products (food in a school restaurant).
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.
18 hours ago, hansv said:he food is sold on monday, tuesday; thursday and friday.
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).
18 hours ago, hansv said:- First the month is chosen
- per product you can choose the days you want to buy the product
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.
18 hours ago, hansv said:Orders can be shown in different lists
- per customer / date / product/
- per food / number per day
- per date / food (per date #bread 1, #bread2, ...)
Demo 2 linked to above shows how you can amend single order views in the backend.
18 hours ago, hansv said:Lists can be emailed to customer, to ...
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.
-
18 hours ago, dotnetic said:
Was version 008 ever released? I bought this module some days ago, and received version 007 (codename James Bond).
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.
7 hours ago, dotnetic said:The reason why I am asking for the release of v008 is because as the initial select I want to display a list of images instead of the title. Is this possible with v007?
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.
-
On 3/11/2023 at 9:27 AM, David Karich said:
From my experience, my clients are overwhelmed with the InputfieldSelector and Lister and don't know what to do with them. I would also prefer a very simple approach here: "Search field for text", optional filter options in a simple UI: file type, time period (of the upload).
Thanks for the feedback.
On 3/11/2023 at 9:42 AM, David Karich said:My idea for the MM: to enable a configuration for the input field that assigns new images to defined categories on the basis of other fields of the template and their values when they are uploaded. If this option is not configured, then I would also prefer the default behaviour "uncategorised" as lying in a "root folder" and the editors have to clean up themselves.
I'll have a think about this @David Karich. It does sound like something that could be accomplished via a Hook.
On 3/11/2023 at 9:51 AM, David Karich said:My wish here would be to map the MM-InputfieldImage in the same way as multi-lang text fields. So with a simple language switch, select another item from the library.
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! 😄
-
Thanks @David Karich, @nurkkaand @gebeer for the great insights and suggestions!
On 3/10/2023 at 7:08 PM, David Karich said:But it behaves like real folders. When you click on "People", only two folders are displayed, but no pictures from both subfolders. I would also prefer this. Inheriting subitems in the view works well for a few folders, but not for 20, 50, 100 and then recursively over several levels lower.
Thanks for confirming. I now see how displaying all items from nested folders in the parent folder view can be problematic.
On 3/10/2023 at 8:38 PM, nurkka said:It would be nice to have a full text search, which would always be visible.
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?
On 3/10/2023 at 8:38 PM, nurkka said:and previously set filter values would be visible right away.
Yes, can work this in. Either cookies, local storage or session.
On 3/10/2023 at 8:38 PM, nurkka said:Also a more compact view for pdf documents would be great, because the current grid and list view both require a lot of space if one has some hundred pdfs in the library. In a past project I added the pdf filenames to the grid view by modifiying some javascript files, to have a more compact view with the filenames visible. Perhaps, pdf icons could be a lot smaller or omitted at all in the document view.
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.
On 3/10/2023 at 8:38 PM, nurkka said:The UI elements could be smaller and information like how many times an image was used, filesize, etc. could be hidden and made visible with a toggle button, so everything would take up less space and more image and document items would fit on the screen.
Agreed. I am leaning toward how it is done in GDrive, with the 'view details' icon opening the details pane on the right.
On 3/11/2023 at 2:43 AM, gebeer said:ATM there are too many steps involved when tagging uploaded media.
Yes, agreed.
On 3/11/2023 at 2:43 AM, gebeer said:I agree this should be separate from the media types. Maybe something like "uncategorized"
Good idea.
On 3/11/2023 at 2:43 AM, gebeer said:The inbuilt image/file tags could be used in the background to store the tags. But for editing I would prefer if I did not have to edit an image before I can input tags. It would be cleaner and faster for editors if they can just edit tags directly without having to go the extra step to edit the image. So the tags field would have to live on the MM page that holds the media. Does that make sense?
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.
On 3/11/2023 at 2:43 AM, gebeer said:Also there should be a way how we can pre-define available categories. Just like we can pre-define available tags for aan image/file field.
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).
On 3/11/2023 at 2:43 AM, gebeer said:Almost all of my clients are overwhelmed by PW Lister filters. Even with predefined filter profiles it is hard for non-techy people to understand the concept and what they see in the dropdown selects. I think this is a very tough one to tackle. If you have just one search input like in WP, you get back results that you where not looking for because the search is too broad. Maybe a combination of a text input that searches for file names and one select dropdown that determines the category you want to search in could work?
Thanks for the feedback. Maybe my suggestion for a 'simple' default search and an 'advanced' one would help with this issue?
On 3/11/2023 at 2:43 AM, gebeer said:Totally agree. It could be a configurable option whether to include files from subfolders in the view or not.
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.
On 3/11/2023 at 2:43 AM, gebeer said:For the time being a config option for icon size would be helpful. Or do the Preview maximum width/height settings already have an effect on those icons?
Another great suggestion! We can make this configurable. No, the preview min/max are just for the upload (They are jQuery File Upload options).
-
1
-
Hi @nurkka,
Thanks for chiming in.
1 hour ago, nurkka said:It would be really awesome if the selection would run through an interface with a folder structure.
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.
1 hour ago, nurkka said:An example: Assuming we have a folder "Employee photos" and a folder "Customers" (or a lot more folders and subfolders 😉 ), then it would be perfect if one could give the input field the information that the image selection on employee detail pages starts in the folder "Employee photos". That would be much easier for the clients/editors to work with.
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,
On 3/6/2023 at 4:09 PM, David Karich said:thank you for your feedback. Since you still ask for wishes for the new version, here are two more. 😃
Excellent! Keep them coming please! 😄 .
On 3/6/2023 at 4:09 PM, David Karich said:Just like the focus point, it would be very helpful to save the image description differently per page base. Example: I want to use a image several times in an article, but I want a different caption in each article.
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.
On 3/6/2023 at 4:09 PM, David Karich said:And the biggest wish I have to pass on: Folder, folder, folder. My clients love thinking in folders. It doesn't even have to be a real folder for PW, but just a "fake page tree". The main thing is to have the feeling of having something organised.
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'.
On 3/6/2023 at 4:09 PM, David Karich said:In this context, a configuration would of course be necessary, where you can, for example, specify where the image is automatically categorised when uploading.
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.
On 3/7/2023 at 1:57 AM, gebeer said:But they'd still love to have their folders back. Technically this would mean that there is some kind of default categorisation apart from media type. I think using tags would be the best and most flexible method.
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!
-
1 hour ago, csaggo.com said:
@kongondofor me this can be closed with padloper 2 version 8, latest pw 3.0.213 and php 8.2 i have no more issues here. so i am assuming something that was done in pw core fixed it
Thanks for reporting @csaggo.com. Massive relief for me as this was a very tricky one!
Quick Add Modal
in Padloper Support
Posted
@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:
Any questions, just holla.