Hi,

You need to order the Professional version of Easy Social.

You should provide more information for the dev's other than Facebook plugin is not working, provide details for them so they can assist you!

Hello Thomas,

Yes, as Alex mentioned, the Starter version includes a "powered by linkback" but since this is a 100% open source project, feel free to edit the source to remove it We do not enforce anything.

As for your issues with Facebook, can you please elaborate more on this issue please?

Well can you tell me when is the file that needs ro be edit.... I looked all over for it.

Thomas, maybe you can work out a deal with the stacked team to pay the extra $10 to go "Professional" which has the link removed. When buying stuff many of us go for the cheapest option, but then realize that extra little bit would have helped us get more precisely what we wanted.

I'm not saying they will work out this sort of deal, but it's worth asking.

Thank you for your advice..

Hi,

Regarding your Facebook plugin issue, please further elaborate your issue and provide necessary access if investigation is required on your site.

Im still trying to find the temp where I need to edit to remove the powered by.. can some one direct me to it?

Hello Thomas,

Take a look at the file /administrator/components/com_easysocial/includes/dependencies.php at around line 46 you should see that block of code.

You are most welcome

Thomas Mason wrote:

How can I remove remove powered by EasySocial

Also The Facbook plugin is not working also....


How can I correct these problems...

I sent in a message asking about how to remove the "com_easysocial" from every file location, (image location) on an easysocial website. I do not like it when products self promote themselves, plus makes the url's longer, etc..

http://www.YourDomain.com/media/com_easysocial/photos/2/2/e35e_large.jpg

He did reply saying that it may be hard coded and can not be changed. But I am waiting for another reply.

Hello Chris,

As mentioned in the ticket, the real reason behind prefixing the path is not to advertise our products and it's pretty silly to advertise it by using folders. The simple reason why we use the path /media/com_easysocial/ is because it is unique to us. There are so many different 3rd party extensions out there that uses the /media/ folder and using a generic name like /media/photos/ or /media/avatars/ is a suicidal attempt because if another extension overwrites your photos simply because they use a generic name, your photos would not be retrieve-able any longer.

Mark I have a clever method to over come the image path problem. The theory is to be flexible and non conflicting. I admit I did not come up with this idea.

So here is a teaser screen shot:



As it implies, the admin can choose the image path. This would theoretically open up the possibility of having paths like mysite.com/image/4275.jpg or mysite.com/original/4275.jpg

Beautiful URL's like that would make people very pleased about linking to one's photos. It's within ES's capabilities. The Joomla extension JoomGallery does this.

Hi,

I have to agree with Josh here, i run a website dedicated to graphic designers and sharing the com_easysocial does not look good when linking.

Many other systems do just fine with custom path's i don't see it being a issue with ES.

Regarding it being unique to you guys there are plenty of other naming paths you could use.

es-images
si-img

For example.


Regards

Thanks Josh, sounds like a good idea but I am wondering what happens if you suddenly decide to change the path. Does the system automatically relocate the folders or you would have to do it yourself?

Hi,

The same as other systems it creates that new folder name and then starts adding the images into that folder, the old one is still there holding the old photos.

The only downside is you will start creating many folders HAHA.

I do hope to see this change soon

Hello Alex,

What about the older photos that doesn't get copied over? Wouldn't that mean that these photos are not available on the site?

Hi Mark,

They would not need to be copied as they are already there

For example:

My current folder is com_easysocial/imagefolder

I then update my own path to the following: images/gallery/

The old image folder com_easysocial/imagefolder would hold the already uploaded images and then the new folder would just take over so when a user adds a photo it would be placed into images/gallery/ so that would leave two folders on the server.

Regards
Alex

Hello Alex,

Does this mean you'll need to manually copy the existing folders over via FTP or a file manager?

For example:

My current folder is com_easysocial/imagefolder

I then update my own path to the following: images/gallery/

The old image folder com_easysocial/imagefolder would hold the already uploaded images and then the new folder would just take over so when a user adds a photo it would be placed into images/gallery/ so that would leave two folders on the server.

Regards
Alex

I'm sorry to say but that doesn't sound like a smart design. 2 or more places to keep one type of files...complicates things a lot when you have to move to another server or to CDN or simply give the site to somebody else.

In vBulletin, XenForo etc.; image folder(s) (attachments, avatars, blog attachments etc.) relocation is done by moving over all the files and changing all the database entries. That's the most viable solution I think (even than there can be permission and execution problems). It also generates many support request because of less knowledgeable users...

Hi All,

