BrendonKoz

If you can, maybe try temporarily disabling Login Register Pro to default to the standard PW login mechanism. Use the PHP code-based password reset trick for a specific account that only you have access to, and see if you're able to successfully login. If you're able to log in, you may need to check the (WireMail) email settings on the new host, as well. If that works, try re-enabling Login Register Pro and see if that now works. If not, you might need to post in the Pro support forum for that module. (I don't use it, so I'm not sure what to suggest.)

The entire PHPVerse has been recorded, and PHPVerse 2025 is now available on YouTube. If you, like me, were interested in the two portions above, they're also broken down into their unique segments (for far less overall watching time): FrankenPHP Building MCP Servers with PHP Thanks again for sharing this, Bernhard! --- Here's the full lineup of talks (since the original page has been updated and no longer contains the agenda) and linked portions that were available: FrankenPHP: Reinventing PHP for the Modern Web by Kévin Dunglas Symfony: Current State and Future Plans by Nicolas Grekas Building MCP Servers With PHP by Marcel Pociot A PhpStorm Announcement You Won’t Want to Miss! Laravel Q&A With Its Creator by Taylor Otwell PHP Anniversary Merch giveaway The Future of PHP Education by Jeffrey Way, Povilas Korop, and Kevin Bond How AI Is Changing the Tech Industry by Cheuck Ting Ho PHP Foundation: Growing PHP for the Future by Roman Pronsky and Gina Banyard

Oh dang, that was yesterday. Did you get to participate, @bernhard? The FrankenPHP and Building MCP Servers With PHP sessions looked intriguing, and I always enjoy hearing Jeffrey Way speak.

