kongondo

EDIT: solved; see post below Could someone please confirm that $page->secureFiles() still works? Testing in ProcessWire 3.0.187 and irrespective of the page published status, the files are still publicly accessible. I have also tried this: And this: but none of the proposed solutions works for me. Dumping $template->pagefileSecure returns 2. Dumping $page->secureFiles() returns false. It only returns true if do you want to manage view and edit access for pages using this template is Yes. Thanks.

Just checking that you expressed an interest? Wow! From performance side of things, that's still fine as each individual combination (variant) is not a page in itself. From a UI/UX point of view though...that can be a nightmare. I wonder if some sort of grouping is possible? i.e. creating configs for similar products. Maybe not worth the effort though as you can use the inbuilt pagination and search on the variations table. You should still be able to. However, I am not sure how your setup looks like. This confuses me: Usually, a single product would have more than one variation, e.g. Red Small, Black Large, etc. However, it is also possible for a product to have one variation/variant only. The key thing here is that a one-to-many relationship is still assumed. The usual setup would be like this: Product A variant 1: Red Small variant 2: Black Small variant 3: Black Large In your Invoice Page, if you have Product A selected, you have access to all its variants (1, 2 and 3). Assuming you have a variations field inside Product A called catalogue, then you can access Product A variations like so: <?php namespace ProcessWire; $productA = $pages->get(1234); /** @var VariationsArray WireData $productAVariants */ // VariationsArray -> WireArray $productAVariants = $productA->catalogue; Since $productAVariants is a WireArray, you can use get() and find() on it like any other WireArray. E.g. <?php namespace ProcessWire; // find variants in Product A whose colour is 'Black' $productABlacks = $productAVariants->find("colour=Black"); // find variants in Product A whose colour is 'Blue' and 'Price' > 5 $productABlues = $productAVariants->find("colour=Blue,price>5"); Again, I don't fully understand your setup so I may be way off base here, but happy to help if I can see an illustration, screenshot, etc. Ahem... It has been a minute and a number of things had to change. This will be explained in due course but I can only say that we have the best of several worlds with the about to be released Padloper 2 Alpha/Early Beta ?. All will be revealed in due course ?.

Hi @alexm. Many thanks for the purchase. No, you don't. You can (as you have found out) use the same Variation configuration multiple times. For example, a 'Catalogue' variation configurations made up of colours (black, red, green) x sizes (small, large, tall). However, currently, Variations does not allow you to remove / hide unavailable combinations (e.g. small / red). That is the way to do it. I'll have a think about how this can be improved. For instance, for some products, the seller would know that some combinations would never exists for that product, e.g. green x large is (silly example, maybe) never available for this product. In such a case, they may want to delete the combination altogether. On the other hand, it is better in many cases to readily see what is and what is not available. In some cases, unavailable might become available in the future. Hence, making it available is easier if the combination is still visible in the UI. Incidentally, in Padloper 2, variations are inbuilt and allow you much more control. You are not tied to one configuration and can either delete or disable a variant. There shouldn't be. How many colours / sizes combinations are you generating? I haven't tested with Table. Are you talking about Table or PageTable, by the way, given that they are different modules? I am not sure I follow the question as well. Please clarify the field on the PageTable. Docs, just in case you didn't see them. Thanks.

I think we forgot a link to the module ?.

https://processwire.com/api/ref/wire-data/ ?

Yes, it is a Pro Board (VIP Support) for Padloper 1. The topic in Dev Talk that I referenced is an identical announcement to the one in the Pro Board.

Thanks for the purchase. Thanks for confirming. Thanks for this. Please do let us know how it goes.

I have been reminded that I forgot to announce this thread in the two main Padloper 2 topics (announcing change of lead developer) respectively in Padloper support board and Dev Talk. Many people follow those topics, especially the latter. I have now cross-linked this topic in those threads. Consequently, the deadline for expressions of interest is now this Monday, 22 November 2021. Apologies for the oversight.

Apologies, I forgot to announce this topic here. Just cross-referencing this announcement/call for testers: Please note the expression of interest was to close yesterday (Friday 19 November 2021). However, the deadline has been extended until Monday 22 November 2021 to accommodate those who would have expected an announcement here. Apologies again.

I am closing the expressions of interest today folks. Final chance to register, otherwise you'll have to wait for the production release. Thanks.

That's the Locality of Behaviour here ?. Cheap one, I know, sorry, I couldn't help myself. Any chance you could please give us your thoughts on this one? We have suggested onLoad and your example here on 3rd-party integration. Would you have other thoughts maybe? Thanks. Nice one! Yeah, Python has been getting all the love ?.

Carson, what an honour to have you here! ?.

Just wondering whether URL Path Hooks would be of help in this respect? https://processwire.com/blog/posts/pw-3.0.173/#introducing-url-path-hooks

How much slower are we talking? In my mockup, the one with the htmx only I talked about earlier, the communication between the windows was quite fast. I don't know, however, how your implemented your communication.

