Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


BitPoet last won the day on September 15

BitPoet had the most liked content!

Community Reputation

2,260 Excellent


About BitPoet

  • Rank
    Hero Member

Profile Information

  • Gender
  • Location
    Near Munich / Germany
  • Interests
    programming, writing, scuba diving, long distance hiking

Recent Profile Visitors

6,492 profile views
  1. Did you adapt the SMTP settings in php.ini? It might be configured to use sendmail by default.
  2. I need to take a look at that, but unfortunately, I'm not hopeful that I'll find enough time this week. Next week should be a bit less crazy though. I haven't found the time to update to the latest FB release, but it looks like soon will be a good time to do so 🙂 Stay tuned.
  3. If you plan to go live with validation email enabled anyway, it would also make sense to use a dummy SMTP server like FakeSMTP. That way, no mail is actually sent out but you have an instant preview, can save all mails to files, view those in your mail application and test the validation links inside.
  4. Thanks for letting me know. Fixed in 0.1.5, already on GitHub and soon in the module repo. I'm pretty sure I caught all translation call issues now.
  5. Behind the scenes, repeater entries are individual pages, so when you iterate over an entry (your second loop), you iterate over all the properties of the repeater page. You can see that if you change your code to: foreach ($child->Portrait_Repeater as $data) { $i = 1; foreach($data as $prop => $person_data){ $content .= $i.": $prop => ".$person_data."<br />"; $i++; } } The solution is to remove the inner loop and address the properties by name instead, like $person_data->email, $person_data->position etc.
  6. Thank you for the feedback. I have merged the change into the main branch, so once 0.1.4 hits the module repository (should be within the next 24 hours) it will be fixed the official package too.
  7. I've had some strange issues recently with pages that had a parent template restriction in the family settings and moving/creating them parent pages that in turn had a child template family restriction. Unfortunately, I didn't have time to investigate this further and just removed one of the restrictions to get things working again.
  8. Good point. If PHP is configured correctly in that regard, you should be able to use date() to set it dynamically. $config->dbInitCommand = "SET NAMES '{charset}', time_zone = '" . date('P') . "' "; I think there was a reason why I didn't try to convert the configured timezone to an offset, but I need to check that. Definitely not intended. That should be taken care of by the Modules class. Did you get any warning messages while uninstalling the module?
  9. Not out of the box. For requirements like this, I usually use a regular text input with a showIf (perhaps also requiredIf) dependency on the "other" option.
  10. It should be possible. You can use the methods of InputfieldWrapper on the return value of buildFormContent, retrieve the field by name, create the new Inputfield and insert that in the place of the original one with insertBefore()/insertAfter() and remove(). //... $wrap = $event->return; $origFld = $wrap->get('parent_id'); $newFld = wire('modules')->get('InputfieldPageAutocomplete'); $newFld->attr('name', 'parent_id'); $newFld->attr('value', $origFld->attr('value')); // do any other instantiation work, like setting/copying title, label etc. $origFld->parent()->insertAfter($newFld, $origFld)->remove($origFld); // done
  11. Looks like the plain _() translation method is not available anymore for some reason (perhaps something to do with the changes in the function API that I didn't catch). Could you try out the version at this link and let me know whether that fixes it for you?
  12. Does it still persist if you delete the contents of site/assets/cache/FileCompiler?
  13. Adding a /*NoCompile*/ FileCompiler hint as explained here should solve the issue (and let you keep FileCompiler active).
  14. Hm. sku_image is definitely not contained in p21fields? The line below is apparently the only one that modifies the page's field values, so still the most likely suspect (unless there's more in the code you left out or some hook magic somewhere else). Maybe outputting $field to the log can shed some more light there. Also, check compareData for singe/double equal sign mixup in if conditions. $p->set($field, $data[$ctn]);
  15. That would probably the relevant part that we would need to see to make an educated guess. Does the script perchance replace the Pageimage object assigned to sku_image with an empty one?
  • Create New...