Leaderboard

@Mark_invisu Hey, sorry to hear you're having trouble. I just uploaded a 30mb file to a ProcessWire install (latest version) and it worked as expected. I think that your host may be a factor in this issue since you did have issues with all of your sites at the same time. Hosting companies can make trouble for anyone on any CMS unfortunately. Here are a few things you can try taking a look at. POST upload size. You did mention setting up .ini to accept larger files, but it would be worth checking off your list if you can confirm that the post_max_size parameter is slightly larger than upload_max_filesize. So for accepting 64mb files, upload_max_filesize=64M and post_max_size=65M. I've missed this detail before. HTTP response code. In your browser developer tools, switch over to the "Network" tab and then attempt to upload a file, then look at the return HTTP response code. Anything other than 200 indicates a problem. Hosting server security. Hosting companies can be overzealous with their security settings. A specific example is ModSecurity which can cause web applications to choke either due to overly strict settings or false positives. Depending on whether the hosting company is using it and how it's configured, your HTTP response may help indicate an issue. A hosting company I've used updated their rules and suddenly some requests from ProcessWire failed with a HTTP 418 response on all sites I had on their server at the same time. Cute, but frustrating. If you see anything like that it could be a good indicator that this may be an issue. It's not a sure thing since security rules can be configured to return any HTTP code. Server logs. If you can access them, check out log files outside of ProcessWire, specifically access_log and error_log. The error_log file may be useful since that is where you'll likely find log entries for server security hits. If you see something similar to this: [Wed Apr 16 19:02:07.918136 2025] [authz_core:error] [pid 3599862:tid 128359658948288] [client X.X.X.X:XXXX] AH01630: client denied by server configuration: /some/path/on/your/server/here then you're seeing something block the action you're trying to take when uploading. ModSecurity also logs to access_log and error_log if I remember correctly. PHP logs. If you can access the logs for PHP itself it might be helpful. Entries in a log like php8.3-fpm.log usually contain errors/exceptions that the application/ProcessWire generally see and log themselves, but checking is a good idea to be thorough. Digging into information outside of ProcessWire will probably be the most helpful. ProcessWire logs errors and exceptions pretty consistently so the fact that you aren't seeing any log entries generated in the PW admin makes me think that this is something failing outside of PHP execution and the result isn't visible to PHP itself. That may or may not be true, but looking at the items above would be the first places I start. If you're coming up short after doing more research, you may need to hop on a chat with the hosting support team so they can take a look at anything that you may not have access to or control over.

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.

Just a heads up for anyone using DigitalOcean and sending out emails using SMTP with port 587, DigitalOcean just recently started blocking this port on "new" droplets. I put "new" in quotes because that's not true: I have a droplet from months ago, before their supposed announced change, and it still got blocked. I didn't realize this until one of my clients brought it up. Good job DO! /s I use WireMailSmtp and power it with Mailgun's SMTP credentials with port 587. I've been doing it this way for a long time, although using Mailgun's direct API approach (of which WireMailgun uses) is more preferred and would avoid this issue. I will start taking that approach soon with new and existing sites. Using SMTP is convenient however. Anyway, I'm not the only one that's complaining: https://www.digitalocean.com/community/questions/smtp-587-ports-is-closed An easy fix, for now at least, is to use port 2525 which is not blocked and which Mailgun also supports: https://www.mailgun.com/blog/email/which-smtp-port-understanding-ports-25-465-587/

I'm pretty sure you're right about that. That's a good catch of my try (I'll show myself out) 🚪🏃‍♂️ Embrace the fatal error, and if the situation demands it- ask for another 😆

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

