Leaderboard

I couldn’t resist the hype and created a simple module using the ChatGPT API to process field values. You can find it on GitHub here: https://github.com/robertweiss/ProcessChatGPT ProcessChatGPT is triggered upon saving, if you select it in the save dropdown. It processes the value of a page field, which can be set in the module config, using ChatGPT. The processed value can be saved back to the same field or to another field on the same page, which can also be set in the module configuration. You can add commands to the value that will be prefixed to the source field content. This way, you can give ChatGPT hints on what to do with the text. For example, you could add ›Write a summary with a maximum of 400 characters of the following text:‹. One of my clients is already using the module to summarise announcement texts for upcoming music events on their website (Let’s face it, nobody reads them anyway ?). If anyone finds it useful, I would be happy to submit it to the official module list.

Or maybe better update the docs so that they can reference blog posts. We have many important explanations in blog posts and the should be linked from/to the docs imho ?

On this side, I don't really find the spambots or seo bots to be much of an issue, so I mostly ignore them unless they get too aggressive. It's instead the vulnerability scanners that tend to be the issue here. They are fine when they are throttled. But when they are unthrottled (as is usually the case), they eat up a lot of resources. Here's just one basic example: a vulnerability scanner might send through thousands (or tens of thousands) of URL variations looking for SQL files that it can grab, with dozens of different names each, like db.sql, database.sql, backup.sql, [domain].sql, database-[domain].sql, db-[domain.sql], [domain]-db.sql, and so on and on and on. Then add all the extension variations, .sql, .sql.gz, .sql.tar, .sql.tar.gz, and then add every URL with a trailing slash in the site as the prefix path for every check. So just a scan for SQL files in-the-open might account for tens of thousands of requests. And it'll try to do them all in a very short period of time, making the server like ours scale to meet the demand. Yet this is just an example of one vulnerability check out of thousands that it'll do. Once a vulnerability scanner gets started, it'll run for potentially days. But I usually block them well before that. Once I get an email from AWS about things scaling, I watch the logs pretty closely and then start blocking IPs. But the goal is to have the module just block them automatically. What the module does is that it allows you to define suspicious patterns in GET or POST requests, or user agent strings (and it comes with several patterns to start). For example, you might have patterns to match things like wp-login.php, those SQL request variations mentioned above, requests for .py, .cfm, .rb, .exe files, or others that you don't use on the server, requests containing SQL commands in the query string... these are just obvious examples. Then it lets you define a number of strikes till the IP is out. So for every pattern match, the IP gets a strike. So if I set it to "3 strikes and you are out" then once it gets 3 pattern matches, the IP is blocked for a period of time, also defined with the module. If additional strikes occur while an IP is blocked, the block time gets reset so it starts over, ensuring it's always blocked that set amount of time from the last strike.

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!

Chatsonic examples: How to create a page with the API of ProcessWire? How to return an array in ProcessWire?

ChatGPT helped me to improve RockMigrations - it's a little scary but it really saved me time today. First, I wanted to support single paths (not json) in the workflow file definition: That worked after I adjusted the variable defaults of input.PATHS to "{}" so that the parsing does not throw an error. No idea why it actually seems to parse the json even if the if-condition is not met, but it works now, so I'm happy with that. Then, as that worked quite well, I tried to fix a warning that I've been getting for quite some time and that worked even better: All updates are on the dev branch.

We really like the ability to add redirects via the page editor, but it is annoying that this functionality is only available to superusers. We often have clients asking us to add a 'short url' redirect for a page (e.g. /jobs -> /about/work/jobs) when it really is something they should be able to do themselves. To solve this problem, we've created ProcessPageRedirects. It does two things: Creates a page (Pages > Redirects) which lists all the visible pages to that user and the number of redirects (among other things) Allows them to manage the redirects for pages they can edit The redirects editor is the same one the superuser gets when editing the page. I hope this is useful, let me know here if you come across any issues with it.

The future looks bright! I'm very excited about the preview edition of GitHub Copilot. Finally someone putting AI to good use. Some of these suggestions are downright scary, they're so great. Write some code, a comment, then hit TAB. Boom. This is like Intellisense, but on steroids, and then some. Anyone else tried it? Care to share your experiences?

The selector documentation page of the API docs could probably do with an update to include the array-format selector upgrades that came fairly early on in 3.0.13.

Just for fun, I asked....

Exactly. I'm happy that you see and understand the potential and that you share that ? Definitely ? Thx for the comment! Having everything in one huge migrate.php does not only have the drawback of getting messy quickly. It does also mean that your migrations get slow, because whenever you change anything in that file all migrations will run, no matter if they are necessary or not. If you have everything in separate files on the other hand you get cleaner code, easier to understand chunks and RM will only trigger the migrations that have changes since the last page load, which makes page loads usually be ~1s here even when migrations run. Yep! ? If you understand the principle once, then you will instantly understand every project you are working on that follows the same simple principles.

