Search the Community

--- Module Directory: https://modules.processwire.com/modules/privacy-wire/ Github: https://github.com/blaueQuelle/privacywire/ Packagist:https://packagist.org/packages/blauequelle/privacywire Module Class Name: PrivacyWire Changelog: https://github.com/blaueQuelle/privacywire/blob/master/Changelog.md --- This module is (yet another) way for implementing a cookie management solution. Of course there are several other possibilities: - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/ - https://github.com/webmanufaktur/CookieManagementBanner - https://github.com/johannesdachsel/cookiemonster - https://www.oiljs.org/ - ... and so on ... In this module you can configure which kind of cookie categories you want to manage: You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience. Currently there are four possible cookie groups: - Necessary (always enabled) - Functional - Statistics - Marketing - External Media All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ... When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax: <script type="text/plain" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The data-attributes (data-type and data-category) are required to get recognized by PrivacyWire. the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision. If you want to give the users the possibility to change their consent, you can use the following Textformatter: [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie. You can also add a custom link to output the banner again with a link / button with following class: <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> I would love to hear your feedback ? CHANGELOG You can find the always up-to-date changelog file here.

Hi everyone, I’m happy to share NativeAnalytics, a native first-party analytics module for ProcessWire. The module is now available in the ProcessWire modules directory: https://processwire.com/modules/native-analytics/ NativeAnalytics provides a useful analytics dashboard directly inside the ProcessWire admin, without relying on external analytics platforms, third-party scripts or external APIs. All analytics data is stored locally in your ProcessWire installation, which makes it a good fit for projects where you want a simpler, more self-contained analytics solution. The module currently tracks and displays: page views unique visitors sessions current visitors top pages referrers devices and browsers 404 hits engagement events such as form submits, downloads, tel/mail clicks, outbound clicks and custom CTA events It also includes: charts and trend views comparison between periods custom date range filtering page-level analytics inside the page edit screen optional monthly email reports optional PDF report attachments exports to CSV, PDF and DOCX helper examples and a small snippet generator for custom event tracking New in the latest version: Goals and conversion tracking event-based goals, for example form submits, CTA clicks, downloads or tel/mail clicks page/path-based goals, for example thank-you pages or booking confirmation pages conversion rate reporting based on sessions and unique visitors a dedicated Goals dashboard with goal cards, goal trends and goal overview easier goal setup with helper text, quick presets and suggestions from already tracked events and pages daily aggregate tables for events and goals raw event retention setting additional database indexes and cleanup helpers for larger datasets There are also several privacy and consent-related options: optional cookie-less visitor/session mode consent-based tracking helper functions for custom consent integrations optional PrivacyWire localStorage consent helper support cleaner behaviour when global tracking is disabled The reason I built this module was that I wanted something that feels natural inside ProcessWire itself, instead of embedding another analytics service into the admin. For many sites, it can be useful to have core traffic, engagement and conversion data available right where content is managed. Goal tracking was added because several users asked for a simple way to measure important actions without having to fight with external analytics tools. For example, you can now create a goal for a contact form submit, a CTA button click, a file download or a visit to a thank-you page, and then see conversions and conversion rates directly in the ProcessWire admin. A small note about very large datasets: NativeAnalytics includes retention settings, daily aggregate tables and cleanup tools, and the latest version improves this further for events and goals. For very high-traffic sites, I still recommend using sensible raw data retention and keeping long-term reporting based on aggregated data. I do not want to overclaim without real long-term benchmarks on extremely large datasets, so feedback from larger installations is very welcome. ! If you tested one of the earlier development versions named PW Native Analytics, I recommend uninstalling that old test version first and installing NativeAnalytics as a fresh module, because the module name and structure changed during development. Multi-site analytics is not included yet, but it is something I am looking into. It would need proper per-site separation in the stored analytics data, so I want to approach that carefully rather than adding a quick workaround. Feedback, bug reports and suggestions are very welcome. Get it here: https://processwire.com/modules/native-analytics/ Enjoy! If you find NativeAnalytics useful and would like to support further development, maintenance and testing, a small donation is always appreciated. The module will remain free, but support helps me spend more time improving it and adding new features. DONATE

