Leaderboard

This week ProcessWire 3.0.214 is on the dev branch. Relative to 3.0.213 this version has 16 new commits which include the addition of 3 new pull requests, 6 issue fixes, a new WireNumberTools utility class, and improvements to various other classes. A newly added $files->size($path) method was added which returns the total size of the given file or directory. When given a directory, it returns the size of all files in that directory, recursively. Improvements were also made to ProcessWire's log classes (WireLog and FileLog) with new methods for deleting or pruning all log files at once. This version also fixes an issue with the front-end page editor (PageFrontEdit) when used with InputfieldTinyMCE. For more details on these updates and more see the dev branch commit log. Something else I've been working on this weekend is a vulnerability scanner blocker and throttler. I don't know if this is an issue for every site, or if it's because this is an open source project site, but we seem to get a lot of vulnerability scanner bots hitting the site. Sometimes they hit the site pretty hard (with hundreds of thousands of requests) and our AWS cluster servers and databases must scale to meet the demand, using more resources, and thus increasing cost. This is annoying, having to scale for a hyperactive vulnerability scanner rather than real traffic. And it always seems to happen in the middle of the night, when I'm not nearby to manually block it. So I'm working on a module that detects vulnerability scanner traffic patterns and then blocks or throttles requests from their IPs automatically. Once I've got it functioning smoothly here, I'll also plan to add it to ProDevTools board download thread in case it's useful to anyone else. Thanks for reading and have a great weekend!

WebP to JPG Converts WebP images to JPG format on upload. This allows the converted image to be used in ProcessWire image fields, seeing as WebP is not supported as a source image format. Config You can set the quality (0 – 100) to be used for the JPG conversion in the module config. Usage You must set your image fields to allow the webp file extension, otherwise the upload of WebP images will be blocked before this module has a chance to convert the images to JPG format. https://github.com/Toutouwai/WebpToJpg https://processwire.com/modules/webp-to-jpg/