ChatGPT is soon to replace Google, Stackoverflow and Quora for answering questions like these. I have used it to either confirm or throw speculation on topics and directions of research. I have asked it very technical academic questions in certain fields and it has given balanced views for just about everything, including outsider views and newer untested views on certain problems. Very fun. It has even been able to tell me when a problem that I thought still existed has already been resolutely solved. Such a time saver! My main comment, though, is that the marriage of page classes and migrations is truly groundbreaking in terms of modular design and in particular the ability to bring over single files that can instantly put in (or remove) scaffolding for demos. This has been AWESOME for live brainstorming and troubleshooting or providing clients with examples of how extensible the system is and how quickly modifications and improvements to functionality can be built out. This has made me more excited about using RockMigrations - I was a bit on the fence when the automation was centralized in migrate.php because of how unwieldly automation scripts can get in other applications I use - but bringing things that involved scaffolding into their respective page classes allow me to really just use migrate.php for mod installations, configuration, general hooks and other core modification processes. This is way easier to navigate, share and especially train on. This method is very easy to coach new devs on also.

I would think it all depends on the cardinality of the relationships. If one-many then children are fine. Otherwise group separately and probably use ConnectFields module.

Hm, I can't make it work. curl_getinfo($curl, CURLINFO_HTTP_CODE) in OpenAi.php returns 0. I can manually curl just fine, so it's not GPT. Edit: aha, curl_error($curl) gives 'SSL certificate problem: unable to get local issuer certificate'. ok, not exactly recommended, but as a quick fix CURLOPT_SSL_VERIFYPEER => false, or download curl cert and add it to php.ini

Note to anyone using potentially using this module: A page-edit-redirects permission has been added to the core - https://github.com/processwire/processwire/commit/dafceffc6f5d2d10c395faa1586ef0993633e6de - and once this hits the master branch I intend to rework this module so that it provided a list of redirects in the system. As the permission can be added to any user role, management of those redirects will happen in the page editor instead of the 'cloned' redirects editor this module currently provides. Cheers, Chris

Nice. Does the module offer a UI under the admin tree? I'm asking because there are naming conventions for PW modules. And the prefix "Process" is usually reserved for modules that have a page associated under the admin tree. Like ProcessPageLister etc. You might want to consider renaming your module before submitting it to the directory.

You could add a rewrite rule to .htaccess, but I reckon it'd be easier (and wouldn't risk being overwritten on updates) to do as you suggest and use a Page::saveReady hook. I do this regularly to manage page names and it doesn't cause problems. You're probably aware of this, but you may need to stop the hook running if the page hasn't yet been created: $pages->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments('page'); if(!$page->id) return; ...

There are not so many, it's only the vars of the pw-theme that need to be done. For the native dark theme (inverse), you can try it by adding `uk-dark` to the body, but will also see that there are some hardcoded value (like the background with #fff) in the pw theme. Will make a example, with a simple script, we can automate the vars declaration ? stay tuned. Example :?

From nowhere, but that's the missing part, I will push a fork of the official AdminThemeUikit so you can try it. The `pw-theme` should expose by default a `:root { --text-color; --bg-color; etc. }` to be used in CSS files shipped with our modules. I Will do that. Nahh ?

mail sent... let's see

Hey @Stefanowitsch thx, I've pushed that update to v2.33.0 ? Not sure if it's intentional, but you don't need the class "rf-scrollclass" on your <header>, you only need the attribute. Also I've been thinking if something like this would make sense: rf-scrollclass="show@300-800" ? But I can't think of a scenario where I'd really need that?! The feature was only developed for to-top scrollbuttons that appear when scrolled down for a certain amount. Not sure if it could be helpful for anything else?

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.

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!

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?

