Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

94 Excellent

About Roope

  • Rank
    Distinguished Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Tampere, Finland

Recent Profile Visitors

4,568 profile views
  1. Hello @gebeer! I made a convert to object literal on your supposal but it had issue when "JavaScript loading method" was set to:manual (where emo.js is loaded after the inline script block). So script init is now again attached to the window onload event and emo.js can be included at any part of page. Thanks for the report! I also dropped ProcessWire namespace for continued 2.x support, thanks for a remind @Robin S! That was maybe too hesitated and no requirements for it. Version bumped to 1.1.1 and it's available at GitHub: https://github.com/BlowbackDesign/EmailObfuscation/releases/tag/1.1.1 Besides bugfixes this version adds support to multilanguage nosript text and template cache.
  2. Thanks for the info! Yeah, I've noticed this module before but I feel the same with Soma here that this should be something that's already implemented as a core feature. The idea of scattered sorting settings between template and module config seems bit complicated in a long run.
  3. +1 for this feature! Maybe there could be a simple "custom selector" option in the dropdown with added text field.
  4. Hi all! Sorry I'm little late for the party. Key validation on every page load is surely not necessary and it was just a simple stupidity be set like that. It's fixed now and I just pushed it to github. Thanks for the notice! (not been using the module after couple of tryouts)
  5. Hello! Yes, I think something like this on your page template should work. $page->addHookBefore('render', function($event) { if(wire('input')->get->myvar) { $emo = wire('modules')->get('EmailObfuscation'); $emo->mode = $emo::modeManual; } });
  6. Hello @Zeka! Sorry for massive delay but I just quickly tested EMO with built-in cache and was able to repeat yor issue. Cache file had emails as plain text and both EMO scripts were missing. On a public page it was still allright (emails obfuscated) so I don't know why it wasn't really using cached version? Switch to ProCache worked as excepted - cached page, which was obfuscated. I'm really lost with PW built-in cache since I'm so used to work with Ryans ProCache module and it has never had any issues running together with EMO. So for now my best bet for you is to get that - in a meantime we'll see if there is something we can about this. Multilanguage support is already in my TODO list, if I just could find the time... Thanks for the notice!
  7. You can do this with EMO too: At module settings page set "Obfuscation mode" to "Obfuscate manually..." (OR adjust exclude/include templates/pages settings to have auto obfuscation enabled only where needed). Then on a page template obfuscate only the parts of markup you want by using $sanitizer->emo() method. // obfuscate single email address echo $sanitizer->emo('hello@world.com'); // obfuscate email addresses from a body field output echo $sanitizer->emo($page->body); Also make sure that you are using the 1.1.x version since this feature was added to the latest release (1.1.0).
  8. You can compress up to 500 images per month for free with TinyPNG API: https://tinypng.com/developers
  9. To be honest, I've missed the whole world of conditional autoloading of PW modules... Dropping off support for 2.2 isn't any issue. There will be older perfecly functional emo releases available if someone needs it. So I think I'll go ahead and make this change same time I'll add PW namespace to the module - which should happen pretty soon. Thanks for the notice!
  10. Currently this is not possible.
  11. New version is now available at GitHub. Added new option to exclude/include module execution at selected templates/pages + new $sanitizer->emo() method to manually control obfuscation for given string. Please go ahead and try it out!
  12. 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.
  13. 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.
  14. 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?
  15. 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>'; ?>
  • Create New...