Roope

OK, thanks guys! Like @Robin S posted, we either have never experienced any problems with twitter (or any other some) handles. Can you @Macrura plese give me more detalied example about false positives you faced with? I was thinking that maybe I could add new 'execution method' to the module config where one could select whether to exclude/include email auto obfuscation at selected templates/pages or go full manual by using public method ever when needed. This would definitely be more flexible than the current route we have in use.

Not that I'm familiar with all of thease but first that pops out from the list is TemplateEngineFactory. I haven't used it and have no idea about the logic behind the scenes but if you could temporarily uninstall it and see what happens.

Thanks @Macrura - I'll try look into these shortly! Sorry, I meant $config->urls->siteModules... And is should read your other post mo carefully since you already mentioned that script block is not included in the end of the document so it's not about js script surely. Don't know what other module could be blocking this but what other 3rd party modules you have installed?

Hello @Barcelo! So email addresses are replaced by text set in module config but conversion back to email doesn't kick in, right? Double check that emo.js is really present because it sounds like there's the issue here. Maybe consider adding modules config url to the file path: <?php echo '<script src=" . $config->urls->modules . EmailObfuscation/emo.min.js"></script>'; ?>

Hi David! I've been super busy all year with our massive house renovation project and haven't got much time to do real work with customer projecs so this module is not tested yet on so many working sites. But it is in use at couple of released projects and works alright. Changes that I promised earlier for v1.1 are done. I haven't tested it on PW3 though, but I can't see no reason why it shouldn't work.

Thanks @horst! This'll do just fine. When I get v1.1 finished, I'll open specific forum thread for this and push it to the modules directory.

@horst - I'd need your help bit further with this one... When hooking to ImageSizer::resize is there a way to get the original resized Pageimage object? Your code example below had something like this: public function hookEventBeforeResize($event) { $this->image = $image = $event->object->image; } But $event->object->image is referring to the array that contains information about the image width and height, not the actual Pageimage. Also, as a reference if someone else is using info from this thread, on ImageSizer you can't set quality property directly - it'll throw fatal error (cannot access protected property ImageSizer::$quality). Instead there is a setter method for doing this: public function hookEventBeforeResize($event) { $image = $event->object; $image->setQuality(100); } Why I need Pageimage object from ImageSizer is that it would make returning compressed tiny variation a breeze when you can just clone the source Pageimage: private function tinyPageimage(Pageimage $image) { $tinyimage = null; $filename = $this->tinyFilename($image); // tiny image file exists, let's clone the original Pageimage if(is_file($filename) && filemtime($filename) >= filemtime($image->filename())) { $tinyimage = clone $image; } // tiny image file is not available, proceed if we can compress the source if(!$tinyimage && $this->compressionAllowed()) { // copy the original source and clone it if compression was ok if(copy($image->filename(), $filename)) { if($this->compressImage($filename) !== true) unlink($filename); else $tinyimage = clone $image; } else { throw new WireException("Failed to copy Tiny image variation: $filename"); } } // return tiny variation of Pageimage when available if($tinyimage instanceof Pageimage) { $original = $image->original ? : $image; $tinyimage->setFilename($filename); $tinyimage->setOriginal($original); return $tinyimage; } return $image; }

Thanks for the detailed info @horst! Much appreciated. Actually the first implementation of this was hooked to ImageSizer::resize but then I decided to abandon that route since while it was doing the actual compression alright, I was having hard time to figure out how to return tiny variation instead of uncompressed resized original from $image->size() call. That's why I chose hooking straight to Pageimage::size where it is easy to just replace return with tinifyed image. That said, I still can't see how this could be accomplished working only with ImageSizer::resize hooks (without overwriting the original resized source). How to tell PW we wan't to use tiny variation of a variation without hooking Pageimage::size? I definitely also want to support compressing original unresized images so Pageimage::tinify method is there to handle such a use cases (also serves us when auto mode is not preferred option). The point you gave here that with ImageSizer::resize we're able to use and modify $config->imageSizerOptions makes it clear that this is the right place to hook for compression. So what do you think if the routine would go like (simplified): Hook before ImageSizer::resize Check that tinify is not disabled at image options and compression can be done (API and stuff). Then set tinify flag and quality to 100%. Hook after ImageSizer::resize If tinify flag is set, copy and compress the image and save it to the page as tiny variation. Hook after Pageimage::size Check for tiny variation and return that if found. So basicly it would be just like your example for PW 2.5.11+ but Pageimage::size still hangs around to return tiny variation. Do you see any downside or is there still something I'm not getting? What goes for PW support, I wouldn't like this to be PW3 only. Specially right now when official stable is still PW2 and anyway it's going to stick around with us way longer. What I would like is to have at least one good solid release available for the PW2 - where support for 2.5.11 and up is reasonable enough. Then we're good to go ahead towards PW3 and make use of all the beauty that it brings (like ImageRenderingChains and stuff which I know none about). P.S. Forget what I wrote on previous post about ProcessPageEditImageSelect::executeResize() - it was just me tripping, not the PW. It works fine.

