Hi Chris,

You are saying having that long image filename will cause issue when users copy the URL and share it via SMS text?

Yes, I agree I think the auto image serial number generated as the filename is just too long.

@Mark Lee, since the path is using the Album ID / Photo ID why not use the Original Photo Filename? In case of filenames with spaces, maybe a method that removes spaces and replace it with _ (underscore). Just a thought. Also, Photo/Avatar/File folders should be prevented from being crawled or indexed by any search engines.

LAC Infosys wrote:

You are saying having that long image filename will cause issue when users copy the URL and share it via SMS text?

Yes, I agree I think the auto image serial number generated as the filename is just too long.

@Mark Lee, since the path is using the Album ID / Photo ID why not use the Original Photo Filename? In case of filenames with spaces, maybe a method that removes spaces and replace it with _ (underscore). Just a thought. Also, Photo/Avatar/File folders should be prevented from being crawled or indexed by any search engines.

Yes, when I tested it, my original file was: happysinkodemayo.jpg No spaces. I was not expecting the 'auto generated serial number'.
Any long URL/link is in danger of breaking when sent in an email or SMS text, so I do think it is too long.

That being said, I think the 'auto generated serial number' is very un friendly. It would be very hard to see what you had if you had more than a few files in a folder with those same type of file names. But I guess we should be more concerned with getting files posted to the site rather than how they will look on someones hard drive.

But with the possibility of so many files/images being uploaded to a site, perhaps you have to do that so that you do not have duplicate file names. I just checked on Facebook and another image site, and they do the same thing. ('auto generated serial number')

I think it is very important for a users to be able to send an image link, and it not be to long, so that it breaks and the recipient never gets to view the image. It would make the website look bad/broken. It would be great to be able to "shortURL" it 'on the fly' and send the link out.

Thank you all and I look forward to any replies and suggestions.

A short url does not have to be done through any web external service which is why I am really enthusiastic about making it as simple as possible now. By making it like stackideas.com/original/mark/50740517.jpg we will make the structure future proof with zero need to ever have to worry about simplifying it again. If we wait several months or years down the road to fix this issue, it will create a lot of SEO issues as well as linking issues (if you guys decide to change it down the road). I'm trying to save the stacked team from dealing with a landslide of complaints down the road.

My simplified ID route method is pretty effective, but if we wanted to go the image-title.jpg route (meaningful title which ranks well in Google), then the path should be stackideas.com/original/mark/beautiful-sunset.jpg which should rely on the image title posted on the site rather than the image title from the image file. If a duplicate existed within that users gallery it could auto increment by 1 so that it would be beautiful-sunset-1.jpg.

So either the simplified ID or meaningful title method would make for excellent urls. Just remember three things are at stake here: SEO Rank, Sharing, and Space Usage.

Thanks for the heads up on this guys. I don't think it is advisable though to use the structure of

/original/mark/

The reason is because the username (may be changed in the future) so there would a handful load of renaming of folders going on and that wouldn't be good for your seo too. What we could do is to use the same folder structure of /{ALBUM_ID}/{PHOTO_ID}/a-more-meaningful-title.jpg

I completely agree that we would not want the url to change if the user decided to change their username. My theory was for the folder name to stay the same even if the user changes their name. If this method was used, ES would refer to the user id rather than the user so that if the user changed their name, the same file location could be used.

The structure you mentioned is better than the current method for sure. This is what it would look like:
stackideas.com/original/591/3081/us-having-a-good-time.jpg

However I still think we should do better. Notice that a directory is create for an individual image? This will be problematic on some hosts due to the large number of directories which we want to avoid.

I suppose we could do:
stackideas.com/original/591/3081-us-having-a-good-time.jpg
domain.com/main-storage/album-id/id-image-title.jpg

(notice the only folder in this method is the one storing all the images of that album). It would read off the 3081 id at the very beginning of the image file name. If a user put a random number at the beginning of the title it would still be 3081-9220542.jpg in which the id would still be read properly.

concatenate the Photo ID to photo filename could be a good idea to reduce the number of folders but the Album ID will still be created.

Right, no matter how we dice this up we will either have folders for each album or a folder for each user. Also note that if we want to separate images from needing a folder per image we need to change the base structure of how we store images. So for each album (or user) they would go into the following base folders:

stackideas.com/thumbnail
stackideas.com/square
stackideas.com/featured
stackideas.com/large
stackideas.com/original

So for a single photo the path would look like:

