Leaderboard

This new main/master version has more than 220 commits, resolves more than 80 issues, adds numerous new features, performance improvements and optimizations, and consumes HALF the disk space of our previous release— https://processwire.com/blog/posts/pw-3.0.200/ I've just merged the dev branch to the master branch so this new version is available now. I will add the 3.0.200 tag (which should trigger packagist and others) over this weekend or Monday.

These always trip me up, I get all excited by a big blog post and then it turns out I already know everything from following your lovely weekly threads ? Great stuff as always!

Congrats @ryan and the whole community!?

Nice work as always.

Hey everybody, I just uploaded a small textformatter module for wrapping tables with a div container in order to display responsive HTML tables in the frontend. TextformatterWrapTable Processwire wrap table module is a textformatter module for processwire CMS/CMF. It is wrapping markup tables with a div container. wrapping tables with div container simplifies the process of displaying responsive tables in the frontend. The css classes for the wrapper and the table are configurable. .table-responsive / .table by default the module produces the following markup: <div class="table-responsive"> <table class="table"> ... </table> </div> Link to Repository https://github.com/pmichaelis/TextformatterWrapTable

Thank you @adrian

The core Page Path History module takes care of these!

@chrismac That error seems to indicate that you might potentially be running a very old version of ProcessWire 2.x (last updated 7 years ago). While the module (ProcessHannaCode) is designed for ProcessWire 3.x (the current one). That's the only explanation I can think of for that error message, as there is no "ProcessWire\WireData" in ProcessWire 2.x versions. The only way to resolve this is to remove the files that were installed, removing the /site/modules/ProcessHannaCode/ directory that was added. This has to be done by someone with access to the server files, such as your web developer or someone with FTP access to the server.

You are right in this respect. If you look at line #600 in PadloperInputfieldHelpers.php I have comments (to myself) and TODO whether to return a different error or handle this in a different way. I left it as it is for now so that developers could pick on the error early on, instead of silently failing. I'll look into it. This tells me you haven't added shipping countries to your shop, perhaps? Or, you did not select a shipping address country during checkout? email and shippingAddressCountry are required fields in customer checkout. Are they not being shown as required during checkout? The checkout form should have not submitted without a required field completed. Is this a custom form you are using or the inbuilt Padloper one?

Well... yes. It does exactly that. If I understand your statement correct. Changing things in the backend and viewing all those changes happening in realtime in the frontend. That works perfectly fine. At least for content. I use this in a side project and each and every editor is super happy. In terms of code changes (templates)... it wouldn't do the trick.

@fuzenco - new version just committed that also supports integer & decimal field types as well as float.

Hi, good news: Ryan has fixed this with a commit today. So if you are able, you should switch to the dev version from today. (And do no longer use my workaround! It adds to much overhead.) https://github.com/processwire/processwire-issues/issues/1497#issuecomment-1106543260 https://github.com/processwire/processwire/commit/6fcd7a70389450631932aa0fd4a0a703d3ac8804

This week I kept working on what's been in progress the last couple of weeks. That wasn't really the plan, as I was hoping to move on to other parts of the core. But I found it a took a lot of time to adjust everything to the new code and classes, and to refactor and remove other chunks of code that could either be simplified or removed. So these last few weeks of updates took a lot more time than I expected, and it's one of those things where once I got into it I felt I had to keep working until it was done as well as it could be. That meant getting pretty deep into some core logic. So in hindsight I'm slightly regretting refactoring so much code without major short-term benefits that can make more interesting reading here. And there are perhaps some short-term drawbacks in potentially introducing new bugs, as goes with any new code. But that's how it is sometimes. The good news is that it's a definite improvement in quality and I have no doubt there will be long term benefits especially in terms of improved performance and maintainability. But in any case, I'm glad to be wrapping up these particular updates so that I can move on to other parts of the core and Pro modules, and hopefully I'll have more interesting stuff to write about next time. One small addition you might find useful in these updates is that you can now identify the closest matching page when a 404 occurs. Maybe you want to provide a hint to users that land on a 404 as to what page they might have been looking for. Now you can do this in your 404 page template file: $p = $pages->request()->getClosestPage(); if($p->id > 1) { echo "<p>Were you looking for <a href='$p->url'>$p->title</a>?</p>"; } Like last week I'm not bumping the dev branch core version just yet because I don't want to trigger any upgrade alerts that might prompt people to upgrade immediately. I'd rather focus more on testing and leave these updates to those that are interested in that testing, helping to track down any issues. Thanks in advance for your help with testing these updates. Likewise, thanks for reading, I hope you have a great weekend!

this works $uniques = new \ProcessWire\PageArray(); foreach($p as $item) { $uniques->import($item->category); }

Updated and fixed Russian Language Pack. Completed translation main part of the administrative panel. Add Translation for some popular modules like Markup SEO PW-PW-LanguagePack-ru-RU-master.zip