Recently Updated Topics

For the record: this seems an issue that started occuring in 3.0.265. All previous versions have not resulted in this problem. We are now sticking to the master branch only.

From a database perspective page reference fields should scale quite well and there's always the option to build a custom table managed with hooks if you need something ultra fast so you have control of the indexes. But, in the admin, is there any field type that scales well? I've tried them all out and from what I can see, all page reference field types and input types, do not have the option to show your page references in a searchable, paginated lit loaded by AJAX; they all go in a single list. I can imagine this getting problematic once the number of page references gets moderately big. Is there such a thing? What do you do if you have 100s of references, 1000s of references or more? At what point are the standard page reference fields no longer an option?

A Jumplinks successor would be awesome…

@Peter Knight Yes, the monitors are at an angle so that whether I'm looking at the left one or the right one, they are always directly in front of my line of sight with no angle. I think it looks more angled than it actually is because I used my phone's 0.5 wide angle lens, which is also why the coffee mug looks a bit stretched.

Hi @tcnet I have a fix request for Login Fail Notifier 1.0.4: fix Undefined array key "SERVER_NAME" under CLI getDefaultData() reads $_SERVER['SERVER_NAME'] unconditionally, and since the module is autoload, __construct() calls it on every bootstrap. On a web request that key always exists, but under CLI (php index.php …) there's no request, so it's undefined, hence I get a lot of PHP Warnings: Undefined array key "SERVER_NAME" on every CLI run. With display_errors on it also lands on stdout and breaks tools that parse CLI output (e.g. JSON). Fix for line 79: 'notification_subject' => 'Failed login attempt at '.($_SERVER['SERVER_NAME'] ?? ''), I applied that fix to the module on my sites, but could you please also apply it? Thanks in advance!

Hi @eutervogel! I just wanted to tell you that I spent quite some time in the demo shop, testing everything out, and I am pretty impressed with the work you've done! Of course I lack the experience of Stefanowitsch in this matter, but I ckecked out all the other shop solutions for PW and all of them are not suited for EU use. This is something I could work with and/or suggest to a client. In the past I had to refuse all requests for a shop... If you are short of testers? I am more than willing to help! Bernd

Stunning work @maximus How the preorder works in digital products? Is the buyer receives automatically an email with a download link during the release date of the product? Also, can we create and integrate more payment methods?

Thank you both, @elabx, yes should be disappear soon... 😉

Hi @markus-th I'm glad I saw this as I was just recently looking for something similar. Thanks for making it. WIll check it out soon.Will

WireWall 1.6.0 Released: Traffic History, AI-Ready Logs, and Dashboard Redesign Hi everyone, I’ve released WireWall 1.6.0, a new update for the ProcessWire firewall/security module. This release focuses on better traffic visibility, AI-assisted analysis, and a cleaner admin dashboard. What’s new AI-friendly traffic history WireWall can now save public request history as daily JSONL files: /site/assets/WireWall/traffic/traffic-YYYY-MM-DD.jsonl Each row contains structured request data such as: time allowed / blocked status block reason IP country city / region when available ASN method URL path and query referer User-Agent selected request headers This is separate from the normal ProcessWire log and is intended for later traffic analysis, including feeding recent traffic into AI tools. New setting A new option was added: Save Traffic History It is enabled by default and can be managed from the WireWall module settings. Dashboard redesign The Admin > Setup > WireWall dashboard has been redesigned with: clearer status header protection/logging indicators improved KPI cards better active bans view cleaner top reasons/countries/IPs sections more readable recent events table traffic history status and path display Agent-readable documentation This release also adds AGENTS.md, describing how AI agents and Olivia-style assistants should safely work with the module, including configuration keys, safe/risky operations, and website blueprint guidance. Version Current version: 1.6.0 Release: https://github.com/mxmsmnv/WireWall/releases/tag/v1.6.0 Repository: https://github.com/mxmsmnv/WireWall Feedback, bug reports, and configuration ideas are very welcome.

