Leaderboard

We had a smooth rollout of the new main/master version 3.0.200 last week (read all about it here). If you haven't upgraded yet, consider doing so, this new version is a great upgrade. I'm going to add the 3.0.200 tag shortly after I finish this post, which should trigger other services (like packagist) to upgrade. I've had a new client project in the pipeline that I've been waiting to start till the new main/master version was out, so this week I started that project. Pete and I are working together on it, like we've worked on others before. It involves taking a popular WordPress site and rebuilding it completely in ProcessWire. I've done this a couple times before, but this time it's bigger and broader in scope. I always find the large site conversions to be great learning experiences, as well as great opportunities to show how ProcessWire can achieve many things relative to WordPress, in this case. At this stage, I'm having to spend a lot of time in WordPress just to get familiar with the content, fields, etc., as well as in the theme files (php and twig). The more time I spend in these, the more excited I get about moving it into ProcessWire. For this particular site, moving from WordPress into ProcessWire is going to result in a big boost in efficiency, maintainability, and performance. Part of that is just the nature of PW relative to the nature of WP. But part of it is also that the WP version of the site is kind of a disorganized patchwork of plugins, code files, and 3rd party services, all kind of duct taped together in an undeniably confused, undisciplined and fragile manner. (Though you'd never know it by looking at the front-end of the site, which is quite nice). This has been a common theme among WordPress sites I've dug into. Though to be fair I don't think that's necessarily the fault of WordPress itself. I always enjoy taking a hodgepodge and turning it into an efficient, performant and secure ProcessWire site. I love seeing the difference it makes to clients and their future by taking something perceived as a "necessary liability to run the business", and then turning it into the most trusted asset. I think the same is true for a lot of us here. We love to develop sites because it's an opportunity to make a big difference to our clients… and it's fun. Ironically, if past history is any indicator, I seem to get the most done on the core (and modules) when I'm actively developing a site. Needs just pop up a lot more. I don't know if that'll be the case this time or not, but I do expect to have weeks with lots of core updates and some weeks with no core updates, just depending on where we are in the project. This particular project has to launch phase 1 by sometime in July, which is kind of a tight schedule, and that may slow core updates temporarily, but who knows. I'll share more on this project and what we learn in this WP-to-PW conversion in the coming weeks. Thanks for reading and have a great weekend!

A week ago the new website of the wuppermann group went online. The Wupperman group is a EU-wide operating company with several locations in different countries. Their portfolio is all about steel fabrication. This includes flat producs, tubes & profiles. The technical production is developed by me, Olaf Gleba. The grafic design is supplied by C&G: Strategische Kommunikation GmbH. Homepage: https://www.wuppermann.com Some Impressions: (Secured) Shareholder portal, only available in german language Former screens deleted on behalf of the client. Technical notes: 1. All contents are populated by provided (i name them) content modules (e.g. Repeater Matrix Types) which gets the client what he needs and either prevent him from doing weird stuff. In nearly all textareas formatting is limited to a absolute minimum. For example, image insertion in CKEditor is generally prohibited. Instead there are dedicated fields for modules which holds media contents. 2. This and that.. - vCards are build on the fly with a admin hook on page save. - PrivacyWire as CCM (just a few cookies to handle Matomo and external movie content) - Uses the SearchEngine Module to handle (multilanguage) site search - Email Obfuscation Module for frontend e-mail addresses - Wire Mail Smtp to deliver automated e-mails - Multilingual (german, english, hungerian, polish, dutch) - Ajax driven content (for example on the contact page) - Heavy use of Fieldtype AssistedURL (Fork by @adrian) to provide language dependend, local file linking (fieldname_[de|en] approach) - Login area (closed shareholder portal) with secured file downloads ($config->pagefileSecure = true) - Email New User, Admin Action (create users batcher), Force Password Change for functionality like adding new users with specific roles, Password reset, Change Passwort a.s.o. - Distribution of concatenate/minified css and javascript is cachebusted (happens within my developement environment,- no modules (like AIOM etc.) involved). - Thanks to @ryan* all images are delivered in WEBP format (with fallback). *) s. https://github.com/processwire/processwire-issues/issues/1497 - The site uses a bunch of modules provided by the ProFields Package (for example Repeater Matrix and Table Fieldtypes).

Me too ?

We upgraded a big multi language site to 3.0.200 and to PHP 8* + MySQL 8 a couple of days ago, several thousands pages, lots of templates and fields (120MB DB). The upgrade went fine, and the site is running super fast! I didn't measure with tools, but just by reaching the URLs of some complex pages and you can see it loading waaay faster. The client could not be happier. ? Fantastic job, Ryan and the other contributors! Thank you, Sergio --- * I used RectorPHP to help upgrading my custom modules, which was nice.

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.

And installing less in addition. Really no big deal, but just saying ?

New Dynamic Selects Here is a preview of the upcoming update to Dynamic Selects (version 008). It is still early days and I don't currently have an ETA. This upgrade redefines the 'select' in Dynamic Selects. You are no longer tied to this <select></select>. This upgrade will give developers control over how they would like to have their Dynamic Selects rendered both in the Inputfield and in the frontend. This is possible thanks to htmx and ProcessWire's TemplateFile class. These allow for partial rendering of templates generated server-side. For each Dynamic Selects data type (Page, Template, User, Field), there will be a default partial templates which receive an object of that data type. For instance, a Dynamic Select that wants to render children of a selected page will receive the PageArray containing those children at their partial template. Developers wanting total control of any partial template will only need to duplicate a partial template and save this to a designated folder under /site (similar to Padloper) and customise that as they wish. This opens up a myriad possibilities. Your markup, your way. You want to render a HTML table, fine. An accordion? Fine. A photo gallery? Why not! The above also means all ProcessWire fields, including custom ones will be supported. This is because the partial template will receive the relevant object. With custom partial templates, this leads to endless possibilities. Repeaters, complex fields, any field. You could even combine this with Padloper to allow your customers to search for or preview products in very creative ways. Because these new version uses template partials, it means you can employ access controls in any part of the Dynamic Selects , for instance, show different fields or markup depending on user's location or if logged in, etc. Using the power of htmx, it also means you can output markup to different places simultaneously (Out of Band Swaps). @999design, this could cover your need in your post above about triggering more than 1 select.

Hi @Maverick, Apologies it has taken too long to resolve this. I have now fixed this. All selects are sorted alphabetically both in the back and frontend. If your download link has expired, please let me know so that I can send you the files personally. Thanks.

awesome! Thanks for using the module - hope it helps and is useful!

Thank you! Finally, I found the root of the problem. I didn't add "return $inputfields;" to the end of file. I'm not using a namespace explicitly. ProcessWire version is 3.0.199 dev, and everything works fine now.

Hi @fruid You have to turn on advanced mode by setting this in your config.php $config->advanced = true; Than on settings tab on that page you will be able to toggle 'system' checkbox

Just because there is no need for this extra. The client is happy what he got. Coming from Typo3... That extra would be 1 module to install and 2 settings to populate... Just saying ? The site looks great - congratulations ?

Ryan helped me to find the issue in another related thread: https://processwire.com/talk/topic/27136-page-list-view-page-path-points-to-localhost/?do=findComment&comment=224041 ?

@Robin S @bernhard @teppo I would say it's less important to limit how many fields you create than it was before, but it's still worthwhile to make efficient use of fields for other reasons (at least for the way I work). But the technical reasons for doing so appear to be much less than before. If you look here at the performance numbers on a system with 1000 fields you can see that prior to lazy loading, it took 0.5167 ms (half second) to load the fields. This might sound reasonable, but note the fields were created with an automated script and not as diverse as they would be in a real environment, so I'd expect the numbers to be higher/slower in real life. After lazy loading that part of the boot process was reduce to 0.0062 ms. Even without lazy loading enabled, the field loading was reduced to 0.0322 ms (in that 1000 field environment) just due to the other optimizations made in support of lazy loading. So there's some question as to whether lazy loading is even necessary anymore now that everything else more optimized. But using less time and energy is always good thing, even if not felt on individual requests, small differences add up to significant numbers over thousands of requests. The way lazy loading works is that everything in the database table (for fields, templates, fieldgroups) still gets selected and loaded, but into an array rather than into objects. That data doesn't get loaded into and converted to actual Field (or Template, Fieldgroup) objects until that specific object is requested. TheTuningSpoon found that overhead came from actually creating and loading the objects rather than selecting them from the DB, and I was able to confirm that. But it also means that the more fields you have, the more memory they will consume. But the memory consumed by the raw field data is very little and I think you'd have to have many thousands of them for it to even be a consideration. Lazy loading fields don't change the way I use fields, at least. I like to have as few fields as necessary just because it's easier for me to keep track of, fewer things to remember when writing code, fewer things to manage during changes, etc. But if your workflow is like the one Bernhard describes above then that seems like a case where more fields would appear to be a benefit.

SMTP is not IMAP. Maybe you can setup your SMTP server to send a copy into your desired subfolder, or simply use the BCC header with every outgoing email for that. see: https://www.socketlabs.com/blog/smtp-or-imap/