Yes it would require users to upload to the new folder but it would only need to be done once, a simple tutorial can solve that issue.

For me that is no problem but other less advanced users could have a issue.

This is a setting that should of been thought of from the start

Kind Regards
Alex

Hello,

Jozsef is right. Support will be a little more difficult as we now have to understand your current setup before being able to determine which files / folders houses these images. We'll see what we can do for the power users

In regards to old locations vs new: Yes the old files would need to be moved to the new folder. We can cut down on support by having the folder option specifically say "New Folder locations require the old files to be moved over to the new folder location".

I'm suggesting this be done sooner rather than later so that we prevent this from being a very messy issue later. Right now ES is relatively new, but once galleries start getting really big it may be a lot harder to have folks port over the images.

ES in my opinion needs to cut down on folder use for the gallery. Right now a folder is being created for each image uploaded. So I have two theories of how to store them:

1. Folders are created on a per user basis. The url could be mysite.com/original/mark/5394.jpg
Basically allowing you to choose what you want as the root directory for the originals, then the username, followed by the image id with a .jpg ending. This would allow others to have more "organized" methods such as mysite.com/photo/original/mark/5394.jpg which would allow other ones like mysite.com/photo/thumbnail/mark/5394.jpg

2. Folders are created on a per album basis, as in a folder is only created as an album is created. The url path could be mysite.com/original/361/3912.jpg (361 is the ID of the album, 3912 is the image id).

I know this works because JoomGallery has pulled it off successfully. It's not like one has to change out each individual folder for the new folder name, just the main directory which is what makes it even more beautiful! Really easy to manage. By doing this method, not only will the url's be shorter, cleaner, but will also make it really easy to find images from certain users. Lets say a user with a specific id/name comes in and notices his/her image does not delete for some reason. With this method it's no problem to go into the ftp and with a few clicks find it and delete it.

+1 for what Josh has suggested.

It makes sense to have the folder structure he has set out.

No disrespect, I love you guys, but I'd prefer not to have another brand in my URLs

Sorry Josh, not completely agree and here's why (also don't want to hijack the topic...as the title is very different ):

Josh Lewis wrote:
ES in my opinion needs to cut down on folder use for the gallery. Right now a folder is being created for each image uploaded. So I have two theories of how to store them:

1. Folders are created on a per user basis. The url could be mysite.com/original/mark/5394.jpg
Basically allowing you to choose what you want as the root directory for the originals, then the username, followed by the image id with a .jpg ending. This would allow others to have more "organized" methods such as mysite.com/photo/original/mark/5394.jpg which would allow other ones like mysite.com/photo/thumbnail/mark/5394.jpg

User name changes are frequent. I wouldn't go in that direction.

2. Folders are created on a per album basis, as in a folder is only created as an album is created. The url path could be mysite.com/original/361/3912.jpg (361 is the ID of the album, 3912 is the image id).

If the album has a limitation in files it might be OK but I have no problem with the current method.

Ps.:
I'm running some communities and some of the "Albums" (they're actually topics) has over 80.000 files (and more than 2 million kept in folders all together).
Although current filesystems doesn't have much limitations anymore for files/folder (they do have of course just hard to reach), FTP clients do have (most of them simply collapsing upon LIST command), File Commanders (for example MC) are the same; also there are other things to consider for example zip can only 262,144 files per archive.
At the end: to have many folders and less files per folder is almost always better than have a few folders but huge amount of files in their root.

Jozsef Simony wrote:

User name changes are frequent. I wouldn't go in that direction.

Right, very valid point. I actually considered this before posting. Two easy fixes for this. Either have the folder remain the same as the original username. Or a perhaps nicer solution would be to use the user id. So if Mark had a user id of 621, the structure could be: mysite.com/original/621/5394.jpg

At the end: to have many folders and less files per folder is almost always better than have a few folders but huge amount of files in their root.

I can't disagree with this. However the method I'm prescribing still uses a "healthy amount of folders". I did not propose having all the originals in a single folder or all the small ones in a single folder. Right now the "root folder" is media/com_easysocial. So changing the root will have no effect on how the gallery is structured. However my folder structure method does.

