Leaderboard

When we released ProcessWire 3.0.200 one of the biggest differences from prior master/main versions was that PW now only includes 1 profile: the site-blank profile. This means there's probably going to be more people starting with it than before. Yet it is so minimal that I thought it deserved a bit of a walkthrough in how you take it from nearly-nothing to something you can start to build a site around. Everyone will have a little bit different approach here, which is one reason why the blank profile is a useful starting point. In this new post, here are some steps you might take when starting a new site with the blank profile— https://processwire.com/blog/posts/starting-with-the-blank-profile/

That's a good Blog post! I really want to read a part two, (and maybe three?). ? Also very useful for new starters, I believe.

The ProcessPageList module now has a configuration setting where you can select pages that should not be shown in the page list. For example, maybe once you've set up your 404 page, you don't really need it to display there anymore, except maybe in debug mode. Or maybe you don't ever need the "Admin" page to display in the page list. This new feature lets you do that, and for any page that you decide. Next, a "Usage" fields has been added to the "Basics" tab in the Field editor, just like the one in the Template editor (requested feature #445). This shows you what fields are using the template. It's essentially the same information that you'll find in the "Actions > Add or remove from templates" feature, but easier to find, especially for people newer to PW. That's all for this week, I hope you have a great weekend!

Part two with "Adding in relevant 3rd party or Pro modules" would certainly help newcomers as well, in addition to "Optimizing settings in /site/config.php".

Hi @Kholja, Thanks for reporting. This has now been fixed in today's update. The issue was we were only checking for quantity=0 BUT NOT 'remove item' request as well. For information, this is how Padloper currently handles items removed/updated/added to the cart. Please note that below ONLY APPLIES to cart and order processing executed via an order checkout form (i.e., not if manually processing cart and order using the API). If at least one item is added to the cart AND the customer has started the checkout process by 'proceeding to confirmation', an order page is immediately created. The line item(s) is added to the order page. This allows for tracking abandoned carts. If an item is updated (increased quantity or decreased quantity BUT NOT ZERO quantity) in the cart: In the line item, there is nothing to do at this point. If an item is either removed OR quantity is ZERO, the item is removed from the cart but still we don't delete the corresponding line item in the order page. Instead, we hide it (it is a pending item). This caters for situations whereby the customer might decide to re-add the product to the cart after removing it completely. In such cases, we only need to unhide the line item in the order page instead of creating another page. When the order is completed, any hidden line item pages (pending items -> meaning they were not purchased) are deleted. I am mentioning the above, especially #3 since if you are manually getting and displaying (i.e., using $pages->find()) order overview before purchase is complete, you should not use include=all or include=hidden as that would display pending items to the customer. Use check_access=0 instead, or better, $padloper->find();

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

Hi @Gary, before choosing any of the countless slider scripts out there consider reading Heydon Pickering on inclusive design of sliders: A Content Slider (For sure not easy if you are a beginner...) Kind regards ottogal

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.

Very nice addition, thanks Ryan! ? This is actually one of the features of a general purpose utility module we install on all our client sites, so will definitely be using this option in the future.

This week we have ProcessWire 3.0.201 on the dev branch which includes a couple minor fixes but also a couple of useful additions: There are new "Tab" field visibility options available for any field in the page editor. This makes the field display in its own page editor tab. It saves you from having to create a new/separate Tab field just to wrap around an existing field to make it display in a tab. So far I've found it particularly useful with ProFields (Combo, Table, Textareas, RepeaterMatrix) as well as the core Repeater, FieldsetPage and Images fields. For instance, I have a Combo field labeled "SEO" that lets me edit browser_title, meta_description, canonical_url, etc., and now I can add that field to any template and pages using that template have their own "SEO" tab. Sure you could do this before by creating a separate tab field with an "SEO" label, but now it's a lot simpler/faster, as any field can now display as a tab on its own. Like with the other visibility modes, also included are options to make the tab load dynamically on click with ajax or make the value non-editable. You can also optionally specify a label for the tab independently of the field label. This is because usually you want tab labels to be very short (1 word is best) whereas field labels have no such need. Please note that this new Tab option is exclusive to the page editor, and in order to work the field must not already be in a tab. Also added this week is a new $page->getMultiple() method. This method works the same as the $page->get() method except that it lets you retrieve multiple page property/field values at once and returns them in an array. For example: $a = $page->getMultiple([ 'foo', 'bar', 'baz' ]); list($foo, $bar, $baz) = $a; It also accepts a CSV string: $a = $page->getMultiple('foo,bar,baz'); By default it returns a regular PHP array, suitable for using in list() like the first example. But if you want it to return an associative array instead, then specify true as the 2nd argument: $a = $page->getMultiple('foo,bar,baz', true); echo $a['foo']; echo $a['bar']; echo $a['baz']; I find this method useful in reducing the amount of code/lines necessary in many cases, and most often I use it in combination with a PHP list() call, i.e. list($title,$subtitle,$body) = $page->getMultiple('title,subtitle,body'); That's all for this week. Thanks for reading and have a great weekend!

