Leaderboard

I have to stop a day early to leave town for one of my daughter's gymnastics meets, so I'm going to save the core version bump for next week, after a few more updates. The most interesting core update this week is one suggested by Netcarver and Pete. It is to make the "HTML Entity Encoder" Textformatter option (for text fields) more foolproof, by making it harder to ignore. That's because this option is rather important for the quality assurance and security of your site's output. If you forget to enable it for one text field or another, then you allow for the potential of HTML in the output for that field, by anyone that can edit pages using that field. Most of the time when you aren't entity-encoding output, HTML is exactly what you want, such as with TinyMCE or CKEditor fields. HTML entity encoding is necessary when the field value isn't itself HTML, but will eventually be used in HTML output and needs to be valid for HTML output. Think of a "title" field, for example. For these cases, you want to be sure that characters like greater than, less than, ampersand and single/double quotes are properly encoded. Greater-than and less-than characters form HTML tags like <script>alert("gotcha!")</script>, ampersands begin entity sequences, and quotes are used to open and close HTML attribute values. By entity encoding all of these characters, we ensure they can't be used for malfeasance, scripts, XSS, defacement, etc. The worst case scenario would be that you neglect to enable the entity encoding on a text field where you are allowing non-trusted user input, as that could open the door to such shenanigans. To make things more foolproof, ProcessWire now gets in your face a bit more about using the HTML Entity Encoder. Maybe it's a bit more annoying for more experienced users, but if you happen to be in a rush, it'll make sure you at least don't forget about it. Or maybe some less experienced developers might not know the importance of entity encoding in HTML, and this update helps them too. Here's what it does: It now enables the HTML Entity Encoder (Textformatter) for all newly created text fields (and derived field types). Previously it just suggested that you enable it, but let you decide whether or not it was appropriate. Now, it errs more on the side of caution. Since the entity encoder is now automatically enabled for newly created text fields (in the admin), it seemed necessary to detect cases where the field configuration clearly indicates it's intended to allow HTML (by input type or content-type). Examples include textarea fields configured to use TinyMCE or CKEditor, or any text field with a content-type set to HTML. When these cases are detected, it advises the user to remove the HTML Entity Encoder from the selected Textformatters. If editing an existing text field (in Setup > Fields) that doesn't appear intended to use HTML (i.e. not TinyMCE or CKEditor and doesn't have its Content-Type set to HTML), it will now test all the selected Textformatters you have selected (if any) and see how they handle HTML. If they leave HTML in place, or you have no Textformatters selected, It will provide a warning to you, letting you know that HTML is allowed, and leave it up you to decide whether that's what you want. Note that these additions are only for fields created in the admin. Fields created from the API make no such assumptions and work the same as before. That's it for this week. More updates and hopefully a version bump next week. Have a great weekend!

