FireWire

On a scale of 1-10, this is an 11.

The $config->allowExceptions value won't manifest in the browser dev tools where that information you posted came from If you can set the $config->allowExceptions to true and then find out how to get the new stack trace where your colleague was able to see it that would be the information you need.

@bernhard I saw that but didn't click. I wasn't sure if that would clone everything and I should have tried it out.

@bernhard So simple and elegant. Thanks!

@bernhard I am almost certain that this is a repeat question but my efforts to find the original answer if it exists have come up short. I have two RPB fields and I'd like to have all of the blocks that were created and located in the original RPB field available to the second field without replicating the block folders themselves. Field 1 (original field): rockpagebuilder_blocks Field 2 (additional field): rockpagebuilder_blocks_2 Thus far all of the blocks have been created in the original blocks field, I'd like the same blocks to be available to the second field. I created an empty folder for rockpagebuilder_blocks_2 as blocks_2. I can't remember if this is possible or if there is a file I need to add to the folder, or rename blocks_2 to something else? I've tried renaming the folder to rockpagebuilder_blocks_2 but no dice. Does it require copying all of the blocks from one directory to another? Thanks!

@Mark_invisu I mentioned above in my comment attempting to get to the underlying exception that may reveal the error that is occurring would be the most helpful in this situation. Are you able to make this change to your config file and attempt an upload again? It would be helpful to see the exception being thrown during the database transaction. Seeing the original error would be very helpful to understanding what is causing your issue beyond the type error exception that is being thrown by ProcessWire. If you're able to get to the error using this config property you may very well be able to skip any upgrades to ProcessWire or modifications to the core. Please share the resulting exception message you are receiving if you can do this. Without this information and the difficulty of others replicating your issue, it is very difficult to provide any advice or help.

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 😆

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.

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

@wbmnfktr apache-fpm in use.

I think Ryan mentioned that core is getting 8.4 compatibility fixes so I assumed 8.3 was taken care of. The few issues that I've experienced with 8.x PHP versions are the newer more strict null values being invalid for native PHP functions. I'm running Tracy which has been pretty good catching both errors and warnings so I'm not 100% convinced it's a PHP version issue, however I'm not against trying. I use DDEV and switching PHP versions is cake. I'll give it a shot.

@wbmnfktr I welcome "that guy", thanks for asking haha. PageListCustomChildren is installed but not configured. I'm not familiar with VirtualParents, so gonna be a no on that one. What is odd is that this is happening on some pages but not others. I tried removing modules and hooks but couldn't get any different results. I'm assuming this may be something that's happening in my install rather than some sort of bug, I just don't know where to start looking. ProcessWire 3.0.246 PHP 8.3

Seeing an odd issue when editing pages. The page list under "Children" should have the page currently being edited as the root page. Example- the page list should show pages under "Directory Profiles" rather than all pages under the "Home" page. So this should only show "Arosa". Haven't seen this before and not sure if it's a setting nested somewhere I'm not familiar with. Disabled all custom hooks, no dice...

@bernhard NICE!

@bernhard Excellent! It took 6 months and a bot attack to get to that number. We were getting many requests per second so this is probably not something many users experience. I'll call it "accelerated testing" 🤣 Thanks for the fix!

@bernhard Admittedly I just had to run some updates to the server firewall because we were getting hit with serious amounts of malicious traffic, so I don't think these may be numbers most RockMigrations users are going to see haha.

The lastrun log file accumulates a lot of entries and is never automatically pruned/cleared. Production server has a ~50mb file with 1.5 million entries. The log file contents are not written in a way that ProcessWire can parse. Is this log file necessary for RM to function properly? The log entries are accumulating even when migrations are disabled.

@bernhard So glad it helped out! Nice to know that it addressed another challenge. Your modules are so great to work with and really improve the developer and user experiences. The less time you spend fixing things is more time you have for building awesome stuff, so I'm happy to help 😎

@ryan Safe travels 👍

