Document how to install Commons so that files can be made private

For sites that need to restrict access to uploaded files, it's critical that after installation you proceed to admin/settings/file-system and configure Drupal to use a private filesystem.

This is documented further at http://drupal.org/node/22240.

Before we send to be added to the official documentation, do we know for sure that Commons installations are working in the wild with private files?

I tested and observed that switching to private files on an existing site, default images like the default group icon were broken. This is to be expected since Drupal doesn't generally support moving from a public to a private filesystem through core alone.

When switching to a private filesystem immediately after installing, I didn't see any broken images. However, even though the default group icon had a private fileystem path, like:

http://localhost/dev/acquia/commons1/docroot/system/files/imagecache/gro...

The directory that corresponds to the private files directory was empty, and Drupal is actually serving this file from the existing public files directory. Indeed, the only entry in the files table on a fresh install is for that icon, and it has a filepath of, "sites/default/files/default-group.png" (the *public* files directory location).

This is because we create new image files that have entries in the files table in drupal_commons_config_images(). We could probably set the default images via CSS instead of submitting files on install and avoid having anything in the files table on a fresh install.

However, the documented instructions here for private files would still work for all new files going forward, provided that the user doesn't remove the old public files directory, so I think documentation is sufficient for 2.0

Craig updated http://network.acquia.com/documentation/commons/install

So what are we doing with this?

Craig added this to the docs, so unless batsonjay has further feedback I think this is fixed.

Moved this comment to a separate issue http://drupal.org/node/1271816

Thanks for highlighting this batsonjay, as it could have been potentially embarrassing with potentially private company files being accessible from the wild! It might be worth considering making 'private file system' a default for DC and utilising something like http://drupal.org/project/xsend to overcome the performance hit on larger sites.

In case it's helpful I've just changed from pub to priv and the only entries in the db that I had to edit manually were user pictures and poll pictures. I can't say for sure that this is an exhaustive list though as it will just depend upon what was uploaded to the site at the time.

This was useful: http://drupal.org/node/344806

Scrap that: using the private file system is useless in DC due to the amount of stylesheets that are required (this needs testing with the default DC install as I have extra modules and CSS files) but the problem is that you can't use CSS caching with private file system and IE throws a fit because of the number of CSS files.

I've come up with this but if someone with more knowledge than I can cast an eye over it, it might be helpful to a wider audience.

1) Leave file system as public
2) goto /sites/default directory
3) create .htaccess file so that it looks like this:

RewriteEngine on
RewriteBase /system/files

RewriteRule ^files/(.*)$ $1 [L,R=301]

4) Then go to /sites/default/files/css and add this .htaccess file:

RewriteEngine off

5) Add this same file to any other folders that you either need for the cache to work and/or you are happy to remain public, eg:

/sites/default/files/js
/sites/default/files/ctools
/sites/default/files/ctools/css

Using this method will still have the performance hit when serving files on larger sites. So, if you need to reduce the server load when serving files/images then use this module: http://drupal.org/project/xsend

...but I will leave that for another day.

Cheers,
Crom

I'm using the advanced aggregation http://drupal.org/project/advagg module with Commons to aggregate css/js files. Works fine.

Since Commons and OG generally give the impression to users that the contents of groups are 'private', I think this would be an important feature.

Agreed!

Looks like another good option. I'll give it a try. Thanks lightsurge

I had some issues with advanced aggregation and ajax_load #1306182: packaged version of ajax_load breaks layouts in certain circumstances

Also, superfish flagged up errors on IE unless I used the advagg bundler to break javascript into a minimum of 3 files.

I don't know if this is already in the documentation, because I don't have an Acquia Network account... Isn't it worth also having the docs at #5 put on drupal.org?

moving comment to issue in #14

After various gripes with advagg for aggregating CSS to make Commons work with a private file system in Internet Explorer, I patched Drupal Core with this pretty solid code:

http://drupal.org/node/572516#comment-4517060

Unfortunately it's never going to make it into Drupal 6, but it might be a good thing until Commons moves to Drupal 7 (which can aggregate css/js as standard in private file systems)

at least the advagg module doesn't quite work right. It looks ok on the surface, but when you look at the group pages things go awry. the right pane information, when the page completely loads, "disappears"/reformats and goes to the bottom of the page. Same problem occurs with the unlimited_css module as well.

@ricks03 I've had the problem you mention in #17 with both advagg and the patch in #16

Seems to be something to do with the order the stylesheets are loaded, as well as css 'reloading' that kicks in when ajax is triggered in a block, and results in default content width overrides that fill 100% (while normally they'd be dynamically set through the grid system) and therefore push content underneath.. Upgrading the http://drupal.org/project/ajax_load module solved some of my problems, but then they re-appeared.

I hadn't seen http://drupal.org/project/unlimited_css although I can see how the problem would be the same... http://drupal.org/project/ie_css_optimizer looks interesting because it looks like you can 'omit' certain module/theme css from aggregation.