Webrocker

Hi Wanze, thanks for this cool module! this really did save some headscratching for a current project I'm working on. Do you have a tip how I can include my ./template/_init.php file for the "pdf"template? I need to use some vars that are declared site-wide in this _init.php file. I'm sure this can easily be achived, esp. after seeing that there's a hookable createPDF function… but I'm not sure how this "prepend file to template" would be addressed…? Sorry if this is something totally obvious, I'd glady take a rtfm link, as well ;-) cheers Tom

hi, what are you trying to archive, do you have the site 'around' your processwire contents in TYPO3, ie do you need to 'inject' the pw contents in the templates of the TYPO3 page? if you need to inject your own data into TYPO3 rendering, you need to create a PHP_SCRIPT content element, give your php file as the lib and return all of your data in a $content variable, this will then be rendered by TYPO3. (http://docs.typo3.org/typo3cms/TyposcriptReference/AppendixA/Index.html) It's been a while since I last fiddled with TYPO3 and external scripts, and I always went with the Typoscript way of handling it, so maybe there's now an easier way with the fluid templating stuff and the newer TYPO3 versions... cheers Tom

Hi Soma, ah, thx for clearing This: ("can't unpublish users') was what I assumed/feared, why I actually _can_ unpublish users in the backend is apparently caused by me using own templates for those special users and not the system template *sigh ) thanks Tom UPDATE: Confirmed, with the ..., $options = array("findAll" => false) added, it works as expected and ignores hidden and or unpublished "users". Thank you very much.

Hi, I just noticed that the following code // jury-portraits.php template file $jury_cats = $pages->find('template=jury_category,sort=sort'); // find users in each category $jury_portraits = array(); foreach($jury_cats as $cat){ $jury_portraits[] = array( 'cat' => $cat->name, 'title' => $cat->get('headline|title'), 'members' => $users->find('roles=awardjury,user_jury_category='.$cat.',sort=lastname') ); } // shortened for clarity foreach($jury_portraits as $jp){ // snip ... loops through the categories $jp['members']->each(function($jm ){ // snap ... do soemthing with title, image etc echo $jm->name; } } returns all users as intended, nicely grouped by my jury-categories. But now I "disabled" one user by unpublishing and hiding his page. I expected that the above would now return all users as expected, but without the unpublished one. But his infos were still visible; the $users->find() behaved exactly as with 'inlcude=all' or 'include=hidden' in the selector. Is there a way to explicitly state that I want to have only the published users? To me, the above translates to "give me all users who's role is "awardjury" and who's category is "foo"… but the "who are not unpublished" part is missing - and the only selector params I found are to allow all or hidden pages, not forbid them. ?? What am I missing? Cheers, Tom

WOW! Just to answer myself; all of the above can easily be covered. Just don't use the render(); method. Step 1: fetch your menu data and store it in an array: $footermenu_items_json = $pages->get('name=footer-menu')->menu_items; // this is the menu page in menu builder, could also be fetched with the ID $footermenu_items = json_decode($footermenu_items_json, true); Step 2: use that array to build your custom markup: if( count($footermenu_items) > 0 ){ $out = '<ul class="nav-list">'; foreach($footermenu_items as $item){ $url = ($item['url']) ? $item['url'] : $pages->get($item['pages_id'])->url; $target = (1 == $item['newtab']) ? 'target="_blank"':''; $out .= '<li class="list-item"><a href="' . $url . '" class="list-item-link" ' . $target . '>' . $item['title'] . '</a></li>'; } if( $user->isLoggedin() ){ $out .= '<li class="list-item"><a href="' . $pages->get('name=login, template=login')->url . 'logout/' . '" class="list-item-link">Logout</a></li>'; } else { $out .= '<li class="list-item"><a href="' . $pages->get('name=login, template=login')->url . '" class="list-item-link">Login</a></li>'; } $out .= '</ul>'; echo $out; } Just make sure to var_dump the array somewhere to get an idea of what info is stored in there for the nested levels, etc. This is really neat. For me it's the best of both worlds - I can easily create and maintain menus in the backend, but can still fully control the output in the template. Thank you!! cheers, Tom

Hi, thanks for the module, I think this is a great addition! Is there a way to set default classes for the menu's li items and possible for the included a tags as well? To keep nesting flat in the css, our stylesheet uses ".list-item" and ".list-item-link" classes. And, would it be possible to set via the $options to not include the outermost "ul"? this would take care for instances like laban describes above (https://processwire.com/talk/topic/4451-menu-builder/page-6#entry97178) or my use case, where I'd like to add a "login / logout" nav item to the footer-menu - depending on the logged in state of the user this is either /login or /logout. I would add this in the template, not as an item via the menu builder, but it still needs to be enclosed in the "ul" wrap of the rendered menu. Or would those two use cases be better taken care of if I used the JSON -> array() thing, just taking the infos provided by the menu builder and creating my own markup around it? Anyways, great work, really looking forward to use this in a production site

hi, thanks for the answers, I think i'll adapt this 't' function concept to my project. this removes the 'hacky' feel of my approach with it's duplicate level of __('foo') functions, in _string.php and the template files. cheers tom

Hi, I'm toying with the idea of having a central place in PW's translation system for phrases and strings that are frequently used throughout several template files. The way I understand PWs translation system after reading the docs (http://processwire.com/api/multi-language-support/code-i18n/) is that everytime a __('translate-me') is used in a different .php file, the system will pull that 'translate-me' in a context of the .php file where it is used - so basically all translatable strings of _one_ file at a time are manageable via the (very cool) translation tool in PW's admin interface. So if for example I were to use __('Daytime phone number') in, lets say, the home.php as well as in the login.php and maybe a profile.php, I'd need to translate this three times, right? - A solution given in the docs is using the gettext context, and have this pointing to the first template file where the string was used first, so I only need to translate that template's strings and the other two will "see" their translation threre. So in my fabricated example: //home.php: __('Daytime phone number'); //login.php: __('Daytime phone number','/site/templates/home.php'); //profile.php: __('Daytime phone number','/site/templates/home.php'); So I only need to look for the translations of /site/templates/home.php in the translation tool and the other occurances of that string will be taken care for. This now brings me to the idea of creating a php file in, say, "/site/language/strings.php". So what I can now do (but what feels kind of hacky to me…?), I use all the frequently used strings of my several template files in this "strings.php" file, wrapped in their language functions like __('translate me'). in _init.php or maybe in config.php I store this file's path for the context: $i18lctx = '/site/templates/language/strings.php'; And now I can use the transalatable strings in several template/php files like this // in home.php, in archive.php etc __('Hello pilgrim',$i18lctx); In PWs admin interface I'll have all the strings in one place: the strings.php (?textdomain=site--templates--language--strings-php). Is this the right way to go about it or am I overlooking a basic fact (maybe like, dude, this is what the language packs are for)? Cheers, Tom

the template append is still there. here's a excerpt from the mail source code if the $mail->body($emailContentPlain)->bodyHTML($emailContentHtml); is used, if I change this to $mail->body($emailContentPlain); the mail is ok (due to the regex stripping I guess). --==Multipart_Boundary_x737b845286a9a5899d535817f4d80ca2x Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <html> <body> <p>Thank you, (snip snap) .... </p> <!-- empty line and comment only lines works as a linebreak with plain emails --> <p>User: Testtest<br /> Email: test@test.te</p> <p>Code: 2b7d110cb29be35bbac13d506e02f7de</p> <p>Link: (domain)/registration/?registerToken=2b7d110cb29be35bbac13d506e02f7de</p> </body> </html> <!DOCTYPE html> <html lang="de"> <head> <meta charset="utf-8" /> <title></title> <meta name="viewport" content="width=device-width,initial-scale=1.0"> <script type="text/javascript" src="/site/templates/js/modernizr-custom.js"></script> <link rel="stylesheet" type="text/css" href="/site/templates/css/styles.css"> </head> <body id="pid-1032" class="pid-1032 p-registration t-user_registration"> <div class="page"> <main class="page-main"> <!-- main content --> </main> <footer class="page-footer"> <div class="container"> </div> </footer> </div> <script type="text/javascript" src="/site/templates/js/jquery.min.js"></script> <script type="text/javascript" src="/site/templates/js/scripts.js"></script> </body> </html> --==Multipart_Boundary_x737b845286a9a5899d535817f4d80ca2x-- yes, and thank you for the alpha reminder ;-) I need to learn the hook things better, and then I'll keep my fingers out of the module's code, promised! ah, and of course I don't expect you to tackle my problems here (just realised that the above may be read as "uh it's urgent, please have a look") but this is not how it was meant; I mentioned it only as an explanation why I hacked in your module's code )

Hi, well, basically I added a function to send another mail after sucessful registration, and bypassed the need to login after the user has entered his/her desired password in the second step. I can send you a pull request of my dev-branch if you like, but rather wouldn't have this public for now since we hard-coded some email adresses and client-related stuff into the code… may I mail you a zip or invite you to our bitbucket team so you can see the fork? (it's all a bit rushed right now b/c it needs to work tomorrow morning (launch) :-D )

Hi, wow, this is fast. and on a sunday, too! <3 I merged your latest master with my local changes, keeping your 5.3 compat changes. Works fine 1000thx

hi, sorry for being unclear, the email template is loaded, i.e. the infos and content etc are in the email. it's only that after that, the _main.php is included, as well, which in my case will add additional (and content-less) html,body,etc markup to the already existing html,body,etc markup in the mail's source code. Changes to the email template are reflected in the mail sent. It's only the additional markup that I'm wondering about.

Hi again ;-) thanks for the tips regarding php 5.3 workaround - that did the trick! Another (minor) issue I encountered is that the generated email will still append the "normal" _main.php template file, which results in a doubled html / body code and may confuse some mail clients. By changing the line //$mail->body($emailContentPlain)->bodyHTML($emailContentHtml); $mail->body($emailContentPlain); in FrontendUserRegisterEmailValidation.module the regex will strip out the _main.php tags as well, which for me right now works as a workaround, but of course I am wondering where I'd be able to undo the automatic appending of the _main.php … my guess is, that $emailContentHtml = wire('page')->render($this->fu->getFile('validationEmail.php', 'templates'), $vars); is the right place to look, but I've yet to find the correct setting for $vars. cheers; Tom

hi pwFoo, i'm toying around with your great register module. I have a php fatal error and since i'm not-so in-depth to php/versions/objectoriented stuff, would you mind and confirm or not if this may be caused by me being forced to use PW in a php 5.3 environment? PW (2.58) in itself runs fine; but I noticed from the earlier notes in your module that it needed php >5.5 (?). Anyhow the error looks like $this (no pun intented): Fatal error: Using $this when not in object context in /var/www/<snipsnap>/site/modules/FrontendUser/FrontendUser.module on line 252 which refers to this line $username = $this->form->fhValue($field->name); in here: protected function usernameRegister() { $field = $this->modules->get('InputfieldText'); $field->label = $this->_('Username'); $field->attr('id+name', 'username'); $field->required = 1; $field->fhSanitizer = 'username'; $field->addHookAfter('processInput', function($event) { $field = $event->object; $username = $this->form->fhValue($field->name); if (empty($username)) return; elseif (wire('users')->count("name={$username}") == 0) { $this->userObj->name = $username; } else { $field->error(__('Username already taken!')); } }); return $field; } many thx for the module cheers Tom

(EDIT) sorry for the duplicate post. --> now in the correct thread (i hope ) : https://processwire.com/talk/topic/8001-frontenduserlogin/#entry95144

ah. ouch. I see. well… in my case I have a setup where I make a distinction between the place where the items are stored/edited and where they are displayed… - home -- News -- (article) (used for display) -- (rss) (used for the rss) ... - News-Admin (template=news) -- My News 1 (template=article) -- My News 2 (template=article) .... So I have the page "News" with urlSegment… /news/article/my-news-1/ which will display the correct news. so the item-link in the rss should be /news/article/{$item-name}… now, with the needed article.php (which is empty) in place, the link in the rss is /news-admin/my-news-1/ I simplified my set-up, in reality there's a lot more bundled under the "administration" page in the tree, not only "news-admin". hm. I think it will be easier to make the rss output by hand and not using the module, then EDIT: Thanks for the idea with the redirect on the item's template. Works like a charm for my set-up.

Hi, sorry if this already has been covered, but I just stumbled over an issue: If the pages in $items = $pages->find(....) use a template that has no template.php file in /templates/, then nothing will be returned by the $rss->render($items) Even though $items is fetched correctly and could be debugged like var_dump($items[0]->title) ... The strange thing is, only the template.php file needs to be there, even if it's empty. Since the $rss->render() is used on a different template anyway (for showing the rss"page"), there shouldn't be a need to have the template for the "fetched" pages…? cheers, Tom

Thanks for the fast replies (this community rocks) "my" image field allows for multiple images. It is possible to (re)upload the "c" image in "b", appending it to b's images. I understand that repeaters internally are nothing but pages, so if PW ties images to pages, they are tied to the repeater context, ok. I'm wondering,though; the image option in the wysywig is able to browse through images already uploaded, even on other pages, so there seems to be a way to get to the already uploaded images. The concept of a central image repo and page selector sound interesting, I'll look into that. For the current smallish site, I'll stick with re-uploading the image. Out of curiosity, how would you handle text/image content on a page if there can/may be one or more of these sections? Hidden subpages, collected on the parent page? I'm still in the baby steps mode, so any nudge in a more proven direction is welcome Thanks again for the support.

Hi, I have a simple content structure like this: - A page -- title -- content (repeater field) --- headline --- body --- images (image field) -- (…) - Another page (...) Is it possible to not only upload images via the "image" field, but let it select already uploaded images (in other "content" repeaters or on other pages)? (Kind of how the image thing inside the wysiwyg works - I don't want to have the image selection inside the "body" field and disabled the image option in the wysiwyg editior setting). Or do I need to introduce a new field alongside the regular mage field? The actual scenario is like this: With the above structure, the editor created three content sections on one page a, b, c. In each section, he uploaded one image. After a whle he decided that the section c is in fact part of section b, and deletes it, after appending it's "body" content to section b's body field. Because now the text of section c is in section b, he also wants to have section c's image go along with section b and the image there - but the image field seems to only offer a new upload of the image - or am I missing something? thanks, Tom

uhm, If the only reason you use the "images" as a repeater field is to get different sizes of the same image, you have other options: If you want to control the size and aspect ration of the different sizes, but allow your editor the control of the part of the image to be shown, have a look at the fieldtypeCropImage module set http://modules.processwire.com/modules/fieldtype-crop-image/. If you just want to use different sizes/scales of the image, you can simply make them on the fly in your output; see "resizing images" here: http://processwire.com/api/fieldtypes/images/ Structure w/o repeater field: - page with images -- images (image field) -- other content (textarea) -- (...) $images_to_show = $page->images foreach( $images_to_show as $img){ $large = $image->width(500); $thumb = $image->size(100, 100); echo '<a href="' . $large->url . '"><img src="' . $thumb ->url . '" /></a>'; } Tom

Hi, I'm fairly new to PW myself, but I think you need to output it like this, assuming your structure is: - page with images -- images (repeater field) --- small_image (image field) --- big_image (image field) -- other content (textarea) -- (...) $images_to_show = $page->images // herein are all image repeater instances of the current page foreach( $images_to_show as $imgs) { // now we are "in" one repeater, so we need to get the repeater's fields foreach( $imgs as $img) { // do whatever you want with the fields echo $img->small_image->url; echo $img->big_image->url; } } I coded this in the browser, not tested, but I think you're missing the loop "inside" the repeater to get to the fields you want.

Works like a charm. Thanks!

Hi Craig, thanks for the fast reply and the nudge towards the module's github page. $pages->get(1001)->my_selector = "template=projects"; $options = array( "selector_level1" => "template=ressort", "selector_level2" => "start=0, limit=10", "selector_level3" => "template=news|events, sort=-created", "selector_field" => "my_selector" ); echo $nav->render($options); I completly missed the nav_selector power somehow when I implemented my navigation. cool. Tom

Hi, first of all thanks for this amazing CMS. I'm currently building my first page with PW, and I really like the concept. I have long years of experience with TYPO3, Wordpress, Joomla and some other more exotic systems, and I think PW just rocks, but I have difficulties to find the right/smart way for my ideas, due to lack of experience and know-how in the PW world. I guess what I'm trying to say -- be patient if waht I'm asking has been dealt with before or is a no-brainer for you guys with more PW-experience. I have a page "events" that I want to show in the navigation(s), since it features some editor-content. Sub pages of this will be "event" pages, and they shouldn't be showing in the main-navigation(s), since they will be linked via teaser boxes and such. Maybe later on, there will be the need to browse these events via their own navigation, but not right now. I understand that I can control the visibility of the "event" page via the page option. Now, it would be possible, but not comfortable, to ask the editor to make sure that "event" pages are published, but not visible. From my experience, this sooner or later will be trouble, because, well, people, you know… ;-) Is it possible to have a "default" status of published pages set (via the parent template)? -- I didn't find that kind of setting in the admin. Another way would be to control the navigation via the template, by simply not showing child pages when on the page "events". Now this is not so smart in my setup, because I opted to use the "MarkupSimpleNavigation.module" to build the main navigation and the navigation that'll show up on the page/content, if child pages are present. I found no way to tell the module to ignore (visible) child pages if in context of a certain page (other than to change the max level or depth setting). Currently I'm using a nav_main.inc.php and nav_sub.inc.php include throughout my frontend templates; I think it would be possible to switch the navigation module's behavior by chekcing for the page that includes them - but I don't want to clutter my code with if/else or switch conditions, if it can be avoided somehow So I think it boils down to: Either a way to set the visibility for new pages under "events" to hidden by default - which would work without the need to touch the navigation module, but may be not future-proof or a way to tell the navigation module if included in the "events" template to ignore the child pages, which can be done in several ways. A third way could be to separate the "events" content page from the "events" container page, but that's kind of, uhm, ugly I think the second way is the way to go, but out of curiosity, how would you take on the first one? Thanks for reading all this, Tom

see you there, then