@bernhard I really like this direction with adding something next to the languages, it makes a lot of sense and does a good job showing the relationship between the button to what it does. The only concern I have is that on fields with smaller widths a larger tab size will cause some crowding next to the language tabs and cause wrapping. Example would be the description fields for images. Real world example for me: If it could be a little more minimal it would fit in a lot of places, especially if there are many languages. Experimenting with an alternate "X" style icon to differentiate it from the trash icon used to delete blocks, groups, pages, etc. Hover state A popup with a similar message would confirm both the intention and purpose of the button. Perhaps "Delete content in all languages for this field? Cancel/OK". A "delete all" action would prevent having to first manually remove the contents of the default language then click to delete the contents for all other languages. A tooltip would show "Delete content for this field in all languages". With both a tooltip and confirm popup the user would see, understand, and remember its purpose when editing content anywhere in the admin. Thoughts?

Entirely understand, a task not for the faint of heart. I haven't had to implement RRule myself but I've reviewed enough documentation to know that your work is tough, but incredibly appreciated. So I offer a message of support and encouragement 🙌 I have a project in dev right now that I'd be pleased to use for testing if/when you need it.

@bernhard Do you see a feature for viewing and managing existing recurring events as a feature implemented in RC?

@bernhard Sure thing when I can get a chance. Maybe this weekend. In the meantime, if you're importing an svg you may have some success taking a look at the markup and seeing if there's anything extra that may be added by Affinity. I had a graphics program that liked to create a lot of attributes and stuff that wasn't needed. No guarantee that's the cause but it may help. Think the List.svg button in the repo is an example of one that has good markup with no extras. That's the best guess off the top of my head.

Hey @bernhard & @monollonom I didn't forget about you, just hammering out some work. Taking notes from your great input. I appreciate it! Will be back when I escape from programming prison 🤣

@bernhard I wasn't able to provide a more robust response above but I wanted to mention that my concept wasn't an impulsive decision. I think my language in the confirmation popup should be changed. The "clear all" feature is a shortcut to clear all content in all languages including the default language so that it has one purpose. One of the things that I first had to consider was how often the feature gets used. Fluency has been available for over 5 years and this feature absolutely has great value but hasn't been mentioned before. I haven't heard about users/devs expressing a need to clear all content from multilanguage fields, and the general practice has been in my experience that if content changes then it would involve entering new content and re-translating. I thought about weighing how often the feature would be used compared to translation and it seemed like much less often, but I didn't have experience to go on. I also wondered if this was a feature that was use most during the initial build and population of content vs. ongoing content management. I think that was another area where the use of the feature may change over time as far as how often it's used, but again I haven't had the need so my understanding may be limited there. I'm not against the concept of a always-visible button or icon. Throughout the admin UI the trash icon is, as far as I can tell, mainly implemented for block, group, or object deletion rather than field contents. This is where the use of the trash icon without a label to explain the difference between what it means when used specifically for a field could be confusing because it does break from what it signifies elsewhere. The position of the translation action menu to the right as a clickable option felt natural with destructive actions located elsewhere. Placing it under a dedicated language icon menu seemed like it would strongly associate the action exclusively with multilanguage field features. Each field can have translation disabled, so there would have to be a decision whether to include just a trash icon even if there is no translation enabled for consistency when working with multilanguage fields. I think this could be a great convenience enhancement even if it steps outside of Fluency's current purpose and may be even be necessary for consistency. This may present another challenge because only multilanguage fields would provide the ability to delete content from the primary field that is visible where all other fields that only have primary content would need to manually be deleted. It's a step that may push a little further into ProcessWire's core behavior because some fields enable you to delete content for the default language alone, but other fields that are not multi-lingual still require a select-all-then-delete action by the user. If the trash icon is not present on all fields, would it seem like an oversight? Another thing that comes to mind is whether a multilanguage field with translation disabled were next to a single language field. On the left you can delete the primary content without deleting any other language, but on the right you can't delete the primary content with one click. The tabs hint that it's related to language fields, but non-language fields aren't afforded the same convenience even though they are visually similar to the end user. The intention is to have the clear all button clear everything in one action, so if the user is aware of the feature then they wouldn't clear any text to begin with. I think the language I used in my original "confirm" example may not have been as descriptive as it should be. It's an all-or-nothing action. The wording you used: "Are you sure you want to clear content in all languages for this field?" is much better and communicates clearly. So my approach was placing the option under an action menu since it felt natural to group secondary behaviors. The button that opens the translator is secondary and the ability to delete content in all languages is secondary compared to the primary feature of translation. I like the ideas and want to take the best approach, and I'm not against any specific implementation. Thinking through this though when you originally mentioned stepping into "core" behavior may be more impactful than it seemed when putting all different types of fields into the mix.