Hi everyone, I’ve released a new ProcessWire module: Oidc. Oidc adds lightweight OAuth 2.0 and OpenID Connect login to ProcessWire sites. It is meant for projects that need social login or company SSO without a full front-end account-management suite. Repository: https://github.com/mxmsmnv/Oidc What it does Adds OAuth/OIDC login buttons to ProcessWire templates Supports Google, GitHub, LinkedIn, Microsoft, Yandex and Yahoo out of the box Supports custom OIDC providers via discovery URL Works with providers such as Okta, Auth0, Keycloak, authentik, Azure AD and Dex Handles callbacks automatically on frontend pages Supports auto-registration of new ProcessWire users Preserves return URLs through the login flow Includes silent mode for SSO-only sites and intranets Provides hooks for identity resolution, login, registration and provider definitions Verifies OIDC id_token claims with nonce, issuer, audience, expiry and RS256/JWKS checks when available Basic usage After installing and configuring providers, render login buttons in a template: $oidc = $modules->get('Oidc'); echo $oidc->renderButtons(); The page that renders the buttons is also the callback page. Set that URL in the module settings and register the same URL in your OAuth/OIDC provider app. Example use cases Add “Continue with Google” or “Continue with GitHub” to a member area Use Okta/Auth0/Keycloak for company SSO Protect an intranet or private section with silent SSO Auto-create ProcessWire users after successful provider login Add custom rules through hooks, for example restricting registration to a company email domain Documentation The README gives the overview, and the repository includes detailed documentation and agent-readable integration notes: README: https://github.com/mxmsmnv/Oidc Documentation: https://github.com/mxmsmnv/Oidc/blob/main/DOCUMENTATION.md Agent guide: https://github.com/mxmsmnv/Oidc/blob/main/AGENTS.md Requirements ProcessWire 3.0.200+ PHP 8.1+ curl openssl The module is MIT licensed. Feedback, bug reports and suggestions are very welcome.

