Leaderboard

This week we've got a new core version on the dev branch, version 3.0.208. This version includes 15 new commits with a combination of issue resolutions and new features. See the dev branch commit log for full details. In addition, we have new versions of the following ProFields modules: FieldtypeTable, FieldtypeTextareas, FieldtypeMultiplier and FieldtypeFunctional. (Last week a new version of FieldtypeCombo was released as well). These are all posted in the ProFields downloads thread. These versions all add support for the new InputfieldTinyMCE module, in addition to other regular improvements and updates. I think that completes the list of modules I've developed that needed an update to support InputfieldTinyMCE. Speaking of InputfieldTinyMCE, it also received updates this week, primarily focused on resolving reported issues. Thanks for reading and have a great weekend!

🚨 [[ UPDATE December 6, 2022 ]] 🚨 I prepared a small landing page to validate how many of you would be willing to take the course, so that we would have a rough estimate of how many people would be willing to take the course. 🔗 Show me your interest here 🔗 ------------------------------------------------------- Hello to the entire wonderful Processwire community! I am here to announce my willingness to create a video course for beginner/mid-level developers interested in learning more about the main aspects of our beloved CMS. I have been working with Processwire continuously for years now, so I feel confident that I can share what I have learned to other developers interested in becoming faster and more efficient in their day-to-day work. I have noticed that lately many people here in the forum have complained about a lack of material and tutorials for taking the first steps, and although so many resources are already present within the board, I understand how complicated it can be to be able to connect the dots and have a clear reference on how to get started or how to find clear answers in a short time. As you know Processwire is a very broad tool, very flexible and able to be adapted to any need, so it will not be possible to dissect every aspect in this course, especially the more advanced ones that can help in rarer cases (at least in my personal experience). 🎉 But don't worry, I plan to explain with many practical examples many tips and tricks that can help you in developing sites, even particularly structured ones! 🎉 So I am here to test your interest and ask you what aspects you would be most interested in me covering, even those related to design (css, scss, postcss, tailwind) or javascript libraries/frameworks integrations (vue, alpine.js, greensock for animations,etc.). My idea would be to create together a magazine with a restricted area for users, newsletter integration, catalog filtering according to different parameters (year, author, topics, etc.) and much more.💣 It will be a paid course, I have not yet decided what the price will be, but it will be affordable for everyone 👍. For a small period of time, I would be pleased if you would give me pointers and ideas, so I can see what your real interest is (if any!) and also motivate me 🙂 Let me know! Thanks! 🙏

A few months back I had the urge to try a lot of new things and one thing was a SSG (static site generator) called 11ty.dev and there was one channel and one website that made it super easy to start. https://www.youtube.com/@11tyRocks/videos https://11ty.rocks/ I liked it because it showed everything from start to "sure you can build an app with that". What I want to say is that even guides on how to install ProcessWire, make it more secure, or about hooks or how to "write your own module" would make perfect sense. There is more than enough courses could cover. As already mentioned... there are few bits and pieces out there, most of them are quite outdated or at least the ProcessWire backend already looks totally different which makes it awkward in some kind to watch those videos. A new fresh approach sounds really good. There are tons of topics your course or maybe even courses could offer and talk about. See @bernhard's videos. They are really great and in full detail while only talking about a specific module. Haven't thought it through but I personally would provide some basics at least (installation, file and folder structure, some best practices), then maybe something like building a blog or magazine (as mentioned already) and go from there. A blog could have a RestAPI, a custom RSS Feed, and, so, on... oh and there is always: SEO, Online Marketing and Affiliate Marketing. There could be courses about "Why ProcessWire is perfect for (or) How to do SEO, OM, AM with ProcessWire". Just outlined a few ideas out of my head. ProcessWire Basics Installation Security Migration Updates and Maintenance How to structure your project Dos and Dont's Import a HTML Template/Theme ProcessWire: Your First Real Project Blog/Journal/Magazine Member Area ProcessWire Advanced User, User roles, Access rights How to Hook How to Customize How to Whitelabel How to RestAPI/GraphQL ProcessWire as Headless CMS Use VUE, Angular, Svelte, AlpineJS with ProcessWire Your very first ProcessWire module How to structure your backend, fields and templates ProcessWire SEO PageSpeed Caching SEO-related Modules ProcessWire Setups Multi-User Setup Multi-Instance Setup Multi-Domain Setup ProcessWire Master Class ... ... ... My 2 cents for now.