With the help of this thread and this StackOverflow response, I think this is working for me with TinyMCE so far: In site/ready.php: $wire->addHookAfter('MarkupHTMLPurifier::initConfig', function(HookEvent $event) { $config = $event->arguments(0); $def = $event->arguments(1); $config->set('HTML.SafeIframe', true); // Allow YouTube and Vimeo $config->set('URI.SafeIframeRegexp', '%^(https?:)?//(www\.youtube(?:-nocookie)?\.com/embed/|player\.vimeo\.com/video/)%'); }); Then, in the PW admin for the textarea field > Input tab > Custom Settings JSON: { "extended_valid_elements": "video,source,iframe[src|width|height|title|frameborder|allow|referrerpolicy|allowfullscreen]" } Note the list of attributes in square brackets after the "iframe". You can use wildcard `[*]` if you want to allow any attribute, though I haven't experimented with that. Finally, clear the HTMLPurifier cache from Tracy Console as described in that GitHub conversation: $purifier = new MarkupHTMLPurifier(); $purifier->clearCache(); This is very fresh, I'm still testing it out, but it seems to work. Might still need to add that bit from SO for the `allowfullscreen`: $def->addAttribute('iframe', 'allowfullscreen', 'Bool');

That's very interesting @BrendonKoz and good to know for everyone who stumbles upon this issue. I've been writing software for many years and haven't run into this, but I've never caught/rethrown database level exceptions for a few reasons, now this one as well. The main concern I have about casting the error code to an int will erase the code entirely since it has alphabetical characters, and that information may be important to debugging. Example: <?php // An unreasonably friendly error $error = 'hello1234'; echo (int) $error; // <= outputs 'int(0)' @Mark_invisu To get a true fix for your sites, it would be a good idea to get a better look at what is happening deeper in your setup. If you modify the core code to handle strings by casting to ints, you'll have modified the core code to bypass an issue that is not relevant to your problem. Take a look at L253 in /wire/core/FieldtypeMulti.php <?php try { // since we don't manage IDs of existing values for multi fields, we delete the existing data and insert all of it again $query = $database->prepare("DELETE FROM `$table` WHERE pages_id=:page_id"); // QA $query->bindValue(":page_id", $page_id, \PDO::PARAM_INT); $query->execute(); } catch(\Exception $e) { if($useTransaction) $database->rollBack(); if($config->allowExceptions) throw $e; // throw original (L253 HERE) throw new WireDatabaseQueryException($e->getMessage(), $e->getCode(), $e); } What you really want to be troubleshooting is the database issue that is causing the exception to be thrown in the first place. The original exception will contain the information and further details you need. My recommendation is to tell ProcessWire to throw the original Exception from PHP rather that catch/throw a WireException derived object. You're still going to get an exception, but it will contain all of the error details you need and doesn't require modifying the core. <?php // ... rest of /site/config.php $config->allowExceptions = true; I think this is the best way to fix your issue now, and then if/when the issue with the WireDatabaseQueryException is handled in the core, you can upgrade in the future where a patch may be implemented. The good news is that exposing the base exception should give you all of the information you need without possibly needing to dig through additional logs. It is worth noting that the logs will likely be inaccurate because they'll be logging the ProcessWire variable type exception and not the database exception. If you can share the stack trace that you should see when enabling exceptions it would be of interest to others that may be seeing this issue. I'm also personally curious even though I haven't run into this myself.

The error message in the session cookie will be displayed in the console results pane on page reload - it's not logged because it will only ever be populated from code that is run in the console panel.

Hi All, If there are any Canadians out there looking for full time work please DM me with some details of your PW experience. Experience with systems engineering and security implementation a big advantage. Cheers, Adrian

Thank you for your comprehensive response, Ajusting. the php.ini file had no affect. the network tab in developer tools returned on 200 errors. The log files you mentioned don't seem to be present so i've requested access to those, some other things i didn't mention in my original post are: I've tried this on another host and get the same problem. I can upload smaler files it's only he bigger ones it's having trouble with Here is the response from the host for my recent query: I've had a look at the error log that my colleague has referenced and below is the error that appears 2025-04-15 15:39:11 oracle https://demo.invisu.uk/control/page/edit/ Fatal Error: Uncaught TypeError: Exception::__construct(): Argument #2 ($code) must be of type int, string given in /data04/insiteportal/public_html/wire/core/FieldtypeMulti.php:254 Stack trace: #0 /data04/insiteportal/public_html/wire/core/FieldtypeMulti.php(254): Exception->__construct('SQLSTATE[HY000]...', 'HY000', Object(PDOException)) #1 /data04/insiteportal/public_html/wire/core/Wire.php(419): ProcessWire\FieldtypeMulti->___savePageField(Object(ProcessWire\RepeaterPage), Object(ProcessWire\Field)) #2 /data04/insiteportal/public_html/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___savePageFiel...', Array) #3 /data04/insiteportal/public_html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\FieldtypeFile), 'savePageField', Array) #4 /data04/insiteportal/public_html/wire/core/PagesEditor.php(918): ProcessWire\Wire->__call('savePageField', Array) #5 /data04/insiteportal/public_html/wire/core/Pages.php(868): ProcessWire\PagesEditor->saveField(Object(ProcessWire\RepeaterPage), Object(ProcessWire\Field), Array) #6 /data04/insiteportal/public_html/wire/core/Wire.php(422): ProcessWire\Pages->___saveField(Object(ProcessWire\RepeaterPage), 'installation_qu...', Array) #7 /data04/insiteportal/public_html/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___saveField', Array) #8 /data04/insiteportal/public_html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Pages), 'saveField', Array) #9 /data04/insiteportal/public_html/wire/core/Page.php(2423): ProcessWire\Wire->__call('saveField', Array) #10 /data04/insiteportal/public_html/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module(2737): ProcessWire\Page->save('installation_qu...') #11 /data04/insiteportal/public_html/wire/core/Wire.php(416): ProcessWire\ProcessPageEdit->___ajaxSave(Object(ProcessWire\RepeaterPage)) #12 /data04/insiteportal/public_html/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___ajaxSave', Array) #13 /data04/insiteportal/public_html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessPageEdit), 'ajaxSave', Array) #14 /data04/insiteportal/public_html/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module(556): ProcessWire\Wire->__call('ajaxSave', Array) #15 /data04/insiteportal/public_html/wire/core/Wire.php(413): ProcessWire\ProcessPageEdit->___execute() #16 /data04/insiteportal/public_html/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___execute', Array) #17 /data04/insiteportal/public_html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessPageEdit), 'execute', Array) #18 /data04/insiteportal/public_html/wire/core/ProcessController.php(361): ProcessWire\Wire->__call('execute', Array) #19 /data04/insiteportal/public_html/wire/core/Wire.php(413): ProcessWire\ProcessController->___execute() #20 /data04/insiteportal/public_html/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___execute', Array) #21 /data04/insiteportal/public_html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessController), 'execute', Array) #22 /data04/insiteportal/public_html/wire/core/admin.php(174): ProcessWire\Wire->__call('execute', Array) #23 /data04/insiteportal/public_html/wire/modules/AdminTheme/AdminThemeUikit/controller.php(15): require('/data04/insitep...') #24 /data04/insiteportal/public_html/site/templates/admin.php(15): require('/data04/insitep...') #25 /data04/insiteportal/public_html/wire/core/TemplateFile.php(328): require('/data04/insitep...') #26 /data04/insiteportal/public_html/wire/core/Wire.php(413): ProcessWire\TemplateFile->___render() #27 /data04/insiteportal/public_html/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___render', Array) #28 /data04/insiteportal/public_html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\TemplateFile), 'render', Array) #29 /data04/insiteportal/public_html/wire/modules/PageRender.module(581): ProcessWire\Wire->__call('render', Array) #30 /data04/insiteportal/public_html/wire/core/Wire.php(416): ProcessWire\PageRender->___renderPage(Object(ProcessWire\HookEvent)) #31 /data04/insiteportal/public_html/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___renderPage', Array) #32 /data04/insiteportal/public_html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\PageRender), 'renderPage', Array) #33 /data04/insiteportal/public_html/wire/core/WireHooks.php(1094): ProcessWire\Wire->__call('renderPage', Array) #34 /data04/insiteportal/public_html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Page), 'render', Array) #35 /data04/insiteportal/public_html/wire/modules/Process/ProcessPageView.module(193): ProcessWire\Wire->__call('render', Array) #36 /data04/insiteportal/public_html/wire/modules/Process/ProcessPageView.module(114): ProcessWire\ProcessPageView->renderPage(Object(ProcessWire\Page), Object(ProcessWire\PagesRequest)) #37 /data04/insiteportal/public_html/wire/core/Wire.php(416): ProcessWire\ProcessPageView->___execute(true) #38 /data04/insiteportal/public_html/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod('___execute', Array) #39 /data04/insiteportal/public_html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessPageView), 'execute', Array) #40 /data04/insiteportal/public_html/index.php(55): ProcessWire\Wire->__call('execute', Array) #41 {main} thrown (line 254 of /data04/insiteportal/public_html/wire/core/FieldtypeMulti.php) The error here is referencing line 254 in the file FieldtypeMulti.php This file can be found in public_html/wire/core. This directory is a core processwire code. This is the line that is causing the error throw new WireDatabaseQueryException($e->getMessage(), $e->getCode(), $e); In the error the code is asking for one thing and is getting a different value. With this being a processwire file there isnt something I can really assist on amending. You can try and get the CMS to generate a new config file as Im assuming the original files will be tailored for MySQL instead of MariaDB. Looking at the file and error online, you can look at amending the code to change the second argument to an integer. I highly recommend doing this with caution though as like I mentioned before this is a core processwire code so amending this may come with risks so please proceed with caution if you go down this route.

Hi, With the introduction of GDPR regulations, many of our clients with "webuser" systems we've developed need a way to email users that haven't logged-in in a while (18 months seems to be the standard) to ask them if they still want their user account. For most of the systems we've developed, we've added a field to the user template which records the time when the user logs in, so we'll be able to develop this functionality. It got me thinking, would this be a welcome addition to the core, accessed in a similar way to created/modified dates e.g. $user->lastlogin? Were it to be implemented, it would be useful to be able to 'silently login' if using $session->login($username, $pass) or $session->forceLogin($username), in the same way you can bypass save hooks by passing in an option to $pages->save(). Cheers, Chris - NB Communication

Thank you very much for the answer, I am really new to all this, I am struggling editing buttons and the design of the page per total. I am using Processwire 2.5.3, I am waiting for an update and maybe after this I can understand more, also I think I might not have access to everything I am trying to change. I used only easy drag and drop type of web designing. All the best

Are you observing abnormal RAM usage before the crash? For the past few months, we've been experiencing an issue on a server that hosts several websites. MariaDB has been using more and more memory, and after a few weeks, it reaches the server's limit of 8 GB, causing the Linux kernel to kill processes. This issue started around the same time I installed a new site built with ProcessWire, but I can't say for sure that it's related. We've checked our MariaDB settings, the opened connections status, investigated what we could, but we haven't found the cause yet.

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?

It is a solution, yes. A good solution? I don't think so. The problem that you are talking about is why I built RockMigrations. ProcessWire makes building all kinds of inputs/apps/guis/relations relatively simple. The drawback is that all these setups that are created via user input (and not via code) are one-off solutions. That means they only work once for this specific project. If you want to make them reusable you have two options: Create a site profile (with all its drawbacks, as mentioned above) Create code that does all the setup that you usually do by hand Option 2 is usually a LOT of work. That's where RockMigrations shines. Instead of building everything with your mouse you build everything with migration files. Once you know how to use it is is not a lot slower. In fact I think if you take the whole picture into account it is a lot faster (think of reverting changes, refactoring, deploying, testing, etc). That was some background. Back to your situation: You can use the site profile on a subdomain. If you need date from the other system you can use bootstrapping or use multi-instance features of PW. It might be easy. It might not. What you can also do is install the site profile and then move things over to your new site step by step.

This one's been a long time coming, but this week we launched a site for the UK charity INQUEST who provide support for families involved in state related deaths. This was part of their 40th Anniversary and the site showcases significant milestones and events from their archive over the last 40 years. There's an interactive timeline, case studies and oral histories. Even given the difficult subject matter we're really pleased with the result: Behind the scenes, the modules we used were mostly the usual suspects, Tracy Debugger, ProCache etc. Also RockFrontend specifically for the ajax routing (would love that as a separate module @bernhard ) which we used with HMTX in various places. Not sure we really needed to use HTMX on this one but hey, it is very handy. One module we made use of which we hadn't used before was @Richard Jedlička's PDF fieldtype so that we could generate thumbnails of PDF documents. There are a lot of historical documents on the site and having the thumbnails generated automatically was really handy. The site seems to have gone down really well. And we actually had a launch party - it's been years since that happened... https://history.inquest.org.uk/ Oh, and it does very nicely in Lighthouse and gets A+ in Observatory as well 🙂

Rock-Monthly Newsletter subscribers know that I'm rebuilding my custom CRM/bookkeeping software. It has already sparked two powerful new Rock modules! 🚀 RockInvoiceItems provides a powerful Fieldtype/Inputfield combo for handling invoice line items with real-time calculations, rich text editing, and a clean UI. Key Features: Dynamic line item management (add/delete/clone/sort) Rich text editing item descriptions with TinyMCE Automatic calculations (subtotals, VAT, grand totals) Multiple VAT rates support Drag & drop sorting Easy to use PHP API, eg $items->subtotal(), $items->grandtotal() German translations included The module extends WireArray and handles all the JSON serialization/deserialization behind the scenes. It's easy to install - just drop it in your modules folder and you're ready to go! Download & Docs: baumrock.com/RockInvoiceItems Let me know if you have any questions! 👋

Grouping your posts by year is a different use case than pagination which is just showing a fixed number of posts per page. For example you might have a year with dozens of posts that still need to be paginated. When we've needed to do this in the past we've used URL segments to pull out a year and then build a selector from that. We can then use the results from that query for pagination if need be. The code below uses a URL like /blog/by-year/2020 ; you could easily build a subnav that has the years in you need to filter by. Obviously you'd need to update the code to match your fields but hopefully it will point you in the right direction. <?php namespace ProcessWire; $filter_title=''; // Do we have url parameters? if ($input->urlSegment1 ) { // in this example we only filter by year if($input->urlSegment1 =='by-year'){ $year=(int)$input->urlSegment2; $year_end=$year . '-12-31'; $year_start=$year . '-01-01'; if($year > 2000 && $year < 2050){ // not really santizing but I just don't want to encourage any Widdecombe of the Week behaviour. $filter_title=$year; } $results = $pages->find("template=news_item, publish_from<=".$year_end.",publish_from>=".$year_start.",limit=12, sort=publish_from"); }else{ $filter_title="Sorry - unknown filter."; } }else{ $results = $pages->find("template=news_item, limit=12, sort=-publish_from"); } if($filter_title){ echo '<h2>' . $filter_title .'</h2>'; } if($results && $results->count){ $pagination = $results->renderPager(); echo '<div class="news-list">'; foreach($results as $result) { echo '<div class="news-item">'; echo '<div class="news-title"><a href="'.$result->url . '">' . $result->title .'</a></div>'; echo '<div class="news-date">' . $result->publish_from .'</div>'; echo '<div class="news-summary">' . $result->summary .'</div>'; echo '</div>'; } echo "</div>"; echo '<div class="text-center">' . $pagination .'</div>'; }else{ echo '<div class="news-list">No results found.</div>'; }