Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

2,482 profile views

theoretic's Achievements

Full Member

Full Member (4/6)



  1. 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!
  2. 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 )
  3. @da², sorry, forum says that I have no permission to see the content You've quoted ( Could You please copypaste it here?
  4. 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 )
  5. 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.
  6. @bernhard, thanks! Quite an elegant solution, works like a charm.
  7. 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.
  8. 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 🙂
  9. 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 )
  10. Hi friends! And thanks for Processwire! I have an interesting question concerning selectors. Let's suppose we have an "inventory" template with "owner" repeater holding all users who owned this inventory. The last repeater item represents the current owner. Is there any possibility to select an inventory page by some data contained in its last owner repeater item? Some pseudocode to clarify what i want: //getting inventory recently owned by different users by currently owned by current user $myInventoryPage = $pages->get("template=inventory,owners(last).id={$user->id}"); Using owners.id is not an option here because the "owner" repeater may contain the current user in any position, not the last one. Thanks in advance for any idea!
  11. Hi friends! And thanks for Processwire! Maybe i'm missing something, but i have no idea how to select an (admin) page by the process it uses. It could look this: "template=admin,process=my_process_name" This could be a great help while using a perfect ProcessSettingsFactory module (many thanks to @Macrura!). That module allows to create admin settings pages, each holding a certain set of configurable data fields. Getting that fields is a piece of cake: $settings = $settingsFactory->getSettings('general'); //'general' is the name of admin page holding the settings $phone = $settings->phone; Works great when we need quite a limited number of settings. But when the things are getting bigger, it becomes quite reasonable to create a number of settings pages and to organize all the settings into a unified structure. Here's an example how it could be: //getting all settings pages $settingsPages = $pages->find("template=admin,process=ProcessSettingsFactory"); //creating the settings object $settings = (Object)[]; //putting all data from settings pages into $settings object foreach( $settingsPages as $settingsPage ){ $settingName = $settingsPage->name; //e.g. 'general' $settings->$settingName = $settingsFactory->getSettings($settingName); } //now we can use the $settings object echo "<a href=mailto:{$settings->general->email}>Mail us!</a>"; This approach definitely requires a process-specific selector. Guess that it could also be implemented at module level but having a specific selector for process could be useful in a large number of tasks. Will appreciate any idea )
  12. @Jan Romero, You're super cool! That extra slash in form action value resolves the problem. Thanks a lot!
  13. Hi friends! And thanks for Processwire! I've got a strange PW behavior which i cannot explain. Maybe i'm missing something. I have a form with method=post and action=action_page (different from page where the form resides). I'm trying to use post vars in the action_page's template. Both $_POST and $input->post() are empty. Deeper analysis shows that PW performs a http 301 redirect to action_page after the form is submitted, so all post vars are no longer available. How can i prevent PW from doing so? Did some simple tests to find the reason, i'm 95% sure that the redirect is triggered by PW. Thanks in advance for any advice!
  14. Hi everybody! And thanks for Processwire! I like PW hooks and use them in almost all of my projects. But it appears i'm missing some functionality. Some pseudocode to explain my wishlist: //somewhere in site/ready.php addHookClass('Page(template=my_template)::my_data', function($event) { ... } //somewhere in site/templates/my_template.php var_dump($page->my_data); //should output a multilevel array or nested objects $page->my_data->set('some_var',$some_value); //doesn't write to database $page->my_data->save(); //$page->save('my_data') is not applicable here because my_data is not a regular PW data field In fact i'm trying to create a solution for manipulating per-user settings (how to display some data on some pages etc.) but this approach may appear to be useful in different cases. Any suggestions are welcome!
  15. Just to clarify the situation. It appears that i've run into Firefox memory issues. I have many Firefox tabs and windows opened at the same time, and sometimes it may lead to strange effects concerning sessions and cookies. So it's not a Processwire-related issue. Hope this will be useful for someone.
  • Create New...