Hi everyone, Needed a way to embed polls and quizzes directly into page content — shortcode in any text field, renders as a cache-safe interactive widget. Built it, it works well, sharing it. GitHub: https://github.com/mxmsmnv/Pulse Screenshot: What it does Polls and quizzes embedded via shortcode into any text field: [[pulse:poll name="my-poll"]] [[pulse:quiz name="my-quiz"]] Polls — voting with live results, multi-select, allow-other option, duplicate protection (cookie+IP, user session, or soft). Quizzes — three modes: graded — points, pass/fail threshold, answer review personality — options award points to outcomes, winning outcome shown at end exam — graded plus timer, attempt limit, question bank, certificate Visual questions — question-level images and image-option layouts. Admin workspace — Setup → Pulse with full CRUD, analytics, CSV/JSON export, import, clone, and demo installer. Security: All scoring server-side — is_correct / outcome_points never reach the client before submission CSRF mandatory on all submissions (token from /pulse/state) Honeypot + rate limiting by hashed IP Voter cookies and IPs stored as salted hashes only Exam HMAC-signed question sets, server-enforced timeouts, signed certificates Cache-safe: renders a static shell, hydrates via JS — works with ProCache. Requirements: ProcessWire 3.0+, PHP 8.2+ MIT License.

Hi @Mikel I use a custom JavaScript function (that name is entered in the PrivacyWire module settings) to check for consent and then set the cookie for activating NativeAnalytics: function initNativeAnalytics() { const consent = JSON.parse(localStorage.getItem('privacywire')); //console.log(consent); if (consent && (consent.cookieGroups.statistics || consent.cookieGroups.marketing)) { document.cookie = "pwna_consent=1; path=/; max-age=" + (60*60*24*365) + "; SameSite=Lax"; if (window.PWNA && typeof window.PWNA.trackIfConsented === 'function') { window.PWNA.trackIfConsented(); } } else { document.cookie = "pwna_consent=; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT"; } }

New Figma to PageGrid Importer From design to production in no time, with the new Figma to PageGrid Importer. At our studio, Konkat, we do all our design work in Figma because it lets us move and iterate quickly alongside our clients. While AI is great at spinning up generic, cookie-cutter layouts, true professional value lies in creating websites genuinely custom-tailored to a client. For that level of work, pure text prompts simply don’t offer the layout precision you need—writing a description will never match the intuitive control of direct visual input. But as any developer here knows, turning a finished design into a live, client-editable website usually requires a lot of manual layout replication before you can get to the core development. Even though PageGrid is already a massive speed upgrade, manually recreating a canvas layout element-by-element is still a time-consuming assembly phase. It eats up hours better spent on deep development, custom logic, and polished execution. That’s exactly why I (with the help of Claude Code) built the new Figma Exporter plugin and a native PageGrid Importer module for ProcessWire. It compresses hours of manual layout replication into a five-second automated import. By handling the structural translation instantly, it lets you skip the repetitive setup entirely and jump straight into the fun stuff: custom animations, fine-tuning, and high-level development. Instead of just telling you what it does, I want to be completely transparent about how it was built, why we intentionally avoided a "live AI" generation solution, and how it changed my perspective on building dev tools. Why We Rejected Live AI Generation When I started working on this, my first instinct was to leverage the power of AI agents directly during the import process. I tried using Claude via a live Model Context Protocol (MCP) setup to directly read my active Figma canvas and dynamically generate the PageGrid layout on the fly. Honestly, AI is surprisingly good at understanding how to build a layout in PageGrid now, and the initial results were already incredibly close to the original Figma designs. Using MCP is a really interesting alternative, but for daily production work, relying on a live AI connection just didn't make sense for a few major reasons: It was unpredictable: Every single time I ran the generation on the exact same layout, the resulting code structure came back slightly different. It was slow: Relying on live AI cloud prompts meant waiting for the model to think, stream, and process the data. API Bottlenecks: The live Figma API connections generated far too many requests, causing frequent rate-limiting issues. Resource-heavy: Each time we want to create a new layout we have to prompt an AI, which uses extra computing power and adds up in ongoing token costs. At our agency, Konkat, we built PageGrid to power actual production sites for our clients. We plan to use these tools daily to optimize our own studio workflow. In a professional production pipeline, an unpredictable guessing game that changes its behavior on every prompt simply isn't an option. We needed something that was completely deterministic, blazing fast, and independent of live external APIs. So, we changed our strategy entirely. Changing the Strategy: AI as the Engineer, Not the Runtime Since Claude had become deeply familiar with the Figma API, and thoroughly understood the structure of ProcessWire and PageGrid, I stopped trying to use the AI to generate layouts on the fly. Instead, I partnered with Claude to write a dedicated, local compiler. Claude acted as my co-developer. Together, we built a simple, two-part ecosystem: A local Figma Exporter Plugin that reads the canvas instantly and packages the architectural structure and assets into a lightweight .ZIP file. A native ProcessWire Importer Module that unzips that package and handles the rendering locally on your server. Because the final tool runs entirely on pure, local code logic, it requires zero active AI API calls, runs instantly, and produces the exact same, predictable structure every single time. Respecting Layout Intent Without Forcing "Auto Layout" Most Figma-to-code plugins fail unless you have meticulously built your file using strict, perfectly nested Auto Layout components. If you design loosely, those plugins break or output absolute-positioned spaghetti code that is impossible to maintain. As a designer, I know that forcing strict Auto Layout workflows during the rapid, creative prototyping phase can feel incredibly restrictive. That’s why we engineered our importer to give you complete freedom to design your way. Whether you prefer nesting elements using strict Auto Layout, arranging them freely using Figma's native Column Layout Guides, or using a mix of both, the compiler adapts to your workflow. When you run the importer, PageGrid respects your structural intent and translates it into standard web architecture: Native CSS Grid & Flexbox: Elements aligned to your column guides are automatically mapped to precise, responsive CSS Grid positions, while Auto Layout frames are translated cleanly into semantic Flexbox structures. Direct Layer Mapping & Smart Flattening: The importer replicates your Figma layer structure directly in PageGrid by mapping all layer nodes straight to native PageGrid Blocks like pg_group (groups), pg_image (images), and pg_editor (text). At the same time, the parser automatically filters the tree, flattening out any unnecessary deep nesting or arbitrary wrappers when needed so your backend tree stays incredibly clean. Maps Figma API to Modern CSS: It natively extracts typography styles, colors, borders, spacing rules, and effects, turning them directly into clean PageGrid metadata or copyable CSS. 💡 The "Grouping" Pro-Tip: Because Figma group nodes map directly to pg_group container blocks, grouping items that belong together directly shapes your PageGrid backend structure. While the importer can handle ungrouped layers, grouping your elements ensures the highest layout accuracy and keeps complex structures beautifully organized under the hood. Keeping You in the Driver's Seat When the import finishes, you are not left with a static image or a fragile webpage that breaks the moment you edit a line of text. You get a native, fully editable ProcessWire page built out of organized PageGrid blocks. Because PageGrid functions like a precise web canvas, the layout remains rock-solid. Your clients can easily log in to update text and images directly on the live page, but they will never accidentally break the structural layout you designed. The mechanical translation work is completed in five seconds. From there, you take over to do the work that humans do best: adding fine-tuned interactions, implementing custom animations, and binding dynamic backend data fields. How to Try It You don't need a paid plan to use it—the plugin works perfectly on the free version of Figma. Here is how to get started: Get the Figma Plugin: Open the Figma to PageGrid Exporter in Figma. Select your main design frame and download your .ZIP package. Install the Importer Module (Self-Hosted Only): Add the PageGridFigmaImport module to your ProcessWire backend. Upload & Run: Go to Setup > Figma to PageGrid, drop in your file, and watch your layout appear natively. Documentation: Figma Import Documentation. I consider this a beta launch, not every generated layout will be perfect out of the box, but results so far have been quite impressive. I plan to improve this over time. Give it a try and let me know what you think!

Dear Community, I am currently looking for a web developer to implement a website based on a fully completed and professionally designed layout provided by a design agency. The scope of work is limited to HTML, CSS, and JavaScript development. All other components, such as PHP integration, CMS setup, cookie banner, and backend functionality, will be handled by me. The website must be fully responsive and optimized for desktop, tablet, and mobile devices. For tax and legal reasons, the developer must be based in the European Union and able to provide a valid EU VAT ID. I look forward to hearing from interested developers. Best regards Nomak

NativeAnalytics v1.0.19 – update This release mainly focuses on privacy/consent handling and admin UI polishing. Added / improved: Added optional cookie-less visitor/session mode for sites that want to avoid browser visitor/session cookies. Added PrivacyWire localStorage consent helper support. Added helper methods for custom consent integrations: window.PWNA.trackIfConsented() window.PWNA.setConsent() window.PWNA.clearConsent() window.PWNA.syncPrivacyWireConsent() Improved consent-based tracking flow, so tracking can start correctly after consent is granted. Tracking-related settings are now hidden/disabled when global tracking is turned off, to avoid confusing combinations like “tracking off + event tracking on”. Added a module settings shortcut button in the analytics dashboard header. Improved AdminTheme compatibility and tab spacing across ProcessWire admin themes. Polished the flat admin UI and removed rounded corners. Fixed panel alignment issues in dashboard grid layouts, especially where side-by-side panels appeared vertically offset. Note: Multi-site analytics is not included yet. It is planned as a possible future improvement because it needs proper per-site separation in stored analytics data. Download is updated in first post!

Hi, @Stefanowitsch, I´m curious: Do you hook into a PrivacyWire method or do you use its built in custom function trigger? We simply have set up a script that checks the local storage for the privacywire key. Then a cookie for Native Analytics is set or unset depending on its "statistics" value. Cheers, Mike

Hi everyone, I’ve released a new module: ProcessLegalDocs GitHub: https://github.com/mxmsmnv/ProcessLegalDocs ProcessLegalDocs generates legal documents directly from the ProcessWire admin, including: Privacy Policy Terms of Use Cookie Policy Data Processing Agreement CCPA Notice Refund Policy Disclaimer It currently supports 93 jurisdictions and 44 languages, with jurisdiction-aware language selection and document requirements. This is also the first module built on top of my new Context module: https://github.com/mxmsmnv/Context Context acts as the AI/site-analysis base layer. ProcessLegalDocs uses it to understand the site structure, installed modules, fields, pages, and configured AI gateway, then uses that context to generate more relevant legal documents. The module can still work without Context, but in that case it falls back to more generic templates. For best results, Context should be installed and configured with AI. Main features: Generates Markdown legal documents with YAML frontmatter Stores files in /site/assets/legal/ Includes dashboard, preview, download, validation, regenerate, delete, and ZIP export actions Supports many privacy/data protection regimes, including GDPR, UK GDPR, CCPA/CPRA, COPPA, PIPEDA, LGPD, APPI, PIPL, DPDP, PDPA variants, and many US state privacy laws Includes settings for owner/company data, DPO, business audience, data categories, processors, analytics, payments, email/marketing tools, cookies, refunds, subscriptions, review status, and optional ProcessWire page publishing Uses ProcessWire admin UI conventions / AdminThemeUikit Requirements: ProcessWire >= 3.0.255 PHP >= 8.3 Context module optional, but recommended for AI generation Let’s take a look at the module interface: Install: Clone into /site/modules/ProcessLegalDocs/ Refresh modules Install ProcessLegalDocs Open Setup → Legal Docs GitHub: https://github.com/mxmsmnv/ProcessLegalDocs Context module: https://github.com/mxmsmnv/Context This is an early release, so feedback, testing, issue reports, and ideas are very welcome.

This module is very much work in progress, but I wanted to get it out as soon as it is somewhat useful, so here we go: say hi to Cookie Table. Cookie Table is essentially a module for managing a list of cookies used on a site. At least around here in Finland it is a necessity to have a list of cookies, regardless of whether they are ones that you need a specific permission for. This list should include key details about each cookie, including name, purpose, and duration. Cookie Table is used to manage this data in the admin, and once you've set up a list of cookies, you can render it on the front-end as a table: echo $modules->get('CookieTable')->render(); ... or using your own custom markup: $cookies = $modules->get('CookieTable')->getCookies(); foreach ($cookies as $cookie) { echo "Cookie name: " . $cookie['name'] . "<br>"; } Now, the reason I'm saying that it's a work in progress — even though it does what I've outlined above — is that there are a lot of things I want to add still. At the moment it is mostly a tool for managing some data in the admin, which is something you could just as easily do via pages, or even simple CKEditor / TinyMCE field. What I am mostly interested is adding some automation: Crawling the site, or at least most important pages, and automatically detecting used cookies Integrating the module in whatever way makes most sense with PrivacyWire Integrating the module with existing cookie databases Adding some way to push/pull updates via web API Once one or more of aforementioned features have been added, I can definitely say that this module is worth its weight 😉 Cookie Table on GitHub Install via Composer: composer require teppokoivula/cookie-table

@Roych thanks! This is a really nice and clean module that integrates straight into the backend. I just installed it on a client site and its already filling with interesting data. @ai_slop I was able to make this module work together with PrivacyWire since I am inside the EU. If consent is chosen the cookie is set and the module activates.

Looks good @Roych Can it work cookie-less for EU sites?

Well, it's been about a year in the making, but v5 is finally available. I have upgraded a lot of sites to it now without issues, but I would still caution you to be ready to revert (or delete module) files if the namespace changes cause any issues - there were a lot early on. The two new banner features are: the console panel can now run very long running scripts (there is a one hour limit just so that broken scripts don't run forever) which is great for massive batch modifications or the like. The dumps recorder panel (either manually loaded or via Enable Guest Dumps) now live polls for new dumps so you don't need to continually load the page to see the entries as they are logged. Have fun! Breaking Changes - Minimum requirements bumped to ProcessWire 3 and PHP 7.1 - Removed legacy Tracy 2.5.x core branch and FireLogger support - Panel DOM IDs now include `ProcessWire-` prefix — update any custom CSS/JS targeting panel IDs Namespace Support - Full `namespace ProcessWire` support across all panels and POST processing files - Autoloader bridge for seamless non-namespaced to namespaced module migration - Third-party panels bridged automatically via `class_alias()` Security - Comprehensive security hardening: XSS sanitization, CSRF protection on all panels, directory traversal fixes, CSP nonces on all inline scripts, cookie SameSite enforcement, and input sanitization New Features - Console — long-running scripts automatically switch to background polling, surviving gateway timeouts; session locks released so you can continue browsing while scripts run; storage migrated to IndexedDB - PW Version Switcher — extracted into its own class with automatic version reverting on failure - Dumps Recorder live polling — live-polls for new dumps from other users and guest sessions - File Editor BlueScreen integration — exception page links open in the built-in file editor - Various smaller additions across Diagnostics, API Explorer, Request Info, and PW Info panels Bug Fixes - PHP 8.x compatibility fixes for `htmlspecialchars()`, `trim()`, and `isset` null handling - Fixed Console panel snippet and polling issues, including cache-busting for CDN/proxy environments - Fixed File Editor not opening files linked from BlueScreen exception pages - Fixed Adminer URL/namespace issues and thumbnail viewer path handling - Fixed Debug Mode panel to use modern API methods instead of deprecated ones - Fixed API Explorer "What's New" section and reflection errors for hooked methods - Fixed "unsaved changes" false positive when saving pages in PW admin - Windows path and line ending fixes Performance - Session lock contention reduced - Various loop and query optimizations

