teppo

I know this is not exactly what you were asking for, and it's based on an older version of PrivacyWire so there may be an easier way to do it now, but here's how I handled a similar need (just in case it's of use to you or someone else here): <script> window.cookieConsentUpdate = function(do_update) { do_update = typeof do_update === 'boolean' ? do_update : true; let privacywire_data = window.localStorage.getItem('privacywire') ? JSON.parse(window.localStorage.getItem('privacywire')) : ''; window.cookie_consent = { 'necessary': privacywire_data ? (Boolean(privacywire_data.necessary) ?? true) : true, 'functional': Boolean(privacywire_data.functional) ?? false, 'statistics': Boolean(privacywire_data.statistics) ?? false, 'marketing': Boolean(privacywire_data.marketing) ?? false, 'external_media': Boolean(privacywire_data.external_media) ?? false }; if (do_update) { // this is where you could send data to GA etc. } } window.cookieConsentUpdate(false); </script> Now just have this function run when cookie settings are changed; do_update will default to true, and any custom code in the if block will be triggered.

Also curious about this one. Is lazy-loading enough to make number of fields a non-issue? Mostly just thinking out loud here, but I do see at least one benefit in sticking with fewer fields: your fields may remain more manageable, especially if the alternative is to have a lot of very specific fields. Consider having to make the same change to settings of 50 fields compared to 5 fields, for an example. (Of course assuming that they are identical enough for this to make sense in the first place.) On the other hand I guess that under some circumstances more fields could even be good for performance, considering that each field has a separate table. This seems unlikely to cause noticeable difference, though, unless we're talking about an absolutely massive scale 🙂

Thanks, glad to hear you like it 🙂 Did you add the "outer" Repeater Matrix field to indexed fields as well? SearchEngine goes through all indexable fields (supported and configured to be indexed), and it should work fine with nested Repeater or Repeater Matrix fields, as long as every containing field is also set to be indexed. Thus if you have field rm_1 with another matrix field rm_2, you need to add both rm_1 and rm_2 to indexed fields. Anyway, let me know if it still doesn't work and I can take a closer look!

Quick note on this: I can definitely see how this could be an issue, and if you require full control over error messages then shutting down browser errors and relying on PHP defined ones instead is a good option. That being said, personally I tend to keep browser level validation enabled due to a few reasons: Although these errors are "defaults" and it's difficult to alter them (constraint validation API is an option, but at least in my experience it's a bit heavy to use), these messages should be in the language chosen by the user. Not the language they're browsing the site in, but the language they're using at OS / browser level. Thus translating to the language of the site may, in some cases, have negative consequences. Personally I like to get feedback early, and thus it feels more intuitive when errors can be displayed before sending and processing the form. Finally I prefer to rely on HTML validation if/when possible for accessibility. PHP generated errors can be added in a way that makes them properly accessible, but it takes a bit of extra work, and typically requires some JS as well. At least in theory HTML level validation features should have the widest possible support 🙂 Anyway, just saying that there are valid reasons for both approaches — combining front-end and backend validation, vs. backend validation only.

Hey @bbeer, Is this related to a specific module, or are you generating PDF with custom code? Asking because a) if it's related to a specific module I can merge this topic with the support thread for that module, and b) if it's custom code, we would have to know a bit more about how you're generating those PDF files. NSURLErrorDomain:-1017 is an error code that apparently means the browser was unable to parse response. If it works on other browsers it could be a browser bug, or some sort of incompatibility between your PDF generation method / its result and the PDF parser in Safari.

If possible, I would check if it works with latest dev version. There have been some selector related fixes, including one that affects strtotime and created/modified/published.

Hey @Ivan Gretsky, I don't see anything wrong with your approach. This is not something I had specifically planned for, but as you've noted above, it works thanks to the autoloader setup 🙂 Only "issue" — and it's not much of an issue to be honest — would be that technically /components/Blocks/ should be the "view path" for a component called "Blocks". I can't really think of any real world situation where this would cause problems, though. The approach Zeka took in earlier posts effectively created a whole new type of components, in some ways more strictly separated from the built-in component structure. I'd say that it's largely a matter of preference.

