maximus

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

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.

I've been working on sites where the standard sitemap setup started showing cracks: XML generated on every request eating memory, no way to regenerate automatically without writing custom hooks, and no visibility into what actually ended up in the file. So I built Sitemap — a module that generates static XML files to disk, splits output by template name, and handles the full lifecycle from generation to search engine notification. What it does differently: Writes files to disk instead of rendering in memory — no RAM spike on large sites Pages are fetched in chunks of 500 with uncacheAll(), so memory stays flat regardless of page count Each template gets its own named file: sitemap-product.xml, sitemap-blog.xml, etc. — the index at sitemap.xml references them all Auto-regeneration via LazyCron with a configurable interval; the LazyCron hook slot is chosen dynamically to match what you configured (every hour, every 6 hours, daily, etc.) rather than always using everyHour A needs_regen flag is set whenever a page is saved, trashed, or deleted — visible in the admin dashboard IndexNow support: after generation, all URLs are submitted to api.indexnow.org in batches of 10,000 Sitemap: directive written directly to the physical robots.txt on save and on generate Lock file prevents concurrent generation Admin dashboard at Setup > Sitemap showing file count, URL count, total size, and last generated time Settings stored in a dedicated DB table (sitemap_settings, name/value, MEDIUMTEXT) rather than the module's data field — avoids the serialized config size limit when template settings grow large. Image sitemap extension and hreflang alternate links for multilanguage sites are both supported. GitHub: https://github.com/mxmsmnv/Sitemap Screenshots: Still v1.0.0, so feedback is very welcome — especially from anyone running it on a site with 10k+ pages.

Yes, of course. I use it on all projects. Maybe not so deep, but I try to avoid red mistakes. regarding the custom path, yes, you can do that by the way. I think this will add flexibility to the module.

Thanks for the detailed bug report! Both issues are fixed in v1.1.5: getMatrixTypes() error - Fixed array iteration (was treating integers as objects) Default settings - Added __construct() to apply defaults on install The module is now available on GitHub. Please update and let me know if everything works correctly.

I think need to fix a few lines of code WireUpgrade to avoid this problem in the future @ryan, and I can easily change the module name.

New 1.8.5 version: System Prompt: Define a reusable base prompt in module settings, pre-filled into the input field on every page. Supports %fieldname% placeholders (e.g. %title%) that are automatically resolved from the current page's field values.

Hello Robert, Does your plugin support filling in fields?

Hey everyone! I just released a new module called InviteAccess. It's something I built for my own workflow and figured it might be useful for others too. The problem: when handing off a staging site to a client or a design agency, you either open it to the world or reach for HTTP Basic Auth — which works but isn't pretty and requires server config. I wanted something in between: a proper gate page that looks like it belongs to the project, with separate codes for each team. What it does InviteAccess hooks into ProcessPageView::execute (before any template rendering) and blocks all frontend requests until a valid invite code is entered. Logged-in ProcessWire users always pass through automatically. You define codes in the module config, one per line: SUMMER2025|Summer Campaign AGENCY-PREVIEW|Agency Team CLIENT-ACCESS|Client Preview The label after the pipe shows up in the access log, so you can see exactly which team accessed the site and when. Features Multiple invite codes with optional labels Session-based auth — enter once, stays valid for a configurable number of hours JSON access log with timestamp, IP, user agent, URL — last 50 entries shown right in the admin config panel Light / Dark / Auto theme switcher on the gate page (saved in localStorage, reacts to OS preference) Accent color setting — red, blue, green or black Configurable allowed pages that bypass the gate entirely CSRF protection, hash_equals() for timing-safe comparison, Cloudflare-aware IP detection The gate page uses ApfelGrotezk font and a design inspired by processwire main page itself — warm gray background, white card, mobile-first. Screenshots Installation cd site/modules git clone https://github.com/mxmsmnv/InviteAccess.git Then Modules → Refresh → Install → Configure. GitHub: https://github.com/mxmsmnv/InviteAccess Happy to hear any feedback or suggestions!

Hi everyone, I'd like to share a module I've been working on: WirePDF — a PDF generation module with full UTF-8 and Cyrillic support. What it does Adds a toPdf() hook to any page, so generating a PDF is as simple as: $page->toPdf(['filename' => 'document.pdf']); You can also pass custom HTML, use a dedicated template file, or save the PDF directly to disk. Key features Two engines: mPDF (recommended) and Dompdf Full field support: all native PW fields + ProFields (Table, Repeater, RepeaterMatrix, Combo) Typography: 14 fonts including DejaVu Sans for multilingual/Cyrillic content Headers & footers with {PAGENO}, {nbpg}, {DATE}, {sitename} variables Watermarks, password protection, configurable margins and paper sizes Logging via ProcessWire's built-in log system (Setup > Logs > wirepdf) Installation cd /site/modules git clone https://github.com/mxmsmnv/WirePDF.git cd WirePDF composer install Then install via Modules > Refresh in the admin. GitHub: https://github.com/mxmsmnv/WirePDF Feedback and bug reports welcome!

i think you need complete form https://processwire.com/about/contact/

Hi everyone, I'd like to introduce Banana Imagine — a ProcessWire module that brings high-quality AI image generation directly into your image fields using the Google Nano Banana API. Key features: Clean generation interface right below supported image fields Generate 1–4 variations at once Smart subtle prompt variations for better batch diversity Selected images saved natively to the page (with clean naming: [pageID]-[timestamp].jpg) Simple configuration: API key + choose which image fields to enable GitHub: https://github.com/mxmsmnv/BananaImagine This module is a fork / spiritual successor to my previous module GrokImagine (xAI/Grok-based): https://processwire.com/talk/topic/31744-grokimagine-ai-image-generation-via-xai/ Installation & usage instructions are in the README: Just drop the folder into /site/modules/, install, add your Google AI API key (billing required for image gen), select fields → you're good to go. Screenshots: Feedback, bug reports, and feature ideas are very welcome! Thanks, Maxim

Good news — found the root cause. The fake browser detection was checking for Sec-CH-UA (Client Hints) and Sec-Fetch-* headers, which browsers only send over HTTPS or to public origins. On http://localhost these headers are simply never transmitted, so Chrome was being flagged as headless automation and blocked on the very first request — before any rate limit counter even started. Fixed in 1.3.5 — the module now detects localhost and RFC-1918 private addresses and skips those header checks for local requests. All other fake browser checks remain active. Please update the module and let me know if that resolves it.

try to install, I have updated the dependencies

@adrian, Big thanks for the detailed reports and for sticking with testing this — especially the browser-specific blocks (Chrome/Firefox/Zen vs Safari) and the fact that bans were coming back many hours later. That helped a ton to reproduce and nail down the issues. Just released 1.3.4 with fixes for exactly those problems (logged-in users bypassing rate limiting properly, no re-triggering bans after expiry, true plain 404 in stealth mode, etc.). Release: https://github.com/mxmsmnv/WireWall/releases/tag/1.3.4 Full changelog: https://github.com/mxmsmnv/WireWall/blob/main/CHANGELOG.md