TrackingScripts Module Manage and inject tracking scripts (Google Analytics, Google Ads, Facebook Pixel, custom code) into site pages, with optional PrivacyWire consent integration and robots.txt/llms.txt file management. Features Google Analytics (GA4) — inject gtag.js with Measurement ID Google Ads — inject gtag.js with Ads conversion ID Facebook Pixel — inject Pixel tracking code with noscript fallback Custom code — free-form textareas for any third-party scripts (head and/or body) PrivacyWire integration — when enabled, scripts are injected with data-category attributes and type="text/plain" so they only load after user consent robots.txt & llms.txt — edit and auto-generate both files from the admin; content is written to the site root on save Per-service controls — enable/disable, position (head or body), and consent category for each service independently ID validation — regex validation for GA (G-), Ads (AW-), and Pixel (numeric) IDs before injection Admin-only exclusion — scripts are never injected on admin or form-builder templates Files site/modules/TrackingScripts/ ├── TrackingScripts.info.php ← module metadata ├── TrackingScripts.module.php ← main module (hooks, script injection) ├── TrackingScriptsConfig.php ← module configuration (ModuleConfig) ├── ProcessTrackingScriptsConfig.info.php ← Process module metadata └── ProcessTrackingScriptsConfig.module ← admin UI for non-superusers Installation Copy the TrackingScripts folder into /site/modules/ In the admin go to Modules → Refresh, then install TrackingScripts Optionally install ProcessTrackingScriptsConfig — this adds a Setup → Tracking Scripts page that allows non-superuser roles to edit the configuration. Assign the tracking-scripts-config permission to any role that needs access. Configuration Go to Modules → Configure → TrackingScripts (superuser) or Setup → Tracking Scripts (any user with permission). Google Analytics Field Description Enable Activate/deactivate injection Measurement ID GA4 ID, e.g. G-XXXXXXXXXX Position Inject in <head> or before </body> PrivacyWire Category Consent category (default: Statistics) Google Ads Field Description Enable Activate/deactivate injection Ads ID e.g. AW-XXXXXXXXX Position Inject in <head> or before </body> PrivacyWire Category Consent category (default: Marketing) Facebook Pixel Field Description Enable Activate/deactivate injection Pixel ID Numeric ID, e.g. 123456789012345 Position Inject in <head> or before </body> PrivacyWire Category Consent category (default: Marketing) Custom Tracking Code Two free-form textareas for any additional third-party code: Custom Code — Head: injected before </head> Custom Code — Body: injected before </body> PrivacyWire Integration When enabled, all tracking scripts are rendered with PrivacyWire-compatible attributes: <script type="text/plain" data-type="text/javascript" data-category="statistics" class="require-consent" src="..."></script> This ensures scripts only execute after the user gives consent for the corresponding cookie category. Requires the PrivacyWire module to be installed and active. Robots.txt & LLMs.txt Edit the content of both files directly from the admin. On save, the files are written to (or removed from) the site root: /robots.txt — search engine crawler directives /llms.txt — LLM/AI bot directives If a textarea is left empty, the corresponding file is deleted from the site root. How It Works The module hooks into Page::render (priority 100) to inject scripts via str_replace on </head> and </body>. This means: No template modifications required Works on all front-end pages automatically Runs before PrivacyWire (priority 101), so consent attributes are in place when PrivacyWire processes the page The robots.txt and llms.txt files are written via a hook on Modules::saveConfig, triggered whenever the module configuration is saved from either the module config screen or the Process admin page. ProcessTrackingScriptsConfig (Admin UI) A Process module that mirrors the full TrackingScripts configuration under Setup → Tracking Scripts. Purpose Allows non-superuser roles to manage tracking scripts without access to the Modules admin. Permission The module registers the permission tracking-scripts-config. To grant access: Go to Access → Roles Edit the desired role Check tracking-scripts-config Save How it works Reads and writes the same configuration data as TrackingScripts via $modules->getConfig() / $modules->saveConfig() Changes from either location (Modules → Configure or Setup → Tracking Scripts) are reflected in both Saving triggers the same Modules::saveConfig hook, so robots.txt/llms.txt files are written automatically Requirements ProcessWire 3.0.110+ PHP 7.2+ PrivacyWire (optional, for consent integration) License Licensed under the MIT License.

