BrendonKoz

This is awesome timing. Our hosting service only allots a set number of processes per customer, and due to bots we have been getting throttled and web requests were being delayed or outright refused due to too many requests being handled. Our overall traffic is, as reported by our host, about 55% bot requests!

I mostly wasn't sure if an adjustment to the htaccess rules if also using the setting for pagefileSecurePathPrefix might provide a workaround. EDIT: It does not appear as though there is a simple workaround here.

Searching the ProcessWire files for the phrase, "Prevent direct access to file assets owned by" led me to ProcessTemplate.module in wire/modules/Process/ProcessTemplate. From there, this is the relevant code: /** * Build the "pagefileSecure" field for the "access" tab * * @param Template $template * @return InputfieldRadios * */ protected function buildEditFormAccessFiles(Template $template) { /** @var InputfieldRadios $f */ $f = $this->wire()->modules->get('InputfieldRadios'); $f->attr('id+name', 'pagefileSecure'); $f->label = $this->_('Prevent direct access to file assets owned by pages using this template?'); $f->icon = 'download'; $f->description = $this->_('When direct access to a file in [u]/site/assets/files/[/u] is blocked, ProcessWire can manage delivery of the file, rather than Apache.') . ' ' . $this->_('This enables the file to be access controlled in the same manner as the page that owns it, while still using the original file URL.') . ' ' . $this->_('Note that it takes more overhead to deliver a file this way, so only choose the “Yes always” option if you need it.'); $f->notes = $this->_('Always test that the access control is working how you expect by attempting to access the protected file(s) in your browser.') . ' ' . $this->_('Do this for when you expect to have access (logged-in) and when you do not (logged-out).'); $f->addOption(0, $this->_('No') . ' ' . '[span.detail] ' . $this->_('(uses site-wide configuration instead)') . ' [/span]'); $f->addOption(1, $this->_('Yes when page is unpublished, in the trash, or not publicly accessible')); $f->addOption(2, $this->_('Yes always, regardless of page status or access control')); $f->val((int) $template->pagefileSecure); if(!$template->pagefileSecure) $f->collapsed = Inputfield::collapsedYes; return $f; } Considering the attribute name is pagefileSecure, I would think it'd be safe to assume that, yes, that enabled pagefileSecure for those templates within your site. I don't use pagefileSecure myself, so I don't know if there's an adjustment that could be made to the htaccess so that secure pagefiles can work as expected, while insecure can still not be rendered by ProcessWire. There might be some results of people working with that in these forums. (I'd normally look, but unless I revisit this later, my break time is up!)

Simply having a manifest file (and referring to it in the HTML) causes it. Ironically, if you don't have one, a lot of website checkers/validators complain when you don't have one, presumably due to some people creating/dragging website shortcuts to their desktop to create a shortcut and not having a predefined way to direct how it (the icon/shortcut) should be presented.

Hi @olafgleba! It looks like others have already solved this for you. I'll let you determine what solution that's provided better suits your need. 🙂

I'm glad to see that print stylesheets were not completely forgotten about, but testing may have been missed after a basic style was applied. 🙂 There are quite a few elements that simply don't need to be printed, and page margins are far too minimal for the default browser configurations of printing (there is overflow from the browser default configurations of headers and footers). At the very least, increasing the @page margin from 0.5cm would make a world of difference. Ironically, the first page's header spacing seems OK, but I haven't identified why. Thankfully it shouldn't require much fiddling to make a huge difference to the print styles! Things that could immediately be hidden in print media: #content-secondary #breadcrumbs (optionally; some may find this is useful in prints) #topnav footer #site-search-q The comment form is part of the body of the blog/news posts, but is unnecessary for printing. Comments themselves may be useful, but the style of them is a bit jarringly large. The "Post a comment" header and the related form aren't in their own section/div, so it can't be (easily) targeted as a whole. Overall body text size could probably be reduced for print (save on paper), but that's more preferential, as it also might just be easier to read at a larger size when printed - a JS text size adjustment would be the only way to allow the visitor to choose that, and I'm thinking that's unnecessary. The ProcessWire logo has what appears to be an underscore between the iconic P and the logotype/wordmark. This whole part of the API wouldn't need to be printed as its an interactive interface only. Windows 11 Pro 24H2, Firefox Developer Edition (v142.0b9)

I had set an InputfieldDatetime field's setting of "yearRange" to "0:+2" and apparently 0, for the number of years before the current year simply is defined as no limit. (This should work for similar datetime field settings that offer a range.) The formatting expectation for the jQuery-UI datetime picker component is a string value that always has a negative value, a colon separator, and a positive value, indicated by "-x:+y". The solution here is simple, but in case anyone else runs into this problem, it just takes the following form instead: yearRange="-0:+2" Simply include the negative sign in front of the zero! 🤦‍♂️

Is this a FormBuilder template using embed method D? If so, it should give you everything you need to modify it. If not, how are you accessing form fields in the frontend?

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!! 🙏