HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


Improving Gallery File Efficiency and Organization

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#60964 (In Topic #13254)
Avatar

Well-settled

Problem: One area I can forecast having issues with down the road: the Gallery user file organizational structure.

When a user creates a personal gallery, their uploaded files are intermingled with everyone's gallery files in the same folder (uploads/galleries).

Even with only a small number of contributors, the number of files that accumulate from different users starts getting extremely large. Users are always modifying their gallery, so that means even more files accumulating due to the large number of orphaned uploads, which have to be deleted manually one at a time (an extremely time consuming task)

Proposed solution: Code OCP Gallery module so that each user's file uploads are contained within their own unique subfolder (uploads/galleries/username). Now a user's uploaded gallery files are organized and separate from any other user's files.

Deleting orphaned uploads or removing a user's gallery files who has quit or banned will be MUCH easier.

I would dread managing uploads/galleries if there were several dozen users (imagine several hundred users) with galleries using the current organizational structure.

Alternate solution: When a user deletes an image file from their gallery, the software should completely delete it from the server. This does not appear to be occurring in tests I've made. Even when 'Delete fully' is selected, the file becomes orphaned and remains on the server. This eventually becomes a critical issue with a large number of users on a server with modest disk capacity.

Also, I wish I was smart enough to code this, but I couldn't code my way out of a wet paper bag :lol:

However, with each improvement in the efficiency of this product from both the user perspective and the managerial backend comes increased prospect of it becoming THE preeminent portal product of the future. I can already see it on its way. Thanks!
Back to the top
 
Posted
Rating:
#60975
Avatar

Hi,

I believe there's a hidden option for this. Please check the hidden options in the bottom of our Code Book document.
It's not on by default as it can't work on servers running PHP's "safe-mode".


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
1 guests and 0 members have just viewed this: None
Control functions:

Quick reply   Contract

Your name:
Your message: