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.

You can do this with a little bit of extra CSS. This example is what i use for a radio select .Inputfield_select_option input + .pw-no-select { position: relative; padding-top: 70px; margin-bottom: 20px; width: 100%; display: inline-block; text-align: center; color: #333; font-size: 14px; cursor: pointer; } .Inputfield_select_option input + .pw-no-select::before { content: ""; position: absolute; width: 100%; height: 50px; top: 0; left: 0; display: inline-block; background-size: contain; background-position: center; background-repeat: no-repeat; border: #d9e1ea 1px solid; border-radius: 3px; margin-bottom: 5px; } .Inputfield_select_option input:checked + .pw-no-select::before { border: #2a2a2b 2px solid; } #Inputfield_select_option_1 + .pw-no-select::before { background-image: url(images/option1.png); } #Inputfield_select_option_2 + .pw-no-select::before { background-image: url(images/option2.png); } #Inputfield_select_option_3 + .pw-no-select::before { background-image: url(images/option3.png); } To add a custom CSS the link below shows one way of doing so.

That is a classic error message that I get all the time: The Database connection cant be established. Mostly because I forgot one of the things: - Do you have a variable in your config to switch between two development environments (local/live)? So that you are still trying to use your local database settings on your live site? - Do you already have a working PW installation on the remote server? Try checking the config values against the config that refuses the connection

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

Hi, haven't seen this before: Upgrading a 3.0.98 installation breaks after second step (database backup, skip backup), s. screen below. State: Master is downloaded, Database backup done, folders are created. Modul Upgrades => last current version (1.1), cleared all possible caches twice. Any ideas? Thx in advance.

thank you!! when I understood it's not a matter of the pw-install, I searched again - and I don't believe how easy it was: the database name was casus sensitive. I had the prefix in capitals: DB... how many hours! learnt also that it's ok to just copy all the files from local to remote without new install thx again

Please give me 24 hours. I have another work too.

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 ?

It's not often I stumble on parity like this, so grabbed this screenshot for posterity ?.

Repeater fields give you a PageArray. Have you tried getPageByID($id) to retrieve the item? Check the return value before removing. It might be NullPage, or when using get() it might be null. As a matter of fact, since you already know the ID, it should be perfectly safe to just delete the page: $pages->get($id)->delete();

The core Page Path History module takes care of these!

My guess would be that it's the line getting a value for $event where things start to go wrong. I'm wondering in particular where you're getting the value of $id from, and whether it's valid? You might want to try var_dump() to check whether $event actually is an object (and if so, if it looks as if it might be a repeater item): var_dump($event);

There is also an option to use cookie and htaccess RewriteEngine On RewriteCond %{HTTP_COOKIE} language=(ua|en) [NC] RewriteCond %{REQUEST_URI} !^/(ua|en)/ [NC] RewriteRule ^(.*)$ /%1/$1 [R=301,L]

Hi @csaggo.com, Work on price fields to accommodate international currencies is now complete. Decimal styles are now handled correctly. In addition, thousands are also separated correctly (automatically). To help with this, we now have a new setting in Shop / General Settings -> Standards Tab -> Currency Format (please see screenshots below). Price fields will be formatted based on this new setting. Price fields also display the currency symbol if one exists or the currency's abbreviated name. Currently, this is not configurable but I can add this in future if there is demand for it. This also works for variants price fields. Update summary: Automatic formatting of price fields based on the General Settings 'Currency Format' (currency locale). This means, e.g. Canada French versus Canada English is possible; France - thousand separator is space; Germany - thousand separator is period and comma is decimal character, etc. Thousands are automatically formatted as you type. Thousands separator is based on the 'Currency Format'. Decimal style is based on the 'Currency Format'. Currency value validation is also enforced client-side. For instance, if 'Currency Format' is 'de-DE', one cannot use a period as a decimal. Other invalid entries are also prevented, e.g. cannot enter text in this field. Automatic currency symbol placement. Currently, there are no in/decrement elements on the price field. Works with both products and variants (include variant creation modal). Not yet implemented in manual order editing (e.g. fixed discount amount, etc). Download Please use your download link to get the updated Padloper. If you don't have this in your email, please send me an email to resend it to you. Once downloaded, use the files to overwrite the ones in your present install. You might need to refresh your browser cache to clear the older JavaScript files. Version The Padloper version stays the same until #8 is resolved. Screenshots Currency Format (locale) Example: Canada currency formats Example: Germany currency format Edit Product (German Euro is currency) Edit Product Variant (German Euro is currency) Create Product Variant (German Euro is currency) Please test and let me know how it goes. Thanks.

Definitely yes ? At the moment no, but I plan to create a video that shows the most important parts. The ProcessWire snippets are available here: https://marketplace.visualstudio.com/items?itemName=baumrock.pwsnippets (also on github of course), but the RockMigration snippets are at the moment only locally available until I've used them a little more. Thx for that feedback. That's absolutely understandable and a valid point ? Update 2023: I've improved a lot here and try my best to not introduce any breaking changes. My modules follow semantic versioning, so a major version bump indicates a breaking change so that everybody is aware and can check if that is a problem in his/her specific situation. Also there is the rock-monthly newsletter now to communicate the most important news.