Peter Falkenberg Brown

Dear All, I've been scouring the API, the forums, and Antti's Fredi module, looking for tips. (Thanks, Antti!) I'm building forms on the front end, for a membership site, and have worked out the permissions, etc. Now, I'm working on how to obtain field values (to edit) while preserving the field settings and attributes, as defined in the backend. My weak point is that I'm not conversant in OOP PHP. It's easy to pull the value of a text field. But, I need to figure out how to pull the fields with single and multiple selects, checkboxes and radio boxes. I'd rather not handcode all of that with list selects and loops, and am assuming (hoping) that PW has an "easy way", since PW is so cool. I'm also working on a method where I loop through a field list and grab the values and surrounding HTML (e.g. for checkboxes), and then, having placed that "field construct" in a variable, replace a tag in an html template with that variable, allowing me to separate the look and feel from the code (I've done that in Perl). Here's a sample of a code snippet, with two fields. The text field works, but the select field (account_type) does not. In the PW admin, 'account_type' would have a dropdown with three or four values. Here's the code. The lines in red don't work. I also realize that if I handcoded it, I'd have to replace the entire input line in red, with a select construct. The input line for that field is just to see what I got back from the code above. Anybody have any thoughts about how to do this? === elseif ( $a_ == 'e' ) { $out .= ":: Edit Mode ::<br>"; $page->setOutputFormatting(false); $e_account_name = $page->account_name; $field = fields->get("account_type"); $inputField = $field->getInputfield($page); $inputField->value = "account_type"; $out .= " <form action='$full_page_url' method='POST'> <input type='hidden' name='a_' value='u'><br> <input type='text' name='account_name' value='$e_account_name' size='50' maxlength='100'> <input type='text' name='account_type' value='$inputField'> <input type='submit' name='submit' value='Update Account Data'> </form> "; } === Thanks! Peter

Dear Matthew, I'm using Ryan's code on this page: http://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form as a reference for my system. (Still designing it.) I'm going to keep the normal admin login for admins and editors, with the blocks that Soma mentioned, for other users. For the members, I'm going to make a new login page that will use the regular API functions to look them up in the user field set, and then, based on their user id, look them up in the /member/ account data set, to grab their membership url, and then redirect them to that page, e.g. /members/1097-8247913542/ I was thinking about putting the membership url in the user template/field set, but I'm also using the member urls as a tree in the back end, for admins to view and manage. I don't have the code yet, but I think the concepts outlined here, combined with Ryan's code, should work well. I hope. But one point is that my membership system is entirely locked down, not viewable by the public, and not even viewable by other members. Peter

Dear Soma, Ah ha... thanks for that clarification! I shall go back and rework my system a bit. The Discovery of ProcessWire continues... Peter

Dear Soma, Thanks for your additional replies. I think I assumed that the 'member' role would have to have edit permissions, but it looks like what you're saying is that since the membership access is all controlled from the front-end, via scripts and the API, they don't need edit mode to edit and update their own pages, via the front end. Is that correct? Somehow that's fuzzy to me, because when they run a page in the front end, they're logged in as a member user, so when they hit a save button to add or edit a page, PW knows that they're saving a page to a template field set, so I would think PW would check and say, "Hey, you don't have access!" Am I missing something? Thanks, Peter

Dear Soma and PogiDude, Thanks to both of you! Yes, PogiDude, you are right. Superusers and editors should be able to edit anything, but 'authors' should only be allowed to edit their own pages. I probably wasn't clear enough. Soma, Oh Great Module Writer, , you wanna turn this into a real live module that we can just go click, click and install? I think that this would be such a beneficial module that I'll bet you a Virtual Doughnut that Ryan would include it in the core. It seems to be me to be a missing element in PW's user scheme. Best regards, Peter

Dear Kongondo, Soma and Matthew, Thanks for your input... Soma, where would you put your code example? In default.php, as Kongondo suggested? Would it be possible to suggest exactly where in default.php, or elsewhere, you would put it, with a complete example? When I looked at default.php, there's a lot going on. The function would have to come into play right after a log in by someone with a barred role. I think this type of code would be very useful, even as a default module. For example, one could configure the backend to only allow xyz types of roles, or perhaps even easier, offer an option to block certain roles. Like an include and exclude list. For the front end: I'm developing a scheme for members with a custom login at /members/, so that the user (who is an actual PW user with the role of 'member') would get redirected to a custom home page just for them, on the front end. When the user registers as a member, from a custom front end page, the script would not only create a user account, but would also create a member home page under the /members/ url, e.g. /members/1097-8247913542/ This would serve as an account page for that member, and offer a variety of functions for the member. The '1097' is a standard user id, and the longer number is randomly generated, with the whole thing used as an account number, used for authentication on every page under the member's section. I made it a hard-to-guess number for just a bit of security, so that the account urls of other members would not be easy to guess. I've created a set of template/field groups that all use the user_id and the account_url, and have structured the member pages just like a regular /section/page/ tree. Using Ryan's idea of not passing html until the end is a good idea, allowing for redirection when necessary, but I'm not just using a master control script because I want to provide different functions for each type of member branch or page. Thus, I'm going to create a template file for each type of page in the member section, and simply include headers and footers, etc, but include them as variables that would get output at the bottom of the page. I've written apps with a huge control script, running off of one url, but the files were, well... huge. I feel now that placing the functions that apply to one type of page or section url, in the template php file, allows those urls to load much faster, with less overhead. I think that PW's design, in this fashion, is excellent. It also allows an admin in the backend to easily navigate through all the members' pages, since each member's sub-pages are all under their account 'home page', in the tree. So... I think I've got the front end concept, but blocking the backend admin from any role that isn't a 'backend' type of user would be a great thing. Thanks, all, Peter

Dear Soma, > PW already adds user id to page. You can get it with created_users_id... or something like this. That's interesting. Thanks. So now... if someone clever would like to add a module that would test for that id, in the admin backend, that would be great. I know how to block edits, etc, in front end code, but integrating it with the backend admin application is another matter. Peter

Dear Ryan and All, I hope I haven't missed a post that answers this. I've viewed a lot of them, but couldn't find this exact function, and wondered how hard it would be for some enterprising module writer to add it. Here's the idea: - users are given add, edit, and delete permissions for a set of templates - when they add a page with one of those templates, their user id gets added to the page - when they go to edit a page, the module checks to see if the 'created_by_user_id' field matches their userid. If so, proceed, if not, they get an error message. - the same function happens when they try to delete a page (based also on the fact that the page has no children). - there would be a permission role, used in the module, for assigned user roles to override a page with a different user id, i.e. a superuser or editor who could edit anyone's page. Thus, this template, if turned on, would add each user's id to any page created by them (as a required, non-editable field), and would thus act as a solid user permission system, which would allow any number of users to log into the admin backend, but only be given permission to edit their own pages. Somebody want to create it? Best regards, Peter

Dear All, I wanted to revisit this post. I still haven't figured out how to block the admin backend. I'm hoping that if anyone logs in with a role other than superuser, they'll get kicked out. Any tips? Thanks, Peter

Dear Ryan, > Now if the page pointed to by "custom_template_file" is hidden, that doesn't matter, because that's a page you are using to match, > not one of the pages being returned by find(). I think I understand the above. The find command is finding pages that are not hidden: it's just the selector values that are hidden, but I'm not trying to display those hidden selectors; I'm just using them to match non-hidden pages. In any case, the selector values won't be accessible as pages, so that's good. Thanks for your help on this. Peter

Dear Adrian, Thanks! I'll look at that page. Peter

Dear Adrian, Yes, that makes sense. After hours of reading PW forum posts, my brain is fried. But... I still need to block the admin backend. I'd love to edit the admin backend, to keep all the great things there, but I noted that Ryan said it was a bad idea to hide sections of the tree, that are only viewable, but not editable, by certain roles. But for my "admin" pages for users, I don't want them to see anything that they don't need to. I also want to heavily customize the look and feel of the admin. So, I'm thinking now that I should just block the regular admin pages, and use custom forms with the api and hooks. Although I was initially interested in the idea of taking an admin edit url and using that. But then I think I couldn't block the rest of the admin pages. Peter

Dear All, I've created a 'member' user role, and would like to block users with that role from seeing the Admin backend. Instead, if they do go to the admin login, and then log in, I'd like to redirect them to to a specialized log in page for members, where I'll do some redirections based on their account details. I also want to modify the standard login screen, and place some explanatory text on it, but I searched for the word "Login" for example, and couldn't find which file to edit. I must be missing something. I've copied the 'templates-admin' directory to my site directory, and have examined the default.php file. But when I put some code into the file to test for the superuser (just as a test, since I actually want to test for the 'member' role), I ended up blocking the login page. So, even the superuser couldn't log in. I believe I placed that code in the wrong place. Does anyone have any tips? I want to block all access to the admin pages, but I still want to allow a member user to add and edit data using custom forms. Thanks! Peter

Dear Ryan, Thanks for your syntax clarifications. > I don't understand this line–it looks a bit unusual for a selector, so wondering if there might be a problem there. In the template, there's a page_id field to select a value from a drop down. So, if I did a $custom_template_file = $page->custom_template_file, I would get an ID value that points to the select value of 'article_page.html'. Thus, when I used the above syntax as a selector, it looks for all pages that have that long textual value. This way, I don't have to use the ID as a selector. But, the 'hidden' attribute doesn't seem to hide that value from being searched. > This should be: $pages->find($selectors); I thought I saw this syntax somewhere in the PW site. I thought it meant that you could specify the parent (e.g. /) in the get, and then chain the selectors off that. Is that incorrect? Thanks for all your help! Peter

Dear Ryan, I've done some more testing, so let me revise my statement above. Everything is working, in the sense that I can view what I need to view, search, etc. I confirmed that the hidden setting is preventing search results in a variety of places. I think the two questions left are: - the item above, about the template permissions, where it's set to not allow searches for guest users. I haven't been able to unlock that in my code, with the params mentioned above. So, I unchecked it. I'm wondering what the value of that is, if one can't access the data via code? - with the hidden data pages: although the other code searches and page searches correctly hide the hidden data pages, the rss page mentioned above did not require the 'include=all' parameter, which I found disconcerting, since the data elements were all marked as hidden. I'm wondering if it's because of the type of selector? custom_template_file.select_value=article_page.html "custom_template_file" is a field in my template field sets, which contains an id, which then links to an 'element' data page, with the select value of 'article_page.html'. Does that type of relational look up get searched, even when the corresponding data page is hidden? It seems so, from the behavior that I'm seeing. I think my bottom line is that my site is functional. I do hope to get more technical clarity about the above, to fill in my knowledge gaps. I must assume it's a knowledge gap, rather than a quirk or bug in your great program! Although I do think that the permissions system could perhaps be presented in a clearer and more intuitive manner. I've been going 'round and 'round in circles about it, for quite a while. Thanks, Peter

Dear Ryan, I've done some testing, and I can't get things to work properly. I've used Waynze's excellent Batcher program (thanks, Waynze!) to set all of my element data pages to 'hidden'. I set the custom_selects template to 'no access for guests', but didn't check the 'block search' radio button. The net result is that my rss items appear when I do NOT use the params: "include=all," . "check_access=0," . which means that the data pages are not protected. The pages appear in IE (not logged in) and in Firefox, after I log out. I'm not using caching at all. The only thing that really locks the pages down is checking the template - not searchable option, but then I can't get in at all, even when I use the check_access=0 param. I'm probably doing something wrong, but I can't see it. [edit: what's really weird is that the hidden flag seems to be working inside a function, where I access a 'chunk' element. I've set the element chunks to hidden, and a non-logged in browser couldn't access them with this code until I added the include=all parameter: $field_chunk_id_array = wire(pages)->find("parent=1052, include=all"); The 1052 id is the parent of the chunk pages. I do a replace of chunk tags in the body field. ==== Here's my code in 'rss.php': <?php $rss = $modules->get("MarkupRSS"); $rss->title = "RSS Feed"; $rss->description = "This feed shows the most recent items that have been published."; $rss->itemTitleField = 'headline'; $rss->itemDescriptionField = 'summary'; $rss->itemDateField = 'publish_date'; $rss->copyright = ''; $now = time(); # "include=hidden," . # "include=all," . # "check_access=0," . $selectors = "custom_template_file.select_value=article_page.html," . "sort=-publish_date," . "publish_date<=$now," . "limit=20"; $items = $pages->get("/")->find("$selectors"); $rss->render($items); Peter

Dear Ryan, I set my template to not have guest permissions, and also set the templates to not be searchable: No - Pages may NOT not appear in searches/lists unless the user has access to view themAPI Note: This setting affects the results returned by $pages->find(), $page->children() and other functions that return PageArrays. I added: "include=all," . "check_access=0," . to my params, but even with check_access=0, the results don't return unless I unselect the above search setting. Is it correct that check_access=0 does not affect that search setting? This is the setting that confused me before. Thanks, Peter

Dear Stefan, Thank you very much for the clarification. I'm not using any template files for the data pages, so I'll go back and set them all as: - hidden - published - guest viewable permissions Thanks again! Peter

Dear Ryan, I've been playing around with the combinations that affect permissions. For my 'data pages', I'm looking for this functionality: - not viewable by the public, in searches, site-maps, or url pages. - however, they should be accessible via the api for output in blocks, or pages, like the rss page. I'm still trying to figure out the right combination, between: - the template access setting (i.e. no guest access) - the unpublished setting - the hidden setting Haven't gotten clarity in my wee brain yet, but I'm working on it. [edit: I see that I can't use 'unpublished' because then the selects aren't available to use in the edit pages.] Peter

Dear Ryan, * About the copyright: Boy, do I feel silly! I had completely forgotten that the module had a settings page; a page in which I had added the © symbol and that copyright line. Oy vey! Sorry to have wasted time and bandwidth! Although I guess I can say that I learned that one can't use the © symbol in the RSS XML. It's truly amazing how many hours one can spend debugging something that was caused by a stupid little typo, or the equivalent, like the above. Oy, oy! Of course, this once again demonstrates that ProcessWire, and your code, is excellent. * About the permissions: I created a list of template values, using a data page for each, so I would normally think that even though the article pages that used those template values were public, the actual selection list of templates would not normally be public. I think I'll try the hidden flag, plus the lack of the template file to control them, while leaving the permissions to view them open to the public. I guess. Or maybe I can lock all of them down, and use the selectors you mention. Sounds like there are a variety of options that one could use. Since ProcessWire specifically uses data pages for lists of values that might otherwise be in non-public areas of the database, it might be good to come up with a tutorial on best practices for the variety of privacy settings, for data pages like that. I've created a variety of "internal" data pages that I don't want to be public web pages. Here's a graphic of them, with some of them expanded. I'd be curious to get your take on the method I've used above; if you recommend it, or not, or if you've done things differently, in your sites. Thanks for your help! Yours, Peter

Dear Soma, I've solved it. It was related to permissions with this line: $selectors = "custom_template_file.select_value=article_page.html," . When I commented that criteria out, it worked. So, I looked at the template and pages that I had created to assemble a list of custom templates. I had used a template called 'custom_data_selects', and had set it to not have guest permissions. Once I gave that template guest permissions, it worked. I have to figure out the permission system, because I had thought that it wouldn't be good to have those "pages" which just have data elements, available to the public. Between template permissions and hidden pages, I'm a little unclear. In MODX, you could create chunks that were not available for public viewing. Do you have any permission tips for that type of thing? So, with the RSS feed, I think I just have the copyright issue to figure out. Thanks, Soma! Peter

Dear Soma, No, I haven't enabled the cache on any of my templates. To run a test, I created a 'test' template, with just the title field, and full guest permissions. I then created a page off the Home page, called /test/. In the test.php file, I placed this code, which, when I'm logged in, shows the data, but when I'm not, the header (Test Page) shows up, but the selected articles do not. So, I've isolated the fact that this has nothing to do with the RSS module. (At least *this* problem. The copyright issue above is different.) Here's the code in test.php: <?php echo "Test Page<hr>"; $now = time(); $selectors = "custom_template_file.select_value=article_page.html," . "sort=-publish_date," . "publish_date<=$now," . "limit=20"; $items = $pages->get("/")->find("$selectors"); foreach($items as $item) { echo "$item->headline<br>$item->summary<br><br>"; } What's weird is that I run this code in the home page template, and it works fine. I'm missing something; probably something ridiculous, but I'm stumped. Thanks for any advice! Peter

Dear Ryan, I found another wrinkle. When I'm not logged in, the RSS page just shows the title, but no content. When I log in, the content appears. However, on the main pages of my site, the content appears whether I'm logged in or not. The rss template has permissions set for the guest to view. I'm stumped. Thanks for your help. Peter

Dear Ryan, I installed the RSS Feed module tonight, and it works very well -- now. I had to dig and dig because the feed was only showing the page title and description, but no articles. I finally found out that the default copyright element in the module was pulling in a copyright line from somewhere -- I know not where, with this line: <copyright>© 2013 The World Community Press</copyright> The feed was choking on the © entity, since that's not legal xml. I then added this to my template: $rss->copyright = ''; and the feed worked. It also worked when I used this: © for the copyright symbol, but I didn't see where the copyright appeared on the feed anyway, so I went back to a blank value. I've searched in the database and in my template files, and even in your module code, and I can't for the life of me figure out where your module was pulling that value from. That company name is inside a page item called 'footer', but it has more than just that in the footer. This is my code in the rss.php template file: <?php $rss = $modules->get("MarkupRSS"); $rss->title = "RSS Feed"; $rss->description = "This feed shows the most recent items that have been published."; $rss->itemTitleField = 'headline'; $rss->itemDescriptionField = 'summary'; $rss->itemDateField = 'publish_date'; $rss->copyright = ''; $now = time(); $selectors = "custom_template_file.select_value=article_page.html," . "sort=-publish_date," . "publish_date<=$now," . "limit=20"; $items = $pages->get("/")->find("$selectors"); $rss->render($items); When I comment out the copyright line, I get the error again. I'm stumped. Any ideas? Thanks! Peter

Dear Ryan, Hmmm... I'll have to look into the bandwidth issue. That's a good point. Thanks, Peter