Leaderboard

I have to say these new AI tools are really impressive, very powerful and more and more useful in my everyday work! I'm working on a small little javascript class to generate random pass phrases. I got an error so I asked chatgpt and copied the whole js file's content: The answer was spot on and it would have taken me a lot longer to find that issue on my own. Actually I learned something new as JS is not my strongest foot and I've had this issues a couple of times before where I was wondering why somethings this.foo() works and sometimes it doesn't. Everything makes sense now 🙂 I'm quite impressed!

Thanks @kongondo You are right, I have overread this 🤪 - it was Sunday morning!! Maybe the regex for the username could be used with Javascript too. The validation of the password is not so easy in this case but you can use the password requirements as posted above, put them inside a Javascript variable and check them against multiple if conditions. This is what comes into my mind. Something like this: if(contains letters){ if(contains number){ if(contains symbols { .... } else { return false; } else { return false; } else { return false; }

Hello @bernhard I have created these validators for my FrontendForms module, maybe this can help you to create your own validations. Check username syntax This is the regex that I use: $regex = '/[a-z\d\-_.@]$/'; It contains all the allowed characters. I guess all allowed characters are listed somewhere inside a file of PW or in the API docs. I have found them somewhere, but I cannot remember where 🤪 You will find the code of my validation here. Check password syntax The password is a little bit more elaborate, because you can set the characters that can be used by yourself. This is the code, that I use: $value = $_POST['yourpasswordfield']; // the post value of your password field on the frontend // get the password field module $passwordModule = $this->wire('modules')->get('InputfieldPassword'); // get the password field module // get the password field by the name of the field inside the user template, usually "pass" $passwordField = $this->wire('fields')->get('nameofyourpasswordfield'); // get the default requirements of the password module as stored inside the DB $requirements = $passwordModule->requirements; // password conditions can be overwritten on per field base, so check before if they are overwritten. Otherwise take the default from the module if (!$passwordField->requirements) { // if no requirements are stored in the database, take the default data from the inputfield default configuration $requirements = $passwordModule->requirements; } else { $requirements = $passwordField->requirements; } // set the requirements for the validation on the next line, so you can be sure that you take the correct requirements $passwordModule->set('requirements', $requirements); // Now check the password if the syntax fits the requirements return $passwordModule->isValidPassword($value); // returns true or false You will find the code of my validator here. As you can see, I take methods from the ProcessWire password module class to validate the password. I hope this helps you to solve your issues. Maybe you will find a better solution and I adapt my codes to your changes too. Have a nice Sunday!!

Of course. And that's the problem sometimes. If you don't know a lot about a problem you simply can't provide a good prompt. For example if you wanted a javascript array with some items and you didn't know what an array is, how would you ever get to that result? I'm on the free account, no idea what version that means. And I'm happy to learn, if you can show me how a good prompt in that example could look like 😉

Ok, thank you both 🙂 Here are my learnings: I went to the backend user profile to see if the password field has some helpful information I searched the core files for "characters long" wich was found in InputfieldPassword.module $minlength was a variable there, so I thought - as always - this would be configurable by PW I looked into Modules > Core > InputfieldPassword and found no configurable fields *surprise I found this thread and especially this answer by ryan: https://processwire.com/talk/topic/3149-password-complexity-requirements/?do=findComment&comment=31155 Luckily @adrian posted a link to the blog post that shows that everything is configurable now, I was just looking at the wrong spot: https://processwire.com/talk/topic/3149-password-complexity-requirements/?do=findComment&comment=158365 / blog post: https://processwire.com/blog/posts/upgrades-optimizations-pw-3.0.22/#major-enhancements-to-our-password-field Then I took a breath and thought about it as I somewhere read that forcing the user to use numbers might not be the best/most secure option and using a random string instead could be better in terms of UX and also security. Also when creating users in PW via the API the password requirements do not apply - so I can choose whatever syntax/requirements I wanted. So I created created an array of 100 random german words with the help of AI and then played around with that a little. This is the result: https://github.com/baumrock/PassPhraseJS I've also built an interactive calculator to see how many random passwords are possible with your chosen settings: https://baumrock.github.io/PassPhraseJS/example.html What do you guys think? Any suggestions for improvements? I'm already working on making the separators configurable so that will increase the number of possible passwords tremendously.

Hey @kongondo thx I'm already working on something and I'll keep you updated! 😎

@Juergen. Thanks for this. I think @bernhard is talking about JavaScript perhaps, for use before the form is even submitted to the server.

Just wanted to say that this is indeed a very nice update! For an ongoing project I'm relying heavily on WireCache for caching due to the nature of the site: most users are logged in and there is a ton of traffic at very specific times. Keen to implement any performance enhancements, and Redis has been on the top of my list. Definitely interested in using (or developing, if need be) a Redis WireCache module. Sure, we have CacheRedis already, but a drop-in solution would be even better. (... not to mention that core support for drop-in caching modules is one instance where WP has been ahead of PW. Not that it matters all that much, but still happy to be able to tick that box 🙂)

ProcessWire Docker Image Dockerized Processwire installation and development enviroment Local enviroment with MariaDB container included Mount local filesystem Processwire versions VSCode Itelliphense configuration xDebug preconfigured Opcache + JIT ready (xDebug must be disabled) Installation & usage Development enviroment installation Build using local script $ git clone https://github.com/laikmosh/docker-processwire.git $ cd docker-processwire $ docker-compose up Install as usual, no extra configuration is needed. There is a config-dev.php file in the ./site/ folder, this file will load by default when running locally, but is in the .dockerignore, so it wont be included at image building time. Custom php.ini settings can be set at: /Processwire/scripts/php/php.ini *Image must be rebuilt for changes on php.ini to take effect Development enviroment usage By default the ProcessWire installer will load the `.env` configuration. Configure .env file for project and DB settings, default database credentials are: Database: {COMPOSE_PROJECT_NAME} User: admin Password: password Server: database Port: 3306 Editable files and templates will be installed to the ./site/ folder. Processwire documentation ProcessWire ProcessWire Repo ProcessWire Documentation

This week I've done some work on the core $cache API (WireCache) to make it able to support other cache storage options. To do that, I had to move all the storage code out of the WireCache class and into a separate class that implements the new WireCacheInterface. So it was kind of a major refactor. Now the WireCache class is independent of storage method, which will make it more flexible in the long term. The first class that implements the new interface is the new WireCacheDatabase. This contains the cache database-storage code that was previously in the WireCache class. But the plan is to also add a WireCacheFilesystem (in progress), and make it possible for others to develop WireCache modules, perhaps for Redis, Memcache, etc. I've been wanting to do this because in some cases I've noticed significantly better read performance from file-based caches. (Though admittedly, at the expense of write performance.) But it made me think it would just be better to have more cache storage options, and also be nice to take advantage of even better cache options available in different environments, like in the AWS environment we run this site on. One of the issues with changing the cache used by the system is that the $modules API (Modules class) depends on WireCache for quite a few things. And the modules basically can't load without the relevant caches being available. At present, $cache has to load before $modules, which makes the whole idea of WireCache-modules a bit of a chicken-or-egg first situation. So I've been working to decouple $modules from WireCache, or at least make it able to function if its cache isn't available on occasion. I made some good progress there, but found that there was a little bit of a performance hit in doing so, so I reverted those changes and put them behind a toggle in the Modules class to experiment with further. But while doing that, I found some other ways to improve the performance of the modules loader. So you'll find the dev branch boots a little faster this week. Maybe not noticeably so (since PW already boots fast), but measurably so. I'm always looking for opportunities to improve performance — even small performance improvements amount to large savings over time. While on the topic of caches, I've also added an experimental $pages->loader()->findCache($selector) method which works exactly like $pages->find($selector) method, except that it caches the page IDs that were found for a period of time that you specify in the 2nd argument (default is 60 seconds). I imagine this method would be useful for complicated or slow page finding operations that don't need to restart from scratch on every request. This is an alternative to markup caching for greater control. But since it caches the result of the find operation (page IDs), and not the actual pages, it has a different set of benefits (and drawbacks) relative to markup caches. I'm still experimenting with this method to get more feedback and make sure it's worthwhile, so far it appears to be. This will likely become accessible at $pages->findCache() once out of the experimental stage. That's all for this week. Thanks for reading and have a great weekend!

As you are on free plan, you are running on GPT 3.5 (fast) model trained. The goal is to trick GPT from the first prompt. For example, I suggest you to give a try to this awesome prompt which can transform ChatGPT into a high-quality programmer with a level 30 code proficiency on steroids 🦾😂 And then: 😼 $: programming: I have two words: foo and bar, I join those words with a dash. How many different strings can I get ? 🤖 $: There is only one way to join the words "foo" and "bar" with a dash, which is "foo-bar". Therefore, there is only one possible string that can be obtained by joining these two words in this specific way. Explore/experiment on flowgpt's prompts, I am sure you will get something amazing for us 🫡 guide link.

I have already tried that. Made no difference. But, meanwhile I think I have found the solution. Adding to the mysqld config skip-log-bin transaction_write_set_extraction=OFF the performance is back to normal levels. It disables binary logging; since this is a standalone (non-replicated) server, this should be harmless (I think).

Hi, without more precise informations about like exact version of the setup, the type of hosting / server, etc, it's quite hard to give you an answer. The only hint I can provide you, as you are talking about MySQL v8 on Ubuntu 20 LTS, it's to look at this known bug: https://bugs.mysql.com/bug.php?id=99593 To test the workaround (second post from the dev team): SET GLOBAL internal_tmp_mem_storage_engine=MEMORY;

Those are awesome news for us! We've had a long standing problem with moving ProcessWire installations from one server to another concerning the caches table. It would be great to completely decouple the modules cache from the user generated cache. Maybe move the modules cache to a separate db table. It seems intuitive (and most administrators seem to take this as granted) that you can simply purge the caches table to reduce the database dump size. But it is not like that ATM. Just had this problem yesterday with an experienced ops engineer, who doesn't have any PW experience... so your are magically right on time @ryan, as multiple times before!

I've been following the news on the new editor and I'll be adding that to the next version of the module. The module is already getting refactored so I'll be able to plan for this much more easily. I'll work on posting some updates here with some details on what's planned!

I did my first talk ever yesterday @ PHP Meetup Vienna!! Once more everything was a lot more work than I first thought, but I'm quite proud of the result 😎 What do you think? Did I forget something important? It was really hard to put 10 years into one hour... The recording was not planned at first, but I thought I'd just give it a try and everything worked quite well 🥳 If you like what you see please share it with others so that ProcessWire gets the attention that it deserves 🙂 Special thanks to @gebeer for showing me ProcessWire in 2013 🤗

https://processwire.com/blog/posts/upgrades-optimizations-pw-3.0.22/#major-enhancements-to-our-password-field