Josh Henly

Send private message

You must be logged in to send a private message.

Group membership

Activity

  • Josh Henly commented on the plugin [Elgg 1.8-1.12 & 2.X: Event Calendar]
    @iionly -- thanks for the reply.  I had missed that the 'Event listing format' setting is where we could toggle a view that already uses FullCalendar.  I just tried it out and it's pretty close to what we need. I found a few...
  • Josh Henly commented on the plugin [Elgg 1.8-1.12 & 2.X: Event Calendar]
    Ok, I got a little ahead of myself in the last post.  I tried out the CalendarUI and event_api plugins on our test-site.  It looks very promising!  Unfortunately it currently doesn't support group calendars, which is important in...
  • Josh Henly commented on the plugin [Elgg 1.8-1.12 & 2.X: Event Calendar]
    @RvR -- thank you!  I didn't see that when searching the plugins directory, but it seems to be just what we were looking for.  I'll give it a try.
  • Josh Henly commented on the plugin [Elgg 1.8-1.12 & 2.X: Event Calendar]
    Hello, We use the Event Calendar plugin on our site, and I appreciate all the work that has gone into creating and maintaining it over the years. I was wondering if there were any plans or discussions about improving the UI.  In...
  • Josh Henly replied on the discussion topic 'Pages' very slow to load
    @Jon, Interesting approach!  I might be missing something, but I don't think all that sorting is necessary.  Though I admit I'm not sure what you're trying to accomplish with the 'seen' volatile data. The items in... view reply
  • Josh Henly replied on the discussion topic 'Pages' very slow to load
    @Jerome I was wondering about whether it might make sense to limit the Navigation structure to just the current page.  I'll take a look at the page_tools plugin -- thanks!  Though for the top level 'Group Pages' section of a... view reply
  • Josh Henly replied on the discussion topic 'Pages' very slow to load
    Rohit, this isn't an issue of pagination.  Whether we use ElggBatch or simply elgg_get_entities(), the purpose of the pages_get_navigation_tree() is to build a navigation structure for all the pages in the container (Group or... view reply
  • Josh Henly added a new discussion topic 'Pages' very slow to load in the group Performance and Scalability
    On our 2.3 site, one of our users makes heavy use of Group Pages.  Currently the group has ~2,800 pages.  I noticed that the page loads on any of the Group Pages for this group (top level or sub-pages) are very slow, on the order of...
    • @Jerome

      I was wondering about whether it might make sense to limit the Navigation structure to just the current page.  I'll take a look at the page_tools plugin -- thanks!  Though for the top level 'Group Pages' section of a group, I think it's going to create the hierarchy for all pages in the group regardless.

      Thanks for the warning about the possible out-of-memory error.  Our server is reasonably beefy, but this is something worth keeping an eye on.  We could probably mitigate the risk (and still get acceptable performance) by using ElggBatch with a fairly large chunk size.  Apparently our server can handle ~2,800 pages fetched at once, but maybe chunking 500 or 1000 at a time would be prudent.

    • @Jon,

      Interesting approach!  I might be missing something, but I don't think all that sorting is necessary.  Though I admit I'm not sure what you're trying to accomplish with the 'seen' volatile data.

      The items in the $tree array are added to the Navigation menu with elgg_register_menu_item(), and the hierarchy is determined by the 'parent_name' => $page['parent_guid'] option.  The order of the $tree items doesn't matter.  It doesn't even matter if you register a 'child' menu item of a parent before you register the parent itself.  Maybe under the hood in elgg_register_menu_item() things will go faster if $tree is already sorted -- I haven't looked.

    • Frustrated by how slow Pages were loading because of the tree navigation, I pulled apart the code for building them in 1.9 and re-implemented it with php arrays instead of n database calls.

      We're using volatile data to store how many times we've 'seen' this page before and using it for error checking rather than maintaining yet another array/map to keep track of that. (volatile data doesn't get set in the database the way other metadata does).

      It may be that versions above 1.9 bring in features that make this easier, but it's a 'solved problem' for our site at this point.