stackideas.com/thumbnail/591/3081-us-having-a-good-time.jpg
stackideas.com/square/591/3081-us-having-a-good-time.jpg
stackideas.com/featured/591/3081-us-having-a-good-time.jpg
stackideas.com/large/591/3081-us-having-a-good-time.jpg
stackideas.com/original/591/3081-us-having-a-good-time.jpg

While that looks like a lot of paths, 5 folders are used per album rather than a folder created for each individual photo. The biggest reason I think we should use either a user-id or a username as part of the path is to reduce the number of directories created. While it's true that a new user who simply posts a single profile avatar will create 5 folders, the same scenario would happen if we had folders created per album. In the album scenario we also have to factor in cover photos and the many dozens of albums a user might make.

As this discussion goes on I do feel that we are getting closer to an ideal result. Now it's a matter of figuring out which one uses the best practices.

Hello Josh,

Hm, to be honest I don't think having separate folders for thumbnails / square / featured / large / original would make sense. When we perform specific operations to an "album", we only need to move the folder around. With your proposed structure, it's going to be extremely difficult to maintain.

This:

/{ALBUM_ID}/{PHOTO_ID}/a-more-meaningful-title.jpg

is certainly better than this:

/{ALBUM_ID}/{PHOTO_ID}/6f9025145f55a142329f37ce5f8383b9_large.jpg

The shorter the URL, with friendly filename is a lot better from a "users" and "sharing" standpoint. Then again, I am not a programmer so I do not know what is needed/required to allow for security, stability, and expanability of the software. First and foremost those factors have to be concidered, but then also make it appealing so that people will want to use it.

Hey guys,

In version 1.2.11 which will be out soon (We also need to address an issue with the latest Joomla 3.3) . We have modified the file names so that it's stored with a more meaningful title.

Mark wrote:

Hm, to be honest I don't think having separate folders for thumbnails / square / featured / large / original would make sense. When we perform specific operations to an "album", we only need to move the folder around. With your proposed structure, it's going to be extremely difficult to maintain.

Fair enough, but we still need to reduce the folder usage. I am now down to three proposed structures:

stackideas.com/gallery/513/large-4231-amazing-sunset.jpg
stackideas.com/gallery/album-id/size-id-image-title

stackideas.com/gallery/mark/large-4231-amazing-sunset.jpg
(mark does not change even if the user decides later to change it)

stackideas.com/gallery/412/large-4231-amazing-sunset.jpg
stackideas.com/gallery/user-id/size-id-image-title.jpg

If one of these makes it in I'll be very pleased. This method does not use multiple folders per album/user unlike what I mentioned before. As a result the structure is easy to maintain and is a lot cleaner than what we currently have. It will also solve the many folders issue.

Following the discussion on both threads with great interest, if I could add a minor suggestion about the sequence of the last file name, assuming one of them is selected:

There are only 6 files per image id folder at the moment so sequence does not matter too much, but if you remove the folder and add the image id into the file name, it should be placed first to keep the large number of files in a logical sequence and the same images grouped together.

If size is first, it will make it a lot harder (for example) to search for and delete all sizes of an image.

The file name in the post above would be 4231-large-amazing-sunset.jpg

Richard, your absolutely right. I was thinking that part from a search engine perspective. Okay so here are my 3 proposals rewritten to reflect the good suggestion you made:

stackideas.com/gallery/513/4231-large-amazing-sunset.jpg
stackideas.com/gallery/album-id/id-size-image-title

stackideas.com/gallery/mark/4231-large-amazing-sunset.jpg
(mark does not change even if the user decides later to change it)

stackideas.com/gallery/412/4231-large-amazing-sunset.jpg
stackideas.com/gallery/user-id/id-size-image-title.jpg

The reason that we separate each photos to each unique folder of it's own is simply because managing it would be much easier. If we place all images within the album's folder, you'll have tons of images and it's hard to manage it.

We have finalized this for now to the following path,

stackideas.com/gallery/412/4231/large-amazing-sunset.jpg

That is a good point which is why I understand the opposition to having a folder per user. But I still believe our best option is for a folder per album to save on an overload of directories (we are talking hundreds of thousands of folders with the current setup).

On average a user posts around 8-12 photos per album. Uploading them is typically done in the order they were taken (so for example a photo from the beginning of the day will more likely show up as the first image). As a result we can not only use the id's because they are required by the system, but we could actually see the order in which they were taken if I were to download the entire album using a ftp.