Hi, I have clients using a processwire site from with other applications (eg browsers in those apps) previously the site was locked down on IP ranges and login was not required. Now that is changed and login is required. One of the clients now get 500 internal server error when trying to login. I think it is related to the session cookies. This is what I've tried: In httpd.conf: Header always set Content-Security-Policy "frame-ancestors 'self' client1.domain.com client2.domain.com"; This I can see also see is set by looking at the headers. Then I'm trying to set SameSite=None wich I can't get to be working, I've tried: In .htaccess: Header edit Set-Cookie ^(.*)$ $1;Secure;SameSite=None In site/config.php: ini_set('session.cookie_samesite', 'None'); and... $config->cookieOptions = [ 'secure' => true, 'samesite' => 'None', ] But still cookies looks like this: Does anyone have an idea why the cookie options seems to be the same, no matter how I configure above? And do you believe I'm on the the right path solving the issue or can it be something else? Running an old Processwire 3.0.123-0 Thanks

Just working on a new module for a customer who is concerned about the wire frontend cookie set w/o prior consent by the user. The customer uses frontend forms which require session cookies (wire) e.g. for CSRF checks, input validation, failed attempt restrictions etc. So he wanted to show a cookie dialogue asking for consent for technical required cookies, even if this is not 100% required by the DSGVO. First used a modified PrivacyCookie module to achieve this, before I went to create a minimalistic module myself. My module hooks before page::render and adds a cookie consent dialogue which asks for consent for technical required cookies and shows an Accept/Decline button and links to imprint and privacy policy sites. My module also hooks into $config->sessionAllow and sets it to true if user gave consent, requested a backend page or a wire session already exists. This way wire cookie is only created in frontend if user gave consent. On the form page of my customers site the display and processing of the frontend form is wrapped in a $session->hasCookie() block to execute only after user gave consent. Without consent a message is shown that using the form requires cookies. By default the consent cookie is stored for 7 days if accepted, so the cookie dialogue won‘t show up on next visit unless user cleared cache. If user declined, the consent cookie expires after the browser session so the cookie banner pops up again on next browser session. So who may be using this module? Clients only using technical required cookies by default (no google fonts, youtube etc.) maybe with an optional frontend form, which are still afraid or simply want to have a cookie consent dialogue before the PW wire frontend cookie gets created. Will do some more tests and polishing, before uploading the module to my Github repository.

