stuck in between floors in the elevator at 'elgg towers'

;)
i am still using elgg 1.8 here in production, since there are still key plugins that have not been upgraded to 1.9+.

i already upgraded my own plugins (mostly) to 1.9 level (basically - without optimising js for AMD) and now am looking at 1.10 and wondering where to go with this. do i skip 1.9 altogether? i can only see 2 plugins that are listed for elgg 1.10 presently.. is that a problem?

can i just use 1.9 plugins in elgg 1.10 anyway without any problem? the claim was made by core devs that 1.8 plugins would be ok in 1.9, but that was not the case at all... so i am wondering if anyone has any concrete info and tips from experience here?

  • Yeah, you have to load the engine or it will be nothing but trouble

  • ok yeah, another query parameter is the answer here.

    there is simply no chance of getting enough performance from loading the engine on every thumbnail load..
    i would say that needing to load an engine multiple times that uses significant resources goes against the nature of computing!
    i am not aware of how any other plugins would filter the thumbnail output at this point. are you?

  • Just downloaded a copy of Videolist. Last upgrade looks like November 2013. The whole thing needs an update. Look in your dataroot though. Mine creates the thumbnails but just does not show them on the site.

  • i've got the thumbnails working ok now - i have already upgraded my local copy to use full size thumbnails and most recent embed codes etc.
    my version does not load the engine for thumbnails, it's just too slow otherwise.

  • Good deal. Glad to hear you got it sorted out :-)

  • I'm sorry. But you haven't sorted it out at all. The number "1" directory is NOT the site_guid. Starting with Elgg 1.9 the user's data directories are sorted into separate directories with each having a maximum of 5000 entries. So, the "1" just indicated that this is the first bucket of user directories. At some point there will be a second bucket created and your method of gaining the filepath will fail then at the latest.

    I very much doubt that you save much time (if any at all) by this approach anyway. The thumbnails are requested via the videolist_icon_url_override plugin hook callback and the extra loading of the engine is only necessary because the retrieval of the actual file in thumbnail.php is done by calling this file directly.

    Take a look at Tidypics or iZAP Videos (my fork at least). The thumbnails retrieval is routed via the pagehandler instead of calling the thumbnail.php file directly. No extra load of the engine necessary and you can rely on all the Elgg API functions without having to add your own implementation of how to retrieve the file. This way you also haven't to deal with any changes in the underlying organization of the file structuring.

    The only plugins that fail to work in retrieving (some maybe also in saving) files are the plugins that deal with this in their own custom way. Any plugin that relies on the Elgg API shouldn't require any changes when upgrading for Elgg 1.9 or later.

  • The fact that your implementation is not checking access permissions would prevent merging the fix into the official plugin repository. (At least I guess that kind of modification isn't something that all videolist users would like to have by default.)

    But still - the correct way to upgrade a plugin is by forking the original repository and making pull requests so that the official version gets updated.

    It seems most people update plugins only to their own local environment instead of the official version. This naturally causes the official versions to become outdated and incompatible with the latest Elgg versions.

  • I just went through a 1.8->1.9 and then a 1.9->1.10 upgrade on an older production site (running since 1.3).

    A number of issues occurred, some that I am still dealing with.

    1.8->1.9 - minimal issues, mainly updating plugins to stop using deprecated functions.

    1.9->1.10 - MAJOR - The stats widget in the admin panel needed more than 512M (worked with 1024M) to load without issues.   Once I deleted the widget from the admin dashboard the page loaded, however I was unable to add a widget back to the page.  The "Add Widget" button is not seeming to work at all currently.

      Major issues on the Basic site statistics.  It begins loading and then:

    Elgg version :    Release - 1.10.1, Version - 2014130300
    Number of users :    966 Active / 1000 Total

    Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /home/www/klatch.org/html/sites/engine/classes/Elgg/Database.php on line 350

    Similar to what happened with the stats, the queries being ran are causing the machine to run out of memory.

      Minor issues with plugin management, being redirected the front page when I move a plugin up or down.

      Minor issues with nginx config (much less than in the past thanks to the default config supplied)

      Minor issues with old entities in the database (user sessions etc).  I manually cleared the table, but 630,000+ sessions saved in there seems like a bug.

    At this point im heads down updating plugins, so no plugin specific issues yet.

     

  • @iionly: ok, i see - this is why i did ask for the documented definition of how the file system is now configured.. i still haven't seen any comment on this at all in official elgg documentation and still don't even know how this is intended to be handled correctly. surely this is a fundamental requirement of using elgg now and yet there are no notes on this? or am i missing them?

    switching the thumbnail loading process to prevent multiple engine load absolutely does speed the process up significantly, i know this as i measured this using new relic php performance analysis software and found the videolist thumb process to be the slowest one on my site (until the thumbnail file was rewritten). i will look at your solution from tidypics, since your approach sounds to be the correct one - thanks.

    @juho - videolist's thumbnail solution has never checked access permissions, as far as i am aware. i agree that this is a needed funciton. videolist is generally very much in need of being rewritten. using the hypeScraper plugin to grab video embed codes remotely is one way to significantly improve videolist's functionality.

  • I can confirm that the admin stats widget leaks memory and causes wsod on a site I upgraded from 1.7. Haven't had a chance to debud yet.