Hey @Ivan Gretsky Good question, and sorry for taking a while to respond 🙂 In this case the first example was, simply put, a mistake — it didn't work at all. Thanks for spotting that, it's fixed now in the docs 👍🙂 As for a best practice of sorts, in my opinion in Controller context one should preferably refer to view as $this->view. Referring to it as $this->wire('view') or $this->wire()->view etc. will work as well, but there's a slight chance that it's a different view. To be honest the "different view" situation is a bit of a border case, and something you're unlikely to run into, so usually this won't really matter. It could, though, happen if a) someone has intentionally provided a new View object to a Controller or overridden the $view API variable (in site/template level code or a module), or b) while using ProcessWire's multi-instance support and rendering content from two instances simultaneously. Personally I also prefer $this->view because it makes sense to me and is (IMHO) syntax wise cleaner than the alternatives. Components are indeed a bit different. First a little dive into the technical background: The Component base class extends ProcessWire's WireData class, and thus when we set $this->title in the example above, what actually happens is that the value gets stored in a local data array, so that $this->data['title'] now contains the value we set for title. When the component is rendered (Component::render() is called), everything stored in that local data array is passed to an instance of the ComponentView class, which makes it available in the view file. In other words the View object doesn't come into play at all. ComponentView has certain similar qualities to View, but it's more limited (in both features and scope). And when I say scope, what I mostly mean is that components are intended to be their own "sandbox", so that what happens in them doesn't directly affect the "outside context", i.e. Page specific view(s), or the layout. What happens in your last example is that you are storing a value in the "global view" instead of the local context of the component in question. This does make it available in the component, since ComponentView extends ProcessWire's TemplateFile which in turn makes it work, but I would say that this working (in some situations) is more a side effect than an intended result 😅 The reason it won't work when rendering components outside of templates fully handled by Wireframe is, as far as I can tell, that in this situation only the necessary parts of Wireframe are initialized. Global View API variable is not one of these. (Honestly this is somewhat fuzzy area for me, and I would've expected $this->view->headline to throw some sort of notice/error.) Reading your post does make me wonder if components should actually provide a "fake view" to make passing variables to their own view layer more in line with controllers, but at this time I'm unsure if this is a good idea. Technically speaking it would be a backwards compatibility break, since someone might currently rely on having access to the "real view". Anyway, this is probably a bit off-topic; the long story short is that "yes, data is passed from components to their views in a slightly different way" 🙂

Same place where we've always been, and where we're ultimately going to be with any dependency management solution, automated or manual: risk assessment. Any time we depend on third party dependencies we're making a choice to trust the vendors of said dependencies (and by extension anyone they trust, and also anyone who might have access to the "pipeline" in between us and those vendors). Whether the benefit is greater than the risk is what matters. (Sorry for going a bit philosophical with this 🙂) As for Composer vs. npm, my opinion is that the situation with Composer is slightly less problematic, simply due to the ecosystem. I don't have numbers to back this, so please take it with a grain of salt, but in my experience relying on numerous interconnected dependencies is more common for npm projects. ProcessWire modules, for an example, tend to have relatively few dependencies, which can be a good thing (in this particular context). One solution, mentioned in that Reddit discussion as well, is roave/security-advisories. I would recommend adding it to your setups, just in case. It's a super simple package that defines a list of "conflicts", each of those being a package + version with known vulnerabilities. When running composer install or composer update, these conflicts crash the process. This may well be the only "positive use case" for conflicts I've come across 😉 It's not a fool proof solution, but a good start — and pretty much a no-brainer, in my opinion. Another thing that can help is private packagist, which provides automated security audits, alerts, and more. Private packagist is not free, but for commercial users it's definitely something to consider (and not just for the security features).

Should have some free time this weekend to work on these, hopefully that'll get us somewhere.

