Leaderboard

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.

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,

Language change in account settings: Language change.MP4 I have tried it with 3 languages and the language select shows all 3 languages in all languages. I do not know why the option is an empty string in your case. Do you have translated the names of your languages under setup languages too?

Hello @da² I have tried to test the file size restriction with various files, but in my case I could not find any issues. It has worked every time. Do you see the red badge warning under the file input field too as in my screen shot below before you submit the form (if you have selected a file larger than allowed)? If you see this red badge, the form could not be valid after the form submission. Please also check the file size in the badge (in this case it is 12.81 MB). Maybe you could provide a screen shot before the form submission? Please check if you have the latest version too! Best regards

Hi @franciccio-ITALIANO form me, exactly as @BrendonKoz says, your website works perfectly and as he says too i tend to think that it's a browser cache issue i've alreaddt had the same kind of issue with an ssl certficalte not installed, the web site seen as not secured by the browser and keeping being seen so even after a correct install of the ssl a simple solution (except from testing with another browser like we've done for you :)) for your current machine and browser is to empty the borwser cache/history (you just need to erase the files and offline data, don't loose your passwords/cookies and so on if not needed) have a nice day