Hi @Inxentas, If disabling protectCSRF and sessionFingerprint results in a continuous redirect to the login page, it’s almost certainly a session persistence issue. ProcessWire likely cannot verify your session after the redirect, treating you as a guest again. Here are a few things to check: File Permissions: Ensure that /site/assets/sessions/ is writable by the web server. If PW can't write the session file, the login will fail silently. Clear Browser Cookies: This is crucial. If you previously had sessionCookieSecure enabled or switched between HTTP/HTTPS, your browser might be holding onto an invalid or mismatched session cookie. Delete all cookies for this domain and try again. Check site/config.php for Hostnames: Ensure your $config->httpHosts array correctly includes the domain (and subdomains like www) you are using to log in. PHP session.save_path: If you aren't using PW's native session handler (Database), check your php.ini to see if the system's temporary directory for sessions is full or unwritable. Native Session Modules: If you have SessionHandlerDB installed, try temporarily disabling it in the database (table modules) to see if switching back to file-based sessions resolves the conflict. Since you have debug mode on, check /site/assets/logs/errors.txt for any "Session save path not writable" or "CSRF" related entries that might have been logged right at the moment of the redirect. Hope this helps!

Hi, I work for UK and EU clients. I remember about five years ago when GDPR came in there was a panic due to the potential fines and the things people did ranged from nothing at all to extreme UX disasters where the first thing you saw was a huge popup giving the user the opportunity to break the site. Since this is a legal area and I am not qualified to do so I do not give clients any advice in this area but will implement whatever kind of policy they decide on. To date many clients are happy to have a cookie notice that acts as a warning rather than manage specific cookies as it saves them disabling Google Analytics, paying for legal advice, etc. A client has raised a concern that since 2019 we should have started giving users the option to disable different types of cookies and therefore the above approach does not meet this legal requirement. Anecdotally, many small sites either do nothing at all or have a cookie warning as above. It seems to be a minority of sites, generally bigger ones, that allow for full on cookie management (i.e. blocking of non-essential cookies) and therefore are likely in a small group that are fully compliant. I've had a quick look today and am unsure on how to implement this. Am I right in saying there are two primary ways: Use a paid third-party service that scans your site for scripts that uses cookies; this handles the popup and management for you Use a jQuery/JS plugin that handles the interface but not the cookie blocking — you do this yourself It also looks like there is a WordPress plugin for this that WP users can use. Do these work like option 2 above or can they actually scan your site? Are there any PW or JS plugins that I should be aware of that can help me out here? I'm just after a bit of general advice from anyone who has PW sites and has implemented cookie management. Thanks.