Anyways from a management perspective no matter how we go about this we have to compare ids when looking into broken images. So with my proposed method we can quickly find an image with an id of "4235" who's size is large by rolling down through the numbers and then going to the right size once your at the right number. I wrote out a seemingly overwhelming list which is actually pretty easy to navigate if you have the right id.

4231-small-amazing-sunset.jpg
4231-square-amazing-sunset.jpg
4231-featured-amazing-sunset.jpg
4231-large-amazing-sunset.jpg
4231-original-amazing-sunset.jpg
4231-stock-amazing-sunset.jpg
4232-small-beautiful-night-out.jpg
4232-square-beautiful-night-out.jpg
4232-featured-beautiful-night-out.jpg
4232-large-beautiful-night-out.jpg
4232-original-beautiful-night-out.jpg
4232-stock-beautiful-night-out.jpg
4233-small-us-having-a-good-time.jpg
4233-square-us-having-a-good-time.jpg
4233-featured-us-having-a-good-time.jpg
4233-large-us-having-a-good-time.jpg
4233-original-us-having-a-good-time.jpg
4233-stock-us-having-a-good-time.jpg
4234-small-having-a-ball.jpg
4234-square-having-a-ball.jpg
4234-featured-having-a-ball.jpg
4234-large-having-a-ball.jpg
4234-original-having-a-ball.jpg
4234-stock-having-a-ball.jpg
4235-small-working-hard.jpg
4235-square-working-hard.jpg
4235-featured-working-hard.jpg
4235-large-working-hard.jpg
4235-original-working-hard.jpg
4235-stock-working-hard.jpg
4236-small-to-be-continued.jpg
4236-square-to-be-continued.jpg
4236-featured-to-be-continued.jpg
4236-large-to-be-continued.jpg
4236-original-to-be-continued.jpg
4236-stock-to-be-continued.jpg

With the current folder per image method you still have to navigate through all the folder numbers to get to the right image. It actually requires more clicking too. With the method I have above, it is easy to manually clear out an image if needed.

Hi Mark

Mark wrote:

The reason that we separate each photos to each unique folder of it's own is simply because managing it would be much easier. If we place all images within the album's folder, you'll have tons of images and it's hard to manage it.

Forgive me if I am mistaken, but isn't Josh's main point of having all related images (I.e. ones perhaps taken at the same time and then uploaded together) placed in one folder the easiest to manage?

To me, it just seems logical that if I upload 16 photos of "sunset.jpg, sunset2.jpg, sunset3.jpg ...etc", that they should be in Folder 1.

Now, if I upload 16 photos of "sunrise.jpg, sunrise2.jpg, sunrise3.jpg ...etc the following day", then they should be in Folder 2 and so on.

Put this another way. If there are ten photos in Album A, they should be stored together in a single folder, if you have ten uploaded at another time into Album B, they should be in their own folder too.

One folder EACH for EVERY SINGLE photo just seems like a management nightmare to me! Add to that the fact that, as I pointed out in the other thread, my Siteground hosting fees will rocked, due to unnecessarily excessive inode use, as a result of having say 50,000 folders, instead of say 5000.

Mark H, that sums it up pretty well. I am trying to make sure this doesn't become a really big issue later down the road. This could literally be the difference between people having to give up EasySocial or getting in trouble with their host provider. No one wants to end up in that situation (once it happens, it's really hard to go back). The single folder per album is easier to manage than dealing with having to look through individual photo folders.

As for the folder per day idea, I think it would be best if the user decided to create a separate album per day if they wanted to go that route. Keep in mind that the id will actually help sort out between the days. (the lowest id being from the first day, the highest being on the last) Looking at the images from EasySocial will of course make it more clear when what was taken.

Hello guys,

The reason that we segregate the photos in photo id folders is because when we introduce sharing options in the future (Image will be created on the fly) and it's going to be really ugly if you have tons of images in a single album folder.

I appreciate your insights on wanting to make sure sharing is as good as possible. While I love features as much as most people, major performance issues should play a huge consideration into this. Because there is no copy button as of now in ES's album manager I cannot quickly re-generate thousands of photos. But if you happen to know of a way that doesn't take too much of your time, I would say now is the time. If I can't convince you that there might be a big performance issue with huge sites, it would be good if some how you could test ES with a huge quantity of photos on your dev site. Doesn't matter if it's the same photo over and over. If we are going to use a folder per image we need to know the impacts to prevent a bad situation for not just the client but for the stacked team (a mountain of complains if it is as bad as I fear it might be).