It's a holdout from the original theme, it likely was overlooked in the new. Probably should be removed in the base theme (imho) realistically, though that's a matter of opinion. I'd imagine it would potentially be easier to style it if it were a browser-native control instead of a range slider that was created prior to browsers having native interfaces for it. This CSS might clean it up a bit. The new theme could likely use some CSS variables in place of the colors below, I simply targeted the base CSS instead. .ui-slider .ui-slider-handle { border-width:0; outline:none; border:none; width:17px; height:17px; background-color:transparent; background:currentColor 0 0 no-repeat; border-radius:21px; box-shadow: 0 2px 2px gray; } @ryan If we're using the admin.css override, and users are allowed to choose their admin theme, is there currently a way to target our overrides to the sub-themes/styles individually? I see the main theme name is appended to the body classes, but not the sub-theme name, and since we can only have one override file, currently... Is there a way to handle that scenario that I'm not seeing? I'm also wondering if there might be opportunity for others to provide sub-themes to the AdminStyleUiKit, and if so, perhaps the naming of the options should be something other than "Original" and "Default"? Default is typically a word assigned to what would be chosen for someone, not a choice to be made. (I do understand the reasoning, though.) I'd be quite happy if Konkat chose a name for their theme/style, whether it just be Konkat, 2025, some iteration therein, or anything their hearts desire! If a body class were added for subthemes, it'd be weird seeing "Original" or "Default". 😉 - - - Installed the DEV branch. The dark mode looks more like a high contrast mode to me. I'm not yet sure what suggestions I have for it, but compared to the light mode, it's quite jarring. (For what it's worth, I use dark mode by default in systems that offer it.) I'll try to think on that a bit more.

Hey there, Pip! Welcome back. 🙂 If you're only going to migrate once, developing up until it's ready to be launched, you can typically just get a backup of your SQL and move it to the production's database (along with your /site/ files and related structure). If you're going to be doing development after the website is launched, and you need to make sure that the development you do does not affect data created on the production website, you'll want to look into something like RockMigrations, or any of the other migration modules.

The send() method in WireMailSMTP is hookable, so depending on how your service's Oauth2 requirement works you might be able to create some sort of supplemental solution.

I'm of the opinion that this is highly opinionated. 😉 One might say that ARIA rules are a waste of effort because the majority of people realize it's not actually a better experience for user interfaces. It's all personal perception. From my own experience, I find that building a template from scratch with having a toggleable (or auto-determining) dark-mode and light-mode in mind is far, far easier than starting with a light mode as a main default, and then trying to tack on dark mode functionality. KONKAT's determination to go primarily monochromatic should make that quite a bit easier, but it's still not easy. And getting dark mode right so that it feels fresh and elegant to a wide population is quite difficult. That doesn't mean that dark mode doesn't have its place though, and that - to feel modern and accepted to a wider audience - it may be a feature that perspective CM(F)S users would look for, whether they use it or not. If nothing else, it's a marketable feature. We'll have to see if KONKAT will expand their CSS variables so that adjusting one color doesn't affect colors of other areas that wouldn't normally be affected. I need to install the dev branch soon so that I can provide some proper feedback and comparable override solutions. I suspect KONKAT is using the cascade with their CSS variables in a way that works, but can cause situations as you're showing above, adrian. (And these are useful things to discover!) CSS variables are great, and they make things quite a bit easier, but there are, and may, be times when you'd need to (or want to) more specifically target the cascade when overriding CSS vars. I suspect most of the issues here are related to that - just needing slightly adjusted CSS selectors, or some additional ones. One thing to note when overriding the CSS - from one of Ryan's prior posts I learned about the new light-dark() CSS method which is awesomely useful for CSS themes that take advantage of light and dark modes. If you're forcibly applying a static color regardless of mode (for branding, perhaps) like Ryan's last example for the masthead, it's less imperative, but for other areas... If you want to make sure older browsers continue working as well, you might need a fallback value, just in case (the light-dark() method came about in 2024).

If not targeting UiKit variables which will exist globally for all "modern" themes (regardless of user choice), how would you be sure to properly assign/override something like a primary color? That would only allow you to custom-target this new theme/style, unless the goal is to make those named CSS variables part of the base theme? I understand that easier-to-read names make things simpler, but as PW has used UiKit for so long, its usage is fairly well entrenched, even in the many Pro Modules (ryan's, jploch's, and bernhard's, maybe kongodongo's too but I'm not familiar with his). Forgive me if I'm mistaken, but doesn't the standard admin style (css/less file) override affect all admin themes by default? If so, is there a way to ensure we're properly targeting overrides for the intended theme/style, or applying a global override? I haven't messed with that for this very reason of uncertainty.

@Mark_invisu How's this issue coming along, have you made any progress??

If, by chance, oddities discovered during the creation of the template - (CSS et al), testing, and reports of usage - could be included in a document by the theme authors somewhere for future work (next iteration of a template?), that would be amazing. Absolutely outside the scope, but likely appreciated by others, for sure! 🙂 Some of the issues will be module-specific, but issues with core, or (more) "commonly" used modules (ex: InputfieldIcon) might be worthwhile to be noted there... Just a thought, after reading all of the feedback thus far. The unfortunate thing here is that once you offer a light/dark mode, prior colors that worked in whatever theme was used previously (in the PW backend, this would essentially be a light theme, by default) just might not work -- and they could have been set as a primary color from a prior theme customization, or even as bernhard said, the company's primary color. For my company's primary color, it is a sort of putrid green (#649a44). Even in light mode it doesn't work well, but is terribly difficult to read in dark mode (when I was developing a light/dark mode for the frontend). I had to use color mode saturation/lightness adjustments to make it appear as though I'm using the same color, while in effect they're fairly significantly different colors (but visually, to the eye, looks right-on-target). This isn't something that can be done by simply assigning a single color. Even with CSS color function adjustments (lightness, saturation, lab colors, etc.) it's a bit of a "magic number" game. BTW - related 👉 Safari: How to have the browser pick a contrasting color automatically via CSS (🤞 for other browsers to implement this too) That said, the custom CSS file override option still works just fine. Since this theme does offer customizations though, the determination would mostly be, "Where does it make sense to offer a customization right in the theme, and where should the dev take the extra effort themselves?" Primary color, I opine, would likely be a configuration option that would often need to be customized further for light/dark compatibility, and therefore makes sense to offer the option in the theme. Similarly for the logo image used in the backend. Just because we may think a certain logo image is fine as-is (ex: bernhard's logo), the client might not, but may also demand it. It's definitely something we can adjust, either with admin JS and/or CSS, but if it may be a common request or need due to the light/dark mode offering, it also seems to make sense to offer the option here (imho). Love seeing the work, excitement, and feedback thus far. I haven't had a chance to give this a whirl yet, but appreciate the massive amount of work that's gone into it, and the early testers that are enthusiastically offering their feedback!! This community is so awesome. P.S. - Is there any preferred way that we might offer any sort of assistance with the theme? Too many "cooks in the kitchen" can cause confusion, but I also know the effort was voluntary and it's easy to identify potential issues, harder to fix, and/or find the time to fix.

Yeah, I was unable to get it to work while HTMLPurifier was enabled. Having it officially supported in PW would make things easier, for sure. 👍

Do you know where your host's support was originally able to get the server and/or PHP error logs that originally showed the issue with the core ProcessWire file's exception? You mention no errors are showing up in the logs, but the logs from the ProcessWire admin/backend may not be able to store the error message if it's happening at a lower level in the stack. The browser dev tools can be helpful to some degree, but it's not the only place to look, nor is the PW admin. If you're not seeing any useful error logs in those two places, have you looked (or been able to look?) at the server logs, whether those are NGINX/Apache, or PHP (runtime) logs? It seems you may be getting different responses depending on the host you're on (you mentioned both a 501 and 504 timeout errors), so having any sort of definitive logs to look at, if they exist somewhere, would be awesome.

Yup. From https://processwire.com/store/pro-dev-tools/api-explorer/ Could check and see what methods are hookable to potentially generate markdown instead of HTML. Current licensing seems to indicate that using it is solely for the purpose of the license holder though, so generating Markdown from it would be usable by the developer, but not shareable. Until or unless Ryan can consider if he would also not mind generating Markdown with the official docs, it may be a more practical option for those looking to do it now.

Interestingly, since I think something in my example should work, I noticed that in my Setup > Templates admin page, my field-image template is reporting that it contains zero pages. I'm not sure if that should be the case since I do use images that have custom fields assigned. Maybe that's why I'm not getting any matches? I'm unsure. I would think Robin's module does something similar to the built-in core functionality, but if that works for you, I'm glad to hear it!

Heading out for the weekend, but I found your question interesting and, I'd imagine, potentially solvable - but I didn't find anything quickly. I was experimenting with the following, as a start (where "field-image" is the custom field template assigned to my image field, and "summary" is the field within that template I am searching within): $test = $pages->find('template=field-image,image.summary%=the'); As an alternative option, would you be able to adjust your solution to use (far shorter) tags for the linking/association aspect of your problem?

@Mark_invisu - due to your report, I created an issue report in ProcessWire's Issues github repository for Ryan to see. He's made core changes to related files in an effort to rectify that, but since he's not experiencing the error, was looking to see if the changes he's made alleviates the fatal error you are seeing (with relation to the Exceptions). If you're able to test this and report back, that would be awesome. Thanks!!

Ohh. Sorry; you said that first but I didn't quite catch it. Thank you for reiterating!! 🙏

I'd normally agree with the concern of losing the error code, but from what I could tell, I think the alphanumeric error code as reported by the database itself is retained in the errorMessage property anyway - at least for PDOException objects. I don't like to make assumptions though, which is why I figure Ryan would be the best person to determine how he might want to handle that in the end. 🙂 Nice! Yes, I like that solution (to get further in the error discovery) better than mine. 👍

Interestingly, this seems to be a known issue for developers that extend PHP's base Exception class and potentially use and/or end up extending the PDOException class when dealing with database-related exceptions. This is likely to be the case here, and is a known oddity within PHP, and requires some sort of workaround. @ryan may want to take a look at the core Exception classes to determine how to handle the expected int value being returned as an alphanumeric (string) value. That said, you should be safe to temporarily adjust the core file's code to forcibly typecast the return value to an integer in order to get past the above PHP error - which is only being shown because there's another error elsewhere that might give us more information towards solving your other problem. (FieldtypeMulti.php line 254) throw new WireDatabaseQueryException($e->getMessage(), (int) $e->getCode(), $e); If after adjusting the line above you still get an error with Exception code values not being an integer, you could adjust wire/core/Exceptions.php at line 40 $this->code = (int) $code; That would catch any class extended from WireException and make sure the property has a proper integer value assigned. NOTE: As your support's colleague mentions, modifying the core code is not recommended. For scenarios like this you can always change it temporarily so you can continue your debugging. Change it back once you're done so that you remain on-par with the official branch of the software.

Ah, sorry to mix the two things together. The download issue was backstory on why I was looking in the console and happened to see the error found within the session cookie string. The actual question related to Tracy was how I might be able to expose that error message (from the session cookie) in a log, if at all. I was thinking it was remnant files/folders from prior module versions that were upgraded, but if they're intended to be there, then I have no need or desire to remove them. Thanks for the quick clarification there!

I just noticed today, while trying to inspect headers (sent from our host server to see why a "download" attribute on a file link wasn't renaming a file), that there was a TracyDebugger message embedded within the session string (when logged in as an admin), but after enabling all available error logging in the module (and making sure I was using the latest version), I'm still not seeing any log of the error (I'm hopeful a textual log would provide more detail). I can see it's line 14, but since Tracy has better insight into my file structure, I wasn't sure which file... I don't get this error message on my development server. P.S. - Is it safe to delete tracy-2.x folders in the module folder, and if so, which ones?

Because ProcessWire is so configurable, content can come from many different places, such as: The page tree Language translation files Site template files 3rd party services / APIs / Webpages An external database/application This is entirely dependent upon how that section of the website was built, and since all we can see here is a photo representation, we can only guide you through an overview of your options. This isn't a situation unique to ProcessWire - other CMSs, such as WordPress, would also suffer similar issues, depending on how plugins were used, and how the plugin authors implemented their modules. As for your specific question: "Is it possible that I am not seeing the whole tree?" That depends on your account's access level. It also depends on whether there are sections hidden within the Admin node in the tree. Is there any additional information that you can provide in relation to this page, and the "following text" that you wish to edit?

I (very thankfully) haven't experienced this issue. I've not attempted running PW on Digital Ocean as of yet though. Out of curiosity, are you using droplets and if so are they of the same type on the hosts you've experienced this with? Curious (and concerned) if you've yet discovered a culprit and/or resolution.

Yeah, I've tried both scenarios (one without the file extension, and one with). I've tried multiple browsers, incognito/private windows. I haven't tried a different PC altogether (which I now will). It's such a simple thing, for it to not work is kind of weird. I checked my htaccess files and all uses of header() just in case, too. I'll try to see if I can capture the headers sent by my webhost, if they're any different.

Has anyone had this not work for them? This works fine on my development machine, but not once it's on the production server...