Leaderboard

Hello community! We would like to share our new module for ProcessWire: ----------------------------------------------------------------------------------------------------------------------------- Asyntai - AI Chatbot Create and launch AI assistant/chatbot for your ProcessWire website in minutes. It talks to your visitors, helps, explains, never misses a chat and can increase conversion rates! All while knowing your website, customized just for you. Your ProcessWire website can now talk. This plugin embeds the Asyntai chatbot on your ProcessWire site and provides a simple admin page to connect your site to Asyntai. Why choose Asyntai? • Increase conversions: Instant, human like replies keep shoppers engaged and buying. • Never miss a chat: The AI replies day and night, even when your team is offline. • Knows your website: Customized just for you; it follows your instructions. • Works in all languages: Automatically detects and answers in the visitor’s language. • Fast responses (1–3s): Keeps customers from bouncing. Installation Download the module from GitHub or from here Copy the module files to /site/modules/Asyntai/ Go to Modules in your ProcessWire admin Click "Refresh" to detect the new module Click "Install" next to "Asyntai - AI Chatbot" Configuration After installation: Go to Modules → Asyntai Click "Get started" to connect your Asyntai account Sign in or create a free account The module will automatically save your connection The chatbot is now live on your site! Don't have an account yet? Create a free Asyntai account at asyntai.com/auth Managing Your Chatbot Once connected, you can manage your chatbot settings, review chat logs, and customize AI responses at: asyntai.com/dashboard Requirements ProcessWire 3.0.0 or higher PHP 7.2 or higher Have a question? Email us at hello@asyntai.com or try our chatbot directly at asyntai.com/ GitHub: https://github.com/asyntai/processwire-Asyntai

Back to the basics. Great stuff! Most of the forum posts are about new features. But I really enjoy reading about how to use PW, tips and tricks and such. Would love to see more of those and from Ryan himself especially.

ProcessWire’s API is accessible through API variables and it provides multiple ways to access them. There are benefits and drawbacks to each approach and this post aims to cover them all. We also look at how to add your own API variables as well. https://processwire.com/blog/posts/api-variable-best-practices/

@Robin S Good question, theoretically it's more efficient to hook to an object directly when it suits your need, though I'm not sure if it is in practice... I've not done any tests to measure. When hooking '$pages' it's called a "local" hook because it's local to just that instance named $pages (and the hooks are stored with the instance), whereas when hooking 'Pages', it's called a "static" hook and it keeps track track of it in the WireHooks class, as it would apply to any current or future instance of the Pages class. But there's only ever one instance of Pages (named $pages) so it doesn't matter in this case. https://processwire.com/api/ref/wire/get-hooks/ Another way of saying it: The $pages->addHook('method') and $wire->addHook('Pages::method') are technically different calls in that $pages->addHook('method') is saying "Hook method in JUST THIS instance of Pages" and $wire->addHook('Pages::method') says "hook method in ALL instances of Pages". While it may not matter in the case of $pages (since only ever one instance), it does matter in cases where there can be multiple instances of the class, such as with the $page class. In that case, you have a choice to make of "do I want to hook JUST THIS $page"... $page->addHook('method', ...); ...or "do I want to hook ALL Page instances" or "do I want to hook ALL BlogPostPage instances", etc. $wire->addHook('Page::method', ...); $wire->addHook('BlogPostPage::method', ...); What's more efficient about local hooks: If hooking just a single $page instance (or other type), then the attached hooks disappear when the $page instance does. When hooking all instances of a class, then that hook sticks around for the entire request, or until manually removed. When a single instance is hooked (local) rather than all instances (static) then ProcessWire only has to consider that hook for the one instance, rather than all instances. So less work. For $pages vs Pages, there's only one of them either way, so it probably doesn't matter much one way or the other in that case.

Please replace self::getDirContents($path); with self::_getDirContents($path); (underline is missing).

Hi @ I have just installed the forked version of this module. I get the below whenever I try to clear cache in the module setting page. Any hints? Fatal Error: Uncaught Error: Call to undefined method AllInOneMinify::getDirContents() in site/modules/AllInOneMinify/AllInOneMinify.module:1216 Fatal Error: Uncaught Error: Call to undefined method AllInOneMinify::getDirContents() in site/modules/AllInOneMinify/AllInOneMinify.module:1216 Thanks. Gideon

Great post, thanks @ryan. I remember you saying somewhere that when hooking a $pages method it is more efficient to add the hook to the API variable. So better to do this... $pages->addHookAfter('saveReady', function(HookEvent $event) { // ... }); ...than... $wire->addHookAfter('Pages::saveReady', function(HookEvent $event) { // ... }); Is that still true? And if so, is it just the $pages variable that the advice applies to or is it broader than that?

Thanks @ryan, Knew there were different ways to create a PW API variable object. Until I read your blog, I didn't understand the nuances of when, where and which method best suits the context. Like @Ivan Gretsky,

For modules that are not premium/pro modules, I'd love to see if their inclusion in core would be of benefit to the greater community. Many of, for instance, Robin S.'s modules aim to make the interface experience better for the end-user. Even if the code may not be 100% compliant to what the core expects, the very idea of the module may prove useful in improving the total user experience without the need to discover it elsewhere. Some extremely popular modules (ex: Tracy Debugger) may not be directly suited to being added to the core, so thought should be taken over its usefulness to all, not just specific circumstances or groups of people. Alternatively, is there a preferred way to request addition to core via the Feature Requests Github repository?

Hey @gebeer thx for that report! I have pushed your suggested fix on the dev branch of RockFrontend 🙂