Jump to content


  • Posts

  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Andi's Achievements

Jr. Member

Jr. Member (3/6)



  1. As much as I appreciate @bernhard's faith in my motivation (😄), and as much as I'd like to contribute, that would at this point go way above my head.. I keep pushing the day where I'll finally take a dive and learn to use git/hub/lab. And I'm still struggling to find my way around these "new" development tools and procedures.. Lots of ground to cover there currently. But yeah this seems like something that would be really useful. Maybe even as some kind of default way of dealing with user input, as I currently could only think of fringe cases where someone would not want to have this enabled..
  2. After some more testing I feel like this should be safe to implement on the production site.. The only remaining issue at this point being.. The image description input fields seem to be a different kind of beast altogether.. Is there any way to extend the hook to cover these as well?
  3. Ok ... ->count() 🙂 in site/ready.php /** * run all Text and Textarea input fields through UTF-8 normalization * requires justb3a's TextformatterNormalizeUtf8 module * https://modules.processwire.com/modules/textformatter-normalize-utf8/ * * @var Inputfield $inputfield * @var WireInputData $input * @var Language $language * */ $wire->addHookBefore('InputfieldTextarea::processInput, InputfieldText::processInput', function (HookEvent $event) { $inputfield = $event->object; $input = $event->arguments(0); if (wire()->modules->isInstalled("TextformatterNormalizeUtf8")) { if ($this->languages && $this->languages->count() > 1) { foreach ($this->languages as $language) { $input_var_name = $language->isDefault() ? $inputfield->name : "{$inputfield->name}__{$language->id}"; $normalize_input = $input->$input_var_name; wire()->modules->get('TextformatterNormalizeUtf8')->format($normalize_input); $input->set($input_var_name, $normalize_input); } } else { $input_var_name = $inputfield->name; $normalize_input = $input->$input_var_name; wire()->modules->get('TextformatterNormalizeUtf8')->format($normalize_input); $input->set($input_var_name, $normalize_input); } } $event->arguments(0, $input); }); This is by no means thoroughly tested.. Use at your own risk 😉 Does anyone see how there could be any downsides to this approach on a live PW site?
  4. So on the input side of things.. I'm thinking, since we don't know about ..but we have @justb3a's module we could combine @interrobang's idea of hooking into InputfieldTextarea::processInput with calling the textformatter module to sort out normalization right off the bat.. This almost works 😉 $wire->addHookBefore('InputfieldTextarea::processInput, InputfieldText::processInput', function (HookEvent $event) { /** @var Inputfield $inputfield */ /** @var WireInputData $input */ /** @var Language $language */ $inputfield = $event->object; $input = $event->arguments(0); if (wire()->modules->isInstalled("TextformatterNormalizeUtf8")) { bd($this->languages); // ### this doesn't seem to be an array ### if ($this->languages && $this->languages->count > 1) { // ### this part never gets called ### foreach ($this->languages as $language) { bd("language loop"); $input_var_name = $language->isDefault() ? $inputfield->name : "{$inputfield->name}__{$language->id}"; $normalize_input = $input->$input_var_name; wire()->modules->get('TextformatterNormalizeUtf8')->format($normalize_input); bd("$input_var_name :: $normalize_input"); $input->set($input_var_name, $normalize_input); } } else { // ### this part works ### $input_var_name = $inputfield->name; $normalize_input = $input->$input_var_name; wire()->modules->get('TextformatterNormalizeUtf8')->format($normalize_input); $input->set($input_var_name, $normalize_input); bd("$input_var_name :: $normalize_input"); } } $event->arguments(0, $input); }); With this, utf-8 normalizing works for the default language input fields, but currently all others remain untouched. I tried looking around for a working example of how to get to the language fields, but no luck so far.. Also feeling just a tad bit twitchy about hooking in at such a deep level, but so far no problems during testing.. Does anyone have an idea where I'm going wrong here? Thanks and all the best..! Almost there I think 😄
  5. Haha @bernhard easy on me.. Still coding like it's 2005 over here.. Guess the 10 year break made me miss out on a whole lot of stuff 😉 Good lord I'm glad these arrays are no longer needed 😄 if ($modules->isInstalled("TextformatterNormalizeUtf8")) { $pgs = $pages->find("template=artist"); foreach($pgs as $p) { $p->of(false); $summary=$p->summary; bd("OLD: $summary"); $this->modules->get('TextformatterNormalizeUtf8')->format($summary); bd("NORMALIZED: $summary"); $p->summary = $summary; $p->save('summary'); } }
  6. Just getting started here but I can already confirm that @justb3a's module completely fixes this issue on the frontend side of things.. Now I'd basically just need to find a simple way to run every text & textarea field in both language versions through the normalizer.. Actually also pagetitle fields.. Or ideally, literally every bit of text that's being saved to the database.. Or would there be any downsides to that at all? --- Module works fine on PW v3.0.148 by the way
  7. I'm aware of that, but thanks for pointing it out @interrobang Thought I just put that here for future reference, I'm imagining many people (like me until 3 hrs ago 🙂) haven't even heard of the term utf normalization. That thread at the wordpress tracker is a great read btw. There's a lot there already, so I think we should be able to get this whole thing sorted out by tomorrow night. Cheers & danke vielmals 😉
  8. Always helps to know what you're looking for 🙂 https://modules.processwire.com/modules/textformatter-normalize-utf8/ Thanks for the pointers @interrobang, this is going to help a lot..
  9. Haha ok looks like you're right on the money 🙂 Awesome stuff, that really makes this all seem a little less nonsensical.. I'll absolutely make sure of that.. Will set this up tomorrow first thing in the morning and report back. Thank you all for your help and advice! Schönen Feierabend! 😉
  10. Hey @interrobang, thanks a bunch. A different angle altogether.. And I guess I'll need to read up on utf normalization a little bit 🙂 https://stackoverflow.com/a/7934397 Guess the problem is that I don't actually, on a technical level, understand what's happening at all.. But that does sound like we're headed in the right direction here.. I'll set up a testbed tomorrow on my localhost and try this approach, since we've already pretty much ironed out all the problematic database records on the dev site. So am I understanding correctly that this hook would also utf-normalize textarea fields for existing records, as long as a user opened the page for editing and just hit save once? Thanks again and greetings from Regensburg 😉
  11. Haha ok then maybe it should also be mentioned that on both of my Linux machines none of this cr#p is any issue at all 🙂
  12. Haven't gotten to the coding part yet, but we had a longer team conference this morning and tried to narrow down this issue a little bit.. In the name of science, so to speak. We tried 4 people with 4 different setups, all copy/pasting to PW from the same PDF file, and those were the results: #1 macOS High Sierra 10.13.6 - Apple PDF Preview -> PW: Broken diacritics - Acrobat Reader -> PW: Broken diacritics - Google Drive (Browser) internal document viewer -> PW : Good diacritics #2 macOS Catalina 10.15.4 - Acrobat Reader -> PW: Good diacritics - Acrobat Reader -> Text Editor -> PW: Broken diacritics (no idea why..) - Google Drive (Browser) internal document viewer -> PW : Good diacritics #3 Windows 10 - No Problems with diacritics during copy/paste #4 Windows 7 - No Problems with diacritics during copy/paste So although I'll still have to implement a hook to deal with the existing records in the database, I think we've established a workflow for #1 to get clean data into the system right off the bat, or at least for the time being.
  13. @bernhard how did I totally overlook that all this time? 🙂 So if I wanted to use this on more than one fieldtype on a multilingual site I'd just need two nested foreach-loops in // Something along these lines? public function replaceBadUmlauts(HookEvent $event) { $page = $event->arguments(0); $bad = array("ü","ö","ä","Ü","Ä","Ö"); $good = array("ü","ö","ä","Ü","Ä","Ö"); $fields = ?? somehow get fields into an array; foreach ( ??fields as $field) { foreach ( ??languages as $language) { $page->??field = str_replace($bad, $good, $page->??field); } } } I'll need to dig into the documentation a little bit and see how to do this.. Thanks for putting me on the track!
  14. Haha thanks @bernhard, you're the man. Think I'm ready to be a PW module coder just yet..? Still a little scared of hooks although it is getting better 🙂 This looks promising, I'll get on it after breakfast 😉
  15. Part III So the questions would of course then be... 1. What the flying f&#k is this sh#t 🙂 2. how would I approach getting all this into a hook (I'm thinking on saveReady maybe?) so this would be fixed automatically for summary & body for both language versions of the page - whenever the user pastes another crazy mess of trematized Umlaut madness into an artists profile? 😄 Thank you all in advance & god bless.. Glad I finally got this off my chest
  • Create New...