[Elgg 1.8-1.12 & 2.X & 3.X: Customsize Groupimage] v1.9.0

Release Notes

  • Version 1.8.0 updated for Elgg 1.9.
  • Hi @iionly, in Elgg 1.9.8 if I enable the plugin I lost the profile image.

  • @Javier I've just tested on Elgg 1.9.8 and it works for me.

    Had you used the Customsize Groupimage already before upgrading to Elgg 1.9.8 or have you not used it before? It might be an issue with another plugin / your theme used on your site. It might help to move the Customsize Groupimage plugin lower in the plugin list to solve the conflct but best would be for you to identify what other plugin might cause the problem.

  • @iionly yes, I had used it before, I´ve just upgraded from 1.8 to 1.9.

    I´ve moved it to the bottom but problem persist, and I´ve the same installed plugins (updated to 1.9) as in 1.8 installation.

    Thanks.

  • @Javier Are you sure that you've completed the upgrade from Elgg 1.8 to 1.9 (no pending upgrades showing up under "Configure - Upgrades")?

    Are you sure that you've updated the Customsize Groupimage plugin to version 1.9.0?

    Even when using the same plugins you've used before on Elgg 1.8 it might still be a problem caused by another 3rd party plugin that only occurs on Elgg 1.9? I would suggest to test with all other 3rd party plugins temporarily disabled. Maybe flush the cache of your site (in the admin backend) and flush the browser cache, too, to make sure the problem isn't a caching effect.

    If these suggestions do not help, I'm afraid I'm currently at a loss. The Customsize Groupimage plugin does neither create nor delete any group images on its own. The only thing it does is displaying the orginal sized group image instead of the resized version on group profile pages. If the original group image is there and no other plugin interferes with displaying it I have currently no idea what could cause the problem.

  • @iionly under "Configure - Upgrades" two upgrades are shown (Group Discussions Upgrade & Comments Upgrade), but when I select them this message appears:

    Upgrades : Discussion reply upgrade

    Upgrade finished

    Upgrades : Comments upgrade

    Upgrade finished

    About 3rd party plugins I disabled some of them (related to groups), but problem persist, I´ll try disabling some more...

    This is the webserver log:

    2015/01/31 08:47:47 [error] 1038#0: *3756 open() "/home/www/redup_triploader_com/htdocs/groupicon/508/master/1412868522.jpg" failed (2: No such file or directory), client: 62.14.183.8, server: redup.triploader.com, request: "GET /groupicon/508/master/1412868522.jpg HTTP/1.1", host: "redup.triploader.com", referrer: "http://redup.triploader.com/groups/profile/508/madrid"
    2015/01/31 08:47:48 [error] 1038#0: *3751 open() "/home/www/redup_triploader_com/htdocs/groupicon/508/tiny/1412868522.jpg" failed (2: No such file or directory), client: 62.14.183.8, server: redup.triploader.com, request: "GET /groupicon/508/tiny/1412868522.jpg HTTP/1.1", host: "redup.triploader.com", referrer: "http://redup.triploader.com/groups/profile/508/madrid"

    Thanks

  • @Javier Do you always get the "Upgrade finished" message when going to the Upgrades page? It should show rather "Your installation is up to date!" if the upgrades have already been done before.

    The error messages about the failure on opening the group image files look not right to me at all. Unfortunately, I can't say exactly what is wrong and why. The path "/home/www/redup_triploader_com/htdocs/groupicon/508/master/1412868522.jpg" looks like a strange mixture of a path that looks rather to be the path to the Elgg root directory (/home/www/redup_triploader_com/htdocs/) than the path to the data directory plus part of the image url (groupicon/508/master/1412868522.jpg) that shouldn't turn up in the path to the file at all.

    Does your site really works without issues apart from the Customsize Groupimage issue?

    It looks to me that something is not right on your site either with the data directory itself, the path currently set for the data directory or the filestore entry in the database.

    May I ask if you have moved your site in addition to upgrade to Elgg 1.9? If this is the case, are you sure than you updated the database entries correctly?

    If all these explanations don't explain what's wrong, it could still be some conflict with another plugin. Please disable ALL 3rd party plugin temporarily and not only the plugin you think that they might be connected.

    Or it could have occured some problem when upgrading the Customsize Groupimage plugin to the Elgg 1.9 version. Maybe it helps to replace the plugin folder with the 1.9 version to make sure that no corrupt file causes the problem.

  • @iionly yes, I also moved the site to test the 1.9 upgrading.

    I´ve done all the upgrade process again and now no pending upgrades appear in  "Configure - Upgrades"

    I´ve disabled all plugins except groups, and now I´ve lost the group profile images. 

    2015/02/01 09:40:33 [error] 1038#0: *6053 open() "/home/www/redup_triploader_com/htdocs/groupicon/6811/tiny/1416395125.jpg" failed (2: No such file or directory), client: 62.14.183.8, server: redup.triploader.com, request: "GET /groupicon/6811/tiny/1416395125.jpg HTTP/1.1", host: "redup.triploader.com", referrer: "http://redup.triploader.com/groups/profile/6811/hotel-tryp-atocha"
    2015/02/01 09:40:33 [error] 1038#0: *6058 open() "/home/www/redup_triploader_com/htdocs/groupicon/6811/large/1416395125.jpg" failed (2: No such file or directory), client: 62.14.183.8, server: redup.triploader.com, request: "GET /groupicon/6811/large/1416395125.jpg HTTP/1.1", host: "redup.triploader.com", referrer: "http://redup.triploader.com/groups/profile/6811/hotel-tryp-atocha"

    With ckeditor I also have problems:

    2015/02/01 09:41:24 [error] 1038#0: *6058 open() "/home/www/redup_triploader_com/htdocs/cache/0/default/js/elgg/groups/edit.js" failed (2: No such file or directory), client: 62.14.183.8, server: redup.triploader.com, request: "GET /cache/0/default/js/elgg/groups/edit.js HTTP/1.1", host: "redup.triploader.com", referrer: "http://redup.triploader.com/groups/edit/6811"
    2015/02/01 09:41:24 [error] 1038#0: *6061 open() "/home/www/redup_triploader_com/htdocs/cache/0/default/js/elgg/ckeditor.js" failed (2: No such file or directory), client: 62.14.183.8, server: redup.triploader.com, request: "GET /cache/0/default/js/elgg/ckeditor.js HTTP/1.1", host: "redup.triploader.com", referrer: "http://redup.triploader.com/groups/edit/6811"

     

    So I think something goes wrong in the database but, how can I check/solve it?

    This is the data directory structure after the 1.9 upgrading, bold marked directories have been created by the upgrade, and 2015 directory now does´t exist.   

    drwx------ 162 www-data www-data 4096 Feb  1 09:09 1
    drwxrwxrwx   4 root     root     4096 Feb  1 08:51 2011
    drwxrwxrwx  13 root     root     4096 Feb  1 08:51 2012
    drwxrwxrwx  12 root     root     4096 Feb  1 09:09 2013
    drwx------  13 www-data www-data 4096 Feb  1 09:09 5000
    drwx------   2 www-data www-data 4096 Feb  1 09:40 system_cache
    drwxrwxrwx   3 root     root     4096 Feb  1 08:50 tmp
    drwxrwxrwx   4 root     root     4096 Feb  1 08:51 translation_editor
    drwxr-xr-x   2 www-data www-data 4096 Feb  1 09:40 views_simplecache
    drwxrwxrwx   3 root     root     4096 Feb  1 08:50 widgets

     

    Thank you very much.

     

  • @Javier The listing of directories in your data directory makes me wonder if the data directory migration not having been completed correctly might be the reason why the group images are not showing up (and possibly other stuff you've not yet missed, too). Even if the upgrade script tells you it's finished I begin to think there were not all user data migrated successfully.

    The directories "1" and "5000" have been created at the data migration. The names are what to be expected within the new data directory structure. BUT the directories "2011", "2012" and "2013" (and everything that's possibly still left within these directories) look like they belong to the outdated data directory structure of Elgg 1.8. I would have expected these directories would be no longer there if they would have been migrated successfully.

    The reason for an unsuccessfully completed data directory migration might be due to the owner and group the "2011", "2012" and "2013" belong to (root:root). The webserver is running on the account named "www-data" anf group "www-data". That's the reason why the new directories show www-data:www-data as owner/group. Even if the directories show up read/write/access permissions 777 (drwxrwxrwx) at least for the "2011", "2012" and "2013" directories this might not be true also for all content and subfolders within them.

    My guess is that when you moved the data directory (most likely rather creating a copy) the original owner, group and permission info was not preserved but instead at least owner and group changed to root (the account used to create the copy).

    I would suggest to start the testing again from the beginning. That might be slightly annoying but you need to have a working basis without errors first before you can start the testing of plugins on Elgg 1.9 in any useful manner. Most likely it would be possible to fix the current test installation by some means, too. But it wouldn't be trivial and most likely would take much longer than starting fresh.

    Start with making a fresh duplicate of the database and data directory to be used for the test installation. Changing the database entries to the new paths and site url and setting up the Elgg install directory with working settings.php, .htaccess files and any 3rd party plugins (compatible version) is to be done as described in the "duplicate site" instructions.

    But before doing the actual upgrade you should execute the following commands on the copy of the data directory to be used for the test installation:

    chmod -R 777 /path/to/data-directory

    and

    chown -R www-data:www-data /path/to/data-directory

    This will make sure that the webserver can read/write/access all files and subfolders within the data directory. Only then should you run the core update immediatelly followed by execution of the data directory migration and comment entry migration upgrades. Hopefully, it will work out this time and then you can start testing the plugin compatibility on Elgg 1.9.

  • @iionly, I´ve just done a fresh duplicate of the database and data directory, disabled all plugins, changed perms and owner, and I done the upgrade process again. I also manually cleaned the cache directories (system_cache and views_simplecache), but the data directory has the same structure after the update:

    drwx------ 162 www-data www-data 4096 Feb  1 16:06 1
    drwxrwxrwx   4 www-data www-data 4096 Feb  1 15:50 2011
    drwxrwxrwx  13 www-data www-data 4096 Feb  1 15:50 2012
    drwxrwxrwx  12 www-data www-data 4096 Feb  1 16:06 2013
    drwx------  13 www-data www-data 4096 Feb  1 16:06 5000
    drwx------   2 www-data www-data 4096 Feb  1 16:03 system_cache
    drwxrwxrwx   3 www-data www-data 4096 Feb  1 15:50 tmp
    drwxrwxrwx   4 www-data www-data 4096 Feb  1 15:50 translation_editor
    drwxr-xr-x   2 www-data www-data 4096 Feb  1 16:03 views_simplecache
    drwxrwxrwx   3 www-data www-data 4096 Feb  1 15:50 widgets

    May it be a server configuration problem?. I´ve NGINX with the recommended rewrite rules, and the server log doesn´t display erros on data directory update process.

    Thank you. 

  • @Javier I thought that the old directories would get removed if they have been successfully migrated (maybe I'm wrong but I still think that this looks like an incomplete migration). Are there any files left in the 2011, 2012 and 2013 directories (not just directories but files)?

    I would suggest to check for one group (where the images are missing) if the group images have been moved to the new location or not.

    The group images are saved in the user's subfolder who created the group. In the old structure this is in

    year/month/day/user_guid/groups

    Here the year, month and day is depending on the user's join date. Within the groups folder the images have name containing the group guid.

    The location of the user's subfolder in the new structure is

    bucket_number/user_guid/groups

    I don't know how you can easily find out in which "bucket_number" directory a user is now to be found. As I understand there is a new "bucket_number" directory for every 5000 users. Just look into the "1" and "5000" directory for a subfolder with the group founders user_guid.

    Are the group images to be found in the user's subfolder in the new structure? If yes, there must be another reason why they are not displayed. If no, the data directory migration fails to complete on your test site - do you see any errors in the server logs? If the latter is the case, I think it's time to open an issue at github asking the Elgg core devs for advice, because this would clearly indicate that there's a severe problem in the upgrade routine. If this problem has anything to do with nginx or what else might influence the migration is something I can't say.

  • @iionly, problem solved itself. I don´t really know what happened, I think Group Tools plugin was the problem source but I´m not sure, I disabled it and enabled again and all works: Groups image, CKeditor, ...  

    The data directory continues with the same structure I posted, but all images and data are accesible.

    Thanks @iionly for your help.

Stats

  • Category: Misc
  • License: GNU General Public License (GPL) version 2
  • Updated: 2019-4-6
  • Downloads: 1515
  • Recommendations: 5

Other Projects

View iionly's plugins