All Activity

I think you can find your answer here :: But please, don't test this on a production site.

Hello @Juergen, I have an issue installing FrontendForms on my processwire instance. After installing the module, the following error appears on the very top of the admin page: Deprecated: FrontendForms\Inputfields::removeSanitizers(): Implicitly marking parameter $sanitizer as nullable is deprecated, the explicit nullable type must be used instead in /home/web/_dev/site/modules/FrontendForms/Formelements/Inputelements/Inputfields.php on line 183 The module seems to work... but I also need to put more efforts in the forms I want to ceate and will see, if it is working as expected despite the error message. I use FrontendForms 2.2.54 together with processwire 3.0.246 stable and PHP 8.4 on Apache webserver. Thanks in advance for investigating.

@BFD Calendar Btw, I did try to access your site, and am getting an HTTPS error. So I think whatever your webhost restored might have broken the HTTPS setup. Chances are your webhost can fix that by checking a box somewhere, or if you have cPanel or something you might be able to do it from there. Once I proceeded without HTTPS, then I got ProcessWire's "internal server error" message, which means that ProcessWire found and logged an error to /site/assets/logs/errors.txt. So the source of the issue is likely identified in that log file.

I have found the issue: This only happens if the ID and name attribute are exactly the same on a single upload field. If there is a difference, everything works as expected, so I have added an additional suffix to the ID attribute of a file upload field to prevent this behavior. display-change.MP4 Now everything should work fine! Module version is updated, so please test if everything works now as expected.

@BFD Calendar Make sure you've got /site/config.php setting $config->debug = true; just so you can see errors. You may want to set it so that it's only in debug mode for your IP address, i.e. $config->debug = $_SERVER['REMOTE_ADDR'] === '123.123.123.123'; Keep an eye on the files in /site/assets/logs/, especially errors.txt. If you have shell access, you can "tail errors.txt" in that directory to see what the latest error messages are. You don't need to be able to login to the admin to view these logs, you can just locate them on the file system. Most of the time they will reveal whatever the issue is. If it's not clear, then post the last few log entries here to see if we can identify anything from it. The errors you mentioned may be expected, as it looks like they are trying to access something related to cgi-bin or a .well-known file, which are specific to your hosting and not to ProcessWire. So if your host blocks those addresses, then you'd expect to see this in the apache error log. Basically, I don't think those error messages are related to whatever is preventing your site from running.

Update once more.... I uploaded the last PW wire version and it worked, but the error logs showed problems with FieldtypeMapMarker, TextformatterHannaCode, Pages2Pdf. I replaced those manually with the lasted versions. Then everything worked perfect - for two hours. Now without any further changes the PW site is gone again due to internal server error. The overdrive in connections was due to an Amazon bot. So in the .htaccess I added <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_USER_AGENT} (Amazonbot) [NC] RewriteRule (.*) - [F,L] </IfModule> and in the robots.txt I added User-agent: Amazonbot Disallow: / In the provider error log for today there's only [Mon Oct 06 00:43:11 2025] [X-OVHRequest-Id: c27eb4c65e400e7a0437243896ebb722] [error] [client 72.14.199.130:0] [host www.birthfactdeathcalendar.net] AH01630: client denied by server configuration: /homez.863/birthfac/www/.well-known [Mon Oct 06 07:40:25 2025] [X-OVHRequest-Id: 4f22632b5d87972a361b0b0f8841a1fb] [error] [client 51.57.57.231:0] [host birthfactdeathcalendar.net] AH01264: script not found or unable to stat: /homez.863/birthfac/cgi-bin but the last entry is from 6 hours ago, after that everything worked fine for at least two hours. I'm getting desperate, even more because everything worked perfect for two hours and then went dead just like that.

OK, I guess what you mean: I will try to find out, what will be the cause and to fix this problem

Hello @da² I have fixed the 2 bugs with the URL segments (fixes will be in the next update), but I have a question concerning the file upload issue in single upload fields. I have tested it with Firefox without any problems. Take a look at the video. Single file upload.MP4 In my case it works as expected. If I drag and drop more than 1 file only the last file will be taken and only 1 file will be submitted. What browser do you use? Maybe it could be a browser related issue. Best regards Jürgen

https://github.com/processwire/processwire/archive/refs/tags/3.0.123.zip

@psy Where did you find the older versions of PW on github? I'm looking for 3.0.123 as this was working fine for me. @matjazp I uploaded that file but still can't login. As mentioned, I want to get my latest working version back working.

Yes, there is one minor issue :: https://github.com/wikimedia/less.php/issues/131 But it works with the latest version of UIkit!

@spoetnik does the latest version of the less parser fix all issues and make it work with the latest version of UIkit?

I made a pull request to the ProcessWire Less parser to update it to the latest version of the wikimedia Less Parser. @ryan this pull request is still open. https://github.com/ryancramerdesign/Less/pull/6

active_connections 18446744073709551581 That's a high number. Can you limit access to your website to your IP address, so that you can login to PW? Can you put robots.txt with the User-agent: * Disallow: / to the root of your website?

I didn't have the same version of PW locally either. I went to PW github and downloaded the next release version from what was on the site.

