Leaderboard

@szabesz @AndZyk Drill down to per-user activity is now behind basic auth, and the main page table is shorter now.

RockForms is based on the great Nette Forms Component and adds a little ProcessWire magic here and there to make working with forms a breeze. It will render forms directly into the markup of your website (no iframes!), which makes it a perfect companion for tools like HTMX or Alpine.js ❤️ Download & Docs: baumrock.com/RockForms

Pruning is kind of an expensive operation as it involves finding existing log entries, exporting them to a new file, then deleting the old file, then renaming the new file to the old filename. I'd avoid doing it every time you save a log entry. I prefer to manually prune from the admin. The error messages seem to indicate that maybe the prune is colliding with the save. Likely pruning immediately after saving is happening in the same timestamp and not giving it a chance to consistently save a log entry. So at the least, I would disconnect your prune() operation from your save() operation, perhaps moving your prune operation into a LazyCron::everyDay hook.

@bernhard So a quick fix for the FormBuilder isssue with the topbar is to exclude the page it renders inside the iframe by template name. <?php public function addTopBar(&$html) { if (!$this->isEnabled('topbar')) return; $page = $this->wire->page; if (!$page->editable()) return; if ($page->template == 'admin' || $page->template == 'form-builder') return; // Adding the extra check for FB here solves it if ($this->wire->input->get('rfpreview')) return; if ($this->wire->config->hideTopBar) return; // etc. It's the only instance of an iframe issue I can think of and that's because the contents are rendering from a page within ProcessWire where it isn't possible for it to be front-end editable.

Just a note to say that I've added a new Page Meta section to the Request Info panel. This displays all meta entries for the page, along with links to open the entries for editing directly in Adminer. Speaking of Adminer - it was recently updated to AdminerEvo and I changed the way links from Tracy to open Adminer work - they now open the bar panel version which I believe is a much nicer experience than the standalone Adminer page. I also added links to edit the values of all fields within the Page Edit interface. If the field has multiple values, it will open Adminer showing all entries instead. This is of course optional, so you can visit the Adminer settings (now merged into Tracy's settings) to turn this off if you prefer. Please note that when you first upgrade, you will likely need to do a modules > refresh to get Adminer to load properly the first time.

@szabesz Done.

@netcarver Thanks! How about also adding robots.txt with User-agent: * Disallow: / plus <meta name="robots" content="noindex"> to head?

I'd vote for this.

You have to check what $page->category->value actually is. You can do that with {bd($page->category->value)} If that outputs "" or null, then you can do n:if="$page->category->value" Likely it will be something else that only looks like a string when using "echo" but behind the scenes it's actually a PHP object. For example the root page in PHP is a "Page" object but echo $page prints "1". This is an exact match, maybe it already works if you use the != operator instead of !== That would tell the comparison to allow the value being converted to "string" before comparison, because you compare it with a string. The same happens if you do this: $page->template === 'foo' will always be false $page->template == 'foo' will be true if the name of the template is "foo"

Great stuff as always ? Receivd your newsletter today that features the release of RockForms. Totally did not see this post before. I have read through the docs completely. Quite impressive. You seem to have all the functionality needed for rapidly building forms. Some nice wrappers around the sometimes clumsy Nette API. I've been building forms with Nette before and that was not always a pleasant experience. Great that your module simplifies the process. Will surely use this in upcoming projects.

Thx, I've added this to the module's info.php as requirement Thx, I've pushed that "fix" to the module ?

Hi guys. Check out my latest project Casa Douro Guesthouses. As the name implies, Casa Douro offers a few guesthouses in historic Porto and on the Douro Region. They came to us looking for a well built website that would fit their marketing efforts and grab direct reservations, instead of relying only on Booking.com and Airbnb. Since their channel manager (CM) software only offers a cookie-cutter website and no API, ours does all the presentation and jumps straight to the booking system when the user decides to make a reservation. As usual on my sites, pages are built using a blocks system (Profields Repeater Matrix), allowing the admin to change things up a little bit between the different units. Plus the usual WireMailSMTP, SEOMestro, and Rockfrontend because I love using Latte templates. The frontend is a mix of Tailwind + SCSS on more complicated components, and JS over Vite which allows me to keep it as vanilla as possible. We already have plans for new sections, and maybe upgrade the booking system in the future.

Still, I wonder if I should revert the behaviour to the just having the standalone version? Or maybe with a new config setting ("Display standalone") I could have it redirect from /setup/adminer to /setup/adminer-renderer/ - maybe that's the best of both? Any thoughts?

Thanks, that works well ?

Ah yes OK - sorry about that @Robin S - I thought I was making things better by embedding it within the PW admin so it has the header menu etc. While I think about it, you can for now simply load /setup/adminer-renderer/ instead and you'll get what you're looking for. You can even unhide that page and hide the other one if you want. It's funny really - now that the "Edit in Adminer" links open the panel version, I never use the standalone one at all, but I can understand why you might prefer it still, especially for the query string reloading.

Hi @bernhard ReactPHP has been very solid for long running server processes in my experience. There's also Framework-X which is a nice layer on top, though I haven't used it much. And FrankenPHP - which I have never used, though it might allow long-running async stuff as well. Sorry to make you feel tracked, I guess things like this that simply snapshot publicly available ephemeral info and turn it into a timeline are somewhat borderline. If people are worried about this I'm happy to take this service down, or put it behind basic auth so only the forum mods have access. Basically, I want to get to the point where I can detect Join Events followed by new topic creation prior to it being published in order to get an early warning of possible spammers. This tool might be able to do that (time will tell.)

Great so see someone else working with ReactPHP as I'm also evaluating it for a new Project ? Thx for sharing! Though I feel a little tracked now ?

New docs about the RockPageBuilder API that makes it easy to import content from old websites and convert it to RockPageBuilder blocks ? https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/api/

Just an FYI for everyone who may upgrade to the latest PW dev version today. If you make use of AOS's excellent "Add button to check/uncheck all checkboxes" feature, it will break the top level menu dropdowns in the PW admin (and maybe other JS). The fix is to replace: ("[data-no-checkall-checkboxes="1"]") with: ([data-no-checkall-checkboxes="1"]) in: /site/modules/AdminOnSteroids/scripts/aos.min.js

For truly dynamic pages that need to change on every request, don't use a template cache or ProCache, and instead use MarkupCache for the parts that don't often change (if you need to use a cache at all). No doubt, delegating things to javascript where possible is very cache friendly with template caching and ProCache. Even if you are shifting things to be ajax-loaded, the ajax requests can themselves be delivered by ProCache or template cache, perhaps just on a shorter cache time. Not to mention, the results of those ajax requests can be cached client side in cookies if needed, serving as a client-side cache that you control. But I honestly don't think most people need to get into this level of caching, unless dealing with some major traffic considerations and/or server that can't keep up with it dynamically.