Hello adrianmak! How do you handle passing values to the PayPal checkout? Maybe you'll need something like this: if($user->language->isDefault()) { $value = $page->fieldname; } else { $value = $page->getLanguageValue($user->language, 'fieldname'); }

Thanks for the reply @horst! I was kind of hoping to get some feedback from you. I fully get the point about issue with uncontrolled auto mode but I don't quite understand what you mean by binding compression to defined suffix option. Currently auto mode is hooked after Pageimage::size and (if enabled) compression is done when given size is allowed, type matches (png/jpeg) and API is available (client connected and monthly compression limit no exceeded). By adding custom image sizer option we could disable auto compression on cases where further image manipulation is done and then handle it manually last in chain or do you have something more sophisticated in mind? $image->width(300, array('tinify'=>false))->pimLoad('prefix')->someManipulations()->pimSave()->tinify(); By the time it's also not prohibited to do re-compression to the images - maybe we should restrict such a use cases: // tinify already tinifyed image $page->image->tinify()->tinify(); // tinify resisized (and compressed) image when auto mode is enabled $page->image->size(100,100)->tinify(); I was thinking about forcing (jpeg) quality to 100% but then I thought we don't need that since if one want's to compress images sized at lower quality, why to restrain that. But when you say lower quality actually makes higher filesize we sure need forced 100%. Since compression is done to existing pageimages, we can only force 100% when image is resized by PW. Do you think something like this could work or again, do you have something else in mind? 1. Hook before Pageimage::size - Check for compression and if ok, save filename to runtime variable. 2. Hook before ImageSizer::resize - Set pageimage quality to 100% if jpeg and filename matches to the one in runtime var. 3. Hook after Pageimage::size - Do the compression and return tiny variation of a pageimage. Also I'd need your help (or maybe from @ryan) with resized images on rich text editors. First I thought hooking Pageimage::size would take care of this one also since it looks like that here in ProcessPageEditImageSelect::executeResize() but for some reason hook doesn't bite. Can you tell me why?

Hi all! Just wanted to let you know that something wicked is coming your way: https://github.com/BlowbackDesign/TinyPNG It's still pretty much "work in progress" but currently module works and you're able to compress Pageimages by either manually with added tinify() method or automatically when image is resized using size() method. Croppable images can also be compressed by adding tinify() to the returned Pageimage object. On next stage I'll add support for (resized) embedded images at richtext editor and maybe some other features if needed. Time is little short right now but I'll try to make it happen sooner than later. This module creates compressed images as a variation of original (or resized) image so any of the source files aren't overwritten. This ensures good quality and tries to avoid pixelated over compressed images. Module uses Tinify PHP client to connect TinyPNG API (and thus is available to use as is as an autoload module). Please feel free to try out and tell me what you think!

Thanks flo! Just pushed a fix to github. Please update and see if it helps.

Hello PWaddict! Haven't use AIOM but according to module readme you have to first enable Directory Traversal Filter: https://github.com/conclurer/ProcessWire-AIOM-All-In-One-Minify#directory-traversal-filter Then choose Load manually as Script file loading method at EMO config page and load required emo.js (or emo.min.js) with AIOM: <script src="<?php echo AIOM::JS('../modules/EmailObfuscation/emo.min.js'); ?>"></script>

Hello Christophe! Could you please tick debug mode on from module admin page and see what it outputs. Found email data is appended to page source after closing </html> tag. Do addresses look ok there?

OK, thanks! I've just pushed a fix to module repo. Please update and see if it works for you.

Hello guenter! Umlautes are working fine here - what kind of problems are you facing?

Thanks for info! Unfortunetaly I don't think there is any other option at the moment and I'm currently very busy with my projects so I don't have any time to debug the module right now but when I do, I'll get back to this. If you have time, you could paste here simplefied test case how to reproduce the issue. Thanks!

