Leaderboard

I recently discovered Pinkary.com which I would describe as a Twitter clone, built by one of the Laravel team members with all the latest and greatest of Laravel and its ecosystem (the project is open-source). Right now it's got about 1000 members after being launched earlier this year and it's almost all web developers, which reminds me of the early Twitter days. I don't get excited about social media or microblogging much, but having a concentrated community of like-minded folks is intriguing and a place to find interesting things going on and nuggets of information, without all the noise, bots and other nonsense you'd see on Twitter/X. I think it's worth a join.

Great to hear that! I'm also very motivated as this has been an issue for me (and I guess many of us) for a long time. Things are really going well so far. I had some troubles today with timezone issues (events starting at 10:00 suddenly started at 11:00 from one month to another etc.) and also with the performance of creating recurring events. Turned out I set a generic pagename and PW had to append a unique suffix for every created page and that got slower and slower as pages under that parent grew in count. I've just quick-fixed that by setting a random name via uniqid() and the performance is quite impressive imho (real world speed on my macbook air with ddev): How cool is the live progress bar??? 😎 It works with realtime feedback from the server using SSE. No polling. No sending hundreds of requests to the server 🚀 I also wanted to update the grid above the progress bar, but that also turned out to slow things down a lot, so I turned that off for now. I have to look into that tomorrow. I think it should be an easy fix. But that's it for today 🙂

Reading this, I am asking myself: A clone followed by a data wipe is nothing more than creating an empty new page with the same template, right? Why don't you disallow clone for these templates (possibly for your client's role only) and instruct your users to use "new" instead?

