Leaderboard

We've got just a few core updates on the dev branch this week, but next week we're looking at finally merging in the InputfieldTinyMCE module! This week I also wrapped up the WireRequestBlocker module that was mentioned in last week post, and the v1 beta is now posted in the ProDevTools download thread. I've been running it here on processwire.com this week and it's been doing a good job of keeping out the vulnerability scanners and bots. For more details on this new module please see the new Wire Request Blocker page that I just posted. Thanks and have a great weekend!

Now that there is llamaindex https://gpt-index.readthedocs.io/en/latest/index.html with connector for github repo https://llamahub.ai/l/github_repo available, I thought it would be awesome to have a LLM that is specifically trained on PW. I thought I'd give it a try and asked GPT-4 for some guidance on how to create an index and then setup training and so on. Here's what I asked for And that was the answer Disappointing. This answer proves that even GPT-4 has only data until Sept. 21 available. At that time llamaindex was not public yet. I'm not into python at all. So I would have a hard time when trying to setup indexing of the PW github repo and then training a LLM on that index. I'd love to see how this would work out. But GPT-3 and 4 are already quite good at understanding PW, it seems. I installed https://marketplace.visualstudio.com/items?itemName=Rubberduck.rubberduck-vscode in vscodium. So I don't have to switch to the browser when asking GPT. Pretty neat tool.

Just took a moment to play a bit more with ChatGPT (v3.5) and built a simple module with it. While it was pretty easy, ChatGPT needs a lot of assistance to make things work out as expected. Adding the Processwire namespace? Nope. Taking care of user input and sanitizing? Nope. But that's totally fine for me. It took about 30-40 minutes from start to published on Github. See: TextformatterAsciiEmoji The README.md was also written by ChatGPT.

Hey @ryan sounds like a great module ? Wouldn't it be nice if the module's config screen showed that information? So it would be in a safe space without additional steps to do ?

Update: SOLVED! Never mind, I had moved a bunch of hooks to admin.php, including the DynamicOptions hook, which is why it stopped working on the frontend. I have put the hook back in ready.php and works as expected. Of course that makes perfect sense in retrospect. [--- Snipped description of the problem, it was a wild goose chase! --]

Just wanted to install Copilot on https://vscodium.com/. Unfortunately not possible atm. And don't think it will be possible anytime in the future. Seems like MS is locking open source projects out. Anyways, I opted for https://codeium.com/ and will give this a go. Had https://www.tabnine.com/ installed for almost 1 month. But it was no great help IMHO. Especially when it comes to PW specific stuff.

I was wondering: when I use the same hooks on different pages, is it better to only use that hook once and divide with if statements or is it ok to call a hook multiple times. Like: $wire->addHookBefore('Pages::saveReady', function(HookEvent $event){ $page = $event->arguments(0); if($page->hasField("field1")) { //do something } if($page->hasField("field2")) { //do something else } }); $wire->addHookAfter('Pages::unpublishReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->hasField("field1")) { //do something } if($page->hasField("field2")) { //do something else } }); or //Things regarding pages with Field 1 //###################### $wire->addHookBefore('Pages::saveReady', function(HookEvent $event){ $page = $event->arguments(0); if($page->hasField("field1")) { //do something } }); $wire->addHookAfter('Pages::unpublishReady', function(HookEvent $event) { if($page->hasField("field1")) { //do something else } }); //###################### //Things regarding pages with Field 2 //###################### $wire->addHookBefore('Pages::saveReady', function(HookEvent $event){ $page = $event->arguments(0); if($page->hasField("field2")) { //do something else } }); $wire->addHookAfter('Pages::unpublishReady', function(HookEvent $event) { if($page->hasField("field2")) { //do something else } }); //###################### Of course the first version looks nicer, but if you have a lot of functions it becomes increasingly confusing to keep track of those functions. The second version makes it much easier to keep logic together but I'm concerned if that will raise trouble with performance.

Hi @Juergen Just tested and in my setup, if there are any nested fields in the fieldset with an error the parent fieldset is get automatically opened. From what I see in the code it is the intended behavior https://github.com/processwire/processwire/blob/master/wire/core/InputfieldWrapper.php#L777 In any case you can manually set collapsed state of inputfields inside the getModuleConfigInputfields public function getModuleConfigInputfields(array $data) { .... foreach ($inputfields->getErrorInputfields() as $inputfield) { $inputfield->collapsed = Inputfield::collapsedNo; } return $inputfields; } or even like this public function getModuleConfigInputfields(array $data) { .... foreach ($inputfields->getErrorInputfields() as $inputfield) { $inputfield->collapsed = Inputfield::collapsedNo; $parents = $inputfield->getParents(); foreach ($parents as $parent) { $parent->collapsed = Inputfield::collapsedNo; } } return $inputfields; }

Hi @ryan, after some testing around with our translation management, I saw that we need XLIFF format for most of our translation tools (https://www.across.net/, https://tolgee.io/) I guess you could take the id attribute in XLIFF and use some [pageid]-[fieldname]. Example for file from tolgee export/import file XLIFF: <file xmlns="" datatype="plaintext" source-language="de" target-language="de"> And "skeleton" is not mandatory. So there is not need for in in Processwire exports. Example XLIFF export format for processwire could look like this: <?xml version="1.0" encoding="UTF-8"?> <xliff xmlns="urn:oasis:names:tc:xliff:document:1.2" version="1.2"> <file xmlns="" datatype="plaintext" source-language="en" target-language="de"> <body> <trans-unit id="1234-title" datatype="html"> <source>Hello World</source> <target>Hallo Welt</target> </trans-unit> <trans-unit id="1234-body" datatype="html"> <source> <p> <strong>A text about flowers.</strong> </p> </source> <target> <p> <strong>Ein text über Blumen.</strong> </p> </target> </trans-unit> </body> </file> </xliff> This approach is for XLIFF 1.2 which is used by across and toolge but its depricated. Maybe it would be good to make an export/import option for XLIFF 1.x and XLIFF 2.x. More Information about XLIFF in Across: https://www.across.net/en/online-help/sdk/connecting-third-party-systems/crossconnect-for-external-editing/implementation/across-xliff-format?r=1

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.

Question: is processwire better than wordpress? Answer:

Seems that things changed slightly ? This worked for me today: Translate file /wire/modules/Inputfield/InputfieldDatetime/types/InputfieldDatetimeText.php Set path: /wire/modules/Jquery/JqueryUI/i18n/jquery.ui.datepicker-de.js Search keys: datetime, date picker, monday, translate, sunday, german