Recently Updated Topics

Thank you for the intel! What would you recommend if I need to decide in mid‑April? Should I still buy and rely on the "old" ProDrafts? It wouldn’t be ideal to implement features based on the "old" ProDrafts only to refactor things shortly afterward to "align with the future".

Thanks @robert! You support is lightning fast ⚡! I was just writing the 2nd issue in github when the 1st one was resolved)))

Contrary to Chrome's preload feature, it only fetches pages from the current site, and you can disable it: mu.init({ prefetch: false, });

Amazing, this looks like the ultimate sitemap module (haven't tested yet) but as @dynweb said a role restriction should be definitely added. I guess replacing the 24th line of ProcessSitemap.module.php with the below will do the trick: 'permission' => 'sitemap-edit', 'permissions' => array( 'sitemap-edit' => 'Edit Sitemap settings' ),

Hey everyone, I've been building a e-commerce project and needed to show personalized content based on visitor location — shipping availability, regional pricing, state-level compliance notices. Nothing like this existed in the PW ecosystem, so I built it. What it does Detects country, region and city from the visitor IP using MaxMind GeoLite2 databases (free). Result is cached in session. Exposes $geoip as a wire variable — available in every template automatically, just like $page or $user. // That's it. No setup, no require, just use it. if ($geoip->inCountry('US')) { echo $page->us_content; } API // Boolean checks — accept single value or array $geoip->inCountry('US') $geoip->inCountry(['US', 'CA', 'GB']) $geoip->inRegion('GA') // ISO 3166-2 subdivision code $geoip->inRegion(['GA', 'NJ', 'NY']) $geoip->inCity('Atlanta') // Inline conditional with optional fallback echo $geoip->showIf('countryCode', 'US', $page->us_block, $page->global_block); echo $geoip->showIf('regionCode', ['GA', 'NJ', 'NY'], $page->northeast_promo); echo $geoip->showIf('continent', 'Europe', $page->eu_gdpr_notice); // Single field $geoip->getField('countryCode') // "US" $geoip->getField('regionCode') // "GA" $geoip->getField('city') // "Atlanta" $geoip->getField('timezone') // "America/New_York" // Full array $geo = $geoip->detect(); // ip, country, countryCode, continent, region, regionCode, // city, zip, lat, lon, timezone, corrected, status Combining conditions // Country + region if ($geoip->inCountry('US') && $geoip->inRegion('CA')) { echo $page->california_prop65_notice; } // Logged-in + location if ($user->isLoggedIn() && $geoip->inCountry('US')) { echo $page->us_member_block; } // Time-of-day in visitor's timezone $tz = $geoip->getField('timezone') ?: 'UTC'; $hour = (int) (new DateTime('now', new DateTimeZone($tz)))->format('H'); if ($geoip->inCountry('US') && $hour >= 9 && $hour < 17) { echo 'Our US office is open right now.'; } // Pre-select shipping dropdown (Vivino-style) $selectedCountry = $geoip->getField('countryCode') ?: 'US'; $selectedState = $geoip->getField('regionCode') ?: ''; User location correction Frontend widget lets visitors fix incorrectly detected location. Stored per-IP in DB, applied on subsequent requests. You can also build your own UI — just POST to /?geoip_action=correct with country_code, region_code, city. Setup Composer package and databases live in site/assets/GeoIP/ — not in the module directory, so they survive updates. cd /path/to/site/assets/GeoIP/ && composer require geoip2/geoip2 Then drop GeoLite2-City.mmdb (or GeoLite2-Country.mmdb) in the same folder. Free download from maxmind.com. The module config page shows the exact path and command for your server. Admin panel Setup → GeoIP — lookup log with country/region/city, corrections manager, manual IP lookup tool. GitHub: https://github.com/mxmsmnv/GeoIP License: MIT Requires: ProcessWire 3.0.200+, PHP 8.2+ Feedback welcome — especially if you're doing anything geo-based with ProcessWire. Maxim

Thanks Peter. I'm bookmarking that haha.

Update: v1.1.6 is now released with configurable export path! You can now set custom paths in module settings as you requested: Setup → Modules → Context → Configure → Export Path For Junie AI integration: .junie/skills/docs Important for CloudPanel/Nginx users: Since .htaccess doesn't work on Nginx, I recommend using an absolute path outside web root for maximum security: /home/lqrs/context-exports/ The module now detects absolute paths (starting with /) and uses them as-is.

Wish I had more time to put into this, but for now just a few random thoughts, sorry in advance for the long rant: I, too, do see the issues that AI is causing (or at least some of them). But this train is not easy to stop. Programming is just one area it is affecting, but in this context I am personally leaning towards the conclusion that AI may well decimate the whole concept of humans writing code for a job. And if things continue to evolve at this pace I don't think it is going to be a decades long process. A few years ago I tried to create a module for ProcessWire from scratch using ChatGPT, and it was a miserable failure. Now Claude is at a stage where I don't think I can truly justify writing code myself from a productivity (or quality) point of view. AI has also made the devops part of my work quite different from what it used to be, and I see no evidence of things slowing down in the near future. For us who work in IT and more specifically programming / development, it seems to me that in the big picture there are a couple of options: get a new job that isn't (yet) as tightly coupled with AI, or keep up with the changes. Also, I wholeheartedly agree with a lot of what Ryan has written in this thread; it's quite a bit easier to influence things positively from the inside 🙂 There will no doubt be some cases where AI is not going to be as prominent, at least for a while. But it seems to me that those are either somewhat niche, or specialized cases. Gamers and the game industry, for example, have been pushing hard against using AI, which I completely understand. ... and of course I may be wrong, and this whole thing may come crashing down any moment. Predicting the future is not easy. By the way, it would be interesting to hear about ways to make AI use less of a problem. A co-worker mentioned https://github.com/rtk-ai/rtk, which is a Rust tool that claims to reduce AI token consumption by as much as 60-90%. Someone correct me if I'm wrong, but e.g. cutting your token use to half should also cut your energy consumption to half, right? (For the record, I have not yet tested RTK properly, so can't say if it works that well.)

Just thought it's worth noting that on modern setups, that 64K limit shouldn't apply anymore. If you run: lsblk -f and the replace the "/dev/nvme0n1p1" with the appropriate partition in this: sudo tune2fs -l /dev/nvme0n1p1 | grep features It will return something like: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum If you see "dir_nlink" then the limit doesn't apply.

Yes, @szabesz I'm sorry about that. First, I had to change my avatar since another forum user copied it; then I changed my name because I’m working on a series of modules and my name here wasn't available on GitHub, and I wanted to be "synced up" across both places. So, I went through a process of trial and error until I found one that was available. It might seem a bit pretentious—"The Wire Codex"—but it’s actually just a technical consequence. LOL

Gemini AI Pro is crazy good these days. I was stuck why the replace hook had no effect, and this solved it (courtesy of Gemini from Google is in italic): The reason your hook is firing (as proven by your bd() output) but $p->path, $p->url, and $p->httpUrl are reverting back to the original /parent/ path is due to a hook priority conflict, usually caused by ProcessWire's Multi-Language modules (or an SEO/routing module). Here is exactly what is happening under the hood: Your addHookBefore runs, sets $event->replace = true, and sets $event->return to /blog/. ProcessWire skips its native Page::path() method because of the replace flag. However, another module (like LanguageSupportPageNames) has an addHookAfter attached to Page::path. That module runs after your code, looks at the $page object, recalculates the original path from the database tree, and silently overwrites your $event->return before it finally gets handed back to your $p->url call. To fix this, you need to change your hook to an addHookAfter, remove the replace flag, and bump the priority so your code is the absolute last thing to run. Change your hook to the following: $wire->addHookAfter('Page::path', function (HookEvent $event) { $page = $event->object; if ($page->template == 'original-parent') { // Overwrite whatever the core (or other modules) generated $event->return = "/blog/$page->name/"; } }, ['priority' => 1000]); // Priority > 100 ensures this runs AFTER core modules And yes, I have multilingual support installed, and this solution works.

This great module by @Robin S https://processwire.com/modules/connect-page-fields/ should work for your use case.

hi, i guess it may come from the fact that creating a vign (the first variation pw creates when tou upload an image) is not that simple (not possible on a server that only has gd and not a recent imagick version) that would be a not very universal feature so far have a nice day

If your CRON is directly calling your template’s php file then yes it won’t work because ProcessWire isn’t bootstrapped. For a client I’m also using a CRON job that calls: "wget -qO /dev/null https://myclient.com/path/to/page". It basically triggers a GET request and thus renders a page with my script in it (it also sends an email). But it seems OVH only allow to execute a php script so maybe you should look into bootstrapping PW, something like: <?php namespace ProcessWire; include("/path/to/your/pw/installation/index.php"); $pages->get("/your/mailer/")->renderPage(); Regarding your LazyCron PageRender::renderPage is not a static function so it wouldn’t work this way, you should instead do something like: <?php namespace ProcessWire; // in your init.php or ready.php $wire->addHookAfter('LazyCron::everyDay', function(HookEvent $event) { $event->wire()->pages->get("/your/mailer")->renderPage(); $event->log("mailer sent"); }; I’m only surprised by this, maybe they changed something in the meantime...

MediaHub update.... TL;DR: MediaHub fields can now detect and import images used on the same page. A per-field import button scans other image fields on the same page and intelligently matches against the MediaHub library. It includes deduplication, perceptual hashing, and confidence badges. This saves significant manual effort when transitioning from standard image fields to MediaHub fields — i.e., you can run both in tandem while evaluating, or until you're ready to switch. I made the jump from building MediaHub to implementing it on a real client site. I ran into issues, and those pain points led to new features. It's a different experience switching from testing with Instagram images to deploying on a 15+-year-old client ProcessWire site — a significant commercial site that can't afford downtime. It features blog posts, staff photos, services, and the usual content you'd expect on a professional services site. Having more on the line meant I approached it with greater scrutiny, taking things slowly — up to a point. My approach: Add a MediaHub field on every page beneath the existing images field. Import each image individually (tedious, but reassuring). Add a script that outputs the MediaHub image first, falling back to a standard image if the MH API had issues. Apply data-type=mediahub to the HTML so I could quickly identify which images had yet to be ported. Step 2 became tedious once I'd confirmed the core functionality was solid. I already have a global import function that scans a site and imports existing images. But I wanted something different for this workflow. If I were an agency porting an entire site, what would be the most useful feature? How would I migrate one page at a time and confirm it was working, rather than relying on the global import? The answer was a localised import button on the MediaHub field itself. Pressing the import button scans existing image fields on the same page and opens a modal containing a list of images available to add to both MediaHub and the MediaHub field. It doesn't yet support Matrix pages, though it works correctly within a Matrix field. The modal assesses whether each asset already exists in MediaHub. Avoiding duplicate images is a core principle of MediaHub, so getting this right mattered. It handles most cases correctly. The one gap: images with different crops are treated as separate images — technically accurate, but better crop detection would be more useful in practice. That's next on the list.

That's a good tip, @Mikel Option 1 was new to me. I'll have a closer look at that, thanks! Your module would have been useful, of course, especially in terms of automatically creating buyers in the backend, MagicLinks, etc. 🙂 But anyway, I'll try my luck with one of the options. Cheers, Thomas

Ah excellent, thanks 🙂 Exactly what I was looking for.

This looks very interesting. Although the specific publishing workflow is not something, I would need. It sure must be fun to sit here and watch the agent churn along and very satifying to open the published URL afterwards :-) The HTTPS API and the migration functionality, those are intriguing. I've been happily using RockMigrations for a few years now. And wouldn't want to miss it. Your JSON-based approach is a wrapper around PW fields/templates API, I guess. Does it support roles/permissions, module install/uninstall etc or is that out of scope for you? That HTTP API layer is very powerful and can be used for all kinds of things, I guess. Does it differ a lot from other API module approaches like AppAPI? Can endpoints be added in a modular fashion, how does auth work? Many questions, I know. Please don't feel obligated to answer them all. Cheers

Thanks @monollonom, we'll trial down the path of a standard module in that case. With configuration options to choose what fields to target.

Hello @grewr11 Thanks for pointing out this issue. I have removed the sanitizer for names on the "Name" field, because usernames are allowed to have numbers in it. This was a thinking mistake. Now it should work as expected. Please replace the following file to get it working: https://github.com/juergenweb/FrontendComments/blob/main/FrontendCommentForm.php I have discovered another issue, with WireMail and localhost, so please replace the following file too: https://github.com/juergenweb/FrontendComments/blob/main/Notifications.php You will find all information about the changes in the changelog.md. I haven't worked on this module in a long time, so there could be more problems. Please report any problems, I will try to solve them as soon as possible. Jürgen