gebeer

Members
  • Content Count

    819
  • Joined

  • Last visited

  • Days Won

    7

gebeer last won the day on March 26 2018

gebeer had the most liked content!

Community Reputation

771 Excellent

About gebeer

  • Rank
    Distinguished Member

Profile Information

  • Gender
    Male
  • Location
    Thailand/Germany

Recent Profile Visitors

7,840 profile views
  1. @Autofahrn @Jan P. Thank you very much for your input. Besides the changes mentioned, did you need any additional rewrite rules in .htaccess?
  2. 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.
  3. gebeer

    @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.
  4. gebeer

    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.
  5. gebeer

    @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) { //... }
  6. 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!
  7. Thanks a lot @flydev So everything goes in the execute method. This will be called after installation which is also fine for me.
  8. 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.
  9. 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.
  10. 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?
  11. From the page edit screen under settings you can change the parent of the page and choose Setup there.
  12. 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.
  13. 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.
  14. 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.
  15. 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