If a folder is created for each gallery, on average a user might upload 5-10 photos per album, maybe 15 for enthusiastic communities. Obviously the range being more. This is not that many files in a single folder. I suppose the user folder method (the one where all a single user's images are within a few folders) could become heavy for heavy duty users who post tons of photos. Very rarely do we see users post more than 5,000 photos on a given site. But if that is an issue, the folder per album method in my opinion would be our best option.

"Right now the "root folder" is media/com_easysocial. So changing the root will have no effect on how the gallery is structured"

I agree with this. I do not think "com_easysocial" should be in the URL. It looks "tacky", and as mentioned "I prefer not to have another brand in my URL".

Perhaps I am incorrect here, but is having such a "unique string" a concern for security? If there was a vulnerability, all someone would have to do it search for "com_easysocial" in any search engine and find many of the easysocial sites?

PS: please take no offence, I love the software!

Chris Mathis wrote:

"Right now the "root folder" is media/com_easysocial. So changing the root will have no effect on how the gallery is structured"

I agree with this. I do not think "com_easysocial" should be in the URL. It looks "tacky", and as mentioned "I prefer not to have another brand in my URL".

Perhaps I am incorrect here, but is having such a "unique string" a concern for security? If there was a vulnerability, all someone would have to do it search for "com_easysocial" in any search engine and find many of the easysocial sites?

PS: please take no offence, I love the software!

I think it does pose a potential security risk. Good point.

Right, all the more reason why a custom path is a good idea.

I don't think it has to be "custom", just non descriptive, generic, etc...

But custom would be good. Some of us like to make structures as simple as possible.

Non-generic = better than com_easysocial and solves the "other brand in my URL issue", but does little to solve the potential security issue mentioned earlier.

Choosing the root folder for all media types (photos, videos, attachments) is a must.

Jreviews guys have implemented this perfectly, allowing you to specify the root path, where sot store the media (local server = Amazon) and allows prefect SEO friendly URLS E.g. domain.com/category/listing/image.jpg

Look at how it's done in Jreviews here:

http://docs.reviewsforjoomla.com/?title=Media_Settings-Storage_Settings_tab

Thanks for the heads up on this Mark

yes, I want to remove media/com_easysocial from url too. are you going to provide a fix please?

We don't have an ETA for this yet. Also, do take note that if you are using the Starter version and if you customize the link back to our site, it's violating our terms of use and we have the right to not provide any support for your site.

Hi Mark

I have read through the above conversations and I am very surprised for a number of reasons.

1: Folder path is a simple code change that can be done. It would not take long to work it out where to locate and change.
2: Having another brand present in both the url and seo is not acceptable and no one in the right mind would accept it.
3: It is a straight forward change to implement the change of folder name and path into the backend any reputable company would have taken this into account.

Other companies have tried to promote their products using this very approach and all they end up with is unhappy customers and encourage code change.

Protecting your software I totally agree with but directly influencing others in SEO and URL I do not!

I have purchased an unlimited package of your software and working towards developing my on sites that includes other software. I need it to work the way I need it to work and not limited by where I can store content in or folder names, nor am I in the business of promoting other companies.

I admire Stackideas for both their products and service, but with all due respect this silly limitation is not acceptable and in my mind is not the correct way of doing business.

Sam, this issue is the number one reason I haven't written a JED review yet for EasySocial. Once the gallery "issues" get ironed out, I'll be more than happy to write a really well thought out review expressing my deep appreciation for the devotion of the Stacked team. I hope my comment here does not in any way discourage the stacked team, but it would mean a lot to allow us as the admin to specify the image directories. A clean base for the gallery is very important to us. Photo sharing as you know is important for a photography site, clean urls will help a lot in that regard. The actual image files themselves are a big part in that. Plus I believe in using as little code as possible when generating articles with thousands of photos (imagine 20+ characters less per url * 40,000+). I can prove the space usage very quickly by showing how some articles are heavily image dependent.

I know the stacked team is getting very busy which is why my requests are slowing down. For now I'll shift my focus on gallery related things that should be addressed sooner rather than later (to avoid future complications).

Hi Josh,
the main issue here is SEO with so many images and with videos in the future, when search engines start to cache your contents every image will consist of easysocial in the url and not your company.

I have experienced this first hand in the use of Phoca gallery and had to dump it. A websites / company has the right to label it's own contents with their name otherwise you will never rank correctly in searches.

I give credit where it's due and Stackideas deserves lots of credit over there products and service. However the correct business ethics must also be applied
.
This is not a free extension we have paid for it and continue to pay for it's development through our memberships, so I expect to be able to label my own contents and promote my own business.

Chris Mathis wrote:

"Right now the "root folder" is media/com_easysocial. So changing the root will have no effect on how the gallery is structured"

I agree with this. I do not think "com_easysocial" should be in the URL. It looks "tacky", and as mentioned "I prefer not to have another brand in my URL".

Perhaps I am incorrect here, but is having such a "unique string" a concern for security? If there was a vulnerability, all someone would have to do it search for "com_easysocial" in any search engine and find many of the easysocial sites?

PS: please take no offence, I love the software!

Hi Mark,

I agree with the guys to not use brand in URL, I was not happy to see /media/com_easysocial/ as the path to my images but that was more like cosmetic. until now with Chris Mathis pointing out security issue with regards to images, I would have to agree again with Josh Lewis that this issue has to be addressed sooner. If you guys try to search for com_easysocial you will actually find websites that Google got indexed. If you are talking to a small community website owners that doesn't care about security at all, they would probably not wanting to address issues like this or will not consider this as an issue. But in our case where users are more diverse, we have members that do Network Security for a living, so probable security risk like this will probably be questioned in the future. We will be launching our community (EasySocial Feature) in our live site soon and hoping that this issue will be patched sooner.

Mark, you guys have done this in EasyBlog if I'm not mistaken where you provided an option to change image locations like what Josh Lewis suggested. Would it be hard to implement the same in EasySocial?

Thanks,

Jackson

LAC Infosys wrote:
Mark, you guys have done this in EasyBlog if I'm not mistaken where you provided an option to change image locations like what Josh Lewis suggested. Would it be hard to implement the same in EasySocial?

Thanks,

Jackson

Yes, this very setting is in EasyBlog, I used it last week to change the paths!

Enter new paths, move files, DONE.

Mark, as you can see, this is a serious concern for us and a number one issue for me.

I do not want to launch my site (or the others I have planned) until this issue is resolved. I consider this a security issue rather than a feature request. It will be too much hassle to resolve later.

I hope you don't feel this is us being pushy, demanding or even ungrateful for your great extensions, it's just that people here have raised justifiable concerns.

Mark, as stated before you are free to look on my test site admin area to see how JoomGallery stores the images in terms of locations and configuration. If inspecting the files help, by all means your free to do so. It might be a stretch, but ideally we would like to see this in ES 1.3 or at the latest ES 1.4. Normally I don't make demands like this, I can actually wait longer. However everyone else might not be able to hold out which is why I feel this is a pressing issue. Especially if some structure changes have to be made. After giving some very careful thought on this subject, I can safely say I think this is the best structure possible:

Site/custom-path/username/image-id.jpg

This would allow for very simple urls as seen here:

• stackideas.com/small/mark/5374.jpg
  


• stackideas.com/medium/mark/5374.jpg
  


• stackideas.com/large/mark/5374.jpg
  


• stackideas.com/original/mark/5374.jpg
  

This will fix the security issue, make the paths feel unbranded, easily sharable, SEO friendly, less data stored when used in articles, easily manageable (if I wanted to go from a small to a big pic it would be really easy via url manipulation), reduce directory use by a lot, and give simplicity to the minds of the user. There are way too many benefits in my opinion to turn this down. The username of the directory should not be changeable (even if that user changes their name) so that no images ever break. While that might be a little annoying to a few users, the benefits way outweigh the minor disadvantage.

The directory issue is a big deal as mentioned earlier, if we have 1,000,000 photos posted (as of right now this would equal 1,000,000 directories) over the years that will be a lot of directories which are said to possibly degrade performance on servers. 10,000 is probably okay, but we need to look at the bigger picture of way down the road assuming that EasySocial takes off so far that people from all over the place want this software. By having user directories we significantly reduce the number of directories by X10 or X100, in some cases maybe even by X1000. On one site I posted over 4,000 photos which with my proposed method would only require 4-5 directories total for all those images.

...and to lead on from Josh's post, with such an unnecessarily large number of folders, your inode usage will increase dramatically, meaning your hosting costs could rocket, or you could have your account suspended altogether. Not good.

Hosts like Siteground are VERY strict on this.

I think my host is even more strict than Siteground. Eventually I plan on going to VPS, but that comes later when money comes in. As it is I'll have a hard enough time covering my EasySocial renewal (I'm a poor lad, but knows how to have fun).