Hello all, is there a way to prevent the creation of the Processwire frontend Cookie wire until the user has confirmed/opt-in to allow technical required Cookies? Not too sure, if the wire Cookie is technical really required for PW to do it‘s job (show frontend stuff, remember layout etc.). In Germany it‘s still a bit fuzzy, what technical required means to a lawyer. So ideally there shouldn‘t be set any Cookie without opt-in by the frontend user, unless it is really technical required. Can anybody shine some light on this aspect? For what is the wire Cookie used in the frontend layer, or in other words technical required by the PW frontend? What parts - except admin/backend - of PW wouldn‘t work without that cookie? Looking forward for some hints on that topic.

WireNPS is a comprehensive module for collecting and analyzing customer feedback via a modern Net Promoter Score (NPS) popup interface. Key Features: Elegant NPS Widget: A non-intrusive, mobile-friendly popup for ratings (0-10) and text feedback. Real-time Analytics: Dashboard featuring NPS score calculation, score distribution charts, and 30-day trend graphs. Multilingual Support: Built-in support for English, German, French, and Chinese with automatic browser/user language detection. Flexible Access: Support for both logged-in users and guests (Public/Private modes). Data Export: CSV export functionality for external analysis. Privacy Control: Configurable IP/User Agent tracking and cookie management. Requirements: ProcessWire 3.0+ PHP 8.2+ Quick Installation: Download or git clone into /site/modules/WireNPS/. Install via the ProcessWire admin. Create an AJAX handler page using the provided template. GitHub: https://github.com/mxmsmnv/WireNPS