Loving the tab feature, great addition. Can this be used within a combo field to group the subfields together?

I was in the need for using this module together with background images too - but in the "classic" way without any components. I am using the famous Lazysizes JS Plugin for lazyloading the images. To create responsive background images with the PageImageSouce module I also included the lazysizes bgset extension So the code in my template file looks like this: <div class="img-title-wrapper lazyload" data-sizes="auto" data-bgset="<?php echo $image->size($imgFormat)->srcset() ?>"> /* your content */ </div> The wrapper element then gets it's height either via CSS (height: 100vh for a big introduction title image) or through the elements inside the container. Adjust the background image styles to your needs (e.g. background-size:cover).

@bernhard That's correct, a $page->extract() wouldn't be possible as the extract() function has a unique ability to create variables, as far as I understand it. The issue with extract() is that any variables it creates are unknown to your editor/IDE, and often times to the caller too. Whereas list() is defining variables in a visible manner that is readable and known to the IDE, clearly identified in the code as $variables. I rarely like extract() in code because it's too ambiguous, like tipping over a box of an unknown items and quantity. But there are times that's exactly what's intended, like in the TemplateFile class, where it has to pass an unknown set and quantity of variables to a php template file and make them directly accessible by $variables. This is fine because the php template file knows what variables to expect even if the class that provided them (TemplateFile) doesn't. So I think extract is good for cases like that, but otherwise I think it's preferable to have some kind of variable definition whether $name = 'value'; or list($name) = [ 'value' ]; etc.

Have just ugraded to the latest version with PHP 8.16! Went everything smoothly ! Thanks a lot Ryan and the other contributors ! PW is the best CMS !!!

I always start from scratch when it comes to creating the fields and templates, and basic site structure, but rarely when it comes to the pages/content. On previous conversions I've gone into WP’s database and exports to migrate content. This new case is a little bit unique in that WordPress couldn't do everything they needed, at least not in a manner that was affordable or reasonable to implement, from what I understand. While some of the content is in WP, other content is coming from authenticated web services. Lots of the pages have some content, custom fields and repeatable blocks in WP, but there are also custom fields with IDs for external services that it pulls other content from at runtime. They are paying a couple other companies quite a bit of money every month to host their content through these web services and make it searchable. They pull from those services at runtime and output it all from the WP templates. It strikes me as really inefficient, but it all works fine and you'd never know it from the front-end. But it's also expensive for them and fragile to have these kinds of external dependencies, not to mention a pain to have to manage content (even for the same page) across different services. This is all stuff that ProcessWire does well on its own, so none of those external services are needed on the new site. Since the front-end of the site is already compiling them all into single-page output, I built a scraper to pull it directly from the existing site and put it into the right places in ProcessWire. Scraping might seem like a last resort, but in this case it was the fastest, most direct way to pull everything out since the content is split among different databases and services. Basically using WP as an adaptor for the services it is pulling from. Luckily I can edit the WP templates to modify the markup (adding wrapping tags or custom html id attributes, etc.) where needed make the scraper relatively simple. @MarkE

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 ?

@ryan Have you considered putting some new screenshots here? It’s a very popular feature judging from showcase threads, developers here love to show off their images to great effect (it was also asked about in this recent thread, for instance), but it gets almost no love in the public docs/store page, and even in the introductory blog post it can only be seen for a split second in the video. The images in the video are also kind of grey in comparison to @olafgleba’s beautiful display ? I’m sure showing it off on the store page would boost sales some!

Ah okay. I do not use the ProField Modules. That's a really cool feature, though.

Great website. Thanks for the behind the scene insights.

Thx. The latest ProField Repeater Matrix has the option (input tab) to define the method for adding items. When you choose Images you get the overlay. By default, the image of the matrix type have the same name and is placed along with the type file location (for example: /site/templates/fields/modules_page/matrix_type.php => site/templates/fields/modules_page/matrix_type.svg). Preparing a good looking Image is just up to you then ?

