theoretic

Hi friends! Many thanks for this brilliant module! It appears I've found a heavy issue concerning php 8.3.7 . In brief: Fluency crashes, giving multiple errors of this kind: Uncaught Error: Undefined constant "Fluency\Engines\DeepL\CURLOPT_CONNECTTIMEOUT" in site/modules/Fluency/app/Engines/DeepL/DeepLEngine.php:220 Digging inside reveals the following code sample: $requestConfig = [ CURLOPT_CONNECTTIMEOUT => 5, ... CURLOPT_CONNECTTIMEOUT looks here like a constant, however it's not. PHP 8.3.4 can however handle this kind of arrays, and Fluency works like a charm. But it's not the case for PHP 8.3.7 . I think it's worth taking this into consideration during further development. I've also created an issue on the Github module page. Hope this will help to make this module even better 😉

I've found the solution. Hope this will be helpful to someone ) //options for AsmSelect should be (int)key=>value pairs $options = [ 1=>'A value', 15=>'Another value', 200=>'And even more', ]; //default values should be array of keys, not values $defaultValues = [ 15, 200, ]; //options can also be an array of (int)keys $otherOptions = [ 25, 35, 45 ]; ... $config = [ [ 'name' => 'myField', 'type' => 'AsmSelect', 'label' => $this->_('My field'), 'options' => $options, 'value' => $defaultValues, ], ... ];

Hm, not bad, not bad ) Could be a working solution if we'll extend the default Page class with some extra data. Thanks )

Thank You @da²! Both ways are usable. But I still think it's a bit "patchy", especially hardcoding the paths/URLs of the default images. Having a "regular" image inputfield allowing to upload images, add some metadata to them etc. could be a much better solution. That's why I had the idea of creating the second set of per-template fields.

Hi fellas! And thanks for Processwire! Couldn't find myself an answer to a question which appears to be not too complex. I'm developing a configurable module which uses a MyModule.config.php file to store its config fields. I'd like to use the AsmSelect fieldtype with some (maybe dynamic) options there. Basically it's dead simple: $config = [ [ 'name' => 'MyFieldName', 'type' => 'AsmSelect', 'label' => $this->_('My config field'), ], ... ]; This code displays the AsmSelect, but I have no idea how to add options there. Tried some staff like this: $config = [ [ 'name' => 'MyFieldName', 'type' => 'AsmSelect', 'label' => $this->_('My config field'), 'options' => [ 'name1' => 'value1', ], ], ... ]; , but couldn't get any result. I know that it's possible to define config inputfields right inside the .module file, but I'd like to separate the config from module itself (and the MyModule.config.php is a perfect way to do so). So dear Santa, do You have any idea on how to add some options to my inputfield? Thanks in advance )

Hi fellas! And thanks for Processwire! I have an idea which, I suppose, might appear interesting to the PW community. I'd call it "template fields". Come on, we have it already! Any template may have fields, it's Processwire basics. Yes. And no! The fields attached to any template are used with the pages having this template, but not with the template itself. Feel perplexed? A short pseudocode example to explain what I'm trying to say. //one-of-my-templates.php ... foreach( $productPages as $productPage ){ $productImage = $productPage->image? : $productPage->template->image; //outputting some html etc. } ... Default field values (e.g. default images) are not a strong point of Processwire. Okay, we can use 3rd-party modules like @Macrura's Settings Factory (but oops, SF doesn't support image fields). Or we can create a dedicated "defaults" page with dedicated "defaults" template having all necessary fields... hmm, looks like a patch, yes? At last, we can give up and use some hardcoded image urls (yes, it's "patchy" again!). Using a kind of $page->template->image could be a much better solution. Let's imagine a second set of data fields bound to any template. The first one represents the fields used like $page->myfield. The second one could be used in the following way: $page->template->myfield or even $template->myfield. This approach may give us much more flexibility than PW already has, and I don't suppose it should be too complex to implement. Maybe it will be reasonable to make a module offering this new functionality. Think I possibly could do this... but would like to see the community reaction first. So what do You think friend? Is it worth doing or not? Thanks in advance for any opinion.

Wow it's just incredible! @BitPoet You're the best ) It's so rare to see a new module being created as a response to a forum question! Love the Processwire community ) Thank you fellas!

Hi friends! And thanks for Processwire ) Maybe I'm missing something, but it appears that PW doesn't have a dedicated selector for text length. Possible selector: $selectedUsers = $users->find("name.length<=5,sort=name.length"); Expected output: Bob Andy Maria ( Steven and Andrea will be skipped because that names are too long ) Of course it's possible to filter the find() results using some custom function, but having a native selector instead could be a better practice. So does that silver bullet really exist? If no, I think it could be useful to many happy PW developers )

@da², sorry, forum says that I have no permission to see the content You've quoted ( Could You please copypaste it here?

Hi friends! And thanks for ProcessWire! There's an inconvenience in ProcessWire file translation process which, I think, deserves a topic here. It's a common case to have same translatable phrases in different translatable files. Using a translation context (in fact, a separate file holding all that phrases) is also a common case, at least for me. Generally i call that context I18N_GLOBAL. So my typical translation may look like this: <?=__( 'Accept', I18N_GLOBAL )?> The problem is that ProcessWire translation interface is context-agnostic. If You have to translate multiple files containing the same 'Accept'-related piece of code, it will be always treated as not translated yet, even if I18N_GLOBAL file is already translated. Quite annoying, especially if You have lots of phrases to translate. So dear Santa, could You please make translation interface context-aware and to mark all the phrases (in all the files) which already have translation in my I18N_GLOBAL file as translated? Or maybe I missed something, and there's a possibility to tweak some settings and achieve this? Thanks in advance for any possible advice or idea )

Hi friends! And thanks for Processwire! While supporting a 5-years-old Processwire project I found that there are both InnoDB and MyISAM tables there. Personally I think that InnoDB is better for Processwire. MyISAM tables came from some modules written years before. Since I like websites to be fast, I altered all MyISAM tables to InnoDB. At first glance, it was a good solution, website is running fast and smooth. Could there be caveats? Maybe I'm taking some implicit risks? I Would like to discuss this.

@bernhard, thanks! Quite an elegant solution, works like a charm.

Okay, thanks! Admin pages are handled in their normal way, have nothing specific to add here. As to the frontend, the form is ajax-submitted to an API endpoint written by myself.

Hi friends! And thanks for Processwire! I have an interesting question. Couldn't find an answer myself. Let's suppose we have a hook of this kind: $wire->addHookAfter("Pages::saveReady", function($event) { $user = $event->arguments(0); //some manipulations with user data } This hook can be triggered both by frontend (there are some forms there allowing users to edit their profiles) and by backend (when superuser saves user page). I'd like this hook to have different behavior in these two cases. My first guess was like this: $wire->addHookAfter("Pages::saveReady", function($event) { $user = $event->arguments(0); $page = event->object; if( $page->template == 'admin' ): //some admin-specific manipulations with user data } No way! $page is always null, no matter how the hook was triggered. Any idea how to guess which page has triggered the hook? Thanks in advance for possible help 🙂

Hi @AndreasWeinzierl! Got into same trouble. Fortunatelty, it can be fixed quite easily. Just uncomment //namespace ProcessWire; at the very beginning of the module. Have no guess why @kixe had commented it. Works fine after uncommenting, at least for me )