eelkenet

@Sanyaissues Of course I could do that, and thank you for your pointers. But my main take away here is: if you offer a site-wide search, it should be a good search. This is even more important for a site like processwire.com, where you should use any opportunity to demonstrate why PW is a good CMS. The whole idea of users having to use external tools in order to find the content of a content management system website... is rather painful.

Maybe we can extend the site-wide search to include the body / description of modules as well, be it with less priority? This is an example of a use case: I knew a module exists that uses DeepL to translate site content, but when I searched for DeepL I got 0 results: https://processwire.com/search/?q=DeepL. However, DeepL gets mentioned 5 times in the body of this module page. It was only until I tried searching for terms like 'Translate' that I could find this module. Edit: there is another module that I missed and in my opinion should have popped up.

Thanks for all the work! I can see clear improvements on lots of places. A couple of things that I bumped into, some of which have been mentioned already: We not just need separate color pickers for light and dark themes, but also logo url fields (I have a white logo which now disappears completely in light mode) Primary buttons should be in the primary color, which is not the same as black! I find these very unclear and even distracting when quickly scanning the page. Return or optionally enable regular checkboxes, please. Accessibility is low. Low hanging fruit: make sure you get :focus, :focus-within working, right now its impossibly hard to see when a 'toggle' or close button is selected. Use https://wave.webaim.org/ to check the rest. (this is a tip for all reading this) Selected icons (in edit template / field) disappears from the list: Again thanks for the work and looking forward to whats next!

The future is here! And this is me from 2025 thanking you for your input from 2019 🙂

Excuse me if I am wrong, but is this not what Module::upgrade($fromVersion, $toVersion) was intended for? Or do you specifically not want to bump a version number?

Hi, I've created a very simple module, that displays the number of (PagesVersions) versions a page has in the Page List: https://github.com/eelke/ProcessPageListVersionsCounter I expect something like to become part of the PW core as the PagesVersions implementation matures, but in the meantime it could be useful to others. So I'm posting it here.

Hi @ryan, (hopefully) a minor request: can the PagesVersions methods please become hookable? In my use case, I use WireCache to cache the rendering of some data. And by hooking after Page::saved I can clean that cache automatically everytime the page is saved. I would like to be able to do the same for data coming from other page versions. Thank you!

I have moved away from the Double JWT solution for now, as PHP sessions seem to work fine for my application. Also I managed to implement TFA validation, by editing the `classes/Auth.php` file. That seemed to be the only way I could do so: I tried hooking into ___doLogin() but couldnt figure out the order of things. See below! So, I replaced line 164: $loggedIn = $this->wire('session')->login($user->name, $password); With // Add Tfa authentication through TfaTotp if ($user->hasTfa()) { $tfa = $user->hasTfa(true); // Get code from incoming data // This only works if credentials + 2FA get sent inside the body $code = null; if ( isset($data->tfacode) && !empty('' . $data->tfacode) ) { $code = $data->tfacode; } $settings = $tfa->getUserSettings($user); if ($code && $tfa->isValidUserCode($user, $code, $settings)) { $loggedIn = $this->wire('session')->login($user->name, $password); } else { throw new AuthException("Invalid TFA code", 401); } } else { $loggedIn = $this->wire('session')->login($user->name, $password); } And then added the 2FA in the body request: // inside a log-in method const credentials = { email: this.identification, password: this.password, tfacode: this.tfacode, }; const response = await fetch('/api/auth', { method: 'POST', headers: { 'Content-Type': 'application/json', 'x-api-key': 'MY_API_KEY', }, body: JSON.stringify(credentials), }); if (response.ok) { return response.json(); } else { let error = await response.json(); throw new Error(JSON.stringify(error)); } I have also managed to do a proof of concept of a register route that works in combination with the TfaTotp module, but that needs some polishing. Update: I figured out that, in order to get be able to hook into Auth::doLogin, I needed to check the 'Deactivate URL Hook' toggle in the AppApi module settings. After doing so, I can now successfully hook and check for the Tfa, hurrah! // In ready.php wire()->addHookAfter('Auth::doLogin', function (HookEvent $event) { $log = wire('log'); $session = wire('session'); // Get the original return value of ___doLogin $originalReturnValue = $event->return; // Check if the original login was successful if (isset($originalReturnValue['username']) && !empty($originalReturnValue['username'])) { $username = $originalReturnValue['username']; $user = $event->wire('users')->get("name=$username"); // Check if the user has TFA activated if ($user->hasTfa()) { $tfa = $user->hasTfa(true); // Get code from incoming data // This only works if 2FA gets sent inside the body, along with password and username $data = $event->arguments(0); $code = null; if (isset($data->tfacode) && !empty('' . $data->tfacode)) { $code = $data->tfacode; } $settings = $tfa->getUserSettings($user); if ($code && $tfa->isValidUserCode($user, $code, $settings)) { $log->save("tfaLogin", "Tfa code = correct!"); $event->return = $originalReturnValue; } // Incorrect Tfa, sign out and throw 401 else { $log->save("tfaLogin", "Tfa code = incorrect, do not allow logging in"); $session->logout(); throw new AuthException("Code incorrect!", 401); } } // No Tfa enabled, sign out and throw 401 else { $log->save("tfaLogin", "User does not have Tfa enabled.. do not allow logging in!"); $session->logout(); throw new AuthException("TFA not enabled!", 401); } } });