How KeyHelp for ProcessWire was built: from a phone idea to a tested module I have been building modules for ProcessWire for a long time, but this one had a slightly different origin story. KeyHelp started not as a carefully planned “module project”, but as a practical question while I was away from my computer: What if ProcessWire could manage a hosting panel directly from the admin area? The initial research happened on my phone. I was looking at how other systems handle hosting integrations, especially WordPress. WordPress has a huge ecosystem around this: hosting panels, one-click installers, backup plugins, deployment tools, billing integrations, and managed hosting workflows. Panels like HestiaCP, FastPanel, CyberPanel and CloudPanel all have their own approaches to WordPress automation. That made me think about ProcessWire. ProcessWire is a very strong developer CMS, and I have built modules for it for years, but hosting operations usually still live outside the CMS: domain setup, databases, SSL, PHP versions, DNS records, FTP accounts and cron jobs. For editors and site owners, that means switching between the CMS and the hosting panel. For developers, it means repeating small operational tasks that could probably live closer to the project. The research then moved toward German hosting panels. I used Google Gemini on my phone to explore that landscape. The conversation started around hosting panel integrations, WordPress automation, CloudPanel, CLI/API wrappers and then German panels specifically. KeyHelp stood out because it is widely used in the German hosting world and has a REST API. I also looked at the broader German ecosystem: LiveConfig, Froxlor, older i-MSCP setups, and custom panels from German hosts like All-Inkl and Mittwald. That context mattered, because KeyHelp is not just “another control panel”. It belongs to a hosting culture where stability, server control and GDPR-friendly infrastructure matter. After that research, I moved to Claude on my phone for the first implementation attempt. The first prompt was essentially: Need build integration module with KeyHelp web panel for administration Webserver inside PW Then I defined the first scope: Domains: create, delete, list Clients / users Databases Email accounts SSL / Let’s Encrypt PHP settings DNS records A ProcessWire admin dashboard with server status, domains and database widgets API access through a KeyHelp admin key Claude produced the first module draft. It created the initial structure with a module file, assets, views, dashboard, domain list, create forms, SSL/PHP/DNS screens, client views, database screens and basic cache/API handling. But the first version was too monolithic. So the next correction was immediate: Do not make it a monolith. Put the settings into the module. Where is the Process module? That changed the architecture. The module was split into: KeyHelp.module.php for configuration, API client, cache, debug logging and module settings ProcessKeyHelp.module.php for the ProcessWire admin UI later, multiple traits under src/ProcessKeyHelp/ views under views/ CSS/JS and Remix Icon SVG assets under assets/ That was the first important turn: not just “make something that works”, but make it feel like a real ProcessWire module. Claude also helped shape the first permission model. The early version was basically superuser-only, but it became clear that a real module needed ProcessWire permissions. The model became: keyhelp-view keyhelp-edit keyhelp-delete keyhelp-server So even before the heavy testing phase, the direction was already moving from “prototype” to “proper ProcessWire admin module”. When I got home, I saved the generated module, opened the module folder in Codex, and the real work began. At that point I also decided to buy a fresh Hetzner test server specifically for this module. That turned into its own small side quest: I had to create a Hetzner account, go through identity verification, take a photo of my government ID / driver license, take a selfie, submit everything, and wait for approval before I could even create the server. Only after that could I create the VPS, install KeyHelp, connect it to a real domain, create an API key and start testing the ProcessWire module against a real hosting panel. The server uptime later showed: 17h 12m That became a nice marker of the whole process. This was not just a fake UI built against assumptions. There was a real KeyHelp panel, a real API key, a real ProcessWire installation, and a real remote server used specifically to test the integration properly. The first real problem appeared immediately in ProcessWire: Cannot reach KeyHelp API: cURL: Could not resolve host: key.smnv.org That led to the first practical improvements in Codex: API URL handling; API access notes; SSL verification settings; DNS resolution override; better module configuration hints; safer debug logging. The KeyHelp panel showed API version 2.14, so the implementation was aligned with the KeyHelp REST API docs. From there, the module became a loop of implementation, browser testing, corrections and UI review. This was the main Codex phase. I had Chrome open with two real things side by side: the KeyHelp panel on the test server; the ProcessWire admin module running on my site. Codex was editing the module files locally, and I was checking the result in the browser. I asked it to click through pages, inspect forms, open tabs, check GET/POST behavior, test UI states, and compare the result with what I saw. The module was tested in Chrome and in the in-app browser across: dashboard domains domain view SSL tab PHP tab DNS tab clients databases email FTP SSL certificates cron jobs installer server page module settings A lot of the work was not glamorous. It was small things that make a module feel real: tabs did not work correctly at one point; buttons had unwanted underlines; Font Awesome icons were jumping because more than one icon set was involved; icons were replaced with Remix Icon SVGs; tables were too custom and started hiding API data; badges were too small; breadcrumbs were inconsistent; some titles and breadcrumbs were not translated; German labels were missing in places; uk-table-small, uk-margin-remove, kh-mono and other styling leftovers had to be removed; dashboard and server screens needed better information layout; module settings needed better UI/UX; slow API pages initially felt frozen, so lazy background loading was added. This is where the human + AI workflow was useful. Codex would implement a change. Then I would look at the browser and say things like: “the tabs are broken” “what happened to the design?” “why is there a big left gap?” “the icons jump” “this table is wrong” “the German version still says Refresh” “this should look like Ichiban” “remove custom table styles” “don’t use Font Awesome” “test this in Chrome” “go through all tabs yourself” Then Codex would inspect the code, patch it, test again, and refine the result. There was also a strong UI direction: the module should not look like a random SaaS dashboard. It should feel like a ProcessWire admin tool. Dense, calm, useful, and close to the Ichiban / AdminThemeUikit style. No decorative landing page, no marketing hero, no unnecessary cards inside cards. The installer became the biggest feature. The goal was: From ProcessWire Admin, choose a KeyHelp domain, choose ProcessWire stable or dev, and let the module install ProcessWire there. That meant the module needed to: resolve the domain document root; support the case where KeyHelp and ProcessWire run on different hosts; support local and SSH remote deployment; download the ProcessWire archive; unpack it; create a KeyHelp database and database user; generate a random admin URL; generate secure credentials; run the ProcessWire CLI installer; adapt Apache configuration for KeyHelp; remove installer files; store credentials securely. At first, the installer assumed the document root was visible locally. That was wrong for real deployments. The KeyHelp panel can be on one server and the ProcessWire admin module on another. So the installer had to learn the difference between local filesystem and remote SSH deployment. That was a very important correction. The module should not only work on my local setup. It should handle the realistic case where the ProcessWire admin site and the KeyHelp hosting server are separate machines. Then came another important question: After ProcessWire is installed, where are the generated credentials stored? The answer became: in a module-managed table, encrypted using the ProcessWire site salt. The domain list now shows a ProcessWire badge when an installation is known, and the domain detail page can show stored admin URL, admin login and database credentials to users with the right permission. There is also a GitHub module installer for already installed ProcessWire sites. It checks whether ProcessWire exists in the target path, downloads a GitHub repository archive, validates PHP syntax, and copies it into /site/modules. The server page also evolved during testing. At first it was too raw. Then it became a proper admin view with: server information; software versions; resource usage; services; server reboot action; links back to KeyHelp where the API does not expose something. A specific note was added because the KeyHelp REST API does not expose start/stop/restart endpoints for individual services. Server-level reboot is available through POST /server/reboot for KeyHelp 26.0+. Debugging support was added too. The module can log sanitized API requests, payloads, responses, cache hits and timings to keyhelp-debug, while redacting sensitive values like API keys, passwords, tokens and secrets. One of the important late-stage changes was performance. Some KeyHelp API calls could take many seconds. At one point Tracy showed pages taking a long time because data was being fetched directly before the admin page rendered. That is bad UX: it makes the admin feel frozen. So the module was changed so slow API-backed pages render an admin shell first, then load data in the background. The user sees that the page is alive, and the data fills in when ready. The module also gained English and German UI support. Since KeyHelp is a German hosting panel, German translation was not just a nice extra. It made sense for the module’s audience. The documentation evolved during the same process: README was rewritten in a release-ready style; German documentation was added; CHANGELOG was made first-release friendly with only an Added section; sponsorship metadata was added; version was set to 100; AGENTS.md was added so future AI agents understand how to work with the module, what not to touch, how the installer works, what API calls exist, and how to test safely. Near the end, the repository was cleaned up: the monolith was split into src/, views/ and assets/; tests were kept local and ignored; unused generated image assets were removed; README was kept version-free; the GitHub branch was recreated using an orphan commit so the public repository starts cleanly with one init commit. The final result is not only a KeyHelp API wrapper. It is a ProcessWire admin integration for a German hosting panel, with a real installer workflow for creating ProcessWire sites on KeyHelp domains. The full path looked roughly like this: I researched hosting integrations and German panels with Google Gemini on my phone. I used Claude on my phone to create the first KeyHelp module prototype. I corrected the architecture so it became a real ProcessWire module pair instead of a monolith. I created a Hetzner account and went through ID/selfie verification. I bought a fresh test server specifically for this module. I installed KeyHelp on the server. I saved the generated module locally. I opened the module folder in Codex. I connected the module to the real KeyHelp API. I tested the UI and API workflows in Chrome. I repeatedly corrected UX, tables, icons, tabs, translations and layouts. I added the ProcessWire installer. I added SSH remote deployment. I added encrypted credential storage. I added GitHub module installation for existing ProcessWire sites. I added lazy loading for slow API pages. I cleaned up README, German docs, CHANGELOG and release metadata. I published the repository as a clean orphan init commit. This is what I found interesting about the process: the AI did not replace testing or product judgment. Gemini helped with research and context. Claude helped create the first prototype. Codex helped turn it into a tested module by repeatedly editing code, running checks, using Chrome, and reacting to very specific feedback from the real UI. The quality came from the loop: build, open in browser, click, notice what feels wrong, fix, test again. The test server uptime, 17h 12m, is a funny detail, but it captures the mood of the whole thing: a fresh server bought just to make sure this module was not theoretical. Repository: https://github.com/mxmsmnv/KeyHelp

