Recently Updated Topics

@bernhard You are completely right! 🤦‍♂️ We can consider that solved, I guess. Thank you!

Hey @Juergen, thank you! That was so quick that I am not sure whether I can test and implement it before you release the next version. 😄 Visually it looks great to me! 👍 But I think, the method should be "smart" and also check whether the module has "fired" yet or if it will in the future (which should not be to hard as it is just a date comparison). I think the big value in highlighting pages in the page tree is in reminding the user that there WILL be a change to this page. The user should not be bothered by pages that already have been (un)published by the module and there could be a lot of those. You could even include a tooltip that gives detailed information on the (un)publication of the page if the user hovers over the clock icon like "Will be (un)published on XX.XX.XXXX – XX:XX:XX". I really love how quick you implement feedback. Thank you again! 🙂

That's a cool idea! Very interesting

I always used simple plain-text signatures cause I thought they didn't matter. However, after using corporative signatures I noticed that they grab my attention more often.

Sure 😊 https://processwire.com/docs/fields/select-options-fieldtype/#multi-language-translating-options

I didn't think about that, but it could be. I don't want to make assumptions about ease of implementation. Breaking changes could be mitigated with fallbacks- use the env if it's available, and fall back to config object if not. I think what would be a true PW4 change would be full adoption of .env and deprecation of config.php. A case could be made that fallbacks now can introduce gradual adoption and make a breaking change in PW4 less impactful. I hadn't seen this discussed there in a formal repo thread before, but good to see interest elsewhere. IMHO, the initial framing of the request around 12 factor apps could have been simplified to just benefits and good practice. Conversely, the argument that not everyone is building 12 factor apps isn't a case against it. All said- I don't want to be critical of a conversation that happened that long ago, I mean- who would I be to talk? I wasn't using .env files in 2017 🤷‍♂️ I do want to share a thought on this specifically in ProcessWire context. One of my favorite things about PW is the file structure philosophy where core lives in /wire and templates, styles, additional modules, assets, etc. live in /site. Site is a living breathing volatile folder and the domain of the developer to extend ProcessWire as a project demands. Replacing /wire is one of the most frictionless upgrade concepts ever and it's flat out elegant. It would be great to see the /site folder adopt that- a true "drag-and-drop" self-contained application directory that can be deployed anywhere ProcessWire exists. The /wire directory wouldn't be dependent on /site, and (aside from core version) /site wouldn't be coupled to /wire. Consider that the root directory is already environment specific. The .htaccess file, node_modules, vendor, .git, etc. are all in environment context. The use of .env fits here. This may come off as an esoteric or abstract argument, but think about how much time you spend naming things in programming and tell me that's not the world we live in 🤣 To address a point in that Github thread as to considerations made inside /site for environment, such as an 'if' statement whether on dev or production, I think that's great for application logic that responds to the environment but does not alter it. It would be great to see this adopted into core, but as always with a project like ProcessWire it's up to the people doing the great work of maintaining and improving it to determine priority. Even if it's not implemented in core, I hope to have made a case for adoption in individual projects.

Thanks for the insights @bernhard, so about the loading order That's the part I was wondering about, since it used to be the other way around in earlier version of RF, as far as I remember. I was wondering if that was an intentional change. Just autoloading the UIKit CSS and JS files (without defer) in the current build gives me pretty bad FOUC and Firefox complaining If I reverse the order by disabling autoload and rendering the assets manually those Firefox warnings disappear, and I feel like the pages render a lot smoother in FF. As for other libs I'm using on a regular basis, at least Leaflet is pretty specific about the loading order of CSS and JS, see here https://leafletjs.com/examples/quick-start/ But I guess that too could be handled via the "defer" method you described earlier. Just need to keep it in mind 😄

@ryan - just following up on the comment by @Denis Schultz - now 4 years on, are you still planning on adding that "Unique" checkbox for Text and Integer fields?

Just curious, does anyone know the approach @ryan uses to minify module JavaScript files? For example, how is he minifying this: https://github.com/processwire/processwire/blob/dev/wire/modules/AdminTheme/AdminThemeUikit/scripts/main.js to this: https://github.com/processwire/processwire/blob/dev/wire/modules/AdminTheme/AdminThemeUikit/scripts/main.min.js Ideally I want to use a CLI-based tool (Linux-based), but I want to avoid using a Node-based solution (such as https://github.com/terser/terser).

I tried accessing your website (and the problematic page) last night and also encountered the error. The error message that I received was about a proxy server having issue, however. Is the current host using nginx or Apache? If there's a proxy server somewhere in there (if not nginx) then it's going to be beyond my experience/capabilities to know how to help. Otherwise, maybe look into why that particular page section (Newsboard) seems to cause trouble when other pages mostly load rather quickly. ProDevTools' ProfilerPro might be useful here, if identifying problem areas on your own ends up being difficult to find.