I'll look into this. It feels like this should be accompanied by a config setting that defines allowed partials directories, to avoid any potential security issues down the line, and I'd also like to extend this to components (or at least build it in a way that makes sense for that context as well). I seem to recall a request for "components from/as modules" (I believe it was suggested by @bernhard), and this could be a good initial step towards that. One thing that won't be supported is accessing partials in other root directories via the object-oriented $partials->path->to->partial syntax. I don't think it's essential here, mostly just thinking out loud. There are both logical issues (potentially conflicting names etc.) as well as technical ones (currently partials directory gets "pre-loaded" to memory during Wireframe bootstrap) that would make this problematic. (And, again, I don't think it's even necessary.) If by latter placeholders you mean partials, then yes, sublayouts implemented as partials have access to $placeholders. Actually had to test as I wasn't sure, but it looks like it works right out of the box 😅 For the record I did consider this approach too, but felt that it wouldn't fully solve the issue. Perhaps I'm too invested in the concept of inheritance as in templating languages, but the main issue is that this would likely be one-dimensional, while I'd like to see something that is more flexible. Sure, one-dimensional stack with enough layers could achieve almost anything, but that could get super complicated and would also affect performance negatively. There may well be something to this idea, but for the time being I think other routes look more promising 🙂

So... that "layouts within layouts" thing almost ended up in v 0.22, but I decided to hold it back. I don't actually think it solves the right issue, or that it makes enough sense as is. In other words I believe I may have been looking at this from the wrong direction. That, or I just need some extra information before going forward 🙂 What I was going to add would've been a new $layouts API variable, which would've made it possible to embed second (named) layout within one layout. Something along these lines: <!-- layouts/default.php --> <head> <title>Hello World</title> </head> <body> <?= $layouts->render('single-column') ?> </body> <!-- layouts/single-column.php --> <main> <h1><?= $page->title ?></h1> <?= $page->body ?> </main> The only thing this really adds to current feature set is the ability to reuse layouts — which, to be honest, doesn't seem particularly useful, especially considering that the downside is that it adds a new API variable, new layer of complexity, etc. To me it doesn't seem too different from this, which is already doable: <!-- layouts/default.php --> <head> <title>Hello World</title> </head> <body> <?= $partials->render('sublayouts/single-column') ?> </body> <!-- partials/sublayouts/single-column.php --> <main> <h1><?= $page->title ?></h1> <?= $page->body ?> </main> With recent API updates, it's also quite straightforward to dynamically change the sublayout: <!-- layouts/default.php --> <body> <?= $partials->render('sublayouts/' . $view->sublayout ?: 'default') ?> </body> <!-- controllers/HomeController.php --> <?php // ... public function render() { // override sublayout for the home template $this->view->sublayout = 'home'; } // ... Unless I'm missing something, this seems like a pretty clean way to achieve simple sublayouts. Only difference is that they live under the "partials" directory, but after thinking this through that actually seems like a logical place: having them under "layouts" would feel a bit weird (these are different from the "main layouts" after all), while adding a whole new "sublayouts" directory at the root level would, at least to me, seem a bit unnecessary. (Although if partials get the ability to point to files in other / absolute directories, it will of course become possible to add such directory on a case by case basis.) Am I on the right tracks here, @Ivan Gretsky? 🙂 Technically you can go as deep as you want with this type of structure, with relatively little code: if you need a third level of sub-sub-layouts, those would just need to be rendered in the sublayout partial(s). I guess it's, in a way, the opposite of what Twig/Blade/etc. do: instead of the sublayout or view defining that they extend some other file (layout or sublayout), you'd output the child in the parent file. Anyway, let me know what you think. I'll be happy to work on this further, but I've realized that since this isn't really something I personally use, it's way too easy to forget what the actual problem I'm solving was... 😅

Cross-posting here that $partials->get('path/to/partial') is now supported in Wireframe 0.22.0, along with new method $partials->render('path/to/partial'). More details in the docs: https://wireframe-framework.com/docs/view/partials/.

Hey @Clarity Some features of Wireframe do need to be initialized for components to work: paths, autoloader, etc. In practice this shouldn't make a difference: those features will be loaded behind the scenes, but you don't have to use the structure provided by Wireframe, i.e. you can render the page in whatever approach you choose. This used to require calling the initOnce() method of Wireframe manually, but I've just committed an update that should make it a bit easier: as of version 0.21.3 calling the static factory method for components (<?= Wireframe::component($component_name, array $args) ?>) will automatically initialize necessary parts of the module if it hasn't been done yet. If you don't want to use the static factory method, you'd still have to get and initialize the Wireframe module at some point.

Heard of it, but not tried it. For now I think I'd rather keep issues and requests in one place, and discussions here at the forum. Definitely something to keep in mind though 🙂