gebeer

Hello, I am trying to get the cleartext password in a hook on saveReady in an autoload module. But I get the already hashed value of the password: Session: pass: L1/CERxHKqXJCJkogk89O48b4bMnsqW What I have protected $templates = ["user", "server"]; public function init() { $this->pages->addHookAfter('saveReady', $this, 'hookSaveReady'); } public function hookSaveReady(HookEvent $event) { $page = $event->arguments[0]; if($page->isNew) return; if(!in_array($page->template, $this->templates)) return; if($page instanceof User) $this->collectUserData($page); } public function collectUserData($page) { foreach ($page->fields as $field) { /*if( $page->isChanged($field) ) */$this->message($field->name . ": " . $page->$field); } } I guess I am hooking too late in the process but have no idea where to place the hook instead. EDIT: same with addHookBefore

I' m not quite sure what you mean by reports. I am using Lister Pro to show all the signup pages that were stored for the events. They can then be filtered and sorted by event, by signup date etc. Possibilities are almost endless and depend on your specific scenario. It is definitely worth reading up on what Lister Pro can do. In particular interesting are the lister pro actions. You can export lists to CSV and more. This might sound like I am advertising the module here. And, hell yeah, I do because I find lister pro really useful and well worth the money

@LostKobraKai Wouldn't you actually need window.onload or $(window).load for that? $(document).ready fires when the DOM is ready and does not wait for all resources like scripts/images. See here and here.

I made an events page with PW where users can sign up for events. Every signup is stored as a page in PW. Reports for events/attendees can be managed through Lister Pro. You could code your own Action for Lister Pro without too much hassle for sending out group reminders/confirmation.

Hi BernhardB, I have a small module that injects a script tag right before </body>. Here's the relevant lines public function init() { $this->addHookAfter('Page::render', $this, 'addInlineScript'); } public function addInlineScript($event) { $page = $event->object; if ($page->template->name !== "admin" && $page->inlineScript) { $event->return = str_replace("</body>", $page->inlineScript . "</body>", $event->return); } } You can adjust that to your situation. Hope it helps.

Frontend members area is no problem at all with PW. You just need to build the login logic via API. I built this with no prior experience with help from the forum. Now there is also a module out there: http://modules.processwire.com/modules/frontend-user/ And this thread is worth reading. Going on from there you either use Form Builder for your forms or you create them via the API and do validation etc yourself. As for the paypal integration, I have no experience myself. But you may find some useful info/code here: https://processwire.com/talk/topic/5281-paypal-payment-method-for-processwire-shop/

I had this issue once with a client site for a photographer. It turned out to be a color profile issue, like mentioned by elabx. Converting images to sRGB before upload solved it for me.

Am I on the right path at all when I try and replace the ___setPass($value) method so that it sets $this->data['hash'] = $value (value that gets passed in to the method)?

@LostKobraKai Thank you. I will look into the Lister Pro Action. Meanwhile I decided to export the users including their hashed password to csv with // get desired users $array = []; $us = $users->find("roles=frontend"); foreach ($us as $key => $u) { $u->of(false); $array[$key] = ["id" => $u->id, "name" => $u->name, "email" => $u->email, "pass" => $u->pass]; } // write to file $fp = fopen('./inc/users.csv', 'w'); $i = 0; foreach ($array as $fields) { // Add headings to the first line. if($i==0) fputcsv($fp, array_keys($fields), ","); fputcsv($fp, $fields); $i++; } fclose($fp); Now I am looking into a way to import the users in the new PW install via API and in that process bypassing the regular $user->pass method for setting the password. So that I can store the hashed password as is during import. Then I'd only need to copy over the salt from the original PW install and the users should be able to login. But when looking at the ___setPass($value) method in /wire/core/Password.php, I am not sure how to hook into it and make it just save the supplied value. Also, looking at /wire/core/User.php, I don't see how this is connected to the Password class or vice versa.

I am trying to find a solution for having same users with same passwords in 2 different PW installs and came across this thread. How would I export the user table? There is no such table as users are pages. So I would need to construct a MySQL query that gets all pages with user template and also grab required fields name, pass, email. Then the other tricky part would be to import that into the new PW install. Is there a PW API side solution that also tranfers the password hashes to the new install?

I can confirm that on FF41.0.2 Linux Mint at 1920x1055. The issue with the footer moving down is related to the stickyFooter.js which applies a margin-top: 137px; once it kicks in. I always had troubles with sticky footer js plugins. Since I found this nice CSS solution: http://mystrd.at/modern-clean-css-sticky-footer/, I am happy. It requires a fixed height for the footer, but you already have that.

@BitPoet Thanks a lot. I just tested this and it brings the desired results.

