Image Path in DataBase Appears Invalid
By Josh Lewis on Thursday, 01 January 2015
Posted in General Issues
Replies 11
Likes 0
Views 713
Votes 0
I recently swapped my photos from "/media/com_easysocial/photos" to "/gallery" as well as the avatars to simply "/avatars" via the ES storage configuration. I moved the files over to the appropriate directories, cleared my browser cache and everything displayed as it should. I looked into the database table "_social_photos_meta" and saw that the value column attempts to use the full path. A value example is "/media/com_easysocial/photos/4/5/ed65b451e9f39a0933c73544204f32f5_original.jpg". However this does not seem accurate. The image is being accessed through the new path which is "/gallery/4/5/ed65b451e9f39a0933c73544204f32f5_original.jpg". Because the old path is now deleted, if the entire path was actually read it would not display the image at all. But instead images are loading just fine.

Screen shot of the _social_photos table.



What I'm getting at is that the root path is being ignored which makes me question why the entire path is being written in the first place. The table "_social_avatars" uses perfect form in my opinion. It also produces way less records based on it's structure (1 record per image rather than 6 just to reference the image paths).

Screen shot of the _social_photos_meta table.



Basically I'm looking out for the infrastructure of ES to save you guys and us headaches in the future. (performance wise/potential complaints in the future) In this case it's about saving space where useless information is being stored. Also I'm a bit concerned about the gallery structure in how 6 records are used to access a single image. Why not use the same method as the avatars or at least one that requires accessing less records for a single photo?

I'm still very happy with how the gallery operates from a user point of view. Hoping all is well with the stacked team and wishing you all a happy new year.
Hello Josh,

Some of your data is actually pretty old. We are no longer storing absolute paths for these photos any longer. Perhaps one of your upgrades messed up as it did not go through the maintenance fix to address the path issues.
Mark
·
Thursday, 01 January 2015 13:58
·
0 Likes
·
0 Votes
·
0 Comments
·
I just tested a new photo, and the path is "/gallery/20/70/p1040949a_original.jpg". This is much better. I'm curious about why the directory specified in the ES storage configuration is required to be stored? For example I figured the one I just mentioned would be "/20/70/p1040949a_original.jpg" in the DB table. Perhaps it's an assumption, but couldn't it be configured so that php renders the base directory and then SQL assigns the proceeding folders? This way the path could be simplified by one more directory.

I do admit it that I'm a bit of a perfectionist, I do not expect perfection but I do strive for it when possible and as long as it doesn't create too much trouble. My point being that my intent is not to be too expecting from you guys, but I do strive for making sure the best practices possible are being used.
Josh Lewis
·
Friday, 02 January 2015 15:47
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello Josh,

I am sorry for the delay of this reply.

Regarding the issue, I've fixed the issue internally and also applied the fix at your site. Can you please try again? The fix will be added into next release of EasySocial as well.

The file is locate -> JoomlaFolder\components\com_easysocial\controllers\photos.php

Hope this help and have a nice day
Arlex Wong
·
Wednesday, 07 January 2015 22:21
·
0 Likes
·
0 Votes
·
0 Comments
·
Thanks Arlex, this goes greatly appreciated. I'm glad to see the path using a simpler structure.

I'm still curious about the multiple records for each image path per photo as seen here:



My main concern is to make sure that the system doesn't slow down due to excessive records. Because EasySocial has bulk uploading (which is a really good thing) I suspect that in the future my site may have a few million photos. I understand that a high quality server is required. But I'm trying to make sure that storing 6 records per image for the image paths is either a good idea or needs to be looked into.
Josh Lewis
·
Thursday, 08 January 2015 16:04
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello Josh,

I'm really sorry that delayed of this reply,
Don't worry Josh, those photo size record are needed and it doesn't slow down your site due to excessive records.
Arlex Wong
·
Monday, 12 January 2015 12:34
·
0 Likes
·
0 Votes
·
0 Comments
·
Thanks Arlex for considering that portion. I'm curious about the EXIF data. I set the option "Import EXIF Data" to no a few minutes ago, then uploaded a photo. Most of the EXIF data did not upload as expected however one record was created as seen in this screen shot:



I'm assuming the "angle" exif data ignores the storage option? Perhaps this was unintentional? Also I noticed that a record is not only created for each generated image size, but for both the width and the height. A thumbnail record for example stores "256" as the width and "341" for the height. Seems a little excessive to store all the values for each size of each image.
Josh Lewis
·
Monday, 12 January 2015 14:03
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello Josh,

Sorry for late reply to this,

It seems like missing the checking when the option is turn off. Try download my attachment file and replace in -> JoomlaFolder\administrator\components\com_easysocial\tables\photo.php and see how it goes?
Arlex Wong
·
Tuesday, 13 January 2015 18:59
·
0 Likes
·
0 Votes
·
0 Comments
·
Thanks for the file mod, it fixed the EXIF data issue. I'm still curious about the storage of each image size for each generated image? There are 6 image sizes total, 2 records for each size which means 12 records created just for the sizes of each picture. This does not include the image paths.
Josh Lewis
·
Tuesday, 13 January 2015 19:24
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello Josh,

You're welcome,
Do you mean this record? Check my screenshot below.
If yes, after resizing of the image, it will store those 1 by 1 record in database. Actually those record is just for store the image data.
Arlex Wong
·
Wednesday, 14 January 2015 13:32
·
0 Likes
·
0 Votes
·
0 Comments
·
Yes, that screen shot shows exactly what I'm talking about. It's seems kinda excessive to store 12 extra records per image of sizing when it doesn't really serve much purpose considering that ES's responsive design handles the sizing mechanisms when displaying them on the page. But perhaps it's used for EXIF data display? If so, it doesn't really help those who do not display EXIF data.
Josh Lewis
·
Wednesday, 14 January 2015 13:39
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello Josh,

Sorry for late reply to this,
Hmm, actually that was not extra records stored in db, you can see each record also stored different `property` and `group`.
Yes, regarding this EXIF data, we only store those data in db and we didn't use much about EXIF data in current system yet.
Arlex Wong
·
Thursday, 15 January 2015 16:57
·
0 Likes
·
0 Votes
·
0 Comments
·
View Full Post