I am afraid I don't understand what this means. Does it mean Menu Builder is not applying those CSS classes to your menu's (MainLeft) markup?

@Frank Schneider, Please stick to this thread with all questions related to Menu Builder. I've merged the thread you started into this one. Thanks.

Welcome to the forums @Frank Schneider. Please have a look at Menu Builder's documentation.

I like date-fns.

Forgot to add. I'll leave the form up for about 10 days, just to give everyone a chance to register.

Hi all, Added link to the Google Form in the first post. Please let me know if there are any glaring mistakes/ambiguities, thanks ?.

I get you now. I've been dealing with this a lot, where custom Inputfields have been updated and InputfieldPageAutocomplete, CKEditor, Selectize, etc stop working. I have been using ProcessWire's Inputfields API to reload them ?, i.e. initFromInputfield, Inputfields.reload, .trigger('reloaded'), etc. htmx has this event htmx:afterSettle that is triggered after the DOM has settled, after a swap. I use that like this: htmx.on("htmx:afterSettle", function (event) { // RUN POST SETTLE OPS // this function will get the details of the trigger and target event // it will then call ProcessWire's Inputfield's methods or an Inputfield's own methods (e.g. InputfieldPageAutocomplete) // to reload the Inputfield that has been updated, e.g. adding a new autocomplete to the DOM via htmx runAfterSettleOperations(event) }) The only challenge I've had with this is Selectize (I reported the error in another post) but I managed to resolve that. If you are not currently using htmx, I imagine you could emit an event after your preview has been updated and reload your elements and their attached events. I'd probably use MutationObserver in that case, and have it watch a top-level wrapper element, e.g. something that wraps all the markup in the preview window. It can detect changes anywhere in the DOM. You might run into performance issues though, if you cast your net that wide, as opposed to watching, say, a number of ul lists.

Yes...this is the same link I posted here: Just pointing this out to avoid confusion ?.

Thanks for your thoughts @ryan. You raise some good points here. Setting the entry level as low as possible is desirable. Do you mean when coding in htmx or vanilla JavaScript/jQuery? Maybe have a look at htmx onLoad method? There is an example here for third-party integration, although I am not sure if it is applicable. Other than that, many of htmx attributes are inherited and can be placed on the parent element. htmx aside, with JavaScript event bubbling/delegation, even with vanilla JS, if you placed the events on the parent element, future events should be picked up. Another option is MutationObserver. It is a beast though! Or maybe I misunderstood the question?

Glad you got it sorted ?.

I have had a play and some of the implementation is literally, trivial ?. SSE SSE is so simple it is unbelievable at first. You only need two things: in our case PHP and a modern browser...batteries included! Example adapted from w3schools. More examples at MDN. server-side <?php namespace ProcessWire; header('Content-Type: text/event-stream'); header('Cache-Control: no-cache'); $time = date('r'); echo "data: The server time is: {$time}\n\n"; flush(); client if(typeof(EventSource) !== "undefined") { var source = new EventSource("/some-processwire/url/"); source.onmessage = function(event) { document.getElementById("result").innerHTML += event.data + "<br>"; }; } else { document.getElementById("result").innerHTML = "Sorry, your browser does not support server-sent events..."; } I tested it and it works fine but was getting errors about wrong mime type if I set the headers later, but that is to be expected. Live Preview Refresh - Partial and Full - ajax - htmx I have this working nicely (will try post the demo later today). The premise is: A change happens. The editor client sends the data to the server to save the change (autosave - was just mimicking this part). Server saves and sends back a response including the name of the field that has been saved and the page ID back to the editor client. The editor client communicates with the preview client (a separate window). It sets the page ID and the name of the changed field name in its message to the preview window. The preview window client (htmx) receives the page id and the name of the field that has changed and sends a request to the server to fetch the rendered contents of that field for that page. The server sends back the html for htmx to swap in the DOM. In this simple communication, we have the field name match the html id of the element we are swapping. E.g. <h2 id='headline'>My Headline</h2> This is simple and straightforward and easily achieves partial refresh. However, it will be difficult to handle the more complex cases I mentioned in my previous post. It will also be somewhat dictating how the developer should name their html attributes. In addition, it still leaves the developer's templates with htmx attributes that will not be needed in production. This got me thinking. Live Preview Wrapper - idea #1 In this case, the live preview window would add a wrapper html element around the rendered template file markup. The wrapper html element would have the htmx attributes instead of the template file markup. This idea didn't go very far. It would inevitably lead to broken / incorrect markup in the preview window as the outermost markup of the template file would be <html> tags. In addition, while it solves the problem of unrequired htmx attributes in production, it doesn't solve the problem of selective rendering. It still wouldn't' know what parts of the markup in the preview window to swap. Live Preview Config - idea #2 What if instead of live preview / ProcessWire suggesting things like naming of elements, standard markup, etc. that are needed in a template file in order to get selective markup rendering, we implemented it the other way round? What if the developer instead, via config file(s), passed properties to live preview to implement the htmx attributes needed for a template file / page? The default would be full page refreshes. However, if live preview detected that a partial refresh config was available, it would implement those. This would offer the granularity needed for partial refreshes. If live preview did not receive / detect any configs, the default would kick in. Live preview would remain as agnostic as possible. It could be something like this (assumes use of htmx): A developer places their live preview partial refresh configs in /site/templates/live-previews/basic-page-live-preview.php (or basic-page-live-preview.json). ProcessWire detects that the template file basic-page has a partial refresh config in .../live-previews/basic-page-live-preview.php When ProcessWire loads the preview window, it injects the htmx attributes for each named element in the live preview configs in the corresponding elements in the preview window DOM. Injection is done by a ProcessWire live preview near-agnostic JavaScript script that only runs in the preview window. When the autosave happens in the editor window and the preview window gets informed, htmx kicks in, responding to an event and fires htmx.trigger(elem, event). The element in the markup with the corresponding event listener (hx-trigger='this-element-event-fired') will pick up the event fired by htmx.trigger() and query the server for the changed markup. The attributes set in #3 will ensure only the markup that has a change will fire. Server sends the response back and the element's hx-swap (or even hx-oob) picks it up and swaps the DOM. #6 is still not straightforward though. What will live preview / ProcessWire send back? Here too the config at #1 can help. E.g. it can tell ProcessWire to send <p>My Field Value</p> or just send the value of the field back, i.e. 'My Field Value'. The former is still complicated. Instead of telling ProcessWire I want <p>My Field Value</p>, how about tell it, via the configs at #1 that if requested field is field A, send me back the raw value (e.g. a plain text) but if the request is for field B, use this defined function in basic-page-live-preview.php to send me the rendered partial markup for field B? All ProcessWire would do is pass the value of field B to the said function. This value could be a Pageimages object. The function would iterate the images and send back the 'gallery' markup back to htmx to swap. example live preview config <?php namespace ProcessWire; $livePreviewConfigs = [ [ 'field' => 'headline', 'element_id' => 'my_headline_element_id', 'htmx-attributes' => ['hx-swap' => 'outerHTML', 'hx-trigger' => 'headlineevent'] ], [ 'field' => 'images', 'element_id' => 'gallery', 'handler' => 'renderGallery','htmx-attributes' => ['hx-swap' => 'innerHTML', 'hx-trigger' => 'galleryevent'] ], ]; function renderGallery(Pageimages $images) { // we only need the <li> since we are using innerHTML swap // the target element is <ul id='gallery'></ul> // -------------- $out = ""; foreach ($images as $image) { $thumb = $image->size(200, 200); $out .= "<li><img src='{$thumb->url}' alt='{$image->url}'></li>"; } // --------- // sent back to htmx to swap return $out; } When the preview window loads, ProcessWire sends $livePreviewConfigs to the browser, e.g. ProcessWire.config.LivePreview. The preview window JavaScript would consume it like this: client set htmx attributes @note: JavaScript written in the browser, not tested, could have errors. // get live preview configs const elementsConfigs = ProcessWire.config.LivePreview // loop through configs, find the corresponding element and set their htmx attributes for (const elementConfig of elementsConfigs) { const element = document.getElementById(elementConfig.element_id) if (element) { const htmxAttributes = elementConfig['htmx-attributes'] for (const [prop, value] of Object.entries(htmxAttributes)) { element.setAttribute(prop,value); } } } htmx-ready DOM changes via live preview injection (runtime only in live preview window): <h2 id="my_headline_element_id" hx-swap='outerHTML' hx-trigger='headlineevent' hx-vals='{"field":"headline"}'>My Headline</h2> <!-- gallery --> <ul id="gallery" hx-swap='innerHTML' hx-trigger='galleryevent' hx-vals='{"field":"images"}'> <li><img src='image-1-src' alt='image-1-alt'></li> <li><img src='image-2-src' alt='image-2-alt'></li> </ul> I have partly implement the above (just hard-coded configs for now) and it works nicely. Takeaways ProcessWire's live preview remains as agnostic as possible. Developer give instructions to live preview (via configs) and not the other way round. Live preview ships with minimal defaults, including full page refresh. It seems like a lot of work on the developer's part if they want partial refresh. However, this partly matches the complexity of their template files. Besides, some of the functionality (e.g. renderGallery()) could be something they already use in their template, hence reusable. Developer does not need to have additional markup in their template files in order to see live previews when editing. This means no cleaning up afterwards. Their templates remain clean. Live preview only alters the DOM (of the rendered template) at runtime. Developer can name their markup attributes as they wish. Developer can decide what needs live preview and what doesn't, even on the same page (e.g. hx-select). ProcessWire stays out of the developer's way, as usual.