Short reasons for why I'm posting this in the forums instead of issues:
- I'm not a Drupal developer (means I don't have Drupal in CVS, thus I make diff manually)
- This was quickly written to make a proof and it worked, but the code standard is currently inadmissible (needs design)
- I made this for Drupal 6.3 and won't check it against Drupal 6.4 before posting it since it would need work anyway. Although I'm certain it should work the same.
- The discussion on D7 still goes (#181003) BUT they are far from getting things done (don't even talk about other issues like JavaScript translation)
Though, as there are some related issues here goes this. (see also #181003: private download method and dynamically generated CSS and JS)
Note: the whole post will be partitioned to make it more readable/followable.
I'm going to post a group of three related patches to solve three different (but related) issues with the same approach.
The common denominator is the private download method and the restrictions it imposes.
1-) The most important issue (of these three) for anyone concerned about performance will be the css/js aggregation (admin/settings/performance) which is disabled once private download method is chosen.
2-) The most perceptible (although prescindible for non-newbies) is the color module neutralization for those themes which supports it (admin/build/themes/settings/garland). If private download method is chosen the easy fanciness is one of the prices to pay.
3-) Last but not least, is the JavaScripts translations issues. If the private directory is out of the web server's reach (as it has to be for being actually private without relaying on .htaccess) then the JavaScript's translations will be done but will get 404 Not Found when pages are loaded. Resulting in the neutralization of the JavaScript's translations.
Of course, there is a workaround (without patch) for issues #2 & #3. Which consist on having a private directory (chosing private download method) under the web server's reach, protected with "Order allow,deny" and a <FilesMatch "\.(css|js)$"> with an Allow from all (as this is beside the point I'm just naming it, contact me for more info on this workaround)
These three patches have a lot in common, but as they can be separately issued/applied/tested I'll will submit it like three independent patches and also as whole patch.
The three of them relay on 6 minor modifications in common. Beyond that, the biggest one only adds 4 minor modifications. Every modification is related with an extended optional parameter to take into account.
The three cases are independent and as such can be applied one at the time, the three at the same time or whatever combination of two of them.
Also note that using js aggregation with patch for case #2 will incidentally do the trick for case #3. Even though disabling js aggregation will always require the third patch.
The core of these three patches is the same: enabling a public folder for those issues unrelated with the private download method.
The way to go is applying a common patch to the file.inc file (it will NOT brake)
Nevertheless these are only working patches which certainly will need to be rethought to accommodate the same functionality in a cleaner/standard way (see #181003: private download method and dynamically generated CSS and JS).
@TODO: deciding whether the required directory must be part of Drupal distribution or programmatically created to kept it configurable via a variable (as of now it must be created manually when applying the patch)
P.S: Sorry, but I don't work with Drupal in CVS, I tried to do the best I could to provide these patches with the diff tool (diff -U 0 -p newfile oldfile > filename.patch), to apply them I use patch -p 0 -u -i filename.patch being in the Drupal's targeted directory.
Comments
The common patch for file.inc
The common patch for
file.incNote that the
diffsays changes are in some functions they weren't whenever the signatures were changedWhat happened until here:
1- The manually creation of a directory for handling those public files only in case private download method is chosen (otherwise everything will remain the same).
2- The alternative is taken into account when returning the
file_directory_path @@ -961 +961,53- The same goes for
file_create_path @@ -64,2 +64,24- Ditto for
file_copy @@ -216,2 +216,25- Ditto for
file_move @@ -330 +330, @@ -333 +3336- Ditto for
file_save_data @@ -753 +753, @@ -764 +764Until this point everything works the same.
All the added argument are optional and by default they behave the same it used to be.
The patch for case #1
The patch for case #1
NOTE: For any of these patches to work a directory
misc/dynamicmust be manually created AND the abovefile.incpatch is required.What happened until here:
1 trough 6- The above
file.inc's patch7- The alternative is taken into account when invoking the
drupal_build_css_cache @@ -1765 +1765, @@ -1791 +17918- The same goes for
drupal_build_js_cache @@ -2237 +2237, @@ -2250 +22509- Ditto for
drupal_get_css @@ -1691,2 +1691,2, @@ -2043,2 +2043,210- Enabling css/js aggregation regardless of the current download method
system_performance_settings @@ -1318,2 +1318,211- Optionally change the description (see below) to point out the current possible causes for these options to be disabled (private download method will be no longer a possible cause)
Note this single one might look big, but it's only changing the explanation about controls being disabled (the last sentence). On the other hand, the new explanation refers to
'misc/dynamic'directory and it is possible to change this by means of variablefile_public_directory_pathas considered in the abovefile.inc @@ -961 +961,5The patch for case #2
The patch for case #2
NOTE: For any of these patches to work a directory
misc/dynamicmust be manually created AND the abovefile.incpatch is required.What happened until here:
1 trough 6- The above
file.inc's patch7- Enabling color support regardless of the current download method, by means of removing the whole
ifblock with watchdog and comment to issue #181003: private download method and dynamically generated CSS and JS alongfunction color_form_alter @@ -35,6 +34,0, @@ -50 +43,08- The alternative is taken into account when invoking the
function color_scheme_form_submit @@ -297 +290, @@ -315 +3089- The same goes for
_color_save_stylesheet @@ -445 +438Note: the statements that were in the
elseblock (resulting lines 35 through 43) weren't properly re-indented to keep thediffas readable as possibleThe patch for case #3
The patch for case #3
NOTE: For any of these patches to work a directory
misc/dynamicmust be manually created AND the abovefile.incpatch is required.What happened until here:
1 trough 6- The above
file.inc's patch7- The alternative is taken into account when invoking the
locale_update_js_files @@ -501 +5018- The same goes for
_locale_rebuild_js @@ -2137 +2137, @@ -2153 +2153END OF THE THREE SEPARATED CASES - BELOW IS THE SAME THREE CASES
Note: consider that invocations to
file_save_datawith the third argument omitted is equivalent to passingFILE_EXISTS_RENAMEwhich I found without sense in the cases in question and that's why I useFILE_EXISTS_RENAMEinstead whenever I need to use the forth argument (wasn't because the fun of it). Nevertheless, fell free to change it back toFILE_EXISTS_RENAMEat your willEND OF THE THREE SEPARATED CASES - BELOW IS THE SAME THREE CASES AS WHOLE PATH
The three patches as a whole (for cases #1, #2 & #3)
NOTE: For this whole patch to work a directory
misc/dynamicmust be manually created.new patch can be found at
new patch can be found at 181003#comment-1972764
maintained patch
#572516: make private download method support css/js aggregation, color module and js translations