If you need recursive version of this, I think you need to modify code from @EvanFreyer a bit: <?php function buildNav(PageArray $pages) { $str = ''; foreach($pages as $item) { // class name for item wrapper // NOTE: since inside function we need to use wire() to get the current viewed page $class = $item->id == wire('page')->rootParent->id ? 'current ' : ''; if($item->hasChildren() && $item->id != 1) $class .= 'parent '; // open item wrapper if(!empty($class)) { $str .= "<li class='". rtrim($class) ."'>"; } else { $str .= "<li>"; } // item link element $str .= "<a href='$item->url' title='$item->title'>$item->title</a>"; // iterate possible childs // NOTE: except for homepage, since those are already included in the array // we pass to the function as first level pages (same logic added to class 'parent' name) if($item->hasChildren() && $item->id != 1) { $str .= buildNav($item->children); } // close item wrapper $str .= "</li>"; } // return ul list return "<ul>$str</ul>"; } ?> <nav class='topnav'> <?php echo buildNav($homepage->and($homepage->children)); ?> </nav>

Yes, while we loop the childs, we can check if the current $child id matches with the viewed $page id. // markup for possible childs if($item->hasChildren()) { echo "<ul>"; foreach($item->children as $child) { if($child->id == $page->id) { echo "<li class='current'>"; } else { echo "<li>"; } echo "<a href='$child->url'>$child->title</a></li>"; } echo "</ul>"; } $page is one of the predefined variables in processwire template files and it represents the current viewed page object. https://processwire.com/api/variables/ https://processwire.com/api/variables/page/ Logic is same when we set the class name for first the level item, except that instead of if else we use PHP Ternary Operator and check the $item id against $page->rootParent which represents the parent page closest to the homepage. // class name for item wrapper $class = $item->id == $page->rootParent->id ? 'current ' : ''; This way 'current' class name is added also when child of the item page is being viewed. <ul> <li class='current'> <a href='/item/'>Item</a> <ul> <li class='current'> <a href='/child/'>Child</a> </li> </ul> </li> </ul> If you don't like this behaviur and just want to actual current viewed page wrapper have this class name you can simply change the condition from $page->rootParent to $page: // class name for item wrapper $class = $item->id == $page->id ? 'current ' : '';

Hello kazu and welcome to the forum! If you'd like to output submenu for the current page, change the code like so: // iterate children of a current page object foreach($page->children as $item) as $item) { if($item->id == $page->id) { echo "<li class='current'>"; } else { echo "<li>"; } echo "<a href='$item->url'>$item->title</a></li>"; } And here's how to put it to the main menu: foreach($homepage->and($homepage->children) as $item) { // class name for item wrapper $class = $item->id == $page->rootParent->id ? 'current ' : ''; if($item->hasChildren()) $class .= 'parent '; // open item wrapper if(!empty($class)) { echo "<li class='". rtrim($class) ."'>"; } else { echo "<li>"; } // item link element echo "<a href='$item->url'>$item->title</a>"; // markup for possible childs if($item->hasChildren()) { echo "<ul>"; foreach($item->children as $child) { echo "<li><a href='$child->url'>$child->title</a></li>"; } echo "</ul>"; } // close item wrapper echo "</li>"; } If you like to have 'current' class for submenu items also, change the child markup of foreach loop to match with the first example.

Thanks for your input kixe! Sorry I'm little late to the party but I finally got some time to look this through on summer vacation. There was also some other issues with the module that I wanted to fix while I'm there so here it goes: I updated the mailto link regex to match only cases where actual email address is also present so your 1st example doesn't get obfuscated no more. While your fix for the second example worked really well, I decided to leave whole url encoding part off since it didn't seem to be vital for this module to work. I also changed the way emo avoids @2x named images to be triggered as false positives so now markup like what @Macrura had in the example here works. Before it was only possible with image tags which were skipped from obfuscation. Old method also failed when there was image inside mailto link. And last but not least; matched mailto link markup doesn't get replaced anymore by new element. We'll use the original captured html and just add required emo_email class to the link - like what @joey102030 just suggested here one post earlier. I've pushed a new commit to Github that contains all these modifications. Please test it out and report any issues you may find. Thanks! https://github.com/BlowbackDesign/emo

OK, this one is bit tricky.. Currently emo uses regex to leave head, form and img tags untouched. Link element can't be left untouched since we're parsing emails. Parsing unregular language like html with regular expressions is always on risky side. For that reason adding support for emo container class like you suggested would need proper DOM parser and IMO that introduces too much heavy lifting for the small need. So, at least for now, you have the following options: 1. Use @2x names on a img tag 2. Disable current page from module settings 3. Disable current template from module settings From these I would personally just go with number one: <a href="/" class="retina-logo"> <img src="../lk-logo-dark.png" data-dark-logo="../lk-logo-dark@2x.png" /> </a>

Thanks Macrura! I just pushed fix for these, so if you can please see how it does. Thanks!

What if we would have two branches - master and broad Master contains all core translations and is kept up to date with current PW master branch. Broad contains master + all site related translations (paid and 3rd party modules). Commits to core translations are always made to master branch and then rebased into broad when merged. Before merging commits that relate to the new PW version, tags would be added, thus making it easy to download snapshot of version specific language package. Versions wouldn't be editable but at least available. If we want to get serious, we could also have dev branch to keep up to date with current PW dev but probably we'll do just fine without it. Thoughts?

I also agree with Teppo that additional module translations should't be included in the official language pack. This looks to be the case with other languages too. I quickly crawled most of them and didn't find any site related translations - not even for the (official) paid modules.