Hi @Sebi, I'm about to start work on a web-app that will (hopefully) use AppApi with 2-factor authentication, using the TOTP module from Ryan. I would like to use the Double JWT authentication for the most secure set-up. As I understand, this would currently not be possible, except maybe if I resort to PHP session instead and create my own login endpoint that implements some of the TfaTotp module methods. Is that correct? Or do you have any pointers as to how to implement this with Double JWT?

Any reason for not using PW's own $input variable? https://processwire.com/api/ref/wire-input/ First of all, your example code should probably be a POST request as you are submitting data and not requesting a page for instance. Then you can simply log the received data with something like this, in order to get the content from your object {'daten':'...'}, and validate it as email. $email = $input->post("daten", "email"); if ($email) { //... do what you need to do. For instance create a record, and echo some valid JSON as a status message to display to the user. }

Hi @kixe, thank you for this very handy module. I've come up with a situation where I would like access to the $hsl value that lives inside the formatColorString method. So I would kindly like to request you add a 10th output: the pure HSL value as an indexed array. At the FieldtypeColor::___getConfigInputFields method, you could add $f->addOption(10, $this->_('array([0,360], [69.2%], [56.7%]) indexed array: H,S,L')); And then the end of the FieldtypeColor::formatColorString method, you could add if ($of === 10) { return $hsl; } If you want I can make a pull request for this, but since it's a minor change maybe this way is fine too? Thanks again!

Hi @charger, Good idea! I've pushed a new version with a defaultValue field, where you should be able to accomplish what you need. Please let me know if you bump into any issues?

Thanks @Robin S! That seems like a smart solution. I didn't know about renderReadyHook before.

Update: I have, in a way, accomplished my goals! I have not been successful at adding any <optgroup>s, BUT I did figure out a way around my issue. Instead of adding the unsupported optgroups, I just inject extra, disabled <option>s. These options can get a label, so I can use them as sort of dividers between the rows of pages Currently I group them by template name, as the selector for the field has that as primary sorting anyway. Pretty simple.. as always with these things, once you figure it out <?php $wire->addHookAfter("InputfieldAsmSelect(name=linked)::render", function ($event) { $html = $event->return; // Get the input field in order to sanitize new values /** @var Inputfield $input */ $input = $event->object; // Create a DOMDocument object and load the html from the Inputfield $dom = new \DOMDocument; $dom->loadHTML($html); // Get the <select> and its childnodes $select = $dom->getElementsByTagName("select")->item(0); $options = $select->childNodes; // Keep track of the previous template name.. $prevTemplate = ''; //Loop through the childnodes for ($i = 0; $i < $options->length - 1; $i++) { $option = $options->item($i); if ($option && $option->attributes->getNamedItem('value')) { // Get the page onject $pageId = (int) $option->attributes->getNamedItem('value')->nodeValue; $page = $this->pages->get($pageId); // If a new template label is found.. if ($prevTemplate !== $page->template->label) { // Create a new <option> $newOption = $dom->createElement("option"); $newOption->setAttribute("disabled", true); $newOption->nodeValue = $input->entityEncode(mb_strtoupper($page->template->label)); // And simply insert it above the current <option> $select->insertBefore($newOption, $option); $prevTemplate = $page->template->label; } } } // Return the new HTML and add a paragraph to double prove this bit of code do its work $event->return = $dom->saveHTML(); }); I'd love to be able to add things like icons, and some more formatting.. but for now: pretty decent.

Thanks for your replies! After @bernhard's suggestion I tried returning a completely custom bit of <select><optgroup><option ...></option><optgroup></select>.. but I would not render at all. So after all of this, it seems that asmSelect completely ignores the returned <select> from the function and replaces it with its own version. So there I bumped into what @Robin S wrote: So yeah.. clearly my idea will never work, unless Ryan decides to suddenly merge a request from 7 years ago on a project which hasn't been updated in 10 years. For now I've decided to leave it, and use InputfieldTextTags instead, which seems a bit more friendly visually. No optgroups there either, and no idea on how I would implement that either. Bummer!