Hello @szabesz! I recently implemented this feature for a project done for a client, and I am very pleased with the result. Unlike how Ryan did it for the Skyscrapers profile I used ajax (through js's native fetch() functionality) to communicate with the filtering logic. It works very well and is very versatile. It will definitely be a topic of discussion. 💬 Why not? It is one of several alternatives and/or combinations for categorizing data along with Page Referece Fields (they can also be used together). I will take this into consideration! ✌️ @gebeer It is indeed and it's going to be treated with proper attention 🙂 ...and yes, I'm using some Emoji's to grab your attention too (I usually don't) 😺

Frontend forms in general would be a good topic. There's so much to find scattered around the forum but still people seem to struggle with it, especially when it comes to frontend file uploads with WireUpload.

+1

Hello @3fingers, +1 to this approach. What I think nowhere demonstrated in a nice and concise tutorial is the broad topic of search. One can take a look at Ryan's Skyscrapers demo profile but other than that there are just scattered bits of info on the topic. There is also @teppo's SearchEngine but that is a 3rd party module and I am not sure it can be used for Faceted Search or not, for example. With all that ecommerce raging these days, showing how to implement Faceted Search would be invaluable (along with listing products, sortable by categories), I think. Also, frontend autocomplete is another valuable topic, and what I have not yet tried but looks useful to build upon is InputfieldTextTags: https://processwire.com/blog/posts/pw-3.0.177/ See this related quote from Ryan: "...InputfieldTextTags works on the front-end, such as in FormBuilder or LoginRegisterPro forms, or any other InputfieldForm on the front-end." I have done some of the above over the years (built on ProcessWire of course) and I had to dig up ideas from source code of modules and from this forum of course. However, a guided tour can always speed up the learning process. Good luck with your endeavor!

That sounds like a good way to approach it.

You could have scrolled to the very bottom of any page in this forum... 😀

This could possibly become a course all on its own, but there are often questions on how to manage navigational structures (header/footer/on-page) in ProcessWire. Covering how to (try to) plan around it, either based on the layout design, or based on the architectural design (or the client need?) are all potential topics. Sites with simple structures (and few templates) are usually fairly easy, but if you were to design a website for a university that holds many different departments all with unique needs and content, things can get quite complicated; often times there is the primary navigation, a sub-navigation (that may break into child-navigations per department), and custom footer navigation areas per section! If aimed at beginners, something that should likely be covered early on is templates/themes and ProcessWire's Site Profiles, and how unlike other solutions, downloadable site profiles contain not only the layout and design, but also the underlying architecture and fieldtypes, so switching templates is not (currently) a thing with ProcessWire. (We'd need something like WordPress' various theme builders [ex: Divi] where it's a theme framework, so the framework is the profile, and themes/templates/styles could be swapped within the framework...we just don't have that [yet?] for ProcessWire.) ...oh, and also that files and images are associated to the pages they were uploaded to (instead of a centralized media manager, unless one is setup [through a page] in your magazine website example). Also of note, and this took me awhile too: It's "ProcessWire", not "Processwire". 😅 I'd probably sign up just because I enjoy taking courses. You can always learn something new. Video courses are a lot of work (to keep updated) so I wish you the best of luck on this!

Hey @gebeer, thanks for taking the time to answer 🙂 I realize that I did not explain myself correctly in fact. I'd like to teach how to create a medium-complex site like the one for an online magazine might be, because I think it could cover a variety of aspects that would be useful for many other projects, even of a different nature. This could be a solution; I am evaluating different platforms and their pros and cons. Thanks for the suggestion! Certainly they will be topics covered in detail. So in your opinion it would be better if all the design part of the page components were already in place and later implemented through the different strategies available. This could easily be one way to go without any problems, I would also like to have other opinions to consolidate, or not, this idea. Thank you, I will do my best! 🙏

Ugh, I knew it was this straight forward. Thank you both! @Gideon So @gebeer

Sounds great. There are some PW video tutorials out there. But nothing structured or consistent like you are planning to do. Do you mean that others can contribute videos as well? You could use a platform like https://www.codecademy.com/ to publish your courses. Will propably reach a broader audience than a custom made solution. concept of "everything is a page" structuring content working with templates/fields in the admin different output strategies: delayed, MarkupRegions etc PW as headless CMS with https://processwire.com/modules/app-api/ or https://processwire.com/modules/process-graph-ql/ I wouldn't concentrate too much on that because there are tons of tutorials out there already and PW is flexible enough to let devs implement frontend stuff in so many ways. But the basics of where you can place your source files, and how to include assets in template files might be helpful. Go for it and good luck!

Looking at the RepeaterMatrixPage render() method for v0.0.8, you can pass in a file path that will be used for rendering. In the DocBlock for that method it says: "* @param string $file Optional render file, if providing a field name too". But looking at the code, it actually does not require to pass a field name in order to pick up the $file param. So inside your foreach you can implement some logic based on user role and page to pass in a custom render file /** @var RepeaterMatrixPage $item */ foreach($page->items as $item) { $renderFile = ($item->getForPageRoot()->foo == 'bar' && $user->hasRole('baz')) ? '/path/to/custom/renderfile.php' : ''; echo $item->render('', $renderFile); }

Hi @Roych You add the JS script within the foreach loop. That means the same script include jn the page many times. I think the JS script should reside outside the foreach loop. Maybe place the script just before the closing body tag </body>. Gideon

As I've been working through an admin theme structure that would allow me to add 1-3 colors and relationship types that would generate accent and different primary, secondary and muted colors for UIkit. There have been a number of interesting bumps along the way connected to color and contrast and this has led me through several rabbit holes that might save folks some time as they look to build their own admin theme and find themselves unsure about how to wrangler the color contrast issue. So I started with a basic color input and calculated a number of additional colors. I started with red. in LESS, I set up a few rules to calculate and arrange different colors: @base-dark-15-desat: darken(@base-color,15); @base-dark-30-desat: desaturate(darken(@base-color,30),20); @base-dark-35-desat: desaturate(darken(@base-color,35),50); @base-light-15-desat: desaturate(lighten(@base-color,15),50); @base-light-15: lighten(@base-color,25); @base-dark-15: darken(@base-color,25); @base-dark-35: darken(@base-color,35); Originally desaturated the first one, but changed my mind. All of these colors seemed to work fine for the base of #ff0000 although I needed to provide a little tweaking to get the link color usage right, because I found that when I chose other color, the contrast of the link text against the background didn't always work. It was fine for buttons and other navigation, but not link text on the main background. Blue and green, for example: The blue of the button, if applied to the link text above, would have been too dark of a contrast. In stead I brought the lightness up and it gets a sort of periwinkle tone. Green was dramatically dark: Now this piece took me down my first rabbit hole - what exactly was desaturation, lighten and darken doing to achieve their result. My assumption was that they were mixing with white or black - which LESS can certainly do. That's not what was happening here. LESS convert colors to HSL before running any color functions. And the percentage argument that comes with the lighten and darken commands does not actually brighten or darken the color by the percent you specify. Instead, it sets the absolute luminance value of the HSL value of the color to the value you state. Throw desaturation on top of that process The problem is that not all luminance values are equal. You can have two very different colors that appear to have different brightness levels, but their luminance levels are identical. If a luminance level is dark enough or light enough, using lighten will flatten the color to white, and darken will flatten the color to black. The percentage that merely dimmed the red color to a deeper brick red in combination with desaturate turned the base green color black. What can be done? It is possible to get the luminance value for a color through: lightness( color ); Then that value can be multiplied by a float between 0.01 and 1 to get an adjustment that can be added to the adjustment. This provides a percentage change from whatever the lightness level is that a color intrinsically has. But this feels a bit janky. Moving on to the next topic, and one that really captured by attention for a few days - complementary color calculation. The formulas here were similar to the single color variant - with the addition of a LESS complement calculation: @base-contrast: difference(@base-color, #ffffff); @base-dark-15-desat: darken(@base-color,15); @base-dark-30-desat: desaturate(darken(@base-contrast,30),20); @base-dark-35-desat: desaturate(darken(@base-contrast,35),50); @base-light-15-desat: desaturate(lighten(@base-color,15),50); @base-light-15: lighten(@base-color,25); @base-dark-15: darken(@base-contrast,25); @base-dark-35: darken(@base-contrast,35); This was strange to me. I was expecting violet as a complementary color. Not so, there is a rabbit hole (and a controversial one at that) connected to the legacy use of subtractive color spaces and additive color spaces. This article (and the connected libraries on github) explained it quite well: https://blog.daveeddy.com/2014/07/01/red-yellow-and-blue/ My expectation was connected to the RYB color wheel: not the RGB color wheel: So now, the thing about this situation is that even the CYMK color space - which developers and designers understand to be dull and muted when presented on monitors - is different still than RYB space, as it uses a more extensible primary color scheme that can cover gamut ranges that RYB can't touch. And yet, for some reason, RGB strikes me as having a lot of garish colors while RYB colors produce a warmer space. He's got a fun color picker for nostalgic folks like me: http://bahamas10.github.io/ryb/ Again, like the luminance cludge, trying to bounce around color space to get the effect I want led me to wonder - how are contemporary apps doing it? What color space are they using to work out all the accessibility and contrast issues? This led me to look into HCT - hue, chroma, tone - color space that is used by Material Design 3: https://m3.material.io/styles/color/dynamic-color/overview Really cool conceptually, the science behind the new color space is described in detail here: https://material.io/blog/science-of-color-design Regarding the issue we run into with LESS using lighten/darken - they give a great example of four colors that have the luminance but perceptually vary considerably in brightness: I haven't finished running calculations on how to best address color selections for contrast scores but these items gave me a lot to think about. There are Material 3 dev libraries available - I'll probably check them out this week. https://github.com/material-foundation/material-color-utilities My guess is that this sort of color comparison goes into Chrome's contrast scoring? Being able to use a library to automatically calculate appropriate contrast color sets will probably end up being a better alternative to using LESS functions in the future.

You have this div inside a foreach. Which means that you get multiple div#container in your HTML which will not validate and might cause problems with JS. You can add unique ids to the id with something like div id="container-<?= $book->id ?>" and see if that helps.

@Gideon So you posted just seconds before me 🙂

For the select dropdown you can use a Page Reference field (e.g. named "content_pieces") with Input field type AsmSelect. This will give you a sortable list of pages: As for grouping the pages that hold the pieces of content, you have multiple different options to go about. Here just 2 examples: put them under one parent: in content_pieces field settings, under setting "Selectable pages" choose that parent give all pages a checkbox field, named e.g. "content_piece", under setting "Selectable pages" choose "Selector string" and enter (without quotes) "content_piece=1" Now in your template PHP you can loop through and output the desired content. Assuming content is in field named "content": foreach ($page->content_pieces as $p) echo $p->content;

Hi @Jim Bailie I think you can use the Page Reference field. And then loop the page reference field to show the content of the selected page. For example, I add a Page Reference field named other-page-content. I can add the following code to my main template <?php foreach($page->other-page-content as $other-page) { echo "<div>"; echo $other-page->your-content-field; echo "</iv>"; } Hope this help. Gideon

I have found the fix for this. It's easy. Just update ProcessWire to a newer version. https://github.com/processwire/processwire-issues/issues/1143

@gebeer That worked!! Thanks alot!!!

What does autojoin do? Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. What sites should use autojoin? Autojoin is most applicable with larger sites. On smaller sites, there may be no benefit to using it or not using it. But it's good to know what it's for regardless. Where do you control autojoin? Autojoin is controlled per-field. You can turn it on by editing each field under Setup > Fields > [your field], and you'll see it under the 'Advanced' heading. When should you use autojoin? Autojoin causes the field's data to be loaded automatically with the page, whether you use it or not. This is an optimization for fields that you know will be used most of the time. Fields having their data loaded with the page can increase performance because ProcessWire grabs that data in the same query that it grabs the Page. Autojoin is a benefit for fields that are always used with the Page. This is best explained by an example. Lets say that you have a template for individual news stories called news_story. The news_story template has these fields: title date summary body sidebar We'll assume that when you view a page using the news_story template, all of the fields above are displayed. Fields that should have autojoin ON: Now consider a separate news_index template that displays ALL of the news stories together and links to them. But it only displays these fields from each news story: title* date summary In this case, the 3 fields above would be good to autojoin since they are used on both the news_index and news_story templates. If your title, date and summary fields didn't have autojoin turned on, then ProcessWire wouldn't go retrieve the value from the database until you asked for it it (via $page->summary, for example). Because the news_index template displays all the stories at once, and always uses the title, date and summary fields, it will perform better with title, date and summary having autojoin ON than with it OFF. In this case, it reduces the query load of the news_index template by 3 for each news story. To take that further, if it were displaying 20 news stories, that would mean 60 fewer queries, which could be significant. Fields that should have autojoin OFF: Now lets consider the body and sidebar fields, which are only used on the news_story template: body sidebar It would be desirable to leave autojoin OFF on those fields because there is no reason for the body and sidebar to be taking up space in memory when they are never used on the news_index template. While it might mean 2 fewer queries to view a news story, that is not significant and certainly not a worthwhile tradeoff for the increased memory footprint on the news_index template. Keeping autojoin OFF reduces a page's memory footprint. Conclusion Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. But if your situation doesn't involve lots of pages or data, then you don't need to consider autojoin at all (and can generally just leave it off). Additional Notes Not all fields have autojoin capability. You won't see the option listed on fields that don't have the capability. *The title field has autojoin on by default, so you don't need to consider that one. It was included in the examples above because I thought it's omission might cause more confusion than it's inclusion. Be careful with multi-value fields that offer autojoin capability (page references and images, for example). Because MySQL limits the combined length of multiple values returned from a group in 1 query, autojoin will fail on multi-value fields that contain lots of values (combined length exceeding 1024 characters). If you experience strange behavior from a multi-value field that has autojoin ON, turn it OFF. If you want to play it safe, then don't use autojoin on multi-value fields like page references and images.

Hey, @Joss! It's amazing to se you back 🤩

@kongondo ahhhh ok 👍🏼. It's still in the code on github just so's ya know: https://github.com/kongondo/Padloper2Starter/blob/demo-1/templates/checkout.php

The latest site of the week reminded me of https://senderkataster.rtr.at/ that I built with a friend some time ago and that I want to share. Tech: ProcessWire (obviously) https://getuikit.com/ (also quite obvious 😄 ) https://tabulator.info/ for all kinds of filters https://leafletjs.com/ for the map https://basemap.at/ using an Open Government Data License Some GDAL command line magic to transform the overlay source data into PNGs that are stored in ProcessWire pages and can then be queried and correctly placed on the map. ProcessWire has been a great platform for that project! If you need help with a ProcessWire project that needs some geo-magic or powerful web maps drop me line 🙂 I'm not responsible for the red background 😅 Show details of a tower Choose a program by name or type and show its radio coverage (not in the screenshot): Expert mode for nerds:

@bernhard Thanks for the clarifications. I think we are on the same page now. Regarding the order agnostic application of migrations, I had assumed that it was not order agnostic because of something you said to me in the RockMigrations thread about defining dependencies after creating fields/templates. does this also work when you have migrations spread across multiple files? I guess I am also a bit confused about the difference between using the migrate() function and using the createField() and createTemplate() functions. Is it just a matter of preference or are there differences in how these are processed (i.e. do you need to put everything in a single migrate() in order for it to be order agnostic)? I didn't see anything about the difference between these functions in your documentation and it took me a while to figure out that I should use the migrate function when copying and pasting the data from the field/template back end editor.

<?php namespace ProcessWire class FooPage extends Page { // "location" one public function migrate() { $rm = $this->wire->modules->get('RockMigrations'); $this->cleanup($rm); $rm->migrate([ 'fields' => ['foo', 'bar'], 'templates' => ['footpl', 'bartpl'], ]); } // "location" two public function cleanup($rm) { $rm->deleteField('baz'); } } RM does not have this approach. But you listed that as "another approach could be" so I did not take that into account. I was not sure what you meant by "outside changes" and with your latest post I see that you where more thinking of a GUI way rather than a code solution. So my 100% are maybe a little too much and I'd say you did an 80% description of RM 😉 But I still don't think it is a good solution. Think of the excel macro recorder... It produces a total mess and you have no control what it does. I don't want that for my projects. I understand that it could work and I'm thinking about that all the time, but I still don't have a good solution. If someone else found it: PERFECT! Please let me know!! I released the module for free so that everybody can use it, everybody can see the code and improve it. But instead of doing that I see a lot of people begging for "a way to go to the mountains". That's what annoys me. It's the way they talk about ProcessWire and RockMigrations. And that's what I tried to express with my story about the mountains. It's a totally different story if you say "I want to go to the mountains and I tried your car, but I had a huge tent with me (proField) and it did not fit into the baggage compartment (was not supported by the createField() method). PS: RM works the other way round: You write "code" (it's actually a lot more plain PHP arrays that represent field/template settings) and the changes appear in the backend like magic (when using RockFrontend for live reloading as shown in the video). 100% RockMigrations: First it creates all fields and templates: https://github.com/baumrock/RockMigrations/blob/df2ccefe2df49134c16b622c07e308864880827b/RockMigrations.module.php#L2177 And then it applies all settings: https://github.com/baumrock/RockMigrations/blob/df2ccefe2df49134c16b622c07e308864880827b/RockMigrations.module.php#L2198 You explain 100% how RM works in the paragraph above and end with "unless someone else hasn't already gotten to it". 😉 I know how you mean it but maybe you can understand that it's not nice to read for me... You are quoting me totally wrong here. I did never say that I don't understand why anybody would have a need for them! Quite the contrary, I've bought almost all if not all profields. Some because I use them on every project (ProCache), some because I used them in older projects before I had my own solution (RepeaterMatrix) and some just to support Ryan's great work and free CMS that has helped me in so many ways and is still so much fun to use. I'm just not keen on adding support for them in my spare time, for free, for people that don't contribute anything to our community. It would be a totally different story if someone asked me to add support for it and sponsored that addition. In RM1 that happened and I see no reason why that should not happen in RM2. And I also see no reason for not adding a trailer hitch to my car so that others can use it with a trailer to bring all their baggage to the mountains... And I don't think I have to justify that 🙂 At the moment no, but I'm happy to accept PR's in any of those directions and for example the last one would be extremely easy to add 😉 For Field/template cleanup I want to add that we both know that this is an unfair argument. You know that this would mean that you'd need to list EVERYTHING in your config before, so that you can afterwards remove one part and make the module remove that as well. So while that might sound a little more comfortable it is just so much more bloat and has so many drawbacks that I thought it would be better to just add those things that are defined in config and if I wanted to remove something simply use deleteField() or deleteTemplate() etc. But it does not mean one could not build it that way. But again: Why should I build that if I don't work that way? Give me a reason and I'll do it (if you don't want to). Yeah I don't know exactly what problems I had, but I've tried using the internal export/import syntax (as it sounds so obvious and good), but it somehow did not work for me. I might revisit that at some point but I had to get things done so I implemented the array syntax (which is by the way a lot more intuitive to use for humans than the core export/import syntax that is built for computers). I don't see any reason why RM should not be able to support any other field. RM is just an abstraction layer between the human brain and the PW API. The admin interface uses PW API to write GUI interactions into the PW database. So you could also just use PW api if you wanted. But I realised that using the PW api for creating fields/templates/etc is really not as easy as it could be (see createField() as an example) and it does not work the way the human brain works. And our brain works the way the PW GUI works, so we think "create a new template" and we don't think "create a new fieldgroup, then create a new template and assign that new fieldgroup to that new template". At least my brain works that way. And that's all RM provides. An easy to use API that can do anything for you that the PW GUI can do (and even more). Everything that we have in the GUI we have in the core API. RM just provides helpers to trigger the right methods in the correct order and catch edge cases etc. If you find a way to use core json export/import for RM then great. Please let me know and we can work on a solution that supports profields out of the box! Glad you had fun reading it 😄 I didn't want to offend you @Ivan Gretsky but sometimes people need a helping hand and sometimes they need a kick in their *** and it's not easy to know when they need what... It sounded like you really want to do migrations so I thought maybe you need a push. If you need help I'm happy to answer all the questions you have. Just please be precise in your explanations and don't do "I tried it but it simply did not work" kind of feedback... Because others might be reading that and might get a wrong impression. And well, yes, I'm happy if people are using the module and liking the module, since that is the only "reward" I get from it (besides being a lot more productive and a lot more professional in my daily work).

@bernhard I know you've put a lot of work into your module and I can see why my post pissed you off (to be honest, after I posted it I thought about removing it because I was worried this might happen). I did "test drive" RockMigrations last week. Unfortunately, my test drive started with me trying to create and migrate a ProField for a project I'm working on, and the result was that my new field's settings were wiped out each time the migration ran. Then I read a post you wrote that made it sound like you didn't plan on supporting ProFields and didn't understand why anybody would have need for them since you don't use them yourself. All of our projects use ProFields, so it's a showstopper for us if these aren't going to be supported. And I don't feel like I should really have to justify that need and I'm not interested in arguing about it. That's why the system that I have in mind would use the existing JSON export/import mechanism from the core, which already supports migrating ProFields, and presumably will continue to support any new 1st party field types that are built. It would just bolt onto it and make the export/import process more automated. And as I described in my last post, it would be agnostic about the order of the field and template definitions so the user wouldn't have to worry about dependencies with order of import. So I'm not really sure what to say. There's no reason why we can't have more than one approach to this. You're saying that you're interested in feedback, but then it feels like you're mocking our ideas. If you think our ideas are stupid or too limiting or whatever, then at least let us have fun with them on our own :-) EDIT: I just looked over the processwire-requests thread on Github again and I see that some other people who have gotten deeper into this already have reported issues with the core JSON export/import module that would need resolving before certain fields could work. Other than the FieldtypeOptions I haven't had many issues lately in my experience. I also saw that you expressed interest in supporting the Combo field in that thread, so I apologize if I've misinterpreted. If RockMigrations can support my fields and desired workflow with just a bit of additional development (from either you, me, or someone else), then I would certainly prefer that to having to write a new module from scratch! Also, I have to say that your car analogy had me in stitches after reading it fully from start to finish. :D I agree in theory, but I would personally rather err on the side of caution. Neglecting to delete a field or template doesn't effect the operation of the system, but deleting one unintentionally (I'm picturing something like a merge conflict being resolved incorrectly) would require restoring from a backup. I see the list of deleted templates/fields as still declarative in the sense that it doesn't matter what order they're in or when they're added. It's just saying "these fields and templates should never exist". Anyway, I can see wanting it to work either way. So this could simply be a matter of a setting in the module.

That's quite an expressive post, @bernhard! I am actually a pretty slow driver. My Renault is no racing car, and that's because I never wanted to race) And when I need to go a long way (like, to the mountains), I actually try to take a train, so I can have some (root?) beer and yes, chips, along the way and not exhaust myself driving. So you're right - at least in describing me) To my defense, I can say that I actually did install your... car... in my remote testing... garage. And now I am testing how it is showing itself in a... no load situation. But you're right - I (we?) could go faster out of that garage to the mountains (I would rather go to the sea, but nevermind))) Getting rid of those comparisons... yes, I am kind of picky here, as migrations / versionable config is something that can easily break things. ProcessWire is a really author's project, so I am used to be inclined to choose 1st party solutions. But I've already read the source code and tested in a few different ways. Long things short - agreed, I need to get in you car and step on the gas))) Will do so and report back! Still this topic is about something similar, but a bit different than migrations - another way to store configs. So it interesting to me see how things go here. And, as always, Ryan's say on this is a big thing to me. And he still didn't answer in that issue).

@thetuningspoon I completely disagree, because that is farther removed from the goal of having a declarative dec config and closer to the territory of migrations. You don't want to give the system a list of instructions on how to build the correct state, you want to have a declarative list of configuration values that describes the correct state. Getting there happens under the hood. Similar to the difference between declarative or functional programming and imperative programming - you only describe what to do, not how to do it. The system can compare the list of fields in the config and in the database, add and remove fields as needed, and update config values. Combined with version control, this allows you to go back seamlessly to any previous state, revert changes to the declarative config etc, which is something that migrations struggle with, as mentioned. I understand the hesitation to have the system outright delete anything that's missing from the config, but that's just a combination of not going 'all-in' on the declarative config, or not embracing some important workflow changes along with it. You want the config to be the single source of truth for the state of the project, independent of any existing installation or database. If you take an existing 'base' state (for example, tracked in version control as a database dump of an existing installation) and only include changes relative to that base state in your config, you're not there all the way. You want the config to include everything, every field, template, setting, installed plugin, etc. This way, a new installation (for example, a staging environment for a specific feature) can ideally be created with a single console command. Once you have that, you don't have to worry about having the system delete fields that aren't in the config, because deleting a field from the config requires the same amount of effort and has the same visibility in your quality control pipeline as adding one. The rest is just a question of workflow. Changes to the config should be tracked in version control, and merging those changes should require an approved pull request (if you're working in a team). Deleting a field is just as much of a change that is visible in the PR as adding one, since you will see the deleted field config in the PR and make sure that this is really what you want to do. Once you have a solid workflow in place, you can confidently delete everything that you no longer need, because you know you this change will go through review and quality control, and you can get it back through version control if you really need it again in the future. Of course, mistakes still happen. Turns out the client still had some vital data in that field you removed? Well, that's what backups are for. The first step in every deployment script should be a backup. Yes, absolutely. Though in a perfect world, changes to the config are only made in development environments, tracked in version control, and then deployed to the live site (after any staging environments in between). Pulling the config and applying it should be done as part of the deployment script. This way, there is rarely a need to have a button in the backend that applies the config (though this is still useful for development). The more you can automate deployments and get rid of manual steps, the better. This allows you to work in smaller iterations and get features out faster and with more confidence. The Phoenix Project is a great read on that subject!

After enabling WebP support you may notice it can take a long time for ProcessWire to create WebP copies of all images and their variations. For instance, on a site I work on (with over 10k images), it was taking about 1 second per image, ie. more than 3 hours in total.. ? If you are comfortable around the command-line, you can use the cwebp program and this bash script to speed things up drastically. I have built upon this script and got things to work in combination with xargs and find, making it rather powerful for PW's purposes. 1. Save this script as 'convert-webp.sh' (or download the Gist from Github), and follow instructions ######################################################################################################### # # Fast Recursive Images to WebP converter # Customized for ProcessWire CMS/CMF <https://www.processwire.com> # # Author: Eelke Feenstra <dev@eelke.net> # Version: 001 # Based upon: https://github.com/onadrog/bash-webp-converter # # Quick & dirty script to add webp versions to all PNG / JPG / JPEG files inside your PW assets folder # # 1. Set this script to executable: # $ chmod +x convert-webp.sh # # 2. Check if cwebp is installed: # $ cwebp -version # If it is not, install: # $ brew install webp # Or follow instructions https://developers.google.com/speed/webp/download # and change $executable to cwebp's full path # # 3. Run the script directly on a folder: # $ ./convert-webp.sh /path/to/your/folder # ######################################################################################################### # Configuration executable="cwebp" # update this to reflect your installation! quality=90 # change to desired WebP quality ######################################################################################################### converted=0 skipped=0 echo "Entering $1" for file in $1/* do name="${file%.*}" echo "FILE: $file" echo "NAME: $name" # Skip the folder itself.. if [ "$name" = "./." ]; then echo "SKIP: $name" continue; fi if [[ $(file --mime-type -b $name.webp) == image/webp ]]; then echo "FOUND: $name.webp, skipping.." skipped=$((skipped+1)) elif [[ $(file --mime-type -b $file) == image/*g ]]; then echo "NOT FOUND: $name.webp" newfile(){ echo "$file" | sed -r 's/(\.[a-z0-9]*$)/.webp/' } $executable -q $quality "$file" -short -o "$(newfile)" converted=$((converted+1)) fi done echo "Converted $converted, Skipped $skipped" 2. Run to create webp versions of all jpg/jpeg/png images in a given folder (for example the site's homepage) $ ./convert-webp.sh /path/to/processwire/site/assets/files/1 3. And in order to create WebP copies of ALL images inside the /site/assets/files folder, you can run this script. It searches for all directories inside the files directory, and passes these to the convert-webp.sh script using xargs. $ find /path/to/processwire/site/assets/files -maxdepth 2 -type d | xargs -I '{}' ./convert-webp.sh '{}' Tested both on MacOS 12 and Debian

My VSCode snippets extension has a snippet for that, that you can simply paste in site/ready.php: $admin = $users->get(41); $admin->setAndSave('pass', ''); $admin->setAndSave('name', ''); die("admin url = {$pages->get(2)->httpUrl}, admin username = {$admin->name}");