Just because there is no need for this extra. The client is happy what he got. Coming from Typo3...

Really cool design! I love the content module solution. I build something like that my own by using nested repeater fields... but can you tell me how you realized that good looking "Select type to add..." popup?

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.

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

For me the opposite is true ? The main reason for that might be my workflows around RockMigrations and custom page classes. Having the fields defined in code directly in the page class is so much easier for me than any other approach I tried. So those additions where very welcome ones for me ? Need some new data for a boat? Go to the boat pageclass file and add a field there. Need a new field for every blog post? Go to the blog post pageclass file and add it... I'm only sharing fields across templates (page classes) when they really have the same purpose (eg a RockMatrix field for the pages content that has several content-blocks like headline, text, quote, etc that should be the same for templates home, basic-page and blog-item). So adding a new content block like "image" for example would make it available on all those templates immediately compared to having to update all templates one by one and adding the new image block to three different fields. For me it feels a lot better to have a single field for a single purpose. Sharing a field for different purposes by overriding settings in template context never felt good to me... I'm using template context a lot, but only to do simple modifications like tweaking the field's label (eg of the title field). One huge benefit of such an approach can be that you get reusable components that you can simply copy from one project to another. That's because the page classes do NOT share fields with other components of your site and therefore are self-contained parts that work on their own. That would not be possible if you shared fields from a central place. Or it would be a pain to reuse single parts of that website. I have been there. I don't want back ?

Also curious about this one. Is lazy-loading enough to make number of fields a non-issue? Mostly just thinking out loud here, but I do see at least one benefit in sticking with fewer fields: your fields may remain more manageable, especially if the alternative is to have a lot of very specific fields. Consider having to make the same change to settings of 50 fields compared to 5 fields, for an example. (Of course assuming that they are identical enough for this to make sense in the first place.) On the other hand I guess that under some circumstances more fields could even be good for performance, considering that each field has a separate table. This seems unlikely to cause noticeable difference, though, unless we're talking about an absolutely massive scale ?

Wow, what an awesome list of improvements! @ryan, I have a question about the lazy-loading of fields. Do you think this change means that the previous recommendation to reuse fields, as in the "Making efficient use of fields in ProcessWire" blog post, is now no longer needed? Say I am using text fields in lots of different templates for different purposes, and if I create and name fields so they describe the use in each template I will have 50 text fields, or if named them generically and reused them I would have maybe 5 text fields. Is their any reason now to prefer the 5 fields option over the 50 fields option, given that in any one template I'll only have 5 text fields or less and so presumably only ~5 or less fields get fully loaded at a time?

I trink the popup is a new repeater Matrix function ? (released in october 2021) https://processwire.com/blog/posts/new-repeater-and-repeater-matrix-features/

This module allows you to automatically send an email to a newly created user with their username and password. It also has the option to automatically generate a password for the user upon creation. http://modules.processwire.com/modules/email-new-user/ https://github.com/adrianbj/EmailNewUser The following things are configurable: Whether Send Email option should be automatically checked when creating new user - also affects new users created via API From email address (if left blank it will use the admin email set in the config/php file Email subject Email body - includes the ability to use any fields from the user template using {field_name} codes so these can be put into the body wherever you want. It's your choice if you want to include the password in the email or not. Whether to automatically generate a password. This can be toggled on/off, but even if it is on, you can override it by simply entering a password manually when creating the new user. Ability to control the length and character sets used to make up the automatically generated password. Option to send a test email to yourself to make sure it is configured the way you expect. Because it is generally not a good idea to email passwords, it is highly recommended to use the new Password Force Change module in conjunction with this module. That way the user has to change their password the first time they login which will somewhat reduce the vulnerability of emailing the password. It can also be used for API generated users: $modules->get("EmailNewUser"); // call the module since it is not autoload on the front end $newuser = new User(); $newuser->name = 'newuser'; $newuser->email = 'newuser@gmail.com'; $newuser->sendEmail = true; // only needed if Automatic Email Send is unchecked $newuser->save(); Please let me know if you have any ideas for improvements. PS Thanks to everyone in this post: https://processwire.com/talk/topic/2981-new-user-welcome-message/ for their thoughts and ideas on how to do this.

Thanks adrian, not only for this new module but also for your abundant supporting posts and contributions in this forum.