Hello, I have "inherited" the administration of this ProcessWire site, which includes an active Padloper store with several products. Looking at the modules page, I assume that this is probably a very old version (not sure if I should be looking somewhere else). How can I upgrade to a more up-to-date/stable version, without having to rebuild the whole shop and inventory from scratch? When I click "check for updates", I get an error that "That module is not currently tracked by the modules directory". Thank you for your help George

@psy That's an option indeed. First I'll ask my provider why the backup version was restored corrupted. I do have older PW wire versions on my site, but none of them managed to get anything back. While I usually only add/edit pages and change almost nothing to modules or other PW settings.

Had a similar nightmare today. Nothing to do with PW itself. Some files were corrupted during upload to the site. Fix was to do a manual PW upgrade, ie: rename wire dir to .wire-3.0.xxx (whatever version) and do the same for index.php upload clean wire directory and index.php To be on the safe side, I also re-uploaded site files I knew were clean Everything then worked 100% as expected. Hope this helps

@ryan Well there were quite a few errors that occured after the upgrade from PW 3.0.123 and PHP 7.x to 8.2. Like in all templates "$feature->template==bfd_events" didn't work and needed change to "$feature->template=='bfd_events'". Or "$webimage = $page->images->random()->url;" no longer worked. I managed to find out everything and got the site back working, when the above mentioned errors started appearing and my provider shut down the site. I went back two weeks in time with a backup option from my provider to make sure I'd get it all as it was before upgrading anything. But now I only see the first lines of the site, and the admin site is no longer reachable: internal error or misconfiguration. Even downgrading to PW 3.0.98 doesn't make any difference and of course now I can't even see any error logs as admin. Other pages like https://www.birthfactdeathcalendar.net/phpinfo.php load normal. With my provider I upgraded my hosting to allow more resources. The AI bot option might be the culprit, could it be Google trying to crawl/index the whole site? There are over 30.000 pages.... Report from Google Search Console: https://search.google.com/search-console/index/drilldown?resource_id=sc-domain%3Abirthfactdeathcalendar.net&pages=ALL_URLS&hl=en&sharing_key=N-nvEOUPuUWWfngX3zI85w.

Thanks to both of you. I did not see the custom paths module. This may work indeed, I will test it, as this is fortunately not a multi-lingual site. And yes, the name property is an option, I could rewrite the navigation module. But knowing the client, I am sure he will want exception for this flat url approach.

@BFD Calendar You can usually downgrade PW as easily as upgrading it, so I would probably just replace the /wire/ with the 3.0.123 version that was working well before. But I think it's unlikely that the version change is the issue, as newer versions are generally more efficient and reliable than older versions. For most sites a version upgrade like this would help the situation. Though there could be something unique in this case, who knows. I would guess you got hit by an AI bot (or a bunch of them) that went nuts and used up the resource limits. If you are hitting this query limit regularly, then your web host would need to increase the resources for your site, or you'd want to upgrade to a plan with more resources. An alternative would be to use WireRequestBlocker to keep the bots from consuming all the resources, and/or using ProCache so that most output can be cached and not hit the database. The most recent error that you posted sounds like something is missing on the file system (per what Matjaz mentioned), or that PHP's opcache needs to be cleared, perhaps a call to opcache_reset() could help matters.

Last week I was on a boat, far from any computer, so that’s why there weren’t any updates. This week I’m back in the office and back to work on the core. The focus has been primarily on optimizations and issue fixes (see dev branch commit log). There were also a couple commits related to PHP 8.4 support. Issue fixes and optimizations will likely continue to get more focus as we get closer to our next main/master version.There are also some Pro module updates in the works as well. Have a great weekend!

Framework 16 daily driver here, excellent choice. Linux? Do it! Outstanding support on the hardware and once you settle in you'll wonder how you ever had to endure Windows.

I suspect that restore was not complete, maybe some files are missing or permissions are not correct? Can you roll back to PW 3.0.123?

Update. I restored to a backup from two weeks ago provided by my provider. Now I'm getting an error on both front and back end: Fatal Error: Uncaught Error: Class 'ProcessWire\InputfieldText' not found in /home/birthfac/www/wire/modules/Inputfield/InputfieldName.module:7 Stack trace: #0 /home/birthfac/www/wire/core/Modules.php(1545): include_once() #1 /home/birthfac/www/wire/core/Modules.php(1502): ProcessWire\Modules->includeModuleFile('/home/birthfac/...', 'InputfieldName') #2 /home/birthfac/www/wire/core/WireClassLoader.php(202): ProcessWire\Modules->includeModule(Object(ProcessWire\ModulePlaceholder)) #3 [internal function]: ProcessWire\WireClassLoader->loadClass('ProcessWire\\Inp...') #4 /home/birthfac/www/wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.module(20): spl_autoload_call('ProcessWire\\Inp...') #5 /home/birthfac/www/wire/core/Modules.php(1545): include_once('/home/birthfac/...') #6 /home/birthfac/www/wire/core/Modules.php(1502): ProcessWire\Modules->includeModuleFile('/home/birthfac/...', 'InputfieldPageN...') #7 /home/birthfac/www/wire/core/WireClassLoader.php(202): ProcessWire\Modules->includeModule(Object(ProcessWi (line 7 of /home/birthfac/www/wire/modules/Inputfield/InputfieldName.module) This error message was shown because: you are logged in as a Superuser. Error has been logged. How to solve this?