Subscribed

#offtopic but interesting
as we are speaking from non conform standards ... take a look on the alias (hardlink) from this discussion
http://stackideas.com/forums/mediamanager,-folder-file-naming
really guys, a comma in the alias link name
i would't say anything when EasyDiscuss still would be a beta version, but that isn't the fact

Thanks for the heads up on this guys. The problem is actually because we don't store these data on the table and it wouldn't really look nice if your folder name looks like my_folder_name . However, there will be a huge improvement on the media manager for EasyBlog 5

since month all we get is the info that EB5 is the answer of all our problems ... but such problems "because we don't store data on the table" sounds for me only as a excuse for a overload on work what you have!

this brings me right up to my old discussion: http://stackideas.com/forums/eb4-0-concerns-about-remaining-components
since you have brought ES in the joomla world EB & ED are stuck totally where they was since over a year ... specially take a look on your forum, it is missing so much standard features that i could not called EASY by the way.

what i really believe mark, is that all member of your team are hard working on all this things, last but not least for me it looks like you have to less people to do this work in a acceptable time!

Hello n00bster,

To be honest with you, I do agree that we have introduced new extensions and it somehow bogged up our development pace. However, that is really not the main issue. What we want to do is to release a major update that makes sense and we believe that the new EasyBlog 5 will be a game changer not only for us but for you guys as web masters / developers of any Joomla site. We do not want to modify some themes, rename some labels and call it a "major" update.

Not to be rude but when EasyBlog 5 is out, I can assure you that you will come back to this thread and let us know that you understood why it took us such a long time

Now, back to the topic where "because we don't store data on the table" seems like an excuse to you but there are a lot of other implications that it will cause if we start changing the way these data are stored. There are customers like you who may have 100,000 photos but there are also customers who has 5,000,000 photos. Changing the way these images are being stored would also mean that we need to cater for these "legacy" items and it's going to be a major havoc if it isn't done correctly.

I totally understand your frustration but we got to do what we think is right for the community and although it wasn't done right in the first place, we learn from our mistakes and we hope that you will help us grow together as well

Now, back to the topic where "because we don't store data on the table" seems like an excuse to you but there are a lot of other implications that it will cause if we start changing the way these data are stored. There are customers like you who may have 100,000 photos but there are also customers who has 5,000,000 photos. Changing the way these images are being stored would also mean that we need to cater for these "legacy" items and it's going to be a major havoc if it isn't done correctly.

hi mark, sorry to go into your discussion here, but i faced yesterday a issue with lack of image database store and for current media manager wich is very annoying!

a User added within 10days some Blog Entrys with several Images and those entrys create also stream items in JS with image links. yesterday he made a mistake and deleted the complete folder with all those added images! there was no warning message like "You can't delete Images wich are used in Blog Entrys"! or "Are you realy sure that you want delete the complete Folder with your images"

instead all images are now missing in users Blog Entrys and JS stream items now i have to repair each of those blog entrys and stream items..very frustrating and time-consuming

Thanks for the heads up on this Rene, this is something that we are still trying to figure out (it's going to be a nightmare for our maintenance script to port all previous images into the database).