How mooSocial Actually Stores Media
Every photo, cover image, and album upload in mooSocial produces more than one file on disk. The platform keeps the original inside the public uploads tree and then generates a series of derivative sizes at upload time using the PHP GD extension. A single profile photo commonly becomes five or six physical files: the original, a large display size, a medium size, and small square avatars used across the feed, comments, and notifications. On a busy community this multiplies quickly, and the storage cost is not only megabytes of disk but thousands of individual inodes that count against your shared hosting quota.
The media lives under the document root in a predictable structure. Photo and avatar files are written to /home/USERNAME/public_html/uploads/, typically split into subfolders such as uploads/photo/, uploads/avatar/, and date-based directories like uploads/2026/01/. mooSocial records the base filename in its database and appends size suffixes (for example _large, _medium, _square) when it requests a thumbnail from the theme. Because the mapping between the stored original and the derivatives is driven by the CMS, you cannot safely delete or rename files by hand without breaking the references the templates expect.
Two symptoms bring customers to this topic. The first is an inode warning in cPanel or DirectAdmin: the account approaches its file-count limit long before it runs out of gigabytes, and the culprit is the sheer number of small thumbnails. The second is slow media pages, where the browser fetches dozens of large JPEG or PNG originals that were never compressed for web delivery. Both problems are fixable from inside the hosting account, and neither requires root, shell services, or edits to server-wide configuration. The tools that matter are the mooSocial AdminCP, the cPanel or DirectAdmin File Manager, PHP Selector, a .user.ini file, and .htaccess.
Tuning Upload Limits and GD Without Root
Large uploads fail on shared hosting for one of two reasons: the PHP request limits are too low, or the LiteSpeed request body size is capped. You control both from the account. Open cPanel → MultiPHP INI Editor (or Select PHP Version → Options in the PHP Selector), and confirm the values that govern media handling. On DirectAdmin the equivalent lives under PHP Selector → Options. The four directives that decide whether a photo upload succeeds are upload_max_filesize, post_max_size, memory_limit, and max_execution_time. The post size must always be equal to or larger than the upload size, and memory needs headroom because GD loads the entire image into RAM before resizing it.
If the INI Editor is unavailable for your PHP handler, create a .user.ini file in /home/USERNAME/public_html/ through the File Manager. LiteSpeed reads this per-directory file for PHP settings you are permitted to change:
; /home/USERNAME/public_html/.user.ini
upload_max_filesize = 20M
post_max_size = 24M
memory_limit = 256M
max_execution_time = 120
max_input_time = 120Changes to .user.ini are cached, so allow a few minutes or restart PHP via Select PHP Version by toggling an extension. Next, verify the image library is present. In the PHP Selector extension list, the gd extension must be enabled for the PHP version your domain runs, because mooSocial performs all resizing through GD. If your host also exposes imagick, leaving GD enabled is still correct since mooSocial targets GD by default. Confirm the active version matches your domain assignment in MultiPHP Manager; a mismatch there is a frequent reason settings appear to be ignored.
Inside mooSocial, the AdminCP has its own ceiling. Go to AdminCP → Photos (or Settings → Photo depending on your build) and review the maximum upload size and allowed extensions. This value must sit at or below the PHP upload_max_filesize you configured, otherwise the CMS will reject files it believes are too large even when PHP would accept them. While you are there, reduce the stored image quality. mooSocial exposes a JPEG quality setting for generated images; lowering it from the default to a range of 75–82 cuts file size substantially with no visible loss on feed-sized thumbnails, and it reduces both bandwidth and the disk footprint of every future upload.
Serving WebP and Controlling Thumbnail Sprawl
mooSocial writes JPEG and PNG derivatives, not WebP, so you gain the most delivery savings by letting the browser negotiate a lighter format when a matching file exists. If you generate WebP copies alongside the originals—either through a mooSocial module that supports it or a CDN that converts on the fly—you can serve them transparently with a content-negotiation rule in .htaccess. Place this in /home/USERNAME/public_html/.htaccess:
# Serve .webp when the browser accepts it and the file exists
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME}\.webp -f
RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,E=accept:1,L]
</IfModule>
<IfModule mod_headers.c>
Header append Vary Accept env=accept
</IfModule>
AddType image/webp .webpThe Vary: Accept header is required so that caches and the CDN do not hand a WebP file to a client that cannot render it. Do not attempt to force WebP conversion through .htaccess alone—rewrite rules only route to files that already exist; they cannot create images. If your mooSocial version does not ship a WebP module, the practical path is CDN-side conversion, covered below, rather than a custom converter you would need shell access to run.
Long-lived caching keeps the browser from refetching unchanged thumbnails on every page. Add expiry headers scoped to the uploads directory so avatars and photos are cached aggressively while your dynamic pages remain fresh:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
</IfModule>To limit inode sprawl, audit what mooSocial generates before more files accumulate. In AdminCP → Photos, review the enabled thumbnail sizes; some themes register square, medium, and large variants that a given community never displays. Disabling unused sizes stops the CMS from writing those derivatives on future uploads. For existing waste, use File Manager to inspect uploads/photo/ and confirm the size suffixes present, but do not bulk-delete by pattern—removing a derivative that a template still references produces broken images across the feed. If you must reclaim space from orphaned files, do it through a mooSocial cleanup module or admin tool that also updates the database, never by hand in the File Manager.
Offloading Delivery and Storage to a CDN
The single most effective change for a media-heavy mooSocial site on shared hosting is to stop serving image bytes from the origin. A CDN in front of your domain caches the derivatives at edge locations, absorbs the read traffic that would otherwise consume your account's CPU and I/O allowance, and many CDNs perform automatic WebP or AVIF conversion based on the request's Accept header—which removes the need for the CMS to generate those formats at all.
If your host provides an integrated CDN toggle in cPanel (commonly a LiteSpeed or Cloudflare option), enable it, then confirm image caching is active for the /uploads/ path. For a standalone provider like Cloudflare, point your domain's nameservers or add your zone, then enable Polish (or the provider's equivalent) with WebP conversion. Because mooSocial builds image URLs from a configured base path, verify in AdminCP → Settings → Site that the site URL matches the hostname the CDN fronts; a mismatch causes mixed-content warnings or requests that bypass the edge entirely. Keep the Cache-Control and Vary: Accept headers from the previous section in place, since the CDN honors them when deciding what to cache and which format to store per client.
Watch the interaction between the CDN and any query-string versioning mooSocial adds to asset URLs. If images update but visitors see stale copies, purge the CDN cache from its dashboard rather than disabling caching. Confirm the result with your browser developer tools: a cached image returns a CDN hit header and, where conversion is active, a content-type of image/webp even though the stored file is a JPEG. That confirms bytes are leaving the edge, not your origin. Between reduced JPEG quality at the source, disabled unused thumbnail sizes, and edge delivery with modern formats, a typical mooSocial community cuts both its inode pressure and its outbound bandwidth without ever needing privileges beyond the hosting account.