All Activity

@ryan Thanks Ryan for the broader picture. Unfortunately, I do not have time to dig in further, but my issue is definitely solved, so thanks once more!

@szabesz My best guess is that there must be some other module that is loading AsmSelect, and doing so on every page load. That would explain the error. I've upgraded a few installations and haven't seen this error, but if it starts appearing for more people then we'd have to identify what's in common among those installs. It's possibly a load order issue, which might be solved by asmSelect moving its getModuleInfo() array to a separate InputfieldAsmSelect.module.info file. ProcessWire should already do a modules refresh on every version update, but it looks like this error popped up before it could do the refresh.

One more thing I forgot to add, is that for the first time "failed" upgrade, even the frontend of the site did not load (500 internal server...) and I guess an admin module should not load on the frontend, should it?

Thanks again! I think I tried to access other admin pages as well, but the issue persisted. But yeah, if the module does not need to be loaded, then sure I should be able to access the admin's module refresh page, too. Anyway, I have just tried the upgrade one more time and after the successful update page in the admin I tried to access the module refresh page (/module/?reset=1) by using the admin menu, and I got the error again, however, simply refreshing the page made the error go away and I was notified: "SystemUpdater: Detected core version change 3.0.266 → 3.0.267" Could there be a way during the upgrade process when using the Upgrades module to automatically have the modules refresh, so that issues like this can be prevented in the firs place, perhaps? Thanks for all the other troubleshooting tips too, I'll save them for later.

@szabesz As far as I know, there isn't any reason why a moved InputfieldSelectMultiple should cause an error on any URLs that don't actually use that module. So if you can go to a URL like the login page or modules page or anything other than a page editor page that's using SelectMultiple or AsmSelect, that should work. But If you are still getting an error, even if a page isn't using that module, then there may be some other issue at play. You can try to refresh the modules manually from the terminal by typing "php index.php modules refresh" in your web root. Another option is to temporarily copy the wire/modules/Inputfield/InputfieldSelect/InputfieldSelectMultiple.module file into wire/modules/Inputfield/ (its previous location), then do a Modules > Refresh. It will tell you that it found two copies of the same module, click the link it gives you to choose which one you want. Select the one in wire/modules/Inputfield/InputfieldSelect/, and save.

Thanks Ryan for the swift reply! The issue is that it was a 500 error, so I could no longer access the admin (I reverted to the last site backup). Is there a way to do a module refresh in any other way? This is the very first time a ProcessWire upgrade has ever brought down a site for me, so I am clueless.

@szabesz The location of the module changed in this version, so you may need to do a Modules > Refresh for it to see the new location.

@ryan Upgrading from 3.0.266 to 3.0.267 resulted in `Class "ProcessWire\InputfieldSelectMultiple" not found`, see the screenshot:

I'd like to showcase the demo shop for my ProcessWire shop system. The demo lets you explore both the frontend and the administration backend. Feel free to log in, place test orders, and try out the available features. The shop automatically resets to its default state every six hours, so you can't accidentally break anything. If you'd like to receive the email notifications using your real email address, please make sure to delete your order immediately after testing, as your email address will be visible in the backend. Because this shop system is primarily developed for the German market, the demo shop and the documentation are currently available in German only. The "Stammdaten" section and the payment methods cannot be edited in the demo to prevent misuse. Demo: https://demoshop.mholte.de/ I'd be happy to hear your feedback, suggestions, and bug reports.

Thanks for your patience. It took me a while to set up a safe demo shop, but it's finally ready. Feel free to log in and place test orders. If you'd like to receive the email notifications using your real email address, please make sure to delete your order immediately after testing, as your email address will be visible in the backend. The demo shop is reset to its default state every six hours. The "Stammdaten" section and the payment methods cannot be edited in the demo to prevent misuse. Please take a look at: https://demoshop.mholte.de/ I'm looking forward to hearing your thoughts and receiving your bug reports.

Hi, We have upgraded two sites recently to PW 3.0.265dev, 3.0.267dev respectively. Both were updated from version 3.0.240. With both we now have an error output in the backend: Error upgrading module (PagesVersions): SQLSTATE[42S02]: Base table or view not found: 1146 Table 'xxx.version_pages' doesn't exist They run on the same shared LAMP stack - where we host dozens of sites without a problem so far. Both sites seem fully functional - as far as we can tell this far. Are we the only ones with this issue? How to preceed?

@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:

Is this the desk setup and keyboard thread? I love seeing people's desk setups. I just cleaned up my desk, so here's mine. Computer is a Macbook Air M5 mounted on a shelf under the desk, running from single thunderbolt cable. Monitors are 27" 4k Dell S2725QC (the cheapest 4k USB-C screens you can buy, but I like them). Keyboard is a Kisnt k85. An ebay thunderbolt 4 hub mounted under the desk feeds the screens and an external drive. A cable management basket under the desk keeps all the cables tidy. Monitors are mounted with arms attached to the rear of the desk. ProcessWire coffee and water bottle are my daily drivers, thanks to @Jonathan Lahijani

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.

This week we've ProcessWire 3.0.267 on the dev branch, here are some highlights (commits): The entire WireTests module has been moved into the core. All of the tests now live alongside the classes that they test. The WireTests module is used from the command line. Once installed, you can type "php index.php test" for a list of WireTest commands. If you already have the non-core WireTests module installed, I recommend uninstalling it and installing the core version. More than a dozen new WireTests and API.md documentation files have been added this week (this is where the biggest additions of the week are). Many improvements to the CLI "docs" command, especially with regard to chapter retrieval. New faster $modules->refresh() method from @matjazp New HOWTO-API.md documentation that outlines how to write API.md files for your own modules. New getFresh() and getRaw() methods added to $fields and $templates. These do the same as their $pages method equivalents (getFresh and getRaw), except for fields and templates. This was requested by an agent in AgentTools. This week we also have a new guest blog post! Page's best kept secret: the meta() method Thanks for reading and have a great weekend!

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.

Hey @jploch Thanks for jumping in and providing your design thinking. All solid reasons.

This is exactly why I tweaked mine to look like this with the top/bottom border (box-shadow) on hover. You get the definition you need with a nicer grey (IMO). with: .PageList .PageListItem:hover { box-shadow: inset 0 0.5px 0 0 #ccc, inset 0 -0.5px 0 0 #ccc; border-radius: 0 !important; }

@Peter Knight The darker color is intentional, there are two reasons why we (Diogo and me) decided for the darker grey: Contrast: Bringing more focus to the white areas even on screens that have bad contrast/color settings. This is especially helpful when input fields are offset from one another; it makes it easier to distinguish between the fields. It also helps to seperate the navigation and content area. The white hover on the page tree is also benefiting from the darker grey. Also like @BrendonKoz says it helps to seperate the inputs from the background. While the borders already enforce this contrast, I feel like the combination of border and background is what makes it stand out more. When putting screenshots from the admin on the PW website we want them to have a different background color so the image stands out better. This is why we choose a lighter background color for the website. While the image usually has a border, the background still improves the contrast, so the two don’t blend together as much. All in all, a lighter color would work too, and I certainly understand that some people might find the grey a bit too “grey.” However, I think the darker grey is a more functional default.