gebeer

@Autofahrn @Jan P. Thank you very much for your input. Besides the changes mentioned, did you need any additional rewrite rules in .htaccess?

Hello, I searched the forum but couldn't find posts about the exact same scenario that I am facing. Instead of serving the different languages through a language specific URL, Each language should have their own domain. Everything is served from one single PW installationh, no multisite setup. So instead of domain.com/ domain.com/de/ domain.com/pl/ etc. the language versions should be available under domain.com domain.de domain.pl etc. I found how to switch the language based on the http hostname. But there are a few more questions: How to properly implement the redirection in .htaccess How to configure PW so it doesn't append the language to the URL? (just leave the language names out on the home page settings tab?) I hope someone has had that scenario before and can help out with some hints. Thank you.

@adrian sorry for the late reply. After going through the module code, I feel maintaining this is a bit over my head. Right now I don't have the time resources to take this on. Also I have no idea why the public send method is in there, sorry.

I just extended the module with some extra methods but am not sure if I am up to maintaining it in the long run. Will have a closer look on the weekend and then get back.

@strandoo You can try this code $this->addHookBefore('Inputfield::render', function(HookEvent $event) { if ($this->page->template->name === 'contact') { // adapt template name to compare with $inputfield = $event->object; if($inputfield instanceof InputfieldSelect) $inputfield->addClass('col-sm-8'); $event->return = $inputfield; } }); or this $this->addHookBefore('InputfieldSelect::render', function(HookEvent $event) { //... }

Client side is fine for not so long running tasks. But for queus that take longer you might not want to sit and wait until they're finsished. So I guess server side is the way to go here. Great!

Thanks a lot @flydev So everything goes in the execute method. This will be called after installation which is also fine for me.

This is exactly the scenario I have in mind. My question is how to implement that. Is there a standard method for modules that handles stuff prior to installation, like in my case letting the user choose some fields to use? All the modules I installed so far have a configuration screen after install. I never saw one with configuration options prior to install. Hence my question.

Great to see someone working on a Newsletter module again! Something that is definitely missing in PW. Ryan made a remark here in the last paragraph that he is planning on releasing a ProMailer module. Looking forward to that also. Like @bernhard said, a process module would be the way to go about it, I guess. @horst has released a basic queue module back in 2016 that might come in handy for batch sending.

Hello all, I am currently developing a process module that will create 2 templates and add pages to the page tree that are then being displayed within the module. I'd like to use existing fields for the templates instead of creating my own where possible and have the code for template and page creation inside the install method. Is there a way to let the user choose module options (in my case fields from a select dropdown) before the module is even installed? Is there a generic PW way to go about this?

From the page edit screen under settings you can change the parent of the page and choose Setup there.

Sorry @netcarver to be bothering again. When I try to search in ListerPro for a subfield (e.g. locality) with "Contains Text", I get following error: Operator '%=' is not implemented in FieldtypeStreetAddress Guess this has something to do with how the module is setup. I had this once in my own custom address fieldtype (that has never been published as an official module). But unfortunately I don't know the exact solution to this problem. But I just found a pointer towards a solution in Ryan's post here. Hope you can sort it out. Would be nice to be able to search for partial strings within the subfields.

Hello @netcarver and thank you for that great module. I just installed v1.0.6 on a brand new PW 3.0.98. Did not get any warnings during install that it requires jQuerySelectize. It is listed in the dependencies of the InputfieldStreetAddress module, though. Then, of course, I got a JS error because selectize is not available. When I click on the JquerySelectize module link in the InputfieldStreetAddress module info section it says 'Session: unknown module' So maybe that module was part of the core before? Anyways, after installing the JquerySelectize module from the modules directory, everything is working fine. However, it would be nice to get a warning on install and on the module page if the selectize module is not yet installed.

Great idea, thank you @bernhard I tried your solution, added a new child page under Admin with name 'my-profile' and assigned the ProcessUser process. When I go to that URL, I get a list of users. When I click on one of the users' name, I get to an URL like .../my-profile/edit/?id=1020 and am on the user edit screen. I need to avoid the first step and go right to the second while still having only '.../my-profile' in the address bar, without the edit/?id=xxx. But your hook is a great way of securing my current setup! Another thing I tried some time ago: In my custom user dashboard which is a process module, I have a method public function ___executeMyprofile() { $processUser = $this->modules->get('ProcessUser'); return $processUser->executeEdit(); } But this never worked because there are some wired in redirects in place, that always redirect to the .../access/users/edit/?id=xxx URL. At that time I even opened a thread on this topic which was never resolved.

Thank you @Robin S for looking into this. My question was: how can I make a user edit screen under a URL like '/adminurl/access/users/edit/?id=1377' available under a URL like '/adminurl/myprofile/'. So that all user edit URLs with different user ids are routed to that 'myprofile' URL and the users that edit their user pages (which are their profiles in my case) never sees the actual user id and cannot try to mess with it. Thus I chose the term 'mask' in the thread title. Maybe the way I explained it was confusing or not clear. I am not using the default user template but my own user template. User pages live under their own parent (https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-templates-or-parents-for-users) Users can edit their pages via the page edit process. This is working fine. I just need to change (mask) the URL for that process. The 2 ways that I can think of for approaching this: make the user edit process available under a custom process module which resolves to '/adminurl/myprofile/' have some htaccess rewrite magic in place I'd prefer number 1, as I cannot easily adjust the htaccess rules so that they only kick in for the custom user type and not for all ''/adminurl/access/users/edit/?id=1377' type of URLs. Hope this clears things up a bit ?

Hello @apeisa, thank you for this module. I use it on many sites. Now I have a client site where the homepage in the default language has a url segment 'de'. In the LanguageSupportPageNames module I have the setting active to redirect the default language pages to that url segment. So the homepage URL in the default language reads 'mydomain.de/de/'. In my opinion this setup does not make a lot of sense but the client insisted, so what can I do.... Now when I add a redirect like '/wer-wir-sind' (which is an old URL from the pre-PW site), the module does not kick in because the LanguageSupportPageNames module adds the 'de' to the URL. Now I end up with a URL like ''mydomain.de/de/wer-wir-sind'. The redirects module cannot find that URL and won't redirect. As a workaround, the administrator could enter redirects for the default language in the format '/de/wer-wir-sind'. Now redirects work but from a logical point of view this doesn't make sense. Because we want to redirect from' mydomain.de/wer-wir-sind' to a chosen URL and not from 'mydomain.de/de/wer-wir-sind'. To make a long story short: I added some code to the checkRedirects method of the module right after line 247, which caters for this special use case: // if homepage in default language has a language segment and the root URL is redirecting to that language segment, // remove the segment from the url so it can be found in the DB if( $this->wire('modules')->isInstalled('LanguageSupportPageNames') && $this->wire('modules')->getModule('LanguageSupportPageNames')->useHomeSegment && $this->wire('user')->get('language')->isDefault() ) { $homeSegment = '/' . $this->wire('pages')->get(1)->name; if (substr($url, 0, strlen($homeSegment)) == $homeSegment) { // remove the language segment from $url so it can be found in the DB $url = substr($url, strlen($homeSegment)); } } If you think it should be implemented into your module, let me know and I'll make a PR on github. Cheers

Hello, I have a user page template with many fields that are organised in tabs. Tabs do not work on the profile edit screen. So I had to find a way how to let users edit their page with tabs in place. The way I solved this is having users edit their user page in the backend instead of their profile page. So basically they are on a page edit screen and not on their profile edit screen which is a different process. The drawback of this method is that the users edit their profile on a URL like .../youradminurl/access/users/edit/?id=1377. So I needed to make sure that users cannot edit other users' profiles by just switching out the id. I did this through hooks that redirect them to their own profile. This is far from a perfect solution. Ideally I would like to mask the page edit url to something like /myprofile but haven't found a way on how to do this, yet. How would you go about this? redirect rules in .htaccess hooking into the profile edit process? Either way I couldn't figure out how to accomplish it. Any pointers towards a solution would be very much appreciated.

Very nice writeup. Thank you for sharing! There are so many different approaches to handling responsive images and it is great to see how others do it. Would love to see more approaches from others here, too. To get the concept of responsive images, I read the anatomy of responsive images which explains them very well. Then I used to implement a quite similar approach to @MoritzLost for some time utilizing the MarkupSrcset module and also my own functions. Until I stumbled upon an article about creating responsive images which shows an approach that I now prefer. In this approach you go through all your different images in the finished layout and determine their exact respective size at your breakpoints. Then you build srcset and sizes attributes for those exact values. So there is no more approximation using scaling factors. You get exactly the amount of images at the sizes you need them. I pass an array with the breakpoints and the required sizes for that breakpoint and build srcset and sizes from that array. Here's the code: /** * Builds responsive img tag with srcset and sizes attributes * @param \Processwire\Pageimage $img * @param array $breakpointsizes array of associative arrays that describe media min breakpoints and width/height of images from the respective * breakpoint to the next * Example: * $breakpointSizes = [ * ['bp' => 320, 'sz' => [500, 0]], * ['bp' => 576, 'sz' => [992, 0]], * ['bp' => 992, 'sz' => [690, 0]] * ['bp' => 1200, 'sz' => [835, 0]] * ]; * @return string */ function renderImageResponsive($img, $breakpointSizes) { $imgSrc = $img->url; // use original image as fallback src $alt = ($img->description) ? $img->description : $img->page->title; // if no description use page title // construct sizes attribute $sizes = array(); foreach(array_reverse($breakpointSizes) as $bs) { $sizes[] = "(min-width:{$bs['bp']}px) {$bs['sz'][0]}px"; } $sizes = implode(', ', $sizes) . ', 100vw'; // construct srcset attribute $srcSet = array(); foreach($breakpointSizes as $bs) { $srcSet[] = $img->size($bs['sz'][0], $bs['sz'][1])->url . " {$bs['sz'][0]}w"; } $srcSet = implode(', ', $srcSet); return "<img class='img-fluid' src='{$imgSrc}' srcset='{$srcSet}' sizes='{$sizes}' alt='{$alt}'>"; } Obviously it does not account for Retina which needs to be added. I will also extend my function to add support for other attributes like you showed it. That is a great idea.

@thomasaull Great that you are converting this into a module. It would be a muc better fit. That way we can add api funtionality to any site easily. Actually, I was thinking about converting your site profile to a module, too ?

Hallo, I wanted to test this site profile and cloned PW 3.0.98 from git. Then cloned the site profile repo and installed PW without any issues. I issued the 2 composer commands to install dependencies. Environment: Apache with PHP 7.0.29 FPM/FastCGI. When I try to access api/test, I get the following error Looks like a namespace issue. I didn't change namespaces on any of the files included in the profile. My config.php is not namespaced. Does anyone have an idea how I can overcome this? EDIT: apache_request headers became available under FastCGI since 5.4.0 according to http://php.net/manual/en/function.apache-request-headers.php EDIT2: After some more investigation I found https://bugs.php.net/bug.php?id=70025. So it seems apache_request_headers is still not supported in PHP 7.0 FPM/CGI environment. I added templates/inc/functions.php with contents of https://gist.github.com/rmpel/11583cfddfcc9705578428e3a2ee3dc1 and added require "{$config->paths->templates}inc/functions.php"; to api.php This solved the problem :)-

I ran into a similar issue with v1.1.0. using Javascript Loading method: Load file to $config->scripts emo.min.js is included on the page before the <!-- emo --> script block which defines var emo_addr. The function emo_replace() never gets called because at the point of script inclusion emo_addr === undefined. In v1.5 of emo.js window.onload was removed. So the script never executes when emo.min.js is included before the <!-- emo --> script block. I have refactored emo.js as an object literal and modified the module Code so that the script block calls emo.init(emo_addr) after defining the addresses. Tested without problems. Modified module can be found at https://github.com/gebeer/EmailObfuscation/tree/dev @Roope do you want a PR for that?

I've been following the discussion about language translation for this module. It is convenient to edit the language specific texts on the module settings page. But if they were implemented as i18n language translation strings, I guess all those problems would be solved. I personally wouldn't mind to edit those under Settings->Languages as long as there is a hint on the module settings page.

Hello, I just installed this module on PW 2.7.2. On the module settings page I get an error "Call to a member function render() on a non-object" from line 78 of CookieManagementBanner.module. $this->wire('files') is null. If I replace line 78 with the following, everything works ok. $cookieBanner = wireRenderFile($this->wire('config')->paths->$this.'wrapper.tpl.php', array('module' => $this, 'lang' => $lang)); Seems like wire('files') is not available in 2.7.2 which is strange. Can anyone confirm this?

Anyone interested in the module with added region option and with added o:deliverytime option can use my fork at https://github.com/gebeer/WireMailMailgun

@cb2004 attached is an amended version of the module and module config. I added a setting for the region and the API URL will adjust accordingly. WireMailMailgunConfig.php WireMailMailgun.module