Jump to content

jon9china

Members
  • Posts

    43
  • Joined

  • Last visited

Recent Profile Visitors

1,582 profile views

jon9china's Achievements

Jr. Member

Jr. Member (3/6)

7

Reputation

  1. What if you are moving a site to a new server but changing domain name in the process? Are there some other steps that are required?
  2. Oh, yes, I am using master version, not dev version. ?
  3. Sorry for missing the reply, adrian. Yeah, in fact I am using the latest version of Processwire. Just installed it earlier this year for this new site. Hmm. surprised that didn't recreate the error. Not sure my description is accurate, then, in light of that fact. Nevertheless, my changing that field from taking a page where template=user, to just a text field did solve the issue and haven't had any surprises from the module since. At least this I can say.
  4. If that is confusing, then it might be simpler to just say the following: to recreate the error, create a template with a field of type page that accepts template=user. (you could name the field 'master_of_this_branch') create a page with that template and select a test user as 'master_of_this_branch' in the test user's profile, restrict him to a branch using that page as its root. reference that field ('master_of_this_branch') in a page in the test user's tree and signed in as that test user, navigate to that page and should produce the infinite loop.
  5. ok, here it goes. Here is the offending code block after being changed: //do we find that a user field for teacher root page matches the logged in user's data? $isTeacherPage=0; $loggedInUsername=$users->getCurrentUser()->name; foreach($myTeacherRootPages as $thisTeacherPage){ $herUserName = $thisTeacherPage->teacher_user_name; if($herUserName==$loggedInUsername) { $thisTeacherId = $thisTeacherPage->id; //found a teacher match; this guyz'a teacher $isTeacherPage = 1; } } the 'teacher_user_name' is a text field. Formerly, what was causing the error, was when this field was a page field that contained pages of template=user. (And on the appropriate page in that field, the restricted user would be selected to indicate that this was her branch) When the user who reaches this page on the frontend is a user who has been restricted to this branch of the tree, which also contains this page, then the page caused the error. The template for these $myTeacherRootPages formerly contained a field of type Page, called 'user_profile' where template=user With the above code, where problem was solved, in the template, this field was deleted and replaced with a text field 'teacher_user_name' whose value is hardcoded to match the 'name' field of the desired user's user page. If, incidentally, the user's restricted branch did not contain this page, then this user being logged in and opening this page did not cause an error. the code formerly was something like this: $loggedInUsername=$users->getCurrentUser() foreach($myTeacherRootPages as $thisTeacherPage){ $herUserProfile = $thisTeacherPage->teacher_profile; if($herUserProfile==$loggedInUser) { $thisTeacherId = $thisTeacherPage->id; //found a teacher match; this guyz'a teacher $isTeacherPage = 1; } } It seemed on any page where I referenced the 'teacher_profile' field in the template, like above, when the restricted user was the one opening that page, then produced the error/infinite loop.
  6. and, yes, my initial post, i did mean "User Specified Branch Parent"
  7. Looks like I solved the problem. Your mention of an infinite loop got me looking out for a potential cause. I had a field of type Page Reference that selected from user pages. When I used that field in selectors - those are the pages that caused the error. They were looking for the page that identified the restricted user that was logged in - if that makes any sense. So hope this description is helpful for understanding the problem. I just modified that field instead of choosing a page with template user, I use a field for email. Not the best solution for me for now, because the user could change their email and then my code will miss the match with that user, but does clean up the code so that I can use the module without having that fatal error. Thanks!
  8. This module can really be a lifesaver for me if I can use it. But unfortunately I am getting this error on certain pages when i have it installed and am using the user restricted branch setting (when i uninstall the module, errors go away): Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 262144 bytes) in /home/u985981598/domains/clozewizard.com/public_html/wire/core/Wire.php on line 1160Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 262144 bytes) in Unknown on line 0
  9. Thanks Bernhard! Looks like one of these modules from a thread you shared may help me. Grats.
  10. I am creating a tutor/student management system where i give processwire’s backend access by roles to tutors and allow them to info such as concerning payments on pages. But I want to be able to keep data like that non-viewable by other ‘tutors’. Is this possible? ‘View’ rights for all things are automatically granted for all roles. Is there a way to, for example, keep child pages of certain pages viewable only by super user and the author?
  11. well, could it be any easier?! Nice. Thanks, kongondo!
  12. it seems that the way to restrict ability to author pages is through roles and templates. Is there a way to disallow a user with a given role to edit pages that a different author created, so that users of that role can create pages and only edit those pages which they themselves have created?
  13. I want to return a repeater object in my pages by matching the value of a field within the repeater. In docs, it says repeater can be treated like a page, but what does that mean for this sort of case? for example, my repeater might be named: 'word_object', which includes fields 'this_word', 'definition', etc. and i want to return a word_object where the field 'this_word' == 'apple'
×
×
  • Create New...