$config->ajax is being set locally, however the exact same call for my client it is not. The request for my client is rather long, 25 seconds. However, I'm stumped as to why, this should not affect this code: $config->ajax = (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest'); If I remove the if($config->ajax) from my ajax function, everything works as expected. Headers sent look correct: Accept:application/json, text/javascript, */*; q=0.01 Accept-Encoding:gzip, deflate, sdch Accept-Language:en-US,en;q=0.8 Connection:keep-alive Cookie:wire=vg8bth2bcv2c8gq58nbbfean61; wire_challenge=nVbLGO0aHzCu%2FMO9ekc4t.N6ol.xf8s5 Host:** Referer:http://*** User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 X-Requested-With:XMLHttpRequest

Hi all, Introducing a new GDPR Cookie Management Banner module. https://github.com/adrianbj/CookieManagementBanner https://modules.processwire.com/modules/cookie-management-banner/ This module was sponsored by VentureWeb in Squamish, BC, Canada. I converted a Drupal module written by Oliver Walker from VentureWeb into what you see here. The Drupal module requires jQuery so at the moment, this module also requires jQuery. I will probably remove this sometime soon. This module certainly has similarities to MarkupCookieConsent but provides the user with the following features: The user can accept all cookies or they can choose to not accept tracking/marketing cookies. Module config options allow you to: define all text and button labels (multi-language support) manually increment the cookie policy version which forces the user to review their consent again select whether users can manage their cookies, or just accept all option to limit display of banner to users only in European Union (by IP address) position selection (top or bottom overlay, or content pushed down from the top) It comes with basic default styling which is easily overwritten by site CSS The module sets various values to the dataLayer array which works together with Google Tag Manager - please read through the code in /assets/js/CookieManagementBanner.js to get a better idea of how this works and what is made available for GTM. You can wrap your tracking/marketing cookie code in a check for the localstorage key of: pwcmbAllowCookies if(localStorage.getItem('pwcmbAllowCookies') == 'y') You can also provide a link on your site (probably in the footer) like this that will allow the user to show the banner even after they have saved their preferences / accepted. <a href="#cookies" class="js-pwcmb-notice-toggle">Manage Your Cookies</a> Would love to hear feedback from anyone who gives this a go.

I changed my default setcookie() functions to the newly added $input->cookie method as described in https://processwire.com/blog/posts/pw-3.0.141/ Just noticed no cookies are saved when using PW's $input->cookie->set() (in template file). I am using PW 3.0.148, PHP 7.3 and testing with setcookie('test', 'test') works just fine. Tried to add age, path and domain as well, but nothing works. setcookie('defaultsetcookie', 'works'); $config->cookieOptions = [ 'age' => 604800, 'path' => null, 'domain' => null, 'secure' => null, 'httponly' => false, 'fallback' => true ]; $c = $input->cookie->set('pwcookie', 'wontwork'); print_r( $c ); print_r( $_COOKIE ); Output ProcessWire\WireInputDataCookie Object ( [defaultsetcookie] => works [wire] => 89ortkjmq5dsgb7em2h6ljod9v [pwcookie] => wontwork ) Array ( [defaultsetcookie] => works [wire] => 89ortkjmq5dsgb7em2h6ljod9v [pwcookie] => wontwork ) Any idea what is wrong? It is strange setcookie() works but PW methods won't.

@Jim Bailie This seems like a good question for ChatGPT, at least to get a starting point. I asked it if it could convert .htaccess to nginx and it said: So I uploaded this v1 ProCache ruleset from one of my site (I replaced product key with "xxx" for this example): # PROCACHE vfd31e36cd7ffdab982312621683b6fee RewriteCond %{REQUEST_METHOD} !=POST RewriteCond %{QUERY_STRING} !.*=.* RewriteCond %{HTTP_COOKIE} !^.*(wire_challenge|wires_challenge).*$ RewriteCond %{DOCUMENT_ROOT}/site/assets/ProCache-xxx/$1/index.html -f RewriteRule ^(.*) %{DOCUMENT_ROOT}/site/assets/ProCache-xxx/$1/index.html [L] # /PROCACHE And it gave me this: # PROCACHE vfd31e36cd7ffdab982312621683b6fee equivalent for Nginx location / { # Skip cache if POST request, query string present, or cookie contains wire_challenge / wires_challenge if ($request_method = POST) { break; } if ($query_string != "") { break; } if ($http_cookie ~* "(wire_challenge|wires_challenge)") { break; } # Serve static cached HTML file if it exists if (-f $document_root/site/assets/ProCache-xxx/$uri/index.html) { rewrite ^(.*)$ /site/assets/ProCache-xxx$uri/index.html break; } # Default: pass to ProcessWire (index.php) try_files $uri $uri/ /index.php?$query_string; } # /PROCACHE I have no idea if it's nginx version works or not, but seems like it might be a potentially good way to convert something like this.

Triggering Custom JS function Hi folks, I'm using Privacywire on a number of sites and it;s working well, thank you! With Microsoft Clarity now moving to requiring a consent signal on cookie acceptance I had hoped to run a signal function for this with the 'Trigger a custom JS function' setting in Privacywire's config (right at the bottom). However, having declared a test function (to just console.log something) higher up in the page script files, and adding the function name into the Custom JS function field in Privacywire, I can't get the function to run when cookies are accepted. I have tried both the function name (e.g. 'myFunction') and with brackets (e.g. 'myFunction()') but neither seems to work. Anyone tried this and got it to work? Thanks for any help!