hwdmediashare has taken the correct approach to both for security and file management for each user. It might pay to have a look at their layout.

One of the main things that I have always done is to change the path to user contents to match with the various extensions that being used on the project.

This allows me to do 2 important things keep the user url string consistent throughout the site and secondly it allows me to keep all individual user content in the some folder location, so if there is an issue with the individual users it can be resolved quickly with minimal data loss from any type of backup system. This no different to terminal services or the creation on network folders and the like.

Hey guys,

Points taken and since there are so many of you who are looking forward to this, I will try to quickly write up something for 1.2.10

Thank you Mark, I for one appreciate this.

Josh Lewis wrote:

1. Folders are created on a per user basis. The url could be mysite.com/original/mark/5394.jpg
Basically allowing you to choose what you want as the root directory for the originals, then the username, followed by the image id with a .jpg ending.

Just a thought on alowing a user to to create the folder name, or based on folder based on username... You could end with a url like:

http://www.domain.com/site/bigti*s/cutekittens.jpg

Just a thought...

brainstorm

Much appreciated Mark and thank you for not only listening but also acting upon this crucial point.

Hey guys,

The latest 1.2.10 update will only include a minor change where you can alter the settings to change the storage path for photos and avatars but the folder structure currently still remains as,

/[configurable_path]/album_id/photo_id/image_files.png

