Jonathan Lahijani

I've only played around with the new admin theme and haven't committed to it yet. That was one thing I noticed as well and I feel the color difference in the original theme definitely makes it easier to visually separate nested fields.

Is it possible to put TracyDebugger in Development mode regardless of whatever settings are in the "Access permission" section? Like is there a $config setting that can force Development mode in which overrides whatever is in Access permission? I have a special case where I want it in Development mode that none of the Access permissions will be quite flexible enough for. To be specific, I want it enabled in PW CLI mode (but on my dev server), which means I can't use user/role-based or IP-based detection. I also don't want to use "Force isLocal" because that will enable it for both CLI and GUI mode. I don't want it for GUI mode in that particular case since my dev server is technically publicly accessible and could lead to TracyDebugger being used as a hacking vector.

https://x.com/adamwathan/status/1559250403547652097

I looked at DaisyUI but it relies on @apply under the hood which the creator of Tailwind said he wish he could uninvent so that didn't sit well with me.

@bernhard Within the Tailwind ecosystem, my goal was to find the "framework" that had the best JavaScript components (the typical things like accordions, tabs, etc.). I started with Tailwind UI but that was geared for headless, however behind the scenes in their demos they had a hidden Alpine.js based solution. That was hacky but I used it for a little bit. Then Alpine.js itself had their premium components and since the two pair well, I went with that for a while but it didn't feel right in the same way that UIkit does. Then I found Preline and played with that for a while, but a couple years ago it was good but not as good as Flowbite. So I stuck with Flowbite for the last 2 years. A couple months ago I re-visited Preline and they've made some incredible progress, so much so that I feel it's "ahead" of Flowbite. Then a month or two ago, the folks at Tailwind finally released non-headless / vanilla JS components officially for Tailwind UI, which I haven't experimented with yet but I'll probably switch to that if it makes sense (which I'm sure it will): https://tailwindcss.com/blog/vanilla-js-support-for-tailwind-plus Also, I've been thinking about eventually switching back to vanilla CSS at some point because of how much progress it's made in the last 15 years. I stopped writing vanilla CSS when Bootstrap 2 came out and every since then I've gone from one framework to another (Bootstrap 2 -> Foundation -> Bootstrap 3 -> Uikit2 -> Uikit3 -> Tailwind). I love UIkit but I feel it's antiquated now and not taking advantage of all the new cool features of CSS. I also came to not like being softly "jailed" in their way of doing things. Also I like the idea of not using a build-step so vanilla CSS is probably what I'll settle on when I'm ready.

I really wish I knew about this issue 2 years ago. Like... really really wish.

@ryan, can you pretty please look at this issue that has to do with a sub-selector bug that occurs when there are about 1500+ pages? https://github.com/processwire/processwire-issues/issues/2084 It would be nice to have that fixed before the next master version.

Just wanted to say this module is working really well under a lot of load. 👍

Thank you very much. This adjustment also fixes admin emails being sent when errors occur. Awesome!

Ack! You're right. I did this API integration a year ago and I forgot about the 'auth' setting in my routes file. Thanks for mentioning this.

@Sebi Is there a reason there is not a simple "API-key based authentication" auth-type, meaning to communicate with the API, you just need an API key (without having to deal with sessions or JWTs)? Would you allow a pull request to add this?

Callbacks were introduced in this update (ProcessWire 2.0.235) but I feel like this was an important update that was not spoken about. Analogous to Rails callbacks.

That worked... I replaced the try/catch block with just $app->run(); The error appeared in the console and logged to 'errors' log. I wonder if it can be refactored a bit? Ideally I'd like to run try/catch in my own rockshell command, but with the current approach rockshell's try/catch will override it, right?

Basically, I'm running a rockshell command and I get this error due to a logic bug in my own code: Call to a member function getProduction() on null However because the error isn't really specific, I'm not sure where in my codebase that's exactly occurring (like which file and which line). It doesn't log it to ProcessWire's 'errors' log. If I run the same code that's inside my rockshell command "outside" of rockshell (using php on the command line), it will also error, but details about it like this: PHP Fatal error: Uncaught Error: Call to a member function getProduction() on null in /path/to/pw/site/classes/BlahPage.php:210 Stack trace: ... Is it possible to log errors to the error log?

@bernhard Somewhere in my codebase, an exception is occurring. It's not rockshell specific, but I'm using rockshell to run a background job and at some point this exception occurs. However, the exception details are very minimal in rockshell's output (just a simple line) which doesn't give me enough information me to track it down. I would think the exception would get placed in ProcessWire's own logs, but it doesn't. Any thoughts on how I can get the exceptions to get logged to help me debug?