As of right now with the current method people like Mark H will be forced to swap away from shared hosting. While I'm sure we can both agree that any major site needs to be swapped to a VPS, some are moderate size that would normally not require a VPS. Keep in mind that images within a album folder makes them easier for users to download an entire album. (if it can access only the large or original photos for download)

I'm curious about the images being created on the fly concept as well as the sharing. Are we talking about sharing the physical images rather than a reference (url)? Also I'm curious about how it becomes ugly? Please understand that I'm trying to look out for your best interest here as well as everyone else who has heavy reliance on photos. I am honestly really glad to see the structure for ES 1.2.11 simplified as it is, now my main focus is performance.

@Mark Lee, how does the photos sharing going to look like? Currently, if an Album is created in a Group that is Private or Closed, the pictures are automatically shared to all Members of the Group. As you said in one of my previous post, the Default Album Privacy in a Group follows Group's Privacy Type. Which is good, but my dilemma is we have 2 sets of Staff Groups for 2 Organizations. When I created an Album in Staff 1 Group then Staff 2 Group won't be able to see the Album, I will have to recreate that Album and re-upload the same pictures in Staff 2 Group so they can see it too.

So I wonder how that Sharing you're talking about is going to look like I hope that will solve my scenario issue. I tried to create the Album as My Album and just share it to a Group but unfortunately Album Privacy does not allow Group, it only allow Friends.

Thanks!

As for the debate on whether to use folder for each photo or not I totally agree with Mark Lee looking at his perspective if Sharing feature is going to be introduced in the future. Coding wise it is easier to share an entire folder rather than picking which file to share inside a folder IMO. Mark H, brought up an interesting point with inode and yes SG keeps track of the number of inodes but IMO if your website is going to have a million or 100 thousands of photos, I don't think it is wise to stay using a shared hosting. I think by the time you reached that much number of photos and I am guessing that the volume of photos is proportional to the number of users unless of course if you are creating a community for Photographers. But still with that number of photos and/or users you would want to have a Dedicated Server for performance and for me if I'm expecting to have that much Photos I would not even think of hosting those files in my webserver.

Just my 2 cents

Jackson

Part of my concern is how much performance issue it might have on a dedicated server as well. I'm not just worried about the shared host folks. I'll probably go to VPS some day when I have the cash, but I want to make sure that I have good performance on it and use the best practices.

I contacted my host about this issue which they replied:

Thank you for contacting technical support.

I understand you would like to know if it would be better to use a one folder per album system rather than the one folder per image system you are currently using.

The more folders you have the harder the server has to work to find the specific image you are looking for. Over time this will absolutely be a detriment to your site, and our server. We request that folder be grouped as few as possible to maintain a smoothly working shared environment.

So now I'm hearing it from my host that more folders will indeed degrade performance which is why I believe we need to avoid this issue. We both know that too many files per folder is bad, I think a proper balance has to be met to get optimal performance. 1 folder per album seems to be the right balance.

I am afraid your hosting provider is wrong here. If you have a folder with 1,000 or 10,000 images , try to list down the files, it is much slower than listing down only 5 - 10 files per folder. You can read http://stackoverflow.com/questions/466521/how-many-files-in-a-directory-is-too-many

So what will be the final format / path etc. Has a decision/plan been confirmed?

When will the EasySocial with the format be released

Thanks for all the input from everyone. I think it has been very valuable in moving the software in a better direction.

Hello Chris,

In 1.2.11, the file naming for new file uploads would be /[configured path]/[album_id]/[photo_id]/photo_title.png

I'm really glad to see us going in the right direction with the gallery structure. While the current method is nice, unfortunately at least 95% of users don't actually name their photos when uploading them. The most ideal way to get the photo title for the image would be for it to get it from the image title name. So for example if I upload a photo of mine named "P1020938.JPG" but then on ES titled it "Mount Rainier Clearing Up", ideally it should be site/gallery/12/58/mount-rainier-clearing-up-original.jpg. Having a clean title for the image would be very helpful for SEO considering that we are breaking away from the ID route.

I suppose one theory for how it could work is it could upload the image as "P1020938.JPG" and then rename it upon saving for the first time (and never change after that).

Thanks for the heads up on this.

However the 1.2.11 version functions, it will be more a step in the right direction.

With that, any idea when version 1.2.11 will be released?

Thank you,

Chris...

Hello Chris,

The latest version of EasySocial is 1.2.15 now actually.

Oh.. Ut oh...

Awkward!

Thanks....

No problem at all Chris