Hi, To be clean I wouldn't use the page name. Name purpose is essentially for url management, not for "company"'s one. 🙂 Name can change in the future, but the company associated with the page won't. So I would create, maybe a select options with company names and ID. Or if these tools have properties that need to be stored in PW fields, I would create a tools template and tools page references on the company page. For the code part (using a select options), I don't like using hooks when it's not necessary, hooks make code less clear and harder to maintain on long term. So my approach is like good old classic and verbose OOP. 😄 I wrote this on a simple text editor, so maybe mistakes... /** * Values of this enum must be also set in select options values. */ enum CompanyToolsType:int { case MICROSOFT = 1; case GOOGLE = 2; } interface CompanyTools { public function foo():void; } class MicrosoftTools implements CompanyTools { public function foo():void { echo "I'm a Microsoft tool"; } } class GoogleTools implements CompanyTools { public function foo():void { echo "I'm a Google tool"; } } class CompanyToolsFactory { public static function getTools(CompanyToolsType $type):CompanyTools { return match($type) { CompanyToolsType::MICROSOFT => new MicrosoftTools(), CompanyToolsType::GOOGLE => new GoogleTools(), }; } } /** * @property $companyTypeSelect I don't remember what type it is (Select Options field with single selected value) */ class CompanyPage extends Page { public function getTools():CompanyTools { return CompanyToolsFactory::getTools($this->getToolsType()); } public function getToolsType():CompanyToolsType { // TODO Can throw ValueError return CompanyToolsType::from(intval($this->companyTypeSelect->value)); } }

What do you think of something like this? // somewhere let HelloWorld = ProcessWire.hookable( { foo: "foo world!", ___hello: () => { return "hello world!"; }, }, "HelloWorld" ); console.log(HelloWorld.hello()); // output: hello universe! console.log(HelloWorld.foo); // output: foo universe! // somewhere else ProcessWire.addHookAfter("HelloWorld::hello", (e) => { e.return = "hello universe"; }); ProcessWire.addHookAfter("HelloWorld::foo", (e) => { e.return = "foo universe!"; }); I built a proof of concept module here, but it's already outdated and I'll work on a new version shortly. The reason why I'm building this is because I needed a way to modify some parts of my JS frontend setup on my RockCommerce project. So I added two methods RockCommerce.after(...) and RockCommerce.before(...) where we as a developer and user of RockCommerce customise every part of the Frontend (for example adding custom taxes or pricing calculations). Now while working on RockCalendar I wanted something similar. And while working on RockGrid I had the same need. For example adding custom locales or adding custom callbacks. What is easy as cake in PHP is not so easy to do in JS. So I thought, wouldn't it be nice to have hooks in JS as well? I asked Ryan and he seems to like the idea, so I'll work on that over the next few weeks. As you can see here I will most likely change the module soon to work with JS proxy objects. This is what provides the magic of AlpineJS behind the scenes. Now I'm wondering if some basic Alpine magic would make sense here as well, for example watching a property and firing a callback can be extremely helpful on its own! let demo = ProcessWire.magic({ foo: "foo", init() { this.$watch("foo", (newVal, oldVal) => { console.log(`foo property changed from ${oldVal} to ${newVal}`); }); }, }); demo.foo = "bar"; // will log "foo property changed from foo to bar" I've renamed ProcessWire.hookable() to .magic() in this example, as it does more than just adding hook support. Not sure about "magic", maybe you have better ideas? What do you think? Would that be helpful? What would be a good name? ProcessWire.rock(...) would be my favourite I guess 😄 ProcessWire.proxy(...) would also be an option. Not sure if adding basic apline magic to PW would be a good idea of if adding alpinejs itself would be better? Any JS experts here that want to help with that project?

X/Twitter is still my favourite place, yet... pinkary sounds nice. Joined a few minutes ago. Let's see. Maybe it becomes the PW Community's home.

Thanks! I've heard about it a couple of times. But your mention made me visit the site once again and join. Seeing a couple of interesting topics on Laravel. And a nice one about PW too)) Had to like it)

Just load everything into Redis and hope the server never restarts. Blazing fast performance fueled by hopes and prayers ⚡ 🙏 🔥 😭

Nothing in particular just that it all looks really good! Made this comment thinking on how it's very complicated to setup the recurring rules, but I like the solution!

Thanks for the quick response! I upgraded the module and it now works perfectly with my multilangual site. Thanks!

@Reeno, I've added multi-language support in v0.2.0. Please upgrade and let me know if you strike any problems.

Watching this cody video made me crazy 😄 , the guy is generating a unit test with AI from the finished implementation! 😬 This is so wrong. We should never write a test from an implementation, tests must be wrote before... because they are meant to validate the implementation. Implementation is a consequence of the tests, not the other way. If an AI generate a test from a wrong implementation, will the test validate the wrong or the expected behavior? 😁 For the fun I asked ChatGPT about this technique: Generating unit tests from the function they are supposed to test might seem efficient for saving time or ensuring that the test covers the existing code, but it has several significant drawbacks. 1. Confirmation Bias: The test may inherit the same errors or biases as the original function. If the function contains a logical error, the test generated from that same logic might not detect it. 2. Lack of Test Case Diversity: A good unit test should verify a function under various conditions, including edge cases or unusual scenarios. If a test is automatically generated from the function, it may not cover all possibilities and might only focus on scenarios the function already handles correctly. 3. Objectivity and Independence: Unit tests are meant to be independent and objective. By generating tests from the function itself, this independence is compromised, which can reduce the tests' ability to identify defects. 4. Lack of Critical Thinking: Manually creating unit tests forces the developer to consider various use cases, possible inputs, and expected outcomes. This helps identify potential flaws in the function's logic. This critical thinking is often lost when tests are generated automatically. 5. Maintenance and Scalability: If the function evolves, the generated tests will also need to be updated. Automatically generated tests may not be as flexible or well-maintained as manually crafted ones. When Can This Technique Be Useful? Initial Generation: For very large projects where tests are nonexistent, generating basic tests can be a starting point before refining them manually. Quick Coverage: In situations where quick coverage is essential, this technique can help, though it should not replace thoughtful and manual testing. Conclusion It is best not to rely solely on this technique. Unit tests should be independent and designed to push the function to its limits, which is difficult to achieve with tests generated from the code they are supposed to test.

And in case using page names is mandatory, the changes are: /** * Values of this enum must be the same as company pages names. */ enum CompanyToolsType:string { case MICROSOFT = "microsoft"; case GOOGLE = "google"; } class CompanyPage extends Page { //public function getTools... public function getToolsType():CompanyToolsType { // TODO Can throw ValueError return CompanyToolsType::from($this->name); } } You can also remove the enum and ask the factory directly with a string, but enum adds a layer of error checking. Same for factory, it can be removed and code moved to CompanyPage, the factory primarily helps with better separation of responsibilities.

It looks like you've each chosen the differing options. 😉

What I’m finding particularly useful is your date Inputfield on steroids allowing you to cover almost all cases. On a recent project I went with a FieldtypeCombo + FieldtypeTable to achieve something similar: If the event is happening indefinitely, I create the first 1000 occurences and have a button to create a 1000 more, like in your screencast (though not live). The one thing missing in my contraption is hiding past occurrences (but keep them just in case). In your example, does clicking on the trash icon delete the occurrence or just deactivate it? Having a calendar UI would of a course be a really nice thing to have as well for clients 🙂

I'm gonna say yes, but would require some more development to achieve... I've also got a newer version personally that does subscriptions but havent got round to putting it up

Version 2.2.15 is out! This update comes with a small performance upgrade. Now you can choose on which pages you want to embed the JS and CSS files of the FrontendForms module. This means that you can prevent the files from loading on pages that do not contain a form. This also allows these pages to load faster This version includes a new configuration field in the backend where you can select all the pages where you want the files to be embedded. Best regards

Got it working again! v0.12.6 works and 0.12.7 has an issue, see https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1039

Webmin + Virtualmin: for web hosting management (I was a plesk user until I found webmin). Analytics: GoatCounter: No tracking analytics for simple (and usually personal) websites. Plausible: Self hosted non Google analytics.