Hello, after an update from 2.6.x to 2.7.1 I always get the annoying alert "This page is asking you to confirm that you want to leave - data you have entered may not be saved. Stay on Page | Leave Page " Even if there are no changes on the page. E.g I open a page and then leave it straight away -> alert is showing. EDIT: Default admin theme Installed modules: Site: AIOM PageRenameOptions (already uninstalled - non change) FieldtypeFontIconPicker Leaflet Map Marker Markup Simple Navigation Database Backups Upgrades Core: Languages Support Languages Support - Page Names Languages Support - Tabs Page Title (Multi-Language) Text (Multi-language) Textarea (Multi-language) This happens in both FF and Chrome and I can't see anythings suspicious in the JS console. What can I do to get rid of the alert for pages with no changes?

Hello, I would like to find all fields that are multi-language. My code $langFields = new FieldsArray; foreach ($fields as $f) { if($f->type instanceof FieldtypePageTitleLanguage || $f->type instanceof FieldtypeTextareaLanguage || $f->type instanceof FieldtypeTextLanguage) { $langFields->add($f); } } Is there a more generic way of how I can determine whether a field is multi language, other than checking "$f->type instanceof" for all three fieldtypes?

Thank you for the hint. I had not enabled that option. After enabling it, all is fine now. Should have looked at the module settings more carefully

Thank you for this module! I have a string "../modules/FieldtypeLeafletMapMarker/assets/leaflet/leaflet.css" in my styles array. But AIOM cannot read it. I get Warning: file_get_contents(): Filename cannot be empty But it should be the correct relative path to leaflet.css seen from site/templates/_main.php. I don't understand why it is not working. Passing in "css/styles.css" is working fine. I read Soma's post and agree that it should be possible to pass in files from outside /templates. I already tried his proposed fix in conjunction with passing in "/site/modules/FieldtypeLeafletMapMarker/assets/leaflet/leaflet.css" but that didn't work either for me.

I am still investigating the strange behaviour of placing a var_dump() in the code preventing the error like I described in #11 Reading up on var_dump() in the PHP docs, I found this: In the foreach that loops through the page fields, why does resetting the internal pointer of the fields array make a difference and what can I change in my code to avoid the error in the first place?