Hi webguy, Unless your client wants to be able to entre their Google Tag ID themselves, no need to create a field for that. As markus-th said, just hard-code it in a partial template that is included on every page (the one that contains the <head> part of your pages).

Welcome to the glorious world of DDEV 😉

Hi @poljpocket, sort (-iname ... ) does not work, because iname_* contain different criteria to sort the images. To have an impression of the site, here's the link: (The new sorting function is not yet implemented completely) http://www.malabu.de But ->reverse(); was the right way, it works! Thanks to you all Günter

OMG. So easy. Although not quite self-explanatory… Thank you! 🙂

@Gadgetto I am struggling with webhooks :-) In the docs it says: * All hookable event handler methods will return an array containing payload Snipcart sent to your endpoint. * In addition, the following class properties will be set: * * $this->payload (The payload Snipcart sent to your endpoint) * $this->responseStatus (The response status your endpoint sent to Snipcart) * $this->responseBody (The response body your endpoint sent to Snipcart) * * (Use the appropriate getter methods to receive these values!) * * How to use the hookable event handler methods (sample): * ~~~~~ * $webhooks->addHookAfter('handleOrderCompleted', function($event) { * $payload = $event->return; * //... your code here ... * }); * ~~~~~ * * PLEASE NOTE: those hooks will currently only work when placed in init.php or init() or ready() module methods! * I have setup a hook for order.completed in the init method of a custom autoload module public function init() { ... // SnipWire Webhooks $this->wire->webhooks->addHookAfter('handleOrderCompleted', $this, 'handleOrderCompleted'); } Issueing post requests to the endpoint returns an empty response body While in the docs it says: when I var_dump($event->object->getResponseBody()) in my handler method, it gives an empty string which explains why the response body is empty. How can I set responseBody from within my hook handler method? There is no setter for that and Webhooks::responseBody is private, so I have no way to set it in my handler. To solve this, I introduced a setter method to the Webhooks class /** * Setter for responseBody. * * @param string $responseBody * @return void * */ public function setResponseBody(string $responseBody) { $this->responseBody = $responseBody; } Now in my handler method I can do $event->object->setResponseBody('{"test": "test"}'); Which results in While I was at it, I also added a setter for responseStatus. Not sure if you still maintain this module, so I will add this to my fork just in case anyone still needs it.

OK, here's my slightly revised `router.php` script: <?php if (PHP_SAPI !== 'cli-server') { die('Expected cli-server'); } if (file_exists($_SERVER['DOCUMENT_ROOT'] . $_SERVER['SCRIPT_NAME'])) { return false; } $_SERVER['SCRIPT_NAME'] = '/index.php'; $_SERVER['SCRIPT_FILENAME'] = $_SERVER['DOCUMENT_ROOT'] . $_SERVER['SCRIPT_NAME']; require $_SERVER['SCRIPT_FILENAME']; The main change is that `$_SERVER['SCRIPT_FILENAME']` is now an absolute path. Not critical, but more correct.

Ryan has always done this (I really don't know why), but the tag on GH is added for the previous master version when the next master version is released and made available from the PW site's download page.

Hi @Christophe Unfortunately we don't have Code Intellisense or autocomplete in latte files at the moment 😞 See https://github.com/smuuf/vscode-latte-lang/issues/5 You are adding the method "listchildren()" to your ParentPagePage, nowhere else. That means you can all this method only on pages that have the template "parent-page". Why should it do that? You are calling a method of an object. If that does not exist it is expected to throw an error. You CAN do what you describe though. Sometimes it is useful and I'm doing that as well. You could add that method to your DefaultPage.php and there return an empty sting. That would make $page->listchildren() return "" by default, which means it does not throw an error. For some page types you can then implement a different logic: DefaultPage.php --> listchildren() { return ""; } FooPage.php extends DefaultPage --> listchildren() { return "foo!"; } BarPage.php extends DefaultPage --> listchildren() { return "BAR"; } // in any template echo $page->listchildren(); That it totally up to you. Same with regular ProcessWire templates. It's up to us devs how we organise things and everybody does it differently. I can only say what I came up with and what works great for all kings of projects (from very simple to very complex ones): layout.latte for main markup /site/templates/sections/... for all sections /site/templates/partials/... for all partials Details: layout.latte --> holds the html markup skeleton of the page, eg: <html> <head>...</head> <body> <header>...</header> <main>...</main> <footer>...</footer> </body> </html> Then all my template files are usually empty (like home.php, basic-page.php, foo.php, bar.php). Next, I divide my design into sections. A section is a portion of the page that goes from the very left to the very right and has an undefined height/content. You can then add those sections to your main markup file like this: <html> <head>...</head> <body> <header> {include "sections/topbar.latte"} {include "sections/navbar.latte"} </header> <main> {include "sections/breadcrumbs.latte"} {include "sections/content.latte"} {include "sections/content-footer.latte"} </main> <footer> {include "sections/footer.latte"} </footer> </body> </html> This is often all I need, because I build all the available sections in RockPageBuilder and then I can simply add them to the pages as I need them. But it works without RockPageBuilder as well. You then just need to code all your page layouts depending on the page template. If all those pages share the same breadcrumbs and content-footer it could look like this: <html> <head>...</head> <body> <header> {include "sections/topbar.latte"} {include "sections/navbar.latte"} </header> <main> {include "sections/breadcrumbs.latte"} {if $page->template == 'foo'} {include "sections/content-foo.latte"} {elseif $page->template == 'bar'} {include "sections/content-bar.latte"} {else} {include "sections/content.latte"} {/if} {include "sections/content-footer.latte"} </main> <footer> {include "sections/footer.latte"} </footer> </body> </html> You could also use a dynamic approach: <html> <head>...</head> <body> <header> {include "sections/topbar.latte"} {include "sections/navbar.latte"} </header> <main> {include "sections/breadcrumbs.latte"} {include "content/" . $page->template . ".latte"} {include "sections/content-footer.latte"} </main> <footer> {include "sections/footer.latte"} </footer> </body> </html> It's just regular PHP inside the latte tags, so you could also do is_file() checks etc: <html> <head>...</head> <body> <header> {include "sections/topbar.latte"} {include "sections/navbar.latte"} </header> <main> {include "sections/breadcrumbs.latte"} {var $file = "content/" . $page->template . ".latte"} {if is_file($file)}{include $file}{/if} {include "sections/content-footer.latte"} </main> <footer> {include "sections/footer.latte"} </footer> </body> </html> Obviously you'd need to create those files. Here I'm placing them into a new folder called "content", which would be /site/templates/content/foo.latte for example. Next, partials: If you have repeating markup inside your sections you can outsource them into the partials folder. For example let's say you want to show a blog overview page that shows all single blog items as cards. You'd have a section like "blog-overview.latte" like this: // blog-overview.latte <div uk-grid> <div n:foreach="$page->children() as $item"> <div class="uk-card"> <h3>{$item->title}</h3> <p>{$item->teaser()}</p> </div> </div> </div> This example is very simple and if you only use your cards here, then it's easier to leave them here. If you are using the exact same cards on two or three places then you can create partials for them: // blog-overview.latte <div uk-grid> {foreach $page->children() as $item} {include "partials/card.latte", item: $item} {/foreach} </div> // /site/templates/partials/card.latte <div> <div class="uk-card"> <h3>{$item->title}</h3> <p>{$item->teaser()}</p> </div> </div>

Great stuff! Cheers 🙂

I have managed to save the charge id to the order. For this to work I needed to make captureOrder hookable. This is probably not the right way tough.. $wire->addHookAfter('PadloperProcessOrder::captureOrder', function(HookEvent $event) { $paymentIntent = $event->return; $orderId = $paymentIntent->metadata->reference_id; if ($paymentIntent && $paymentIntent->status === 'succeeded') { $chargeId = $paymentIntent->latest_charge; // Load the order page using the order ID and save the charge ID $orderPage = wire()->pages->get("template=padloper-order, id={$orderId}"); if ($orderPage->id) { $orderPage->of(false); $orderPage->set('stripe_charge_id', $chargeId); $orderPage->save(); } } });

Thought this might be interesting for the UIkit/Tailwind users, maybe best of both worlds?? https://www.franken-ui.dev/docs/introduction

Amazing stuff, Ryan. Thank you.

Also another possibility - are you running Debian? If so, I find I have the same issue unless I add this to config.php /** * Enable Session Garbage Collection * Garbage Collection is disabled in Debian as default (probability set to zero) * Enable session garbage collection with a 1% chance of running on each session_start(); * Chance calculated as gc_probability/gc_divisor * Session path is defined inside wire/core/Session.php and points to site/assets/sessions * Thanks to this modification session now takes into account gc_maxlifetime set in config */ ini_set('session.gc_probability', 1); ini_set('session.gc_divisor', 100);

Are you calling your create() method from the constructor?

Dear all, thank you for all submissions. We will be contacting all of you whitin this week. Please do not send any further applications. All best, Dino