DV-JF Posted October 31, 2019 Share Posted October 31, 2019 Hi, maybe I've found a bug, but there's a behavior I can't explain: I'm trying to hook into Pages::saveReady with following code example: https://processwire-recipes.com/recipes/extending-page-save-process/ <?php /** * Hook the saving of pages to add own processes. * * ProcessWire 2.x * Copyright (C) 2014 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://processwire.com * */ class HookAfterPagesSave extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'HookAfterPageSave', 'version' => 1, 'summary' => 'Hook the saving of pages to add own processes.', 'singular' => true, // Limit the module to a single instance 'autoload' => true, // Load the module with every call to ProcessWire ); } public function init() { // init() is called when the module is loaded. // saveReady is a hook after processing the previous changes of the page, // but just before those changes are saved to the database. // It's called for each page that's being saved, no matter if it's in // the backend or in your templates via the api. $this->addHookAfter('Pages::saveReady', $this, 'afterSaveReady'); } In the afterSaveReady() function I'm trying to get the language property of the user who saved that page, but instead of returning the correct user language the default language is always returned. <? public function afterSaveReady($event) { $userLanguage = $this->user->language; bd($userLanguage); $this->message("User Language: ".$userLanguage); }; Here's the output and a test with the console of TracyDebugger Any ideas? Should I open a ticket here: https://github.com/processwire/processwire-issues/issues ? Many greets! 1 Link to comment Share on other sites More sharing options...
bernhard Posted October 31, 2019 Share Posted October 31, 2019 Just tested and I can confirm that behaviour: // ready.php bd($this->user->language, 'ready.php'); $wire->addHookAfter("Pages::saveReady", function() { bd($this->user->language, 'saveReady'); }); I have no explanation. Anyone? 1 Link to comment Share on other sites More sharing options...
dragan Posted October 31, 2019 Share Posted October 31, 2019 Yes, it's weird, and most probably a bug. Funny thing is that the current active language is recognized correctly (status10189 = 1), but language name and title are mixed up. 2 Link to comment Share on other sites More sharing options...
bernhard Posted November 1, 2019 Share Posted November 1, 2019 Thx @DV-JF I've gone ahead and created an issue: https://github.com/processwire/processwire-issues/issues/1020 1 Link to comment Share on other sites More sharing options...
DV-JF Posted November 1, 2019 Author Share Posted November 1, 2019 @bernhard Thank you for creating the issue in repo. 1 Link to comment Share on other sites More sharing options...
Noel Boss Posted November 3, 2019 Share Posted November 3, 2019 What does $languages->getLanguage(); return? I have instances where this gives me the correct Language. I also had flacky results with setLanguage and unsetLanguage… Overall, it feels like quite a bit a mess here ? I think, ProcessWire would do very good with some (unit)test… Also for the selector engine… 1 Link to comment Share on other sites More sharing options...
dragan Posted November 3, 2019 Share Posted November 3, 2019 1 hour ago, Noel Boss said: What does $languages->getLanguage(); return? That actually seems to work! Meanwhile, with latest PW dev, I get an error on line 242 (my screenshot above): ProcessPageEdit: Method ProcessWire::getCurrentUser does not exist or is not callable in this context This error didn't occur with the previous dev version o_O Link to comment Share on other sites More sharing options...
DV-JF Posted November 4, 2019 Author Share Posted November 4, 2019 On 11/3/2019 at 12:00 PM, Noel Boss said: What does $languages->getLanguage(); return? I have instances where this gives me the correct Language. When I do bd(wire('languages')->getLanguage()); in my module, I get an error: Session: Method Languages::getLanguage does not exist or is not callable in this context Link to comment Share on other sites More sharing options...
bernhard Posted November 5, 2019 Share Posted November 5, 2019 It's not a bug as Ryan just explained in the issue: Quote The pages.save operation is intentionally done while language is default. It changes it to default language at the beginning of save, and restores it back afterwards. This ensures that all fields are in a predictable state and language values don't get mixed up or overwrite each other. If you need to identify the language, you can hook either before or after Pages::save() as the language will be in its original state in either case. 2 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now