I managed to successfully change my default language Everything went quite smoothly, except for some strange errors that I desribed above and which might be related to my particular environment. Here my complete function for swapping a language with the default language. Instructions for necessary steps after swapping languages are included. <?php function swapLanguages($pages, $lang) { $startTime = microtime(true); $langDefault = "default"; $log = ["languages" => "Swap field values for language {$langDefault} with {$lang}", "pages" =>[]]; $languages = wire("languages"); // get languages $l1 = $languages->get($langDefault); $l2 = $languages->get($lang); foreach ($pages as $p) { $log["pages"][$p->id] = ""; $fieldlog = " name"; $p->of(false); // swap page names $nameDefault = $p->localName($l1); $name = $p->localName($l2); if($nameDefault != $name && !empty($name)) { $p->set("name",$name); $p->set("status$l2",1); $p->set("name$l2",$nameDefault); } elseif($nameDefault != $name && empty($name)) { $p->set("status$l2",1); $p->set("name$l2",$nameDefault); } // iterate through all fields and swap multi language field values foreach ($p->template->fieldgroup as $field) { if($field->type instanceof FieldtypePageTitleLanguage || $field->type instanceof FieldtypeTextareaLanguage || $field->type instanceof TextLanguage) { $fieldlog .= " {$field->name}"; // var_dump($p->$field); // needed this for some pages otherwise they threw an error // $p->of(false); // needed this for some pages otherwise they threw an error $langDefault = $p->$field->getLanguageValue($l1); $lang = $p->$field->getLanguageValue($l2); if( $langDefault != $lang && !empty($lang) && !empty($langDefault) ) { $p->$field->setLanguageValue($l1, $lang); $p->$field->setLanguageValue($l2, $langDefault); } elseif( $langDefault != $lang && empty($lang) ) { $p->$field->setLanguageValue($l2, $langDefault); } elseif( $langDefault != $lang && empty($langDefault) ) { // only needed this for pages that got created through API and had no default lang value set $p->$field->setLanguageValue($l1, $lang); } } } try { $p->save(); $log["pages"][$p->id] = "Swapped values in fields: {$fieldlog}"; } catch (Exception $e) { $log["pages"][$p->id] = 'Error: ' . $e->getMessage(); } $p->of(true); } // write logfile $logfile = fopen(wire("config")->paths->logs . "swaplanguage-log.txt", "w") or die("Unable to open file!"); $iterator = new RecursiveIteratorIterator(new RecursiveArrayIterator($log)); foreach($iterator as $key => $value) { fwrite($logfile, "$key => $value\n"); } fclose($logfile); $time_elapsed = microtime(true) - $startTime; echo "Finished after {$time_elapsed} seconds"; } /* Usage: // swapLanguages($pages->find("template=basic-page, parent=1, include=all"), "de"); // argument 1: pages array // argument 2: language name that you want to swap with the default language // A log file will be written to site/assets/logs/swaplanguage-log.txt. // It contains page IDs and fields that were swapped for each page */ /* // After executing this function for all required pages, following steps are needed: // 1. load core translation files for the language that is now your default (e.g. german translation files) to Setup->languages->default // 2. change titles of the default Language to your language (e.g. Deutsch) and the language that got swapped (e.g. English) // 3. if default language was English before swapping: delete core translation files for the language that you swapped // 4. if default language was not English before swapping: load the core translation files for that language // 4. in settings for home page, change the URL for your default language and the language that you have swapped. // Example: // Before swapping: default was en, swap language was de // After swapping: default is now de, swapped language is now en */ The function will swap page names and the contents of multi-language fields TextAreaLanguage and PageTitleLanguage. If any of you know a more generic way of checking whether a field is multi language, other than if($field->type instanceof FieldtypePageTitleLanguage || $field->type instanceof FieldtypeTextareaLanguage) that would be great. The function is also available as swap-languages.php gist. EDIT: Added field type TextLanguage to the fields that will be processed.

Replacing the dynamic variable names didn't help either. I observe that this is happening only for some pages. Now I need to go and find out what these pages have in common or what makes them different from the pages that are working.

Now I found a pattern. When I have the var_dump($p->$field); in place, it is working. When I comment it out, I get the error. What can that be? EDIT: I don"t even need the $p->of(false) in the foreach loop. As long as thje var_dump is in place, the error is gone.

No, I set $p->of(false) just before these operations. I also tried with including $p->of(false) in the foreach. EDIT: @LostKobraKai : thank you! I changed my foreach to foreach ($p->template->fieldgroup as $field) { if($field->type instanceof FieldtypePageTitleLanguage || $field->type instanceof FieldtypeTextareaLanguage) { $fieldlog .= " {$field->name}"; var_dump($p->$field); $p->of(false); $$langDefault = $p->$field->getLanguageValue($l1); $$lang = $p->$field->getLanguageValue($l2); $p->$field->setLanguageValue($l1, $$lang); $p->$field->setLanguageValue($l2, $$langDefault); } } Strange, when I tested earlier, I had the $p->of(false) before the if statement and it wouldn't do. EDIT again: And now I suddenly get the error again, on a different page even with $p->of(false) in place. I just found that after reloading the edit screen for the page in the backend, the error disappears.

In my language swap function, I iterate over all page fields and swap the languages only for multi language fields var_dump($p->id); foreach ($p->template->fieldgroup as $field) { if($field->type instanceof FieldtypePageTitleLanguage || $field->type instanceof FieldtypeTextareaLanguage) { $fieldlog .= " {$field->name}"; var_dump($p->$field); $$langDefault = $p->getLanguageValue($l1); $$lang = $p->$field->getLanguageValue($l2); //line 268 $p->$field->setLanguageValue($l1, $$lang); $p->$field->setLanguageValue($l2, $$langDefault); } } What is really boggling me is that for some pages that all have the same template basic-page, this code works fine. But for others it throws an error Fatal error: Call to a member function getLanguageValue() on string in /var/www/utgpw/site/templates/convert.php on line 268 the var_dump reveals int 27 object(LanguagesPageFieldValue)[372] public 'default' => string '404 Not Found' (length=13) public 'de' => string '' (length=0) public 'fr' => string '' (length=0) public 'es' => string '' (length=0) object(LanguagesPageFieldValue)[395] public 'default' => string '' (length=0) public 'de' => string '' (length=0) public 'fr' => string '' (length=0) public 'es' => string '' (length=0) int 1421 object(LanguagesPageFieldValue)[376] public 'default' => string 'Mantak Chia' (length=11) public 'de' => string '' (length=0) public 'fr' => string '' (length=0) public 'es' => string '' (length=0) string '<p>test</p>' (length=11) For the same field of type TextAreaLanguage in one case "$p->$field" returns an opject and in the other case a string. Now why is that? Pages where this happens have been imported through the API. I can't pull up the code that I used for the import because it is some time ago. The affected pages are working fine in the frontend, though.

@tpr Then they would be presented with a backend in English. But they should have the backend in their native language. I also do page manipulations through frontend forms and there the user language determines for language fields which language to populate. So your suggestion is not an option. I am currently writing a language value swap function and will report back here.

@tpr Thanks for the suggestions. As I wrote in solution #1 in my first post, from the frontend side that solution would work. But it brings problems in the backend when users with non default language are creating pages. Because page title values only fall back from default to non default languages and not vice versa. To illustrate this: user has language German assigned and creates new event. There he gets presented with the "Deutsch" Tab of the title field where he fills in his title. Now he hits save and gets an error, because there is only a german title and page name. And the default (English) title and page name do not fall back to the german value

Came across this while importimg lots of pages. I agree with rajo, that languages should be activated by default when creating pages via API. ATM it is not obvious that we have to do it manually. And I just realized it after already having imported some 300 pages