It's crazy sometimes how quickly the work week goes by. On Monday I started working on a Stripe Checkout integration for a client (using the FormBuilderProcessorStripe module), and somehow today I'm still working on it, and it feels like only a day has passed. This particular integration is a little more complicated than others I've worked on. The user makes a few selections that determine the final price, and when they submit the form, it has to authorize (but not yet capture) the amount due, so that the money is basically in a holding state. Then it has to send a notification to another company asking them to approve or deny the request. If they approve it, then it captures those funds through Stripe. Or if they deny it, then it releases the hold on those funds. It's also connected to multiple Stripe accounts in different currencies, and it has to use whichever one corresponds with the transaction details. In this particular form, some of the purchases also involve a 3rd party web service to confirm availability. And there's more to it as well, but I'll leave it at that... it's just a lot of moving parts, so I guess that's why I haven't done anything this week other than work on that. But the good news is that much of it has been added to the FormBuilderProcessorStripe module, so that the next this time need comes up for you or me, hopefully it won't take so much time. Here's a few of the things that have been added to FormBuilderProcessorStripe: Previously you could just accept a payment. Now you also have the option to setup a separate authorization and capture. And you can capture from a newly added API method, from the FormBuilder entries screen, or from our Stripe dashboard. On the API side, all you need to complete the capture is the ID of the payment (called the payment intent ID), which is saved with the form entry. The capture typically must be done within 7 days of the authorization. Doing an authorization (and later capture) is preferable to a charge when you think there's a reasonable chance the it'll need to be un-done. One reason is because an authorization costs nothing, whereas a charge (or capture) does, regardless of whether it is refunded. The module also has a new option to create a Customer in Stripe that you can charge later. This is different from authorization/capture in that creating a customer doesn't authorize any particular transaction or funds, but rather saves their payment info in Stripe, enabling you to charge it anytime later. This is useful for many cases, but one would be where a customer wants to save their payment information with their account, so they don't have to re-enter it every time they make a purchase. Several new configuration options were also added. New public API methods were added for capture, cancel and refund payments. You can now pass any data from the form into Stripe metadata. You can now specify the Stripe API version that you want to use with the module. And you can now send email receipts, even if not enabled in Stripe. More transaction information is now shown when using the "view entry" in the admin. Several new hooks were also added. Technically this update to FormBuilderProcessorStripe is ready to post now, but I'd like to do a little more testing first, so I'll be posting this module update in the FormBuilder board next week. I also have some updates to the InputfieldFormBuilderStripe module as well (which uses Stripe Elements rather than Stripe Checkout), and it may be updated at the same time, or shortly after. No core updates this week, but hopefully I got enough client work done this week that I can really focus on the core next week. Thanks for reading and have a great weekend!

@bernhard yeah I'm gonna use it for my next PW project. But I was interested in the vite setup for my other projects, like when I'm doing just basic html integration with no CMS, but I still want to use sass, have my css preprocessed, using js module ect. I don't want a BIG setup, doesn't use tailwind, just the basics for building my assets and browser-sync

Hey @dotnetic, I would be really interested !! at least by an exemple of your configuration to use vite with PW.

v2.15.1 ignores module migrate files if the corresponding module is not installed ? And it will trigger the migratefile right after the module has been installed! Thx for your input and feedback guys! Keep up bringing good suggestions ?

I totally agree and would have expected RM to work like that. No use for a module-related migration if the module is not installed.

@snck I am currently working on implementing Repeater Matrix support. It is basically working but needs some more thorough testing. ATM the setMatrixItems() method seems to be working well. If you like, you can grab a copy from https://github.com/gebeer/RockMigrations/tree/repeatermatrix and test it out. This is how you create a Repeater Matrix field: // first create the blank field $rm->createField('repeater_matrix_test', 'FieldtypeRepeaterMatrix', ['label' => 'Product Content Blocks', 'tags' => 'products']); /** * Set items (matrixtypes) of a RepeaterMatrix field * * If wipe is set to TRUE it will wipe all existing matrix types before * setting the new ones. Otherwise it will override settings of old types * and add the type to the end of the matrix if it does not exist yet. * * CAUTION: wipe = true will also delete all field data stored in the * repeater matrix fields!! */ $rm->setMatrixItems('your_matrix_field', [ 'foo' => [ // matrixtype name 'label' => 'foo label', // matrixtype label 'fields' => [ // matrixtype fields 'field1' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], 'field2' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], ], ], 'bar' => [ // matrixtype name 'label' => 'bar label', // matrixtype label 'fields' => [ // matrixtype fields 'field1' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], 'field2' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], ], ], ], true); Still need to test the other methods for removing/adding items etc. But this one should work. At least it was working in my tests. When testing is completed I will make a PR so @bernhard can implement.

No theres no unpublish($page, true) You can use the Batcher module to mass edit pages. You'll need a selector like "has_parent=1004" id of parent... The behavior of children of a unpublished parent is the same as when it's published. It doesn't influence it's children. Hard to say without seeing your code. But my guess is you have a script that tries to find the parent page but can't because it's unpublished... and you call $parent->children() somehwere but $parent isn't really a page object. that's what the error says at least. But you still could get the parent and it's children via API even if unpublished, you just add "include=all" to the selector or just use a get $parent = $pages->get(1004); // id of the parent $children = $parent->children(); // works as usual, even if $parent unpublished But it's still unclear to me what you try/need. Why unpublish them, when you want to query them? That's a question I can't really give an answer, as I still don't know the reason why you want to unpublish all those pages? Do they need to be hidden in navigation? Where hideing the parent would be enough? I can imagine that if you really want to make them all unpublished and not reachable to unpublish the parent for the branch and control a 404 in you templates init somewhere like the head.inc. if($page->parents("status>=". Page::statusUnpublished)->count()){ throw new Wire404Exception(); } Basicly checking if any parents of the current requested page ist unpublished, and then show 404. But not tested really, just a example.