My print-on-demand webapp is very complex. It has: hundreds of fields tens of thousands of pages (let's focus on orders) listers (again, let's focus on my "Orders" lister) many filters on listers (my Orders lister has about 20 filters) When you load a ListerPro lister page, it technically does 2 requests: first request is to build the interface second request (ajax) loads the results based on the filters, etc. I noticed it became very slow over time, but I didn't look into it deeply until now. Even though I have thousands of order pages, that's actually not the issue. First, part of the issue is what type of page reference fields you are using, which I wrote a tutorial about, so make sure to view that as well. (also keep in mind TracyDebugger slows things down a lot here as well) But even with that, it's still slow on the first request. It would take 8-14 seconds to load a ListerPro page on the first request! The issue? Having too many filters (20 for example) combined with the fact my site has hundreds of fields means that generating that filters list is incredibly intensive. That filters list is powered by the InputfieldSelector field. I worked with DeepSeek and it came up with a simple solution: when rendering the field list (ie, the first dropdown in InputfieldSelector), don't show every single field as an option... instead only grab the fields that I have actually used. This keeps the InputfieldSelector field working correctly, but eliminates a bunch of fields I wouldn't have wanted to use in my filters anyway. So, we're sacrificing a little (unneeded) flexibility for extreme performance gain. Now my ListerPro page loads in less than a second! Use this hook in ready.php: if(wire('page')->process == 'ProcessPageListerPro' && !wire('config')->ajax && wire('input')->urlSegment1 !== 'config') { wire()->addHookBefore('InputfieldSelector::render', function($event) { $is = $event->object; // Don't interfere if limitFields was already explicitly configured $existing = $is->limitFields; if(!empty($existing)) return; // Parse field names from the current selector value $value = (string) $is->attr('value'); if(!strlen($value)) return; $fieldNames = []; try { $selectors = wire(new \ProcessWire\Selectors($value)); foreach($selectors as $s) { foreach($s->fields as $field) { if(strpos($field, '.') !== false) { list($field,) = explode('.', $field, 2); } $fieldNames[$field] = $field; } } } catch(\Exception $e) { return; } // Always include system fields (needed for the template row) foreach(['id','name','title','template','parent','status', 'created','modified','published','path','has_parent', 'created_users_id','modified_users_id','num_children', 'count','include','limit','sort','_custom'] as $f) { $fieldNames[$f] = $f; } if(count($fieldNames)) { $is->set('limitFields', array_values($fieldNames)); } }); }

Hi all 👋 AiWire is now Squad. Same module, same author, cleaner name — and a lot more under the hood since the last release. If you were using AiWire, this is your upgrade-and-rename notice; if you're new, here's the short version. What Squad is A provider-independent AI gateway for ProcessWire. You write your code once against a simple API ($squad->ask(...)) and switch model/provider with a single option — no provider-specific glue in your templates. What's new since AiWire 14 providers through one API — Anthropic, OpenAI, Google, xAI, OpenRouter, plus direct Chinese providers: DeepSeek, Qwen (Alibaba), Moonshot/Kimi, Zhipu/GLM, MiniMax, 01.AI/Yi, Doubao, Ernie (Baidu), Hunyuan (Tencent). Embeddings — embed() for vectors (OpenAI / Google / Qwen / Zhipu), single or batched. Images — image() (xAI Grok Imagine, OpenAI gpt-image-1). Agentic tool-use — run() runs the full tool-calling loop for you (OpenAI/Anthropic differences normalized). Encrypted key storage — keys live encrypted at rest (libsodium); a DB dump shows only ciphertext. You can also reference an env var with env:MY_KEY so nothing secret hits the database. Prompt caching, adaptive-aware model handling, and a refreshed model catalog (Opus 4.8 default, Fable 5, current GPT/Gemini/Grok). Familiar helpers kept: chat(), ask(), fallback chains, multi-key rotation, per-page file caching, save-to-field. Migrating from AiWire (order matters) Install Squad first — it auto-migrates your key table and settings (your encrypted keys are preserved). Then uninstall AiWire. ⚠️ Do it in that order. Uninstalling AiWire first drops the old key table, so you'd have to re-enter keys. Links & requirements GitHub: https://github.com/mxmsmnv/Squad (old AiWire links redirect) Requires ProcessWire 3.0.210+ and PHP 8.1+ MIT, by me — smnv.org Feedback and issues welcome. Thanks to everyone who tried AiWire — Squad is where it grows from here. 🚀

@ryan Great update! Since the blog post is about $page->meta(), I wanted to share my pull request from 2022 that adds meta support to the pages export/import module 😊: It adds support for exporting/importing $page->meta() data via core ProcessPagesExportImport Module. Tested with multiple pages and works well so far. I made changes to the PagesExportImport Module, but it might be better to implement this in the core PagesExportImport Class. That would make the feature available to the API and other modules as well. But I am not sure how to do that, because to import the meta data, the pages must be created first, so the code might only work in the module, after the pages are created. It would be a nice addition in general, and especially for PageGrid, since it uses meta data for layout and settings. Right now meta data is no being exported/imported at all. The fix should not be too complicated. Maybe you can ask your agent about this 😊

There was an issue with email delivery because the six-hour reset also reverted the sender address in the "Stammdaten" section back to the placeholder. I've fixed it, so emails are being sent correctly again.

@ryan Question: Will there at some point be a separation between AgentTools and the migrations system that powers it? It's nice that there's now a first-party approach to migrations, but it's tied directly to AgentTools. I realize I can write AgentTools migrations without using AgentTools directly, but it would be great if it worked entirely without it. Also, same idea for Jobs capability of AgentTools.

Hi Erik — thanks a lot for the detailed write-up and the clean patch notes. I’ve added this in 1.9.4. The Group field is now a text input with datalist suggestions, seeded with the built-in groups (`content`, `taxonomy`, `custom`) plus any custom groups already used by existing collections. On save, custom group names are accepted and sanitized with ProcessWire’s name sanitizer, falling back to `content` when empty. I also updated the README and changelog to document the new behavior. Release: https://github.com/mxmsmnv/Collections/releases/tag/1.9.4 And right after that, 1.9.5 was released for a small PR fix that makes the `published` system field format as a date, matching `created` and `modified`: https://github.com/mxmsmnv/Collections/releases/tag/1.9.5 Thanks again for taking the time to test this locally and explain the exact spots that needed changing — that made it very easy to fold in. @ErikMH

Yes. Composer is only needed to build the `vendor/` folder; the module does not need Composer on the server at runtime. You can run this locally: cd /path/to/site/assets/GeoIP/ composer require geoip2/geoip2 Then upload the whole `site/assets/GeoIP/` folder to the server, including: site/assets/GeoIP/vendor/autoload.php site/assets/GeoIP/GeoLite2-City.mmdb The module looks for the autoloader at: site/assets/GeoIP/vendor/autoload.php So as long as that file and the GeoLite2 database are there, it should work without Composer installed on the hosting server.

Thanks for the thoughtful reply. You are doing tremendous work.

Claude is always asking me to test things via Tracy console. This is why I added to the copy MD for agent, including the Copy All button at the bottom. It lets it understand the file/template/data structure and also to run comparisons on the data retrieved when refactoring code or adding new features. I much prefer this to giving Claude direct access to the site DB - this way I can check each query it's about to make and to choose whether I provide it with the complete results or not. Not that it is a real lock, but Tracy does have a setting to prevent all access to superusers with another role so if they don't know about Tracy then you could keep them out. Best bet would be to define this setting via $config>tracy rather than in the module settings so it's harder for them to override.

@ryan, I often see the JS error below in the browser console:

Hi everyone, I have released a new ProcessWire module: TokenForge. TokenForge is a lightweight JWT/signature toolkit for ProcessWire modules and external API integrations. It creates, signs, validates helper inputs, and caches short-lived JWTs for services that require server-side signed tokens. GitHub: https://github.com/mxmsmnv/TokenForge What it does Generates JWT tokens with HS256, RS256, and ES256. Supports Apple .p8 / EC P-256 keys for ES256. Supports RSA private keys for RS256. Supports shared secrets for HS256. Provides createJwt() and createCachedJwt() APIs for other modules. Uses ProcessWire cache for reusable short-lived provider tokens. Fingerprints cached entries by token options, so changed claims/keys do not accidentally reuse an old token. Includes a superuser-only admin UI with dashboard, quick presets, Apple service setup, JWT generator, diagnostics, cache tools, and activity log. Why I built it I needed Apple WeatherKit support in my Meteo module. Apple WeatherKit requires ES256 JWT generation with an Apple .p8 key, and I did not want that signing logic to live only inside one weather module. So TokenForge is intentionally separate: it can be used by Meteo, but also by other modules or integrations that need JWT-based authentication. Apple support TokenForge includes an Apple-focused preset for services that use signed developer/provider tokens, for example: WeatherKit REST API Apple Maps Server API / MapKit JS tokens APNs token-based authentication App Store Connect API MusicKit / DeviceCheck-style developer tokens The Apple preset helps prepare the usual ES256 structure: issuer/team ID, service identifier, key ID, .p8 private key path, headers and payload. Not only Apple The module also includes starting points for: Android/Firebase-style RS256 service account assertions Samsung-style RS256 service assertions Generic HS256 Generic RS256 Generic ES256 Quick presets include demo signing material, so the generator can be tested immediately. For real integrations, replace the demo identifiers and keys with provider values. Security notes TokenForge does not store generated JWTs, private key contents, or shared secrets in module settings. Recommended production usage is to keep private keys in a file path such as: /site/assets/private/AuthKey_XXXX.p8 and pass private_key_path to TokenForge. Basic example $tokenForge = $modules->get('TokenForge'); $jwt = $tokenForge->createCachedJwt('my_provider_token', [ 'ttl' => 3300, 'algorithm' => 'ES256', 'key_id' => $keyId, 'private_key_path' => $privateKeyPath, 'headers' => [ 'id' => $teamId . '.' . $serviceId, ], 'payload' => [ 'iss' => $teamId, 'iat' => time(), 'exp' => time() + 3600, 'sub' => $serviceId, ], ]); Requirements ProcessWire 3+ PHP 8.1+ OpenSSL extension MIT licensed. Repository: https://github.com/mxmsmnv/TokenForge

Meteo update: Apple WeatherKit provider Small update for Meteo: Apple WeatherKit support has been added. Meteo now supports these providers: Open-Meteo OpenWeatherMap WeatherAPI.com Apple WeatherKit Apple WeatherKit uses Apple REST API authentication and requires ES256 JWT tokens. For that part Meteo now uses a separate helper module, TokenForge, which handles JWT generation and caching. Meteo repository: https://github.com/mxmsmnv/Meteo TokenForge repository: https://github.com/mxmsmnv/TokenForge Apple WeatherKit requirements To use the Apple provider you need: Apple Developer account Team ID WeatherKit Services ID Key ID downloaded Apple .p8 private key TokenForge installed Recommended key location is a private, non-public path such as: /site/assets/private/AuthKey_YOURKEYID.p8 Meteo asks TokenForge to create and cache the short-lived WeatherKit JWT, then sends it as a Bearer token to Apple WeatherKit. This update is in Meteo 1.1.0.

Hi @Robin S - sorry for delay in responding, but thanks for the follow up. I haven't used that module regularly in so long. Anyway, glad you figured out an approach that works for you. Cheers.