Jump to content

einsteinsboi

Members
  • Posts

    132
  • Joined

  • Last visited

Posts posted by einsteinsboi

  1. Page field with PagelistSelectMultiple as inputfield is probably your best bet.

    It's great but the fact that you have to select one option at a time and then it collapses and you have to reopen it can be a bit time consuming... it's fantastic otherwise :)  Would be great if there was the option to use checkboxes as a workaround to select multiple options at once.

    • Like 2
  2. I'm using this fieldtype to assign some users access on a per-page basis (something I have occasionally seen a need for in other topics here on the forums) and agree with Soma that it would be good to be able to keep the tree open after selecting an item.

    Does anyone have any idea how to do this? I looked at the JS file for the module but couldn't see anything obvious in there unfortunately.

    Is there a simple way to prevent it collapsing automatically using some JS?

    I'm wondering if anyone ever solved this? Still searching the forums...

  3. Hi einsteinsboi,

    It still would be nice to what your hostingcompany did to produce those errors. What did they exactly trace and how they did it?

    It seems like the server had some issues with the directory structure since no ProcessWire file by default calls those functions as far I know. 

    Yeah they wouldn't tell me exactly, just that it was the output of a trace command, so not sure. Looks like Matthew got the exact same errors in the admin area  :huh:

    Greetings,

    Yes -- same error, same time. And yes, references to files that never existed. It happened for me in the admin area just after I confirmed the deletion of a couple of fields.

    Is it possible we're on the same server?

    The problem resolved, but I am concerned about what it means that it happened at all.

    Thanks,

    Matthew

    Possibly. This particular website is on Site5 on one of their Sydney servers. What hosting are you on?  I thought it was a weird glitch on my end but the fact that you got those same exact errors does make me a tad more concerned...  I'm running PW 2.5 and the non-core modules I have installed are Map Marker, Form Builder, Map Markup, Markup Simple Navigation, Page Edit Field Permission, and Page Edit Per User.

  4. That's strange... weird that two completely unrelated PW installs decided to go wonky at the same time... When you say the same errors do you mean the ones with the missing files that never existed in the first place?  All my other PW installs are fine and dandy, only this one decided to barf and barf hard it did.

    Greetings,

    I had exactly the same errors around the same time that einsteinsboi posted here. It got me concerned, but within an hour it resolved itself. Not sure what that was about.

    Should this be a concern?

    Thanks,
    Matthew

  5. @kongondo, very freaky coincidence indeed! 

    Thanks for the tips. What I had done was make a copy of the module folder. I renamed that copy PageEditFieldPermissionCustom and then renamed the .module file and did a find - replace inside the .module file. 

    Will follow your exact steps above tomorrow and see how I go. 

    thanks again :)

  6. @Mary,

    Yes, you need to create an autoload module...You would need the other bits required in a module, e.g. the install and uninstall methods...Shout if you need any help..

      ??? I've never created or tried to create a PW module... :undecided:   Time to leap into the docs again... I'm sure I'll be shouting soon...

    thanks for your help kongondo

  7. Thank you for responding.  Wanze's code in the second link looks like just what I need but I'm puzzled a bit about where it goes. I have left a question on that thread and in the meantime I'll do a bit of experimenting to see if I can't figure it out on my own.  Thank you again for pointing me to those links.

    I don't think there are any 'ready to go' solutions for this, mainly because hiding non-editable pages in a tree based hierarchy can be problematic. I'm digging up a quite old -but still relevant i think- thread with also some contributions from Ryan. https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/

    If this is really needed i'm wondering if it wouldn't make more sense to keep such users out of the pages tree all together, and instead build a custom page where they can view everything the are allowed to, and nothing more. https://processwire.com/talk/topic/6142-hide-page-tree-in-the-admin/

    Maybe someone else has some new insights on this subject.

  8. This looks like just what I need but what I'm puzzled about is where do I put this code? Do I create a new module with this code or?

    Hi reno,

    I think it is doable with two hooks. One hook would return false for Page::viewable() for the ProcessPageList page.

    Another Hook can be used to redirect your users to a custom admin page after login.

    I've only used the second one in a project, but I think something like this should work:

    // This needs to be an autoload module
    
    public function init() {
      $this->addHookBefore('ProcessHome::execute', $this, 'rootPage');
      $this->addHookAfter('Page::viewable', $this, 'viewable');
    }
    
    /**
     * Redirect users with custom-role to another page after login
     */
    public function rootPage(HookEvent $event) {
      if ($this->user->hasRole('custom-role')) {
        $this->session->redirect('custom-admin-page/');		
      }
    }
    
    /**
     * Don't give users with custom-role access to Pages page
     */
    public function viewable(HookEvent $event) {
      $page = $event->object; 
      $user = $this->user;  
      if ($page->id == 3 && $user->hasRole('custom-role') {
        $event->return = false;
      }
    }
    
    
  9. Thank you Horst. I had not even had a chance to install the module as I couldn't find it in the list of modules, and then the module admin page stopped loading, and then the site went kaput!

    After chatting with my hosting company for a bit they discovered there was a segmentation error and once they changed the PHP version the 500 internal server error went away (https://processwire.com/talk/topic/8268-strange-internal-server-error/) and the site loaded fine.  I still don't completely understand how or why it happened so suddenly.  I'm taking a small break now and will be back to experiment with the custom module tomorrow.  Fingers crossed nothing goes wrong now, will take full backups before doing anything.

    @Mary: do you have uninstalled the core module before you installed the CostumModule?

    There may be chance that are settings in the modules cache that need to be refreshed after you have deleted it manually. Does the Frontend work? If so, you can simply add a line of code to force a refresh of the modules cache:

    wire()->modules->resetCache();
    

    If you also cannot use the frontend, you may simply empty the DB table named "caches". (Do not delete the table, but delete all of its records). If this doesn't change the 500 Error, do it again and also check in the table named "modules" around the last entries, (when sorted upon field created), if there exists an entry for your manually deleted CostumModule. If yes, drop that record. Now try to go to the admin again. HTH & good luck.

    BUT, BEFORE you start with manipulating the DB, please make a backup! :)

  10. So they seem to have fixed it by changing the PHP version... I still don't get why it was working one second and then down the next though.  Here's the message they've sent me:

    I was able to resolve the issue on your site by adjusting it to run under PHP5.4. It looks like the issue was due to the php version, indication from the segmentation fault which is by definition an unhandled error most likely related to PHP and the set environment on the account.
    

    I'm not sure what version of PHP they changed from but have asked them. 

    • Like 3
  11. Can't reproduce the error notices, but when I asked them where they got the errors from they say it's output from a trace command.  They're also suggesting it's something wrong with the software (i.e. processwire) because when they try to execute index.php directly they get a segmentation error?

  12. My processwire site had been working just fine. Today I was doing some edits, added a couple of users, and was making a copy of a module to play around with the code when the site started acting funny. I never got to install or activate the modified module because  first the module admin page kept redirecting to my sites 404 page. Then the whole site started delivering an internal server error (500).  I deleted my custom module folder but that didn't help. I checked the processwire site/assets/logs/error.txt file but nothing there.  The cpanel error log also seems to show nothing there.

    I have opened a support ticket with my hosting company and this is what they've come back with:

    I have looked over this and it seems like the script you have there is ending execution prematurely. Upon a closer look we have noticed that multiple script related files are missing, such as theme files:
    stat("/home/thecodin/public_html/mnz/wire/core/AdminThemeDefault.php", 0x7fff1ad9eb60) = -1 ENOENT (No such file or directory) 
    stat("/home/thecodin/public_html/mnz/wire/core/AdminThemeDefault.php", 0x7fff1ad9e980) = -1 ENOENT (No such file or directory) 
    stat("/home/thecodin/public_html/mnz/wire/core/AdminThemeDefault.php", 0x7fff1ad9eb90) = -1 ENOENT (No such file or directory) 
    stat("/home/thecodin/public_html/mnz/wire/core/AdminThemeDefault.php", 0x7fff1ad9ebe0) = -1 ENOENT (No such file or directory) 
    stat("/home/thecodin/public_html/mnz/wire/core/14fk4pd5jgte0811d.php", 0x7fff1ad9ebe0) = -1 ENOENT (No such file or directory) 
    stat("/home/thecodin/public_html/mnz/wire/modules/PageRender.info.php", 0x7fff1ad9f380) = -1 ENOENT (No such file or directory) 
    stat("/home/thecodin/public_html/mnz/wire/modules/PageRender.info.json", 0x7fff1ad9f380) = -1 ENOENT (No such file or directory) 
    stat("/home/thecodin/public_html/mnz/wire/core/PageRender.php", 0x7fff1ad9eb70) = -1 ENOENT (No such file or directory)
    

    Anyone have any ideas? None of these files look familar to me. I have uncompressed and checked my last backup and they weren't there, and they're not in the original PW 2.5 download folder as far as I can tell. So how can they be missing?

    Any thoughts are welcome.

  13. Really strange, my site was working just fine and I editing was some pages, just content, and I also added a couple of new members the usual way, no problems.  Then I decided to try to make the changes to the module.  I created a copy of the module folder and renamed it as you recommended, and renamed the .module file and did a find replace then edited the code in the custom module as you recommended. When I tried to go to the /modules/ page to find and install the new module, it wouldn't see it, and a few seconds later the whole site started throwing an Internal Server Error (500).  I have checked the processwire error log and it shows no errors, and have also checked my cpanel error log, also no error. I deleted the custom module folder but still getting a 500 error.  What could be causing this and how do I fix it?  All other sites on the account are working fine but this one's throwing an internal server error and I can't help but wonder. 

    @Mary...With the current module you can't...but...with the following simple change, you can :-). Of course, you can always just request Ryan to make this configurable (i.e. whether to completely hide the field or just lock it down, etc)...Meanwhile....

    1. Create a custom copy of the module

    2. Rename the module file from PageEditFieldPermission.module to say PageEditFieldPermissionCustom.module

    3. Rename the module class similar to #2 plus change all instances of PageEditFieldPermission (whole word) in the module code to PageEditFieldPermissionCustom

    4. Change line #91 in your PageEditFieldPermissionCustom as shown below (see inputfield collapsed setting constants here)

    //if($field) $field->parent->remove($field);//comment this out
    if($field) $field->collapsed = Inputfield::collapsedNoLocked;//add this line
    

    Haven't thoroughly tested...

  14. Thank you kongondo... I'll give this a try and let you know. You're awesome :)

    @Mary...With the current module you can't...but...with the following simple change, you can :-). Of course, you can always just request Ryan to make this configurable (i.e. whether to completely hide the field or just lock it down, etc)...Meanwhile....

    1. Create a custom copy of the module

    2. Rename the module file from PageEditFieldPermission.module to say PageEditFieldPermissionCustom.module

    3. Rename the module class similar to #2 plus change all instances of PageEditFieldPermission (whole word) in the module code to PageEditFieldPermissionCustom

    4. Change line #91 in your PageEditFieldPermissionCustom as shown below (see inputfield collapsed setting constants here)

    //if($field) $field->parent->remove($field);//comment this out
    if($field) $field->collapsed = Inputfield::collapsedNoLocked;//add this line
    

    Haven't thoroughly tested...

  15. I have just installed this module and I'm using it to restrict members of a site from being able to edit certain fields which are part of their user profile page (which is a page on the tree that only they have access to edit). However, I want them to still be able to see the fields, just not be able to edit them. Is this possible?

×
×
  • Create New...