Leaderboard

Thanks @Craigand @flydevwe have now resolved the issue. Clearing the cache was good for temporarily unlocking space in blocks to get through. Turns out the issue was a recent code change where the Pageimages class was used for handling a group of Pageimage's from across many pages (where we'd previously use an array) - we had not realised at the time that this leads to each image getting instantiated again (and therefore duplicated)!

@adrian thx. Actually I'm not sure if that is still an issue. First they have pushed something to vscode and closed the issue: https://github.com/microsoft/vscode/issues/197319 And second it seems to work on my end again. No idea what's going on...

This week I've been working on various ProcessWire related projects, but haven't pushed much to the core. There was a core feature I've been working on which I decided to instead put in a module. It's one of those things that should be be really beneficial for some people, but not necessarily needed by everyone, so it makes more sense as a module. This particular module expands upon the page-lock option and permission in ProcessWire. The page-lock option (which you'll see as the "Lock" status in the Settings tab of the page editor) provides the ability to lock a page for edits. This can be really useful if you want to prevent a particular page from being modified for whatever reason. For instance, maybe you are doing a $pages->get('/some/page/'); on the API side and if the path /some/page/ got changed, it would break something in the site. So to prevent clients from breaking the site, you lock the page to prevent them from screwing it up and breaking something on the site. This is quite useful, and often a life saver. But I don't use it as much as I'd like because of one downside. That downside is that it locks the entire page so that nothing on it can be edited. So it's just too heavy of a lock. What if you just wanted to lock the page so that the name, title and parent couldn't be edited, but everything else could be? That's what this new module enables. To lock a field in the page editor, you click its header and hold until a dialog pops up asking if you want to lock it. To unlock, you do the same thing. Once a field is locked, it remains locked (non-editable) until unlocked. Only users with page-lock permission on the page can lock or unlock fields. Locks can also be managed with checkboxes in the page editor Settings tab as well, just in case that is more convenient in some contexts. While these are editor locks rather than API locks, the locks do affect contexts outside the page editor too, such as actions in the page list. For instance, if you locked "parent" then you wouldn't be able to bypass it dragging a page in the Page List. I finished developing the module today, but I've not yet written documentation for it or uploaded to GitHub, etc., so I'm going to give it another day of work and testing before releasing it next week, and will cover more details in next week's post. Thanks and have a great weekend!

Hi, it seem a server issue, but for now we cant see what is the root source of the disk being filled. Do get an access to ssh again, which is the most important thing for now, you could use à logged user, and then in the admin, delete all logs file, then SSH asap. Once in the server, check /var/log and remove some old *.gz or the bigger to get more space, then investigate. Try to make a backup or an image of the server if you can before doing root cmd.

TL:DR I've updated a PW page we've built 9 years ago for the first time and it's still a solid experience. Backstory Back in May I was on a crowded train somewhere in the middle of Germany. Now working as a "Consultant" who builds slidedecks instead of websites, I happily noticed the men next to me talking about responsive webdesign with his friend. During the obligatory "This train is late" announcement we started to chat. My seatmate, a geography teacher, recently attended a web workshop at a large Hamburg agency. He told me he now understands the value of a CMS for updating their site and he wonders how to build a responsive layout. They don't get paid for this and work on their homepage in their spare time. And they have a Typo3 installation ? Back in 2013, together with my friend Marvin, we've rebuild our school website with ProcessWire optimized for mobile devices. Launched in 2014 this was quite an impressive feat including online time tables, a working event calendar (with import feature) and many small nice touches. After my encounter on the train, I checked the page and yes, It's still online and updated daily! The next day I wrote my old teacher a short email if we should have a closer look into the underlying tech and within minutes I got a super happy reply that he is so glad that somebody would help (again). So let's dive into what we've done. Situation First some details about this ProcessWire installation that is updated by a few teacher on a regular basis. Over the 9 years they've wrote nearly 900 news articles and kept more than 250 pages up to date. The asset folder is over 11GB. Build with Processwire 2.4 (?) and lots of janky code we've updated the page once to 3.0.15 somewhere in 2016 quick and dirty. They even used the old admin layout. ProCache, CroppableImages3 and a few other plugins were used. Every single one of them required an update It's used the classical append-template approach with a single big "function.php" included file. It's running on PHP 5.6 and for whatever reason no PHP update was enforced by the hoster (But the admin panel screamed at me) A privacy nightmare: Google fonts embedded directly, no cookie banner and a no longer working Google Analytics tag included The old ProcessDatabaseModule made a database backup every week as planned over all these years. Nice. No hacks, no attacks and all teachers are using their own account with assigned permissions Changelog I've updated the page with a focus on making it stable and reliable for the next 9 years. After making a development copy of the page, I've started working on the following changes: Updated ProcessWire and all modules to the latest stable version. After reloading a few times, no errors encountered Updated the whole templates to make it work with PHP 8.2 Removed all externally hosted scripts, disabled cookies for all regular visitors and introduced a 2-click-solution for external content Reworked a few frontend style issues around the responsive layout, made slight visual changes for 2023 (e.g. no double black and white 1px borders) Ported the image gallery feature to more templates (Big wish of the people updating the site, they've used a workaround) Cleaned up folder and structures, removed a few smaller plugins and admin helpers no longer needed All this was done back in May and - with a big break - completed now in October. It took a few days and most of the time was spent figuring out our old code. Learnings ProcessWire is robust as f*ck. I just clicked "Update" and it mostly worked instantly I nearly removed features for the PHP update. A custom written importer for the proprietary XML schedule was hard to debug and understand (5-dimensional-arrays...). Gladly I've tossed a coin and just gave ChatGPT the php function source and error message and within a single iteration it updated the code for PHP8. The "responsive" CSS framework aged badly. The used 960gs skeleton uses fixed widths for the responsive layout. I couldn't get it be wider than 320px on mobile screens. So the site is responsive but with a slim profile for now. Replacing it would be a complete layout rewrite Result and looking forward The Werkgymnasium site is now updated and live again. It still loads superfast and looks great after all these years. We have a few more features planned to help our editors input new content but overall it just works. Looking forward a few issues remain. ProCache would require the paid update but it still works fine. The layout needs improvement on mobile screens. There is still an error with the pagination. We'll cleanup the code more and then make the whole template public on Github so that maybe a few students after us can continue with the updates. Maybe even rebuild the frontend one day. I hope I can give you an update in a few years again. As a closing note: I'm still grateful for the amazing community here and all the features ProcessWire has to offer. My daily work no longer resolves around websites but PW has a permanent spot in my heart. Thanks Ryan and all the contributors.

Native AVIF support would be great for creating performant sites. When WEBP support was added to the core, it was done as a one-off addition. AVIF could be added in the same way by accessing an $image->avif property on the image object. However — I think @BrendonKoz touched on this above — adding more alternative output formats will probably require some rethinking to keep this part of the core modular. We'll definitely see more image formats being developed in the future, and it'd be great to access them from a single property or as a single parameter with formats and fallbacks, e.g. $image->url(300, ['format' => 'webp,png']).

To add informations on Steve suggestions, and avoid more troubleshooting than necessary, as you are running out of space, the second issue "SQLSTATE[08004] [1040] Too many connections" is certainly due to lack of disk space. The explanation is: lack of disk space make MySQL waiting before INSERT, UPDATE, etc, can complete and then increase the number of pending connections until the limit of `max_connection` is reached. For checking disk usage you might want to use a better tool like duf (muesli/duf/releases) to get a nice insight of disk usage (you will might not be able to install it due to the issue, just remove some log files to get a bit space, you require less than 900kb).

If you still want to review your code, you can also use regular php code in your Processwire projects. Check google for options: https://www.google.com/search?q=php+malware+code+scanner

You need to get out of habitual thinking when comparing Processwire with Wordpress. From the beginning, Wordpress was never made for 1) websites 2) safety. And so, all through the years tons of spaghetti plugins were made for Wordpress to make things work. Processwire has a completely different Architecture because it is made both a cms and a cmf with safety in mind to make websites and apps without the need for essential plugins.