BrendonKoz

Hey @rooofl, I saw your request for help. I unfortunately don't do client work, but would still like to offer at least one additional chance for fixing this issue. It doesn't seem like this client is a Dreamhost customer, but it's entirely possible that the host may have similar configurations for security on their server. You may want to reach out to, or have the client reach out to, the webhost support team and ask if the URL as provided in the network devtools that you screenshotted would cause their server security to prevent the request. For Dreamhost, the solution was simply to change the custom URL for the administrative panel from whatever custom option (ex: "admin" in your screenshot's case) back to the default of "processwire". This is due to their custom mod_security rules. They can update their rules for one-off requests, but the next time they update the server software it'll break again. Here's where I mention it: It's worth a shot to, at least, try changing the admin panel URL from "admin" to "processwire" and then testing an upload to see if it fixes things. Otherwise a support ticket to the webhost would be my next suggestion.

The website, permacultura-cattolica.it, appears to be working as expected right now. It's possible your computer browser's cache is remembering things incorrectly...? Can you try from a different computer (phone?) or browser just to verify? Either that, or you've fixed it, based on @virtualgadjo's suggestions (which sound correct to me).

For modules that are not premium/pro modules, I'd love to see if their inclusion in core would be of benefit to the greater community. Many of, for instance, Robin S.'s modules aim to make the interface experience better for the end-user. Even if the code may not be 100% compliant to what the core expects, the very idea of the module may prove useful in improving the total user experience without the need to discover it elsewhere. Some extremely popular modules (ex: Tracy Debugger) may not be directly suited to being added to the core, so thought should be taken over its usefulness to all, not just specific circumstances or groups of people. Alternatively, is there a preferred way to request addition to core via the Feature Requests Github repository?

I found it hard to answer your question because I've always started with a blank profile. It gives the most freedom without any constraints, to build a custom site as needed for the project right from the start. No more, no less. I'm not sure which framework might work best with PageGrid, that would likely be a question for the PageGrid-specific forum. The last few sites I've built, I have taken advantage of Bootstrap with the assumption that if anyone were to need to maintain or edit after me, using something that is more ubiquitous would be useful. Beyond that reasoning, we can choose what we would like. Tailwind might be a better (or prettier?) option now, depending on certain factors. If it's a lightweight enough website in terms of elements/components to be used, vanilla CSS without a framework would be awesome.

Not sure if it was body text, or quote, or code, so trying all three. Sync report == StripePaymentLinks: Sync (TEST RUN) == Mode: DRY RUN (no writes) Update existing: yes Create missing users: yes From: 2025-10-08 To: - 2025-10-08 13:53 cs_test_a12s... [LINKED] XXXXXXXXXXX => action: UPDATE purchase #1961 2025-10-08 13:02 cs_test_a1DI... [LINKED] XXXXXXXXXXX => action: UPDATE purchase #1964 2025-10-08 09:19 cs_test_a1U9... [LINKED] XXXXXXXXXXX => action: UPDATE purchase #1965 2025-10-08 09:10 cs_test_a1iB... [LINKED] XXXXXXXXXXX => action: UPDATE purchase #1966 Sync report == StripePaymentLinks: Sync (TEST RUN) == Mode: DRY RUN (no writes) Update existing: yes Create missing users: yes From: 2025-10-08 To: - 2025-10-08 13:53 cs_test_a12s... [LINKED] XXXXXXXXXXX => action: UPDATE purchase #1961 2025-10-08 13:02 cs_test_a1DI... [LINKED] XXXXXXXXXXX => action: UPDATE purchase #1964 2025-10-08 09:19 cs_test_a1U9... [LINKED] XXXXXXXXXXX => action: UPDATE purchase #1965 2025-10-08 09:10 cs_test_a1iB... [LINKED] XXXXXXXXXXX => action: UPDATE purchase #1966 I did not get blocked. I'm wondering if it's forum category/subforum specific?

Sorry, you've said you could, and couldn't a few times, I wasn't sure what was currently accessible anymore. Are you able to develop this website locally, off of the live production server, in an environment that you control? Due to the restoration process from your host seemingly not working as expected, it would be nice to get the filesystem to a properly restored and working point, and developing locally might be the simplest option.

I would recommend deleting the errors.txt file (if/when you have access to the PW admin, it's under Logs -> Burn [while viewing that log; expand "Helpers" at the top, and then "Actions"]), or if not deleting, pruning it. I suspect that log has lived since the website has been running. It's unlikely you care about errors from 2 months ago or more - just the recent issues. I leave that decision up to you, but having an error log that large is unlikely to be useful (at least for me). I think it would be good to fix the errors that are popping up first. Your upgrade of the /wire/ directory is the first step; making sure the modules you have installed and enabled are up-to-date is another (and maybe you have some that aren't fully compatible?). Then making sure each template no longer has any problems (since we're working on a newer version of the core, it's unlikely but entirely possible). If you don't yet want to invest in additional development time to implement ProCache, you could try the built-in template cache as a quick test to see how your website would behave with that enabled. This would be good for pages (URLs) where the content doesn't change often. The cache is rebuilt after a set period of time, or when changes are made to the page, or its template. To enable template caching, go to the template you might want to try this on, head to the "Cache" tab, then enable it and choose the settings you think would best suit your site's template.

Off the top of my head, if you require all pages to utilize the unique status, ProcessWire can take care of this for you. You don't ever need to know the path, only the $page->name property, when creating links to pages. That will retain what your client seemingly wants. It may cause issues elsewhere though, if you actually need depth (potentially with URL hooks), or certain modules. I base my response from this short topic:

I've been considering accessibility constraints quite a bit lately, and in doing a little research, I haven't found any PHP-based PDF generation library supports the PDF/UA standard. With countries outside the US having more stringent accessibility and privacy standards, can PDFs generated through mPDF be considered accessible (with a little work on behalf of the developer)? I'm currently using mPDF in a smaller capacity, but RockPDF definitely offers some compelling features! RELATED: Unfortunately it seems that form fields are definitely not compatible from mPDF-generated PDFs due to the v1.4 PDF standard being used. I work in an industry that doesn't want to use the web, and desperately intends to keep digital documents, so I was looking to see if FormBuilder could be used to export as PDF, but that appears to not be the case (when accessibility is concerned). As most (open-source) PDF generation libraries have borrowed or forked code from one another, I doubt any would offer accessible/compatible forms.

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.