BrendonKoz

Hi @Morphosis - glad you found a solution! Based on the module documentation on Github, you can also define this in your site/config.php using an array-based syntax. Choose whichever method you would prefer! Example: /** * Module: SearchEngine * * Override any module settings or other config values here. Anything set here * cannot be overridden. * */ $config->SearchEngine = [ // Render arguments affect the rendered output from the SearchEngine module. 'render_args' => [ // Various attributes used by the search form and results list when rendered. 'form_action' => '/search/', ] ];

I think @Pete may have run updates on the forum software. If that is the case, it may be related.

Could the idle timeout be caused by FastCGI waiting for an available PHP process due to too many active requests? Our site has been having outages within the last couple months, seemingly due to an increase in requests/visits by bots (crawlers for AI-specific data harvesters). Although I believe the server should be able to handle these requests perfectly fine, our host has said that seems to be our issue. I only bring it up since you seem to have mentioned it started somewhat recently (coincides similarly to our timeframe). If that is the case, the solution(s) would be upgrading to a beefier server, implementing caching solutions, attempting to block bots (ex: robots.txt, htaccess rules, etc.) and/or using Ryan's new [updated] Pro module (Request Blocker + Throttler), and examining all PW find requests to see if the raw versions of those API requests might be faster/more efficient...but yeah, caching mostly. Hopefully your host can give you some more insight. Our server log errors are a little different (webhost: Dreamhost): [Tue Sep 16 05:29:37 2025] [example.com] [warn] [client xxx.xxx.xxx.xxx] [pid 13103] fcgid_bridge.c(481): mod_fcgid: can't apply process slot for /dh/cgi-system/php82.cgi Once FastCGI hits a limit, it affects all rendering of the entirety of the website since it's linked to the webserver itself. Since removing some AJAX loading calls (that rendered PHP and made database calls) that were loaded on every page, a CSP report functionality, and adding Ryan's Request Blocker + Throttler, our site's total traffic (requests) has reduced 21% (from an average of 120k+ hits/mo), and stability has been better. I cannot say this is the same issue, I simply see comparisons, and since not much else has changed with your site, and PW is fairly stable overall through updates, I don't know what else it might be right now.

Hi @Jan S.! Welcome to the forum, and congratulations on your first post! We're glad to have you. 😊 Based on what you're showing, your code looks good from what I can see of the TextBlocks documentation, so I am not entirely sure what to suggest, other than maybe seeing if removing the "echo" from your template call to the field will still render the field. I don't think it should, but since it's being duplicated, it can't hurt to try. Beyond that, TextBlocks is a paid ProDevTools module, so support for that module is in its own forum, locked down for paid/active module owners. Assuming your module support status is up-to-date, that can be found in the ProFields Support subforum here.

When I load up your site, although I'm seeing JavaScript errors, I'm not currently seeing any 500 errors in the browser console for loading up any assets. Have you identified and fixed all of the issues, or are the problem(s) you're experiencing not 100% repeatable? Database errors sound like a resource issue. If the 500 errors are related to a database issue, are there particular pages that show the errors more often than others? Do those pages have a lot of requests to pull in data for display of content? Can things be cached to alleviate database resources and PHP processing? Have queries made through the ProcessWire API been reviewed for efficiency? Since I'm not seeing the errors myself (or any errors that point to specific files), I'm only speculating. It's hard to know what to suggest. Do you have any further specifics? Any non-core modules installed? Any hooks being run?

Did your upgrade of PHP perhaps change from CGI to FastCGI, or even FPM? There might be a resource utilization difference there, as I don't believe the upgrade of ProcessWire would cause SQL error states like that. I'm not sure if ProcessWire is fully PHP v8.4 compliant yet. You should be pretty safe with PHP 8.2, and maybe PHP 8.3. The errors should be, if I'm not mistaken, warnings, however, not actual errors.

Anthropic seems to be a little extra greedy! It seems as though the throttler appears to be working! We've still had some outages of our website as reported by UptimeMonitor, but since making a few changes and adding this module, it's only happened once; we were experiencing it multiple times per day, a few days per week. It can't all be attributed to this module, but I'm certain it's helped! It would be nice eye-candy if there were a small animation to "compress" (or scroll up) the grouping of active throttles for their removal from the list. It's quite jarring when the updates occur in rapid succession and the prior entries simply disappear and get replaced. I thought the time-to-display was coordinated with the time-to-block, but I just recently witnessed (via Firefox) a fairly rapid succession of updates, and each update caused the prior list/time-report to disappear. The below animation, although it repeats, is in realtime. The one I witnessed was a little faster. (Maybe a memory leak? I've had this open for about about 4 hours now.)

The largest problem with the JSON-type WYSIWYG implementation of editors is that they all have their own custom implementations and conventions of how they represent the DOM via JSON. Quill was one of the first (that I was aware of) to have a complete and somewhat sane implementation therein. That said, since that seems to be the way editors are moving in general, I think it makes sense to go in that direction as well, but choosing should be made with care, determining as many pros and cons of features and technical decisions for the choice as possible. The topic that covers editor.js is: https://processwire.com/talk/topic/24876-pw-30170-– core-updates/ There was another one (I believe the next update by Ryan in News & Announcements) that partially continued the discussion, but most of it, if I'm remembering correctly, was here. Statamic's Bard uses TipTap, and prior to that used ProseMirror (TipTap uses ProseMirror under-the-hood which is likely why they were able to easily switch to TipTap; the same underlying JSON representation). EDIT: I think @jploch's module, PAGEGRID, originated out of that discussion. 🙂

I think experimenting with a block-style editor would be great. In the very large discussion over WYSIWYG editors (I don't recall of this was a 2025 wishlist, or a discussion of the future of TinyMCE/CKEditor, but it had a LOT of paginated responses), a few people even experimented in creating a proof-of-concept with editor.js, showing their results. I gave it a shot but determined the end result (interface) was too cumbersome for most of my users (and I usually try to aim for a very low bar as a standard; less complaints / support needed). Even in the demo (tried today) I was able to cause a rendering bug in both of the editors mentioned (TipTap, Editor.js) above. That said, if a true module is attempted to be released, since they render and use JSON as the underlying structure, I would recommend using a similar database structure to TinyMCE and/or CKEditor, and save the HTML-rendered output in a field just in case someone wished to switch back to a standard text editor for a particular field. (Unfortunately that means only one-way compatibility, however - and increased storage costs/size...so maybe an option for that in the module.)

The module is installed and running. Will report back on statistical findings after letting it run for about a week. The upgrade folder replacement went fine and did take up the settings from the database, so I didn't have to merge anything. The version info from the prior version is still reporting as the most up-to-date in ProcessWire Upgrade though (so searching for new versions won't show this version as available). Since I didn't get the column header in the cropped photo below, the 0.0.4 is currently installed, 0.0.2 is latest version (as reported).

As the module name has changed, is there any recommended way to upgrade from the prior module? The ProcessWireUpgrade module doesn't seem to notice there's an update to the WireRequestBlocker, but I'm thinking they'd share the same folder name on the physical server, but if they have a different database record, any custom settings may not transfer?

I hope to give it a try tomorrow, but if I can't get to it, the first chance I'll have is next week. That said, I will definitely let you know! From a cursory search with recent logs, the following bots were problematic: Bingbot (Microsoft, USA) Bytespyder (ByteDance, so TikTok, China) MJ12bot (Majestic, SEO Tool, UK) AhrefsBot (Ahrefs, SEO Tool, USA) PetalBot (Petal Search Engine; China) CensysInspect (Internet Vulnerability Scanner, USA -- I think this is being abused and used as an attempted attack vector on our site, but they say it abides by crawl delay) I honestly did not realize there was/is a crawl speed directive for robots.txt (that some bots follow). I would've implemented that a long time ago. I do intend to implement ProCache at some point as well but this will be a very nice intermediary.

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.