dragan

@picarica Could you please use a more civilized language in here? I'm no PW forum admin, but I'm pretty sure the F*** word is not welcome here. If you have a problem with that particular module, you should post your question in the respective support forum instead:

@modifiedcontent you can do $users->find("roles=superuser"); $users->find("roles=superuser")->first; yes, PW doesn't limit the number of superusers to just one single user.

I don't think so... the trick with PW hooks is to find out which hook to use, and whether to use before or after. Page::loaded seems to be the wrong method to hook into for what you want to achieve. Here are some code-bits I used in the past, and they all work as expected (inside site/ready.php) $this->addHookAfter('Pages::saveReady', function (HookEvent $event) { $page = $event->arguments[0]; // ---------- $pages->addHookAfter("ProcessPageEdit::buildForm", function (HookEvent $event) { $page = $event->object->getPage(); $form = $event->return; // ---------- $this->addHookBefore('Pages::saved(template=invoice, parent=23444)', function(HookEvent $event) { $page = $event->arguments(0);

I guess you need to use a hook.

That's where a proper IDE should kick in, to do its stuff (auto-suggest/auto-complete etc.). Mere text-editors can only do so much... With PW, that didn't really work so well for a long time. But if you enable the Functions API, and use page() instead of $page in your code, you'll get the hints in your working environment. /** * Allow core API variables to also be accessed as functions? * * Recommended. This enables API varibles like $pages to also be accessed as pages(), * as an example. And so on for most other core variables. * * Benefits are better type hinting, always in scope, and potentially shorter API calls. * See the file /wire/core/FunctionsAPI.php for details on these functions. * * @var bool * */ $config->useFunctionsAPI = true;

Did you do any of that? Do you have Tracy Debugger installed? Do you have debug mode enabled? Did you check if you have any hooks activated that could block your code? Saying "it doesn't work" without trying to debug each line of code makes it difficult to find the culprit, and for those people trying to help you. We don't even know your PW version, or what modules you have installed. For starters, what happens if you simplify the code and enter a few lines directly in the Tracy console (e.g. just edit the bio field). Does it work or not?

Well, insert debug code (Tracy's d($var) or plain print_r() etc.) to see if any of your variables/functions doesn't do what you think it should. body and fullname are certainly fields you have added to the user profile yourself, they're not part of the default user template. Perhaps you need to check those fields in the user template where it says "What fields can a user edit in their own profile?"

Well, I just tested out this on PW 3.0.167, and it works as expected: $user_roles = user()->roles; $user_roles_count = count($user_roles); // make sure the current user has more than just default "guest" role if (($user_roles_count > 1) && !input()->post->ts) { $u_name = user()->name; $u_id = user()->id; $here = page()->url; $ts = time(); $form = <<<EOF <h1>Hello $u_name . Would you like to change your password?</h1> <form method="post" action="$here"> <label for="new_pass">New password: <input type="password" id="new_pass" name="new_pass" autocomplete="false"> </label> <label for="new_pass2">Confirm new password: <input type="password" id="new_pass2" name="new_pass2" autocomplete="false"> </label> <input type="hidden" id="uid" name="uid" autocomplete="false" value="$u_id"> <input type="hidden" id="uname" name="uname" autocomplete="false" value="$u_name"> <input type="hidden" id="ts" name="ts" autocomplete="false" value="$ts"> <button type="submit">Change your password</button> </form> EOF; echo $form; } if (input()->post->ts && input()->post->new_pass && input()->post->new_pass2 && input()->post->uid) { $out = ''; $errCount = 0; $form_uid = input()->post->uid; $form_uname = input()->post->uname; $curr_uid = user()->id; $curr_uname = user()->name; $form_new_pass = input()->post->new_pass; $form_new_pass2 = input()->post->new_pass2; $form_ts = (int)input()->post->ts; $max_time = 30 * 60; // 30 minutes // If the POST arrives a half hour later, something is probably fishy if ($form_ts < (time() - $max_time)) { $errCount++; $out = "It seems that it took you longer than 30 minutes to change your password - your request has been blocked due to security concerns. Please try again."; } // user has maybe manipulated the hidden form input fields if (($curr_uid != $form_uid) || ($curr_uname != $form_uname)) { $errCount++; $out = "Your request has been blocked due to security concerns. Please try again."; } // for added security, I would highly suggest to take this note seriously @ https://cheatsheet.processwire.com/user/user-properties/user-pass/ // "you will need to add your own complexity checks for passwords to ensure they meet a minimum length and character requirement." // I'm not sure if there is an API sanitizer method available for this purpose // below is just a basic check to ensure both pw-field values are identical if (($form_new_pass !== $form_new_pass2)) { $errCount++; $out = "Your new passwords do not match. Please try again."; } // If we've got that far, we're ready to update the user's PW if ($errCount < 1) { $user_page = users()->get($curr_uid); $user_page->of(false); $user_page->pass = $form_new_pass; $user_page->save(); $out = "Success! Your account has been updated with the new password you've chosen."; } echo $out; } If syntax like user()->roles doesn't work in your installation, you can either enable it in site/config.php ($config->useFunctionsAPI = true;) or re-write it with $user / $page / $input notation.

First things I'd do: check PW logs check server error logs (Apache / PHP) inspect in the browser (JS errors) If you don't find any hints that way, you could see if it's a CSRF problem, or something to do with sessions. Switching to SessionHandlerDB can help (a core module). In one of my setups I had to put these two config values to false, when I encountered similar problems: $config->protectCSRF = false; $config->sessionFingerprint = false;

It's weird that mySQL Workbench doesn't show any INNODB_FT_DEFAULT_STOPWORD table, just these three: That's with version 5.7.24 though. It seems strange that I don't see that table, but PW search works just fine. You could try to use the Migration Wizard from Workbench (with a local copy), perhaps you'll get more control with your import. But ultimately, since this is a system table, maybe you don't have enough rights to manipulate that anyway on your hosting setup.

@DrQuincy Not much I can add here, other than maybe encouraging you to take a look at WireCache and MarkupCache, which is in core.

@PWaddict Did you mean to post this question in the FormBuilder (pro) forum? Otherwise you'd have to clarify what "by default" means (some kind of frontend-framework?).

You can go to site/assets/files/1234/ and send these JSON files to the translators. 1234 being the id of the alternative language. You'll see the language id @ setup/languages/ when you hover over the language edit link (1010 seems to be the default language). Before that, you'll want to make sure all those JSONs are there, so you'll need to click the "find files to translate" button @ setup/languages/edit/?id=10189 under "Site Translation Files". There's also two buttons there in the bottom-right for downloading all files as CSV or ZIP. When you get the translated JSON files back, you can upload them here as well, and replace the old ones.

Can you elaborate on this? Is the quantity derived from a page / selector count? And that's all you really need with all those queries? There are faster ways to get counts than to always return the full page arrays. (I probably miss the "big picture", sorry if it's a dumb question)

Variables like $page are reserved by PW, so you shouldn't try to redefine them. PW tries to find a field 'autores', which is not available in the current $page, but in the page array you're looping through. Try: foreach($pages as $p) { if(count($p->autores)) { If you install Tracy Debugger (which every PW developer should, imho), you can include debug output for variables, which is a big help when developing.