Send private message

You must be logged in to send a private message.

Friends

No friends yet.

Activity

  • Fabio commented on the plugin CKEditor - Replaces TinyMCE
    I am having a strange issue: We use CKEditor to create new pages CMS like. When we have the following code INSIDE a CKEditor instance, the CKEditor displays the code right, but the newly created page doesn't display the code! Any idea what could...
  • Fabio commented on the plugin Group Admin Transfer
    I can see that it is not: There is a call to elgg_add_action_tokens_to_url() in views/default/group_admin_transfer/transfer.php.   elgg_add_action_tokens_to_url ( $  url  )    Since: 1.7
  • Fabio commented on the plugin Group Admin Transfer
    Hi Jeroen, we also really need this (thanks so much!). Is this plugin compatible with elgg 1.5? I am also having troubles. Clicking on 'edit group', I get a white page...Before debugging any further, I'd like to know about the...
  • Fabio added a new discussion topic Add default widget for existing users? in the group Elgg Technical Support
    At our site we want to enable the 'thewire' plugin, and add a 'thewire' widget to profiles. Now, I can do that with the 'default widget' plugin. However, that appears to work for NEW users only. Is there a chance to display default widgets for...
    • Dhruva,

      I intend to do that but I need to strip first for any client specific info :-).  If time permits it should be there by next week.

    • Fabio,

      The main problem that I see with the above code I posted is that users could end up with duplicate widgets if they already had one of the widgets you were inserting.

      It sounds as though your client is basically wanting a locked down set of mandatory widgets for everyone.

      You could always delete all profile widgets first before running my code if your client does not care what their users already have.

    • The quick-and-dirty way to lockdown widgets is to hide the edit page and edit widget links using CSS.

  • @PLai, I'd say your comment hits the nail on the head. I hope to be able to try it out soon...but as usual, other critical bugs around, so leaving the working horse to be checked later :) view reply
  • Sorry guys, was working with different branches and got confused. The problem was not at all there. I override the input/acces view, because as we have dgroups and groups, the drop-downs for access were always displaying both "group:xxxx" and... view reply
  •   Using elgg 1.5 We have a special arrangement, in that we have a 'group' plugin which we use for 'projects', and a 'dgroup' plugin which we use for groups. Basically two copies of the same plugin. All was working fine, until I discovered a...
    • Sorry guys, was working with different branches and got confused.

      The problem was not at all there. I override the input/acces view, because as we have dgroups and groups, the drop-downs for access were always displaying both "group:xxxx" and "project:xxxx" (coming from the dgroup and group respectively) - when in fact in a specific page, it can be only the one OR the other.

      I put in this code in my input/access view (sorry for length):

      /* line 40 */ foreach($vars['options'] as $key => $option) {

      $page_owner = page_owner_entity();       
             
              if ($page_owner)
              {
                  $type = page_owner_entity()->getSubtype();
                  $start = substr($option,0,strlen($type));
                 
                  //if the option starts with project or dgroup
                  if ( (stristr($option,'project') ) || (stristr($option,'group')) )
                  {
                     
                      //if it's a group, we don't need the project access list
                      //if it's a project, we don't need the group access list
                      if ( strcasecmp($start, $type))
                          continue;
                  }
              }

      it looks like a terrible hack but it works, it seems...my problem was that in the page which was breaking, page_owner_entity()->getSubtype(); didn't return a valid page_owner_entity and thus the call to ->getSubtype failed.

      If you see some obvious misconception here or have any other suggestion, you're most welcome.

       

       

    • Instead of changing input/access.php, you could also try to use the 'access:collections:write' hook.  You would notice that input/access.php calls get_write_access_array() when the list of access groups is not provided through $vars['options'].  The 'access:collections:write' hooks are called by get_write_access_array() to customize the access group list.  So I suppose one of your plugins can do the filtering.

      Note that the groups plugin attaches group ACLs to the access group list precisely through this hook.  You may choose to change the code there (and presumably in your dgroup) to be more discreet, thus avoiding filtering later.

      Yet do you expect page owner entity to be null?  If not, you may want to look into it further.  It may cause you other problems down the road.  A plugin can call add_page_owner_handler() to make custom page owner available.

      I also remember you had problem with "group:guid" in URL.  I wonder whether you use "dgroup:guid" or just "group:guid" for your dgoup's name.  I am not sure if it is necessary to override the name format.

    • @PLai,

      I'd say your comment hits the nail on the head. I hope to be able to try it out soon...but as usual, other critical bugs around, so leaving the working horse to be checked later :)

  • Fabio replied on the discussion topic Pagination problem elgg 1.5 with page_handler
    Right PLai, thanks for this. I have decided to fix it the same way you did, although I am also not super happy about this solution :) thanks view reply