Hi Mark,

Thank you for considering our request you rock!

Yes, /[configurable_path]/album_id/photo_id/image_files.png is good, personally I don't see the need to have the user's info in the path. And personally I don't like seeing User's ID in the path as well.

Thanks again, I think I speak for everybody for extending our appreciation to your team

Jackson

Glad to hear we are on the right track. Eventually we still need to address the directory issue as well, my version wasn't just for friendly url's, but the method used much fewer folders which will help with optimization (still enough folders though so that no single folder will contain a million photos).

Hi Mark (or anyone else),

I have found the settings for changing the paths of photos and avatars, but where do I set the path for files?

Mark.

Thanks Mark for making the change. Eventually if the gallery structure gets cleaned up, an ideal situation would be to allow individual paths for different types of photos. This screen shot sums up what I mean:

Mark H wrote:

Hi Mark (or anyone else),

I have found the settings for changing the paths of photos and avatars, but where do I set the path for files?

Mark.

Yep, can't find Group Files storage settings. Hopefully, when you guys get a chance to clean up the backend I think both Photos & Avatars settings can be under Settings > Photos or maybe it would be better to move Photos, Avatars, Files, Remote Storage settings under Settings > Storage instead of having it in separate places.

Thanks,

Jackson

I changed the path to avatars and photos and after moving the folders in S3 to reflect the path change, the Group Avatars image path is still pointing to /media/com_easysocial/avatars so when viewing Groups there's no avatar images showing.

EDIT: Nevermind, found it!

I tried this tonight and it worked. Thank you!

I have a question though, I uploaded an image, (shared with everyone) then 'right clicked' on the image to copy the image URL so I could send it to myself via mobile, (text message) the URL turned into this:

/media/testfolder/photos/3/5/6f9025145f55a142329f37ce5f8383b9_large.jpg

The file name was turned into: 6f9025145f55a142329f37ce5f8383b9_large.jpg

It was so long that the url 'broke' and "page could not be found" was displayed on the phone.

I know this happens in email as well. Is there a way to resolve this? Concerned as "mobile" access is huge. This also happened before the com_easysocial update.

Thank you in advance.

Chris, what your mentioning is one of the many reasons I believe a short url is essential. When a user hovers over a long url in the browser it is auto trimmed. As a result even the most observant users can be tricked by creating a fake site. Someone almost snagged all my site data when they had an email that went as host.com/bla-bla-bla(50 characters more)/fakeurl.com (they used sub domains to fake my host with a sub domain of .com and a long url so I would not see the real domain!). It's a long story, but the point is that simplicity in my opinion helps create security and really helps with linking. I'm not talking about normal security (hacks) but it reduces the chances of clever tricks which I've seen pulled off pretty well (unfortunately).

Even if my site had 50 million photos posted, the url is still pretty. Compare the url structures below:

Good:
stackideas.com/original/mark/50740517.jpg

Current:
stackideas.com/original/photos/3/5/6f9025145f55a142329f37ce5f8383b9_large.jpg (this one doesn't even have a high ID which means it will get worse)

Hey guys,

I haven't added the "files" portion yet but right now it's only the two main critical path, which is photos and avatars. I will add a new tab for the "Storage" settings so that it's much easier for you guys to look up for things.

Chris,

I am not too sure if I understand your issue here but can you please start a new thread and provide us with the steps to reproduce this issue?

Mark,

Thank you for adding this feature, works great

You are most welcome Alex

Mark wrote:

Chris,

I am not too sure if I understand your issue here but can you please start a new thread and provide us with the steps to reproduce this issue?

-----

Ok sure. I just posted a new thread. I look forward to the replies.

Thank you.

http://stackideas.com/forums/com_easysocial-gone,-but-image-url-very-long

Thanks Chris