I oftentimes create a checkbox field called 'test' and assign it to certain templates. I check the box if the page is a test page. These pages may exist on the live site and I don't want to hide or unpublish them, but at the same time, I don't want them to appear in the XML Sitemap. (not part of this tutorial, but I also noindex,nofollow those pages using a meta tag in the head so search engines don't index them) In that case, you can remove them from the WireSitemapXML like this in /site/ready.php: $wire->addHookAfter('WireSitemapXML::allowPage', function(HookEvent $event) { $page = $event->arguments('page'); if($page->hasField('test') && $page->test) $event->return = false; });

TL;DR Just copy this folder to your module and get fully automated releases, tags, changelog and with one additional line of code (see note below!!) also fully automated version numbers for your PW modules! Background/long story: @dotnetic asked me some time ago to use conventional commits for my modules. It was totally new to me, here is the link: https://www.conventionalcommits.org/en/v1.0.0/ I've since adopted that workflow to most of my modules, as it is really just copy and pasting the .workflow folder (and you can simply copy that folder from RockFrontend: https://github.com/baumrock/RockFrontend/tree/main/.github/workflows) This workflow is great, because It will create new releases automatically for you: https://github.com/baumrock/RockMigrations/releases It will create new tags automatically for you: https://github.com/baumrock/RockMigrations/tags (This is something that I always forgot and someone was asking for it long time ago, because tags are important if someone uses composer to manage their modules, as far as I understood. Now I can't forget them any more ? ) It will create a changelog for you automatically: https://github.com/baumrock/RockMigrations/blob/main/CHANGELOG.md And last but not least: It will create version numbers automatically for you. One thing that has always been annoying though is that you have to make sure that the version number that is automatically created matches the version number that you set in your modules .module.php or .info.php file. I have always tended to have everything in my .module.php file, but I just recently noticed that this can lead to problems if you are using PHP8 syntax in your module and the website still runs on PHP version <8 --> You end up getting a fatal error whenever the module is loaded, which totally breaks ProcessWires module backend. The solution is easy though: Just split your module config into two files - the .module.php with all the module's logic and the .info.php file with only the array that defines the module's info array. Thx for that reminder @BitPoet! Here is the HelloWorld's info.php file with some helpful comments: https://github.com/ryancramerdesign/Helloworld/blob/master/Helloworld.info.php I did that today for RockMigrations and I realised that you can even fully automate the version numbering of your module, because the conventional commit workflow creates a package.json file that holds the version number in a json string: https://github.com/baumrock/RockMigrations/blob/main/package.json All you have to do is to grab that json string and write that version into your module's info.php file: https://github.com/baumrock/RockMigrations/blob/92a33ba4e7146a69fb1f52d5b67270b66d9f1e54/RockMigrations.info.php#L5-L9 Afraid of a performance penalty? You don't have to. The module's info is cached by PW and only updated on modules::refresh! Maybe other module authors like @adrian or @Robin S or @kongondo or @teppo or @netcarver or @Macrura or @flydev want to adopt that workflow as well. Thx for reading and have a great weekend ?

Template Access Log is a straightforward module that logs changes made to template level access settings: the useRoles option, or applicable roles and/or role-specific permissions. This module is primarily intended for use cases where an audit log is needed, and (at least for now) it just logs data to a log file template_access_log.txt and provides no admin view (apart from what can be found from the logs section in admin). Data is logged as JSON: 2023-03-18 18:42:05 admin https://example.com/processwire/setup/template/save {"template":"basic-page","template_id":29,"use_roles":1,"permissions":{"view":[37,1061,1062,1125],"edit":[1062],"add":[1061,1062],"create":[]},"permissions_changed":{"edit":[-1061]}} This is something that I needed for some projects, so thought I'd share it here in case someone else has use for it as well. I may add more features later, but at the moment it's already doing pretty much everything it needs to for my use case(s) ? GitHub: https://github.com/teppokoivula/TemplateAccessLog Packagist: https://packagist.org/packages/teppokoivula/template-access-log

@wbmnfktr Have you given Jeffrey Star's 7g firewall a try? Very simple install straight into your .htaccess file.

Most likely this commit in ProcessField.module (now) at line 2562 - $value = $sanitizer->words($value); + $value = $sanitizer->getTextTools()->strtolower($sanitizer->words($value));

Sure, I forgot to mention that I've also added the suggested fix and it works for me on 3.0.214 ?

Hey @Richard Jedlička am I missing anything or are you asking for a PR to remove one slash in one file as @szabesz already explained? I think it would be less effort if you just changed that file yourself (you could do that even in the browser) than having someone make a pr and approve and merge that ?

Hey @flydev it's a nice theme, just tried it again as I'm getting more used to dark mode in general. I'm not sure about how we should approach this. I think before we ask module developers to adopt to our workflow we'd need to find a solid workflow for ourselves and find standards that we can agree on. For example it seems that your style does not use my rock-primary convention? Also why are you suggesting SCSS when the module and AdminThemeUikit use LESS for everything? Here's a project with your style: And here it is with my style: What I find great about the rock style is that I can simply set a primary color in the module's settings and the backend instantly fits to the clients CI: Your module has this yellowish primary color which in my case should be #00bb86 ? Another thing is that my PageBuilder uses SVGs for showing available content elements: I'd not be extremely happy if I had to add support for dark themes here. But that's obviously only a topic of lazyness efficiency ? I'm happy that you try to move forward here and I agree that module authors should provide the stylesheets for supporting dark styles. But I also think we should make it as easy as possible so that it's as little effort as possible.

Thanks for the reply, I was going to push and see if the modules dir was grabbing the version. Reverting it ? To Ryan: please let’s the modules dir taking care of the field `version` of the package.json file, if present. And just sayin, it will also be a time saver for some profiles using npm at the same time ?

Hey @flydev great to hear that ? Unfortunately there is an issue with my approach of reading the version number from the json. It will break the version number in the PW modules directory (as you mentioned). I've asked Ryan to make the modules directory grab the version from package.json if it does not find a version in the info file/method. Hopefully he will add that. The workflow is a huge time and brain saver for me every day. See https://github.com/processwire/processwire-issues/issues/1690 I'm also using this approach now not only for my modules but also for the project's main repository. It's great. I push to dev and github deploys the site to staging. I push to main and github creates a new release and then pushes that release to production ?

@ryan maybe this could help: https://www.phpclasses.org/package/12821-PHP-Detect-and-block-spam-bots-from-accessing-sites.html

@bernhard I made a little tweak to the rf-scrollclass script. Okay it was not me directly. Instead I asked a certain AI if it is possible to alter the script... just for scientific purposes of course ? I want to add multiple rf-scrollclass attributes to one DOM element: <header class="rf-scrollclass" rf-scrollclass="scrolled@20 scrolledmobile@15"> Now the class "scrolledmobile" gets added at 15px, the "scrolled" class gets added at 20px - all on the same element. This gives me the ability to use css media queries for some responsive tweaking of the position of my fixed navbar (for example!) header { position: absolute; top: 40px; width: 100%; z-index: 100; @media @min-m { &.scrolled { top: 20px; position: fixed; } } @media @max-s { top: 30px; &.scrolledmobile { top: 15px; position: fixed; } } } Long story short, here's the updated script: (function () { let scrollElements = document.querySelectorAll("[rf-scrollclass]"); for (i = 0; i < scrollElements.length; i++) { let el = scrollElements[i]; let attrs = el.getAttribute("rf-scrollclass").split(" "); for (j = 0; j < attrs.length; j++) { let parts = attrs[j].split("@"); if (parts.length != 2) return; let cls = parts[0]; let y = parts[1] * 1; window.addEventListener("scroll", function () { scrollpos = window.scrollY; if (scrollpos >= y) el.classList.add(cls); else el.classList.remove(cls); }); } } })();

That's because there isn't one yet. I have the search functionality somewhere back in my mind. Promised! I thought I keep it simple. As mentioned above the search functionality will come, yet I'm not sure about which way I go here. For now the whole setup is more a proof-of-concept but we will get there. You are absolutely right about that. For now in an upcoming version I went another route with this as just plain white and shadows didn't work out that well on the eyes as well. I have some thoughts and ideas here to solve this dead end kind of browsing. I guess we will have this next week. Depends on other projects. You can just send a pull request with an updated version of the recipe. There is no rule against several solutions in one recipe. In my opinion this would be actually really awesome to show and tell that there are different ways. So feel free to either submit a new or updated recipe. I really appreciate both! In case you update the existing recipe you want to update the version, if available or give a new one, and add yourself to the authors. I updated the recipe sample here. In case you or someone else need additional data points like ProcessWire min/max versions or similar. Just add it to the recipe, let me know in the PR and we get it sorted. Thanks guys for all the great feedback and ideas!

https://github.com/elabx/FieldtypeRecurringDates Well a few summers later, finally got like a sort of working version. For info please take a look at the repo's readme. It's still super alpha but going to deploy into a couple websites to replace Recurme so wish me luck. This module is only a Fieldtype and Inputfield, there are no "markup" modules as there used to be in Recurme. I'd appreciate any testing or any kind of comments.

I also sort of have this scenario and decided to use separate Time fields to indicate start and end time of each occurrence. I just have to assume that the occurrences have the same time.

Version 2.1.19 contains changes to make the module compatible with PHP 8.2 and following versions. All dynamically created properties have been removed and replaced by a declared property which hold all the properties inside an array. The reason for this is that dynamicalle created properties will be depreciated in 8.2 (leads to a warning) and the will be forbidden in upcoming PHP 9. So, this was a change affecting a huge amount of files. So please test it carefully and report any issues directly on GitHub. IMPORTANT! Due to a writing mistake, there are wrong values inside the database: These wrong values will not be overwritten during the update. It is recommended to uninstall and reinstall the module after the update to be sure that the correct values are stored inside the database. Otherwise it is most likely that you will get an error after a form submission. Just to mention: the error is in the fieldname of the custom messages: instead of the field name "input_alertErrorText" and "input_alertSuccessText" I have written "input_input_alertSuccessText" and "input_input_alertErrorText". This causes an error after form submission. Thanks a lot!

This week the focus was on core updates and we have a quality mixture of minor issue fixes, pull request additions, and other improvements in ProcessWire on the dev branch. My favorite addition was from a PR by @matjazp that makes improvements to ProcessWire's pagination module, MarkupPagerNav. See more updates and PRs in the dev branch commit log as well. There's still more to add before we bump the version to 3.0.214, so stay tuned for that next week. By the way, if you've recently launched any new sites in ProcessWire, please add them to our sites directory. I think most of us are already subscribed to the ProcessWire Weekly email, but just in case you aren't, you can subscribe here. The email content is from weekly.pw written by @teppo and is great to read, highly recommended! Thanks and have a great weekend!

Yes, but I haven't received it for quite some time now. ?

The main ideas behind this update are Migrating the frontend to a "reactive js framework" which I think simplified the frontend code A LOT. So the UI is powered by Alpine.js. Migrating the database schema to use Date column to store event occurrences as data, not as text within one row. Not sure if warn people that this could get out of control easily in the sense that you could store whatever thousands of pages the computer can handle lol. The data can now be queried by the date column and it uses the regular date selectors we are used to, you can also paginate the results of each occurrence definition and it will paginate them form the dabase, making it more efficient in general than how it was built previously. So you can to something like: $page->recurring_dates_field('start=20, limit=100')

This is done as a regular Fieldtype under a `data` column, it basically looks like a Datetime field db table, and there is a secondary table that saves the field settings in terms of UI state. I might need to still to a bit of cleanup in this because I was going to include an "exclude" boolean column, to skip specific dates in an occurrence rule, but I am thinking of changing that approach. I set a hard limit through either count limit, or a date. This is basically a limitation of the php-rrule library itself, as you WILL end with an infinite loop if either COUNT or UNTIL parts of the rule are not set. So if I remember correctly now, the module should even throw an error if you try to save something without one or the other value. I want to implement a "Never" option, but the only way I can think of it is to depend on a hidden hard limit, and a async task that "recalculates the rule" in the database. In the previous module it didn't recalculate, it just assumed you'd never reach the 50k iteration of the occurrence lol, I'm surprised it has actually worked pretty well until now.

To be honest this wasn't a very conscious decision it just felt kinda odd to define it within the Fieldtype module? I also though of it to be able to combine with other Date module fields through a hook in the finder, I'll set an example as soon as I can too, since this definitely needs documentation. Yes I will upload a GIF as soon as I can! I'm not sure there is a lot to say?? In general I feel it's overall regular Fieldtype/Inputfield development. Which took me some time to grasp lol. (Thanks @MarkE for your fieldtype breakdown!). Also de UI is built with Alpine.js. And the heavy lifting (calculating the occurrences) is done by php-rrule. Ok after writing this I'm thinking it might be worth to explain myself a bit more haha. Thanks mate!

Great to see someone tackling this ? I wish you all the best for the challenge ? Do you have some screenshots? And maybe a short description how the module works from a technical point of view? Why did you split the finding part in a separate module?

I want to show you a project that I started developing in summer of 2022 and that went online in january 2023. Kulturhaus Wilster ("Arts Centre Wilster") https://www.kulturhauswilster.de The Kulturhaus Wilster - also called "Wilster's living room" by many visitors - is a socio-cultural center in the heart of Wilster. Wilster is a small City located north from Hamburg, germany. Despite the fact that this is a small venue they offer large amount of events. The events range all the way from concerts to theatre and everything inbetween! The old version of the site was a super simple WordPress website in a black-and-white only color scheme. In my opinion it did no justice to the very colorful program that the Kulturhaus offers so I tried my best to bring some color into the game. The whole website should have a shabby-chique look combined with clean, modern elements. The Homepage offers a preview of the next 8 upcoming events. A blog section is also included and the latest post is displayed next to the event calendar book as PDF download. The event pages offer a quick-reservation form (tickets are not sold online) and a quick look to the next upcoming events in the sidebar. The website features a large event calendar. It was a really nice exercise in using ProcessWires very own paging and selector features. Events can be searched and filtered by type (and month), too. All with a few lines of code only. For example "Look for events that take place in the future in a specific category" $events = $pages->find("select_event_cat.title~|%=$c, template=event, date_event>=today, sort=date_event, sort=time_from, limit=6"); Besides that the website features some colorful content pages with large images, galleries, textboxes and some teaser elements. The editors of the website are able to display all facets of the Kulturhaus this way. Tech Talk: Frontend Framework is Bootstrap 4.6 ProcessWire Modules used on this one are: - WireMail: SMTP (https://processwire.com/modules/wire-mail-smtp/) - SEO Maestro (https://processwire.com/modules/seo-maestro/) - All in one minify for asses (https://processwire.com/modules/all-in-one-minify/) - PageImageSource for webp image srcsets (https://processwire.com/modules/pageimage-source/) - JkPublishPages is used for time-controlled publishing of the blog posts. Please check out this module! Thanks @Juergen - @bernhards great RockFrontend was also used. In this particular project only the autorefresh feature (because this module was brandnew back then and development of the page was almost done). But even "only" using autorefresh makes it worth using it! Please have a look:

@flydev any news about this project?

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

@flydev ?? - sorry for the mention, but are we going to have this module soon ?

Ping