Leaderboard

This week's commits include fixes for 8 reported issues and a couple new $sanitizer methods for entity encoding values in arrays. I mentioned earlier that I'd like to try and get a new master version out early this year and that's still the case. I've been successfully migrating some of the production sites that I work on to the dev branch, and so far, so good. Please let me know how it works for you. We're on track for a new master version hopefully soon. A couple weeks ago I mentioned a module I was working on for automatically saving front-end forms in progress. For the moment, it's it's called FormAutoSaver, but maybe I'll come up with a better name (or not). It emails the person filling out the form with one or two reminders with links to finish it if they leave it before submitting it. The emails are template-file based so fully under your control, and the delay in sending 1-2 reminders is also fully configurable, whether hours or days. This module is essentially finished and now I'm just writing the documentation. I already have it in use on 1 site and it's made a helpful difference, not just in getting people to finish their forms, but also in helping us to analyze where people tend to get stuck and stop filling out the form. It also comes with an admin tool that lets you browse the forms in progress and see where they are at. Whether you want to increase the completion rate of of any particular form(s), or you want to identify bottlenecks, I think you'll find tool helpful. You don't have to design your form for it, as it will work with any existing form. I expect to have this posted into the ProDevTools board as soon as next week. Thanks for reading this short update and have a great weekend!

In summary... @ryan and @horst use what PW provides... @bernhard uses his RockMigration... all others of us use what ever fits our need and I'm totally fine with that... and really appreciate that. Yet... somehow I'd really love to see a CraftCMS-like (even though I never saw or used it) JSON/YAML-Recorder-style tool @bernhard showed to us. What if we open a money-pool for such a development? Someone interested? If I could have some kind of a solid working solution for a real time JSON/YAML-file-export/import solution which I only need to migrate via Git, without writing any functions, code or whatever, solely based on my PW-setup, to make all my instances the same... sure with some checks in the background but... YES... that would be my dream. Still... I want and have to try and test the solution CraftCMS has available. I put my money where my mouth is and start upfront with EUR 500 in the pool. I will post some details of all the features I'd like to have and see in such a module in the upcoming days, maybe a week or two. Yet... whoever wants to join, let me know. In case you want to develop such a module, PLEASE let me know. I guess I want to see this module happen in some kind or another (community or pro module). My goal is... making PW even better. And maybe this could be another step. This thought elsewhere (Added: 2022-01-29):

Hello Seba, yes, this is possible. I have connected the login to our domain controller via LDAP and the control of the authorisations runs via corresponding groups. (Customized Version of this Module: https://github.com/conclurer/LdapSignIn ) in general, its just a normal website with access protection ?

Hi, @Jan Romero is right, if you only want to calculate the difference between two years, the first solution will work but, if you want to calculate the number of years between a specific date and today, then, as easy to achieve with php but switch to date_create() and date_diff() <?php $start = date_create('1980-07-01'); $today = date_create(date('Y-m-d')); $diff = (array) date_diff($today, $start); echo $diff['y']; the result will change every 1rst of July, a simple way to calculate an age and not only the difference between two years just print_r($diff) if you want to see how far you can go with what you get and could display with date_diff ? have a nice day

The problem: Synchronizing fields and/or templates made on the dev server with the live server is cumbersome. At the same time, there is no version control of fields and templates, which some folks (including myself) see as a disadvantage of ProcessWire. A way to have version control to track changes and replicate automatically would be desirable. There is the template and fields export feature in ProcessWire which has said for ages that this is only a beta version, although I have used it many times without any problems. However, even with this method, it is very cumbersome to reconcile changes between dev and live. You have to remember which fields / templates you created and select them, then copy and paste them on the dev server. This is a manual, cumbersome and time consuming process. Existing solutions: For this reason, several solutions have been developed such as: Migrations by @LostKobrakai https://processwire.com/talk/topic/14603-rocksvn-brings-version-control-to-your-fields-templates/ ProcessWires Template's and field's export function https://processwire.com/modules/rock-migrations/ https://processwire.com/talk/topic/25307-oh-no-not-another-migration-module/ https://processwire.com/modules/auto-export-templates-and-fields/ Other systems like Laravel, Craft, Kirby and Statamic use configuration files (migrations, YAML) to manage fields / templates, which allow to create a state of fields / templates. Since the configuration is done in a file, you can of course manage it with git (or other vcs). By configuring in a file, it is also possible to automatically execute these migrations during a git push through different deploy pipelines like github actions, buddy, bitbucket pipelines and thus you have the desired state on the desired server. Where to go from here? In another post @bernhard showcased a prototype, that uses a YAML-file to create and manage fields / templates in ProcessWire. At the same time he showcased a YAML recorder which writes all changes that are made to templates and fields into a YAML file, which looks very promising. I think a combination of a recorder and a YAML config file would be a optimal solution, at least for me. What format to use for such a configuration file was and has also to be discussed: Update 30th September 2022: Until we might have a native method for migrations, I encourage you to checkout the great RockMigrations module. With the module you can have one or multiple migration files, that handle all the stuff mentioned above, like adding fields, adding templates, creating pages with content and setting roles. As the migrations are file-based they are also version-controllable. This makes it easy to work on a feature in a different branch which requires to have other fields/template than in the main branch. Now you can switch between branches and always have the required fields and templates. This is a huge time and workflow improvement. @bernhard steadily improves his module, and me and other contributors try to enhance it, or give feedback.

I've been interested in sharing my setup since it's radically changed over the last year for the better. Wish I could open the repo for the code of my flagship project, but it's the site for the company I work for and isn't mine, www.renovaenergy.com Local Dev: Code editor is Sublime Text tuned for my preferences/workflow. OS is Ubuntu Linux, will probably distro-hop at some point like Linux users do. Environment is provided by Devilbox, which I can't recommend enough. It's a fast (mostly) pre-configured yet customizable Docker tool with outstanding documentation. A ProcessWire ready container is available. CSS/JS compiled by Gulp/Babel/Browserify for local dev and production builds. ES6 modules. Zero frameworks, no jQuery. Focus on lightweight JS and code splitting for better load times. CSS is compiled and split into separate files by media queries which are loaded by browsers on demand based on screen size. Currently building out website unit/integration tests using Codeception. This is becoming increasingly necessary as the site becomes more complex. Firefox Developer Edition Tilix terminal emulator, Quake mode is awesome Cacher stores code/scripts/configs in the cloud for easy sharing across machines. IDE integration is solid Meld for fast diffs WakaTime because who doesn't like programming metrics for yourself? DevDocs but locally in a Nativefier app. REQUEST: Star ProcessWire on Github. If a project has 7k+ stars it is a candidate to have it's documentation added to DevDocs. Production: Code editor is Vim on server Deployment is via Git. Local repositories have a secondary remote that pushes code to production via a bare GIT repo which updates assets on the server using hooks. Access to server via SSH only. Changes to files only made locally and pushed. Hosting by DigitalOcean with servers custom built from OS up for performance/security. Custom PageSpeed module implementation. Automatic image conversion to webp, file system asset caching, code inlining, delivery optimization, cache control, etc. Driven down TTFB <=500ms on most pages with load times around 2 seconds sometimes less if I'm lucky haha StatusCake monitors uptime, automated speed tests, server resources, and HTTPS cert checking. PagerDuty is integrated with StatusCake so issues like servers going down, server resources (ram/disk/memory) low, and whatever else get notifications on all your devices. 7G Firewall rules are added to the PW .htaccess file to block a ton of bots and malicious automated page visits. Highly recommended. Mailgun for transactional email ProcessWire Modules & Features: Modules (most used): CronjobDatabaseBackup, ProFields, Fluency, ImageBlurHash, MarkupSitemap, PageListShowPageId, ProDevTools, TracyDebugger, ListerPro, ProDrafts Template cache. We used ProCache initially but saw some redundancies/conflicts between it and PageSpeed tools on the server. Would absolutely recommend ProCache if your hosting environment isn't self-managed. All configurations are saved in .env files which are unique to local/staging/production environments with contents stored as secure notes in our password manager. This is achieved using the phpdotenv module loaded on boot in config.php where sensitive configurations and environment-dependent values are made securely available application-wide. Extensive use of ProcessWire image resizing and responsive srcset images in HTML for better performance across devices. URL Hooks - Use case- We rolled out a Web API so external platforms can make RESTful JSON requests to the site at dedicated endpoints. The syntax resembles application frameworks which made development really enjoyable and productive. The code is organized separately from the templates directory and allowed for clean separation of responsibilities without dummy pages or having to enable URL segments on the root page. Also allowed for easily building pure endpoints to receive form submissions. Page Classes - My usage -This was a gamechanger. Removing business logic from templates (only loops, variables, and if statements allowed) and using an OOP approach has been fantastic. Not sure if many people are using this but it's made the code much more DRY, predictable, and well organized. Implementing custom rendering methods in DefaultPage allowed for easily "componentizing" of common elements (video galleries, page previews, forms, etc) so that they are rendered from one source. Helped achieve no HTML in PHP and no PHP in HMTL (with the exceptions above). Also allows for using things like PHP Traits to share behavior between specific Page Classes. I completely fell in love all over again with PW over this and now I couldn't live without it. This literally restructured the entire site for the better. Probably other stuff but this post is too long anyway haha.

Switched all my personal sites to the latest dev branch last week (after accidentally updating the server from PHP 8 to 8.1 — whoops...) and have had no issues — as far as I know — so far. Apart from a few minor ones (deprecation warnings) related to PHP 8.1, but those are already reported via GitHub. I'd say that it seems pretty solid so far ?

This API ref page is pretty low level — so yes, the core does (by default and automatically) track changes made to pages, but it's mainly for checking if a specific Page object was changed during this particular request. The core itself doesn't maintain a log of changed pages, that's usually where modules step in. I'm not entirely sure what this module is; you're not referring to Activity Log, are you? Anyway, a module that tracks changes should be able to keep track of changes made via API as well, with just one exception: if the API request is made with the noHooks option enabled, no module will be able to track that. In other words API requests alone are nothing special, so they should be tracked normally, unless the one triggering said API request is specifically preventing any hooks from running, in which case there's no (clean) way to intercept or track it ?

I'm not sure if I correctly understand what you want to track and how, but there is this module that may provide what you are looking for: https://processwire.com/modules/process-changelog/ Besides a paginated logpage in admin it also comes with an additional RSS feature:

Tracy was useful in testing out what I'm trying to achieve. I'm trying to get away from copying and pasting though. I used the Tracy console, and this code is on the track of what I want: $modulePath = $config->path('MyModule'); //moduleFields is an array of field names foreach($moduleFields as $fieldname){ $testField = $fields->get($fieldname); $data = wireEncodeJSON($testField->getExportData(),true,true); $file = $modulePath . 'data/fields/'. $fieldname . '.json'; file_put_contents($file, $data); } This gives me a nice directory of field definitions that are required by a given module. ProcessWire already handles module dependencies including module versions with the requires property in getModuleInfo(), so if I define fields that are used in multiple places in a base module and specify that as a dependency of other modules that install other fields, then I can make sure I end up with all the fields that I need. Because I'm using a manually created array of field names, if there are fields that depend on other fields, I can list them in the right order to satisfy dependencies. Fields like page reference fields can depend on a template as well, so my array might need to specify both object name and type to install all the dependencies in the correct order, but I think I'm on track to being able to build a reproducible configuration I can easily deploy to multiple sites. I think it might not be too hard to build and admin module to provide a UI to build the dependency configuration files for custom modules either, as ProcessWire already supports adding and reordering items in lists in various Process modules. Edit: The reason I'm outputting one JSON file per object rather than just one big JSON file as the built in exporter gives you if you select multiple fields, is that I think it will be better for source version control, especially if a modified timestamp property is implemented for fields, and if there's a need for multiple collaborators on a project. Unmodified object definitions don't need to be regenerated. Additional Edit: Usually a module provides some kind of functionality, but there's no reason why a module can't just exist to install/uninstall a bunch of fields and templates, and otherwise just sit dormant. If it's not an autoload module, it's not going to do anything unless it's called from somewhere, and a module seems like a good way to encapsulate a whole lot of stuff. With the right design around dependencies and inheritance, it should be possible to change 'skins' or 'themes' for a site; something that's not possible with site profiles, as they're basically just a dump of a specific site state. eg, you could have baseModule that installs xyz fields and templates, then themeModule1 and themeModule2 that each provide different front end presentation, but depend on baseModule, so there can be certainty that all the fields they need exist.

Hello Zoeck! Thanks for responding so quickly. You have given me excellents news! ?

Hello ! Thank you for this very nice module @dadish I'm trying to get the ProField RepeaterMatrix to work based on this fork here by Tulios link. But I'm having a hard time, struggling for some days deciphering the complex GraphQL architecture and logging everything in the console haha I really would like to use it like this screenshot below, with fragments for every repeater matrix types. The main issue I have is I can't find a way to build the list of every possible templates types. The way RepeaterMatrix works is it is differentiating the types based on the repeater_matrix_type. It doesn't seem to work with templates. I tried to use the constructor `new Template()` to create some based on this property but I don't know where to add this line. Also should I create a new RepeaterMatrixPageArrayType based on your PageArrayType? Any chance you would take a look? I know it's a ProField, but if you got some time I would be very grateful

The latter one. The very first two versions used the former option, but it turned out it is hard to maintain and even harder to grasp. Using config based migrations it's simply copy&pasting field config data from tracy to a migration file and you instantly see what the migration does (and you get a diff view via git). Correct Where does this array come from? This sounds a bit like you are starting to understand RockMigrations... ? It would be nice if you could provide more details on that point. What did you do? How did you do it? What did you try to do? etc

TBH I totally forgot about the Export/Import feature of templates and fields until I have read about it here again. My workflow was to have two windows open (developement and staging/production) and manually rebuild fields I have created in my development environment. But export/import is way easier. Thank you for reminding me. Maybe this feature should be more prominent with additional buttons at the beginning of the overview for people like me who don't look at the end of the page. ? As for the other discussed solutions: A JSON/YAML solution would also be great for version control, but for me it would not be necessary, because in my experience the gap between development and staging/production is not that large. But for large websites this could be handy.

Hi, wouldn't you want to calculate the $diff with the unformatted timestamps and just output the result in 'Y' Format? (Or I misunderstand the use case.)

That sounds solid and reliable. I'd almost bet on this but it never worked out somehow. But could have been right after this feature was introduced. Can't say for sure. Never tried it since or at least for a long time.

FIELDS first! TEMPLATES second! CONTENT last! Even if you want add two new templates at once with a family relation like parent <>child, you paste in the JSON on the import site, it tells you about the conflict after inspecting. The solution is simply to run the import twice (two times). That is already supported by the importer.

I did, this week. Not for the very first time, but for the very first time within a very real project. It worked. Until it became complicated in some ways and I had to change, switch, move, re-add, and so on. It took me about 2 hours to get things done I normally do within 10 minutes. Yet... that was on purpose. I wanted to try it again but on the other hand I have had a time-limit. I guess RockMigration can do this, but I don't know how yet, but... how could I export an existing set of fields, templates, individual settings from an existing setup into an RM-script? My favourite goal would be... installing RM into a lot of existing projects, create RM-export scripts that put everything into a PHP (or whatever) files I can use later on to re-import/re-migrate into a new project. So I could build up some kind of library for cases I always need. Is there a RM-function that allows me to export all fields, templates, and field/template settings into an RM-PHP? In case this sounds weird, I'd understand. So... maybe... just drop me a message with "You are weird!" better though... a message with "Yes... (but)... look here... use this function here and there". I somehow start to understand this module. Even though it's way out of my comfort zone.

You can copy it directly from Tracy when viewing a field's settings. Does that help?

Thanks, should be fixed in v0.2.2

Hi @neophron, Apologies for the late response. This is a bit of a cop-out answer, but there are no prescriptions for srcset/sizes. What is right is whatever works best for your use case. The only way to get there is to experiment. That said, perhaps this is what you should do? <?php echo "<img class='photo' src='{$slide->size(760, 0, $options)->url}' srcset='{$slide->url} 2x' alt='{$slide->description}' loading='lazy'>"; Regarding the 'orientation: portrait' sizes attribute - this isn't to do with the image's orientation, it is the device orientation. You can use it to specify a size profile for this e.g. <?php // Render an image using custom set rules and sizes // These rules will render 'portrait' versions of the image for tablet and mobile // Note the advanced use of the `srcset` option passing both `rules` and image `options` // WebP is disabled // Picture is disabled echo $image->render([ 'srcset' => [ 'rules' => '320x569, 640x1138, 768x1365, 1024, 1366, 1600, 1920', 'options' => [ 'upscaling' => true, 'hidpi' => true, ], ], 'sizes' => '(orientation: portrait) and (max-width: 640px) 50vw', 'picture' => false, ]); // <img src='image.jpg' alt='' srcset='image.320x569-srcset-hidpi.jpg 320w, image.640x1138-srcset-hidpi.jpg 640w, image.768x1365-srcset-hidpi.jpg 768w, image.1024x0-srcset-hidpi.jpg 1024w, image.1366x0-srcset-hidpi.jpg 1366w, image.1600x0-srcset-hidpi.jpg 1600w, image.jpg 1920w' sizes='(orientation: portrait) and (max-width: 768px) 50vw' loading="lazy"> I'm not 100% myself on how the above actually works, but it provides '2x' portrait images for small portrait devices e.g. mobile. If there's one bit of advice I'd give with srcset, it is keep it simple! I hope that helps. Cheers, Chris

well if you want a dynamic code depending on an entry, yes you will ? your hanna code tag could accept either [[count_years]] or [[count_year startyear="1920"]] in this case you can just start your hannacode with a default value $start = $startyear != '' ? $startyear : 1980; this way you cover both insertion, with and without attribute and my pleasure ? have a nice day

Thx for the feedback. I guess many who are having your painpoint are missing RockMigrations because of this reason... I've updated the first post of RockMigrations with an easy step-by-step guide:

Since these tags are introduced by CKEditor you know they’ll always be there and always look the same (I guess). So you can pretty much just count how many characters you want to skip at the beginning (3) and end (4) and do it without ever mentioning anything about <p> and </p> to PHP: $bodyCopy = mb_substr($pages->get("/nastavitve/")->kontaktni_podatki, 3, -4); Or you can go the replace route: $bodyCopy = mb_ereg_replace('^<p>|</p>$', '', $pages->get("/nastavitve/")->kontaktni_podatki); Note how using mb_ereg_replace you don’t need those annoying slashes. The regex ^<p>|</p>$ just means, “find a <p> at the beginning OR a </p> at the end”, so this leaves all the inner p-tags alone. You can get more fancy if you need to take into account all the ways a HTML tag might appear, but eventually you’ll get into this territory. There is also the ol’ strip_tags function and ProcessWire ships with a Textformatter module called ParagraphStripper, I believe. As well as HTMLPurifier if you really want to get your hands dirty.

ok so i edited ImageType.php and added webp as a pageimage field then i was able to pick it up from the configuration, looks like it works