Yes, it’s not going to pick up changes to the Fields, because behind the scenes you’re actually adding the Field to the Template’s Fieldgroup. Can’t figure out how to get added fields, but getting removed fields seems to work reliably: foreach(wire('templates') as $template) { /** @var Template $template */ $template->setTrackChanges(Wire::trackChangesValues); $template->setTrackChanges(true); $template->fieldgroup->setTrackChanges(Wire::trackChangesValues); $template->fieldgroup->setTrackChanges(true); } wire()->addHookBefore('Templates::save', function (HookEvent $event) { /** @var Template $template */ $template = $event->arguments(0); bd($template->getChanges(true)); }); wire()->addHookBefore('Fieldgroups::save', function (HookEvent $event) { /** @var Fieldgroup $fieldgroup */ $fieldgroup = $event->arguments(0); bd($fieldgroup->getChanges(true)); //says NULL for added fields, because the previous value of the added field was no field, works well for removed fields bd($fieldgroup->getItemsAdded()); //gives all fields in the set for some reason bd($fieldgroup->removedFields); //this seems to work well }); If you have a use case for this there may be opportunities for PRs here. For example it doesn’t seem reasonable to me that removing a field tracks the change as "removed:<fieldname>" (plus the field itself as the old value) while adding one tracks as "add" without the field name (and no old value, because it was an add).

But pageClass doesn't work on pages. I see you're calling it on $template though. So I think we want to populate "class" on both the page and template info sections which required different approaches. Please try the attached and let me if you're getting what you need in the Page Info and Template Info sections. RequestInfoPanel.php

Hi @bernhard - sure. Any preference?

Hey @adrian could the request info panel please also show the page's pageClass? Or is that information somewhere else? See here, where it's a quite essential information that the current page is of type "\RockCRM\Invoice", which is obvious in the dump but not in the request info panel: Thx in advance!

It seems that the .htaccess file is buggy. I played around with an old version of Processwire what was still working. When the .htaccess was replaced it worked again. Maybe lateron I will look into the problem in the .htaccess Ok. This is awkward. In VSCode my .htaccess file was reformatted this was causing the issue

This module is from Ryan, you don't have to worry about it.

Well, this is embarassing, I did actually try it yesterday and it didn't work, but I tried again this morning and it works just fine now. I don't know what changed - maybe I forgot to save something before. Sorry about that!

This may be helpful for others who are using DDEV inside of WSL2 on Windows... Although Mutagen fixed the page loading problem, it introduced a (lesser) problem of creating a delay between when code is changed and when the change is picked up by the file system. See my post below for the correct solution to both problems. Do yourself a favor and Enable Mutagen! I did not enable Mutagen because the DDEV docs say it doesn't make a difference when using WSL2. IT MADE A HUGE DIFFERENCE for me. Every page request was about 1 to 2 seconds before. After mutagen, it's about 200ms.

You may save an project with the module ProcessExportProfile for a new installation. Open Export Site Profile under Administration. Create a new profile in the input mask. Copy this /site folder (site-yourprojectname) into the installation folder before a new installation, select your site profile, that's it. Everything is included, only own files like ready.php … are not included, have to be transferred manually.

Hello everyone! Recently I wrote these scripts for TracyDebugger console in order to make work with RepeaterMatrix easier and faster. I want to present them to the community. Show relationship between all types, names and labels. $repeaterMatrixModule = $modules->get('FieldtypeRepeaterMatrix'); $fieldName = 'content_blocks'; $repeaterMatrixField = $fields->get($fieldName); $typesArray = []; foreach($repeaterMatrixModule->getMatrixTypes() as $matrixName => $matrixType) { $typesArray[$matrixName] = $matrixType . ' ' . $repeaterMatrixModule->getMatrixTypeLabel($matrixType, $repeaterMatrixField); } db($typesArray); Show all pages which have specific type in field (repeater_matrix) with this name: $repeaterMatrixModule = $modules->get('FieldtypeRepeaterMatrix'); $typeName = 'block_text'; $fieldName = 'content_blocks'; $repeaterMatrixField = $fields->get($fieldName); $typeId = $repeaterMatrixModule->getMatrixTypeByName($typeName, $repeaterMatrixField); $typeLabel = $repeaterMatrixModule->getMatrixTypeLabel($typeId, $repeaterMatrixField); $pagesWithType = $pages->find("{$fieldName}.type={$typeName}"); db($pagesWithType); db($typeLabel, 'Name of type'); This list can be continued as soon as I'll invent more scripts.

No, not all. Only all the things that should be the same across all your setups ? That's a small but important difference. You can still use the GUI if you want to. But that means that you need to apply those changes manually to all other instances of your project as well. The thing is: Those changes are really really easy once you get used to it. 90% of the time it's setting the 'label' property or the 'columnWidth' setting of a field and adding fields to templates. Using the snippets for VSCode is definitely a huge help. Without them creating fields would be a little pain ? If anybody knows how that feature can be ported to other IDEs let me know! But if something is very complicated using RockMigrations you can still use the old-school way of making those changes manually! For example you could create some fields on the remote system and create some pages, then pull the database changes to your local development and just add all the easy stuff to migrate.php PS: Many of the settings I do not know by heart as well. But it's most of the time quite easy to find them by hovering the inputfield: PPS: I'm quite sure that finding the setting and writing it to migrate.php is faster than doing that manually on local dev and then replicating that change on the live system. It get's even better once you use multicursor in your IDE to set for example 3 fields to 33% width!

In case you are looking for a nice and easy replacement for Pages2PDF as you might face problems with it due to PHP 8 - this might help you to get started and helped me today to get a site up and running again. Thanks to @bernhard for this module. <?php namespace ProcessWire; // file: templates/invoice.php $pdf = $modules->get('RockPdf'); $pdf->settings([ 'mode' => 'utf-8', 'format' => [210, 297], 'img_dpi' => 300, 'default_font' => 'DejaVuSans', ]); // Pseudo header $pdf->write(wireRenderFile('pages2pdf/_header.php')); // Footer $pdf->set('SetHTMLFooter', wireRenderFile('pages2pdf/_footer.php')); // Body content $pdf->write(wireRenderFile('pages2pdf/invoice.php')); // Styleshee $stylesheet = file_get_contents('pages2pdf/pdf.css'); $pdf->write("<style>$stylesheet</style>"); // Actions $pdf->show(); In this example I re-use my already existing pages2pdf-templates and even CSS. It's a super simple PDF, so I really don't have to deal with page margins and such in this case. So you might want to read the docs of mPDF and RockPDF to get this working in your project. There is a lot more you can do in terms of settings and such which can be found in this post for example:

FWIW I have made a little work-round that saves $template->getExportData() as a session var on 'ready' then compares it with the changed value, hooked in 'saved'. It seems to work, but there must be a less clumsy way. trackChanges etc is not very helpful.

@bernhard Thanks! ? I was looking for a nice way to compile some SCSS (Bootstrap in my case) the other day and as Sassify has not been updated for almost 4 years I had a look into your Scss module. It might not have been your intention, but as this a viable wrapper for scssphp I could use it for my case as well. Maybe this can be a starting point for somebody else looking for a way to compile something else than the PW core: <?php $compiler = $modules->get('Scss')->compiler; $input_scss = $this->wire->config->paths->templates."scss/custom.scss"; $bootstrap_scss_path = $this->wire->config->paths->templates."bootstrap/scss"; $output_css = $this->wire->config->paths->templates."css/bootstrap_custom.css"; $output_map = $this->wire->config->paths->templates."css/bootstrap_custom.map"; $compiler->setSourceMap($compiler::SOURCE_MAP_FILE); $compiler->setSourceMapOptions([ // relative or full url to the above .map file 'sourceMapURL' => $output_map, // (optional) relative or full url to the .css file 'sourceMapFilename' => $output_css, // partial path (server root) removed (normalized) to create a relative url 'sourceMapBasepath' => $this->wire->config->paths->root, // (optional) prepended to 'source' field entries for relocating source files 'sourceRoot' => '/', ]); $compiler->addImportPath($bootstrap_scss_path); $compiler->setOutputStyle("compressed"); $result = $compiler->compileString('@import "'.$input_scss.'";', $this->wire->config->paths->templates."scss"); file_put_contents($output_map, $result->getSourceMap()); file_put_contents($output_css, $result->getCss()); ?>