BrendonKoz

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.)