Leaderboard

Yes helper functions like this can be included using a separate php like in the head.inc and used throughout your templates. I extracted this function from a module I have for a project. This module has various helper function and then I load it in the templates. It's much the same as if I would include a php with functions and just personal preference. For example: $helpers = $modules->get("TemplateHelpers"); then use it like this where I need it. echo $helpers->wordLimiter($page->body); I'm not sure what you mean by applying the function to the body. I use this function to create teaser texts that are limited, and show the complete body only on the detail page. Of course you could modify the body output, that every time you do an echo $page->body, it will run it through a function, but I'm not sure this is a good practice. This using a hook on the formatValue of textfields would do it: (directly in template like a include, or by making it a module) function wordLimiter(HookEvent $event){ $field = $event->argumentsByName('field'); if($field->name != 'body') return; $str = $event->return; $limit = 150; $endstr = ' …'; $str = strip_tags($str); if(strlen($str) <= $limit) return; $out = substr($str, 0, $limit); $pos = strrpos($out, " "); if ($pos>0) { $out = substr($out, 0, $pos); } return $event->return = $out .= $endstr; } wire()->addHookAfter("FieldtypeTextarea::formatValue", null, "wordLimiter"); // now this will trigger the above hook echo $page->body; But it's a little cumbersome, as you can't set the limit. Also this strips tags and on HTML text you'll lose formatting. But just to show adn example what is possible. From your post I guess you like to do something like: echo $page->body->limit(150); // not possible It's not possible to do this, because the $page->body, body is just a string and not an object you could add methods to it. But something like the following would be possible using hooks. echo $page->wordLimiter("body", 120); You can use addHook to add a method wordLimiter to page: function wordLimiter(HookEvent $event){ $field = $event->arguments[0]; // first argument $limit = $event->arguments[1]; $endstr = isset($event->arguments[2]) ? $event->arguments[2] : ' …'; $page = $event->object; // the page $str = $page->get($field); $str = strip_tags($str); if(strlen($str) <= $limit) return; $out = substr($str, 0, $limit); $pos = strrpos($out, " "); if ($pos>0) { $out = substr($out, 0, $pos); } return $event->return = $out .= $endstr; } // this will add a custom method to Page object wire()->addHook("Page::wordLimiter", null, "wordLimiter"); // now you can do this echo $page->wordLimiter("body", 100); // or this echo $page->wordLimiter("summary", 100);

Umm.. perhaps something as simple as this would work (writing from memory and not tested at all.. and I do have to admit that I wasn't 100% sure which values you actually wanted to find): SELECT t1.g_id, t1.g_title, t1.g_summary, t1.g_description FROM g2_Item t1, g2_CustomFieldMap t2 WHERE t1.g_id = t2.g_itemId AND t1.g_canContainChildren=1 AND (t2.g_field IS NULL OR t2.g_value IS NULL); Slightly offtopic: I find this representation of different join types (even if it's not entirely correct) very useful when trying to get those right..

I don't have a clue about the answer, but you can post this here for sure. That's what the dev talk forum is here for!

Password field is not made for uae like this. Module config stores json array. But password needs to be a field on a page as it stores pass and salt. Also when using like you do you only use the inputfield and not the fieldtype which encrypts the data. You may consider using a page to store.

I often listen to this kind of music while my fingers are dancing on the keyboard..

We do the same as Marty. We have several empty email templates. Pages with empty email templates may receive pages with content blocks, that way we can build a newsletter. Then the source of the rendered newsletter is copied to the Newsletter Server.

I wouldn't go near sending bulk emails from your own server as Martijn suggested. I have however toyed with using PW as a e-newsletter content creation tool for a couple of clients. Regards Marty

I think you mean something like this: function wordLimiter($str, $limit = 120, $endstr = '…'){ $str = strip_tags($str); if(strlen($str) <= $limit) return $str; $out = substr($str, 0, $limit); $pos = strrpos($out, " "); if ($pos>0) { $out = substr($out, 0, $pos); } return $out .= $endstr; } echo wordLimiter($page->body);

... no answer. I decided to help myself and hope somebody else will profit from it. I changed the following lines (450 ff) in the module-file from: if ($this->user->avatar) { $cropped_avatar = $this->user->avatar->first()->size(150); $avatar = $cropped_avatar->url; } to: if ($this->user->avatar->first()->url) { $cropped_avatar = $this->user->avatar->first()->size(150); $avatar = $cropped_avatar->url; } Now its working. About security: After logging-in each user can reach every profile about other users via profile/info/username. I think I will make some modifications for my personal use in this line (481): if($this->user->isLoggedin() && $this->input->urlSegment1 == 'info' && $this->sanitizer->name($this->input->urlSegment2)) { I would also recommend to include a field which inquires the old password before giving the allowence to set a new one in the edit-area. Until going deeper in PW I like it more and more and can image how big the potential for the future is. kixe

This just means that everything worked as expected; Redirects module doesn't do redirect if PW page with that URL exists (it only does redirect when 404 is encountered), so when using it you shouldn't create matching page.. try removing it and redirect should work There's a slight problem in your code; it would seem that you're using (probably undefined) variable called $redirect instead of $page->redirect (redirect property of $page object, ie. the value of redirect field.) If your intention was to use value from field called "redirect", try this instead: <?php $session->redirect($page->redirect);

Looks interesting Ryan, you got me curious. Outside I love a strong and foamy espresso, but at home use one of these: Back to the music. This is what I'm listening to http://grooveshark.com/album/Little+Dragon/1417265

Another factor to consider with the current solution is that it depends on an autoload module (executed on every request). That's a little less efficient than a solution that is specifically called upon when needed, as an Inputfield would be. From that respect, it would probably make sense for this to be InputfieldTextareaCounter. It would also be the simplest and most straightforward to implement and maintain. The drawback would be that you couldn't apply the counter functionality to other types of unknown future textarea derivative inputfields. But if someone is making a new text inputfield, chances are it's like TinyMCE, ACE editor or some other type of thing that wouldn't be compatible with the counter anyway. Ultimately the functionality provided here is pretty darn useful regardless of how it's implemented. But if I were implementing it myself, I'd probably make it an Inputfield rather than an autoload module. As a bonus, this would also guarantee compatibility with non-admin Inputfield forms, like those from FormBuilder, FormTemplateProcessor or API generated Inputfield forms.