Closed (fixed)
Project:
Boost
Version:
5.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
3 Dec 2006 at 19:33 UTC
Updated:
22 Apr 2010 at 19:37 UTC
Jump to comment: Most recent
Boost not working if drupal is installed in a directory. (eg. xyz.com/drupal)
Is there any workaround for this?
Comments
Comment #1
Arto commentedAsif, please describe your problem - that is, in what way it doesn't work - in a bit more detailed fashion.
I don't off-hand know any reason why Boost wouldn't work in a subdirectory if Drupal's clean URLs do (meaning you've set your
RewriteBasedirective in the.htaccessOf course, there may certainly a bug in the code that would prevent it - I don't have any Drupal installations in subdirectories so I haven't tested Boost with that.
Comment #2
Arto commentedOops, the text got cut off... what I meant to say:
I don't off-hand know any reason why Boost wouldn't work in a subdirectory if Drupal's clean URLs do (meaning you've set your
RewriteBasedirective in the.htaccessfile, etc.)Of course, there may certainly a bug in the code that would prevent it - I don't have any Drupal installations in subdirectories so I haven't tested Boost with that.
Comment #3
Asif99 commentedI have installed drupal in a subdirectory and it is working fine with clean urls and rewritebase. I installed boost and its not working. (no boost stamp in html). Although cache files are being created in cache directory.
Then for testing I created a Virtual Server in apache with drupal directory as Document Root. And removed 'RewriteBase /jauhar' from .htaccess. Boost is now working!
Comment #4
Asif99 commentedfound the problem in boosted.txt (.htaccess)
RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}/0/%{REQUEST_URI} -d
RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}/0/%{REQUEST_URI}/index.html -f
RewriteCond %{DOCUMENT_ROOT}/cache/%{HTTP_HOST}/0/%{REQUEST_URI}.html -f
DOCUMENT_ROOT does not have any cache directory! cache directory is inside drupal. Changing these to following seems to be working.
RewriteCond %{DOCUMENT_ROOT}/drupal/cache/%{HTTP_HOST}/0/%{REQUEST_URI} -d
RewriteCond %{DOCUMENT_ROOT}/drupal/cache/%{HTTP_HOST}/0/%{REQUEST_URI}/index.html -f
RewriteCond %{DOCUMENT_ROOT}/drupal/cache/%{HTTP_HOST}/0/%{REQUEST_URI}.html -f
What should be the best solution for this?
Comment #5
Asif99 commentedwell, above is also not working.. I type the wrong url for testing... :(
Comment #6
Arto commentedThe best thing would be if you can attempt this on a server where you have access to change the
RewriteLoglevel, so that you can get debug output and quickly find out what the problem is.Looking at your rewrite rules, my hunch at the moment is that the
%{REQUEST_URI}in theRewriteCondstatements includes the/drupalprefix, so the files are being looked for indrupal/cache/hostname/0/drupal/page.html, when in actuality the file is written out by Boost asdrupal/cache/hostname/0/page.html(note the missingdrupaldirectory in there). If so, that is a bug and needs to be corrected in the code, after which your modified rewrite rules should work.As I don't have a whole lot of time at present to tackle this, could you please verify that this indeed the cause of the problem; that is, if you manually create the
drupaldirectory under thedrupal/cache/hostname/0directory, and move all the generated files into it, does caching work with your modified.htaccessrules?Comment #7
Asif99 commentedI enabled RewriteLogLevel, but it is not generating any logs under subdirectory drupal installation. (tail -f /var/log/httpd/rewrite_log |grep cache)
It does creates host folder, 0 and html pages correctly, but not able to use these for displaying. Any other suggestions?
Comment #8
Arto commentedFrom recent comments by Justin Miller I think Boost still has this bug. Hunting down the bug is not a high priority for me at present, but I'll probably eventually get around to it. A patch to fix it sooner is welcome, of course.
Comment #9
brush@groups.drupal.org commentedthe following is a hack that is currently working for me (knock on wood), and could be used to make a proper general fix.
note: "drupal" should be replaced with appropriate subdir.
order matters.
hth,
.brush
Comment #10
liam mcdermott commentedJust thought I'd confirm this bug. Am using the 5 stable branch (assuming as the htaccess has not changed between this and the dev branch that the bug is in both). The static files are created correctly, but not served. Am using a
RewriteBasestatement to point Apache at a subdirectory.Comment #11
Boringo-1 commentedThanks .brush for the code, I had to replace "/share" to "/drupal" in a few lines of your code and the system finally worked perfectly in a subdirectory named drupal.
Comment #12
Mixel Adm commentedhi everybody
i just installed boost in a site under a subdirectory and i don't see any complication on it.
i see you use some replaces bud i didn't make any raplacemnt. the only thing you need to do is uncomment the line with the text
# RewriteBase /drupal
and write your subdirectoory like this
RewriteBase /agregador/
look that theres is a / at the end.
and magic happens....
Mixel Adm
Comment #13
DA Designers commentedHi Asif,
Please email me your contact info at info@dadesigners.com - i would like to speak with you.
Hope to hear from you soon.
Danish
Comment #14
gdtechindia commentedi tried all the options, but boost didnt work in sub directory for me.
Comment #15
drupdrips commentedIt should work. I don't know about Apache, but in lighttpd, I have physical docroot of mydomain.com pointing to /var/www/public_html/mydomain.com . Drupal is installed at : /opt/drupal5
I have created a "cache" folder under "/var/www/public_html/mydomain.com" that soft links to cache folder under /opt/drupal5. /var/www/public_html/mydomain.com/cache -> /opt/drupal5/cache
In lighttpd.conf I have server.document-root pointing to : /var/www/public_html/mydomain.com
In lighttpd / lua rules for rewrite conditions : I made sure physical path gets picked up relative to physical docroot, which is how it should be anyway. Again, similar to Apache here, just that I have re-worked apache rules for lighttpd.
There is ONE bug that I found for which I had to resort to the option of softlinking as I mentioned in para 2.
That is this: Boost was creating cached files for me in web docroot and also lighttpd rules (I made sure) was picking up from the right place relative to docroot. However, page expiry was NOT happening. This is because boost_cache_directory is using cwd (current working directory) to arrive at the cache location which is working a little erratic (I did not choose to troubleshoot further as I found a easy quick solution). Basically cwd was switching between webserver docroot location as cwd and drupal base install as cwd directory. It was using docroot for creating cached files. But it was looking for drupal base install directory when trying to expire pages. So pages were not expiring for me. The quick solution was the softlink of "cache" subdirectory so it would find the path either way and use only one location.
Comment #16
Arto commentedI will not be supporting the 4.7.x version any longer, but if somebody wants to roll up a proper patch and get some reviews and testers on it, I will certainly commit it to CVS. It would be a useful feature to have and should probably get forward-ported to 5.x and 6.x, if and when somebody does take the time to get this closed out.
Comment #17
Arto commentedUnassigning myself as I don't intend to work on this just now. Anyone interested in seeing this work should feel free to tackle it.
Comment #18
drupdrips commentedHi Arto,
with soft linking between the cache folder from docroot and cache folder under drupal base install (wherever the directory maybe .. doesn't matter) this is no longer a problem. Maybe you can include a point in the usage guideline.
BTW Thanks for a great module with a real kick a$$ benefit.
Comment #19
gingerjoos commentedworkarounds/fixes mentioned in #18, #12 didn't work for me. Workaround mentioned in #9 seemed to work, once the fix mentioned in #11 was applied. Thanks a bunch guys :)
Comment #20
giorgio79 commented#9, #11 work for me only for the front page, the other pages are saved but not retrieved.
#18, #12 did not work for me unfortunately...
Comment #21
andreiashu commentedI think that the problem comes from the boost_cache_set function too. More specifically the way we get the path aliases. My drupal installation is also in a subdir. Al least for me the REQUEST_URI var looks like this: /subdir/path_alias (i already have a "RewriteBase /subdir" in the .htaccess). Tthat means that we must include the subdir in the boost_cache_set too. So in the boost_cache_set function replace:
with this
This if for the 6.x-1.0-alpha1 version. For me it worked flawlessly (until now).
Also for those of you who have a multilanguage site please have a look at: #342323: boost_cache_set not getting the correct url alias
Please try to test this and tell me if it makes sense what is said here.
Thanks
Comment #22
develcuy commentedI have hacked it for Drupal 5:
1. .htaccess
Notice: I'm using 'drupal' instead of '/drupal'
2. boost.api.inc
Blessings!
Comment #23
gerhard killesreiter commentedI am using boost on a multisite install where the individual sites are "subdirectories" of the main site. The subdirectories are actually fakes creates by symlinks back to the main install.
I've modified boost to work for this use case.
The only modification I needed in boost itself was in boost_cache_directory:
original:
modified:
Maybe more is needed, not sure, it seems to work.
The modifications in .htaccess are a bit more extensive. The problem is that mod_rewrite tries to be helpful and strips the subdirectory from the path. The solution I found was to add that subdirectory into an environment variable. This needs to be done in the main vhost config:
The .htacess code then looks like this:
Comment #24
rsvelko commented@Gerhard Killesreiter: give more detail on the places of the dirs you use - which is where and links to what - examples? I can give advice on the best practice and I have done the same inthe past.
nice to know about the env vars in apache - may be useful in a curent feature request with moving cache dir to sites/example.com/html_cache ...
Comment #25
mikeytown2 commentedIf the above rules could be generalized so they work on single & multi; shared & VPS; apache 1.3+; root & subdir that would be amazing. For the php something like
Apache would require something like this ?
http://httpd.apache.org/docs/1.3/mod/mod_env.html
http://httpd.apache.org/docs/2.0/mod/mod_env.html
I think it can be set in the .htaccess file in 1.3
How deep does the subdir work with this rule?
example.com/my/deep/sub/dir would need to work, in order for this to be added to the main branch of boost.
Comment #26
gerhard killesreiter commented@rsvelko: Don't think I need advice there, it works after all. But thanks.
@mikeytown2: the rewrite condition looks at the requested file path and stores the first part in the variable. This relies on the fact that I already know that the first part is the subdirectory I want. Would my install be two directories deep I would need to modify the regexp.
I am not sure this can or should be added to the main code. Maybe as some extended docs?
Comment #27
mikeytown2 commentedI'm leaning towards php generated htaccess rules that you then copy/paste in. That would keep the rewrite rules fairly simple and still allow for many different installation profiles. I think there's enough info here to do a subdir install & possibly a multi site install. The php would generate some hard coded settings to make the rewrite rule generation easier.
Comment #28
mikeytown2 commentedHere's some rules for 6.x-1.0-alpha4 & for a subdir install. Replace
DRUPAL-SUBDIRwith your subdir. Based off of #9 above.Comment #29
mikeytown2 commentedFor some reason gzip messes up here. This should work for a subdirectory Drupal installation, but only gzip support for the front page.
Comment #30
marcingy commentedJust tried it on development server with drupal in a subdir and it seems to work well. Thanks for the fix.
Comment #31
toolman-2 commentedThe solution in #29 may not work depending on your site configuration.
If your DRUPAL-SUBDIR is not under %{DOCUMENT_ROOT} usually /var/www the cache folder is not found.
You have to replace %{DOCUMENT_ROOT}/DRUPAL-SUBDIR with the absolute path on your server e.g. /home/www/drupal.
Comment #32
Anonymous (not verified) commented#29 is working well for me. Thanks mikeytown2!
Comment #33
mikeytown2 commentedThis will stay at RTBTC until #428942: AHAH update textarea for .htaccess rules on performance >> boost page. is done
Comment #34
Drupal_is_amazing commentedso, does gzipping currently only work for the root, as of this moment? I've done lots of fiddling with various rewrite rules, but can't seem to get it to work for the majority of pages on my site.
Which raises another issue-- how do I know _if_ it is working. I've been using firebug to see the size of the incoming files, but I don't know that actually works. Perhaps adding another banner to the file before gzipping it would allow us to look at the source and see whether we're being served live, normal cache, or gzipped cache. Or is there already an easy way to determine which is which?
Comment #35
mikeytown2 commented@Drupal_is_amazing
My other project has a good explanation for checking gzip: http://drupal.org/project/css_gzip
Gzip for subdirs only works for root ATM. I have some creative ideas on how to make it work #276495: Update for Rewrite Rules - Give Boost even bigger performance gain, but its a low priority; boost needs a lot of help still in other areas.
Comment #36
Drupal_is_amazing commentedYeah, I imagine it's less of a priority for my site than for most-- my site is very text intensive, so gzip seems to cut my bandwidth in half. For a site that was more photo based, the gzip probably wouldn't offer as substantial a benefit.
Thanks so much for all the great work your doing on this. You're a lifesaver.
Comment #37
mikeytown2 commentedRenaming title to better match current state of this issue
Comment #38
mikeytown2 commentedGive this a shot, should do gzip in subdirs.
EDIT: Replace
aprilwith your subdir name in the above code.Comment #39
mikeytown2 commentedMoving to
#428942: AHAH update textarea for .htaccess rules on performance >> boost page.
Comment #40
mikeytown2 commentedk... figured out the root cause of the majority of the headaches. The $path variable isn't the same when accessed from different routes in the code. boost_init() is to blame. This line needs to be added to it in order to correctly handle subdirs
It adds on the $base_path to $GLOBALS['_boost_path']. $path from drupal has the $base_path already added to it. This will simply the rewrite a little bit more :) and make fixing some bugs simpler #443736: Smarter boost_cache_expire(). Path Changes & Wildcard Support.
I will add this code to the boost_init() rewrite patch #385924: Don't cache pages when there are PHP/MySQL errors and make the corresponding changes to the htaccess generation function.
Comment #41
mikeytown2 commentedreopen for 5.x #22
Comment #42
mikeytown2 commentedClosing all 5.x issues; will only reevaluate if someone steps up #454652: Looking for a co-maintainer - 5.x
Reason is 6.x has 10x as many users as 5.x; also last 5.x dev was over a year ago. The 5.x issue queue needs to go.
Comment #43
mclinn commentedAdding my two cents (and gratitude) here. Same thing, version 5, drupal in a subdirectory, no luck with Boost. Created cached files but wouldn't retrieve them.
Comments #9 and #11 worked for me. I also had to change the RewriteBase parameter to match my subdirectory, also added a default charset to utf-8 directive to stop high ascii characters from showing up. And I will probably force all requests to "non-www" format to avoid that ambiguity.
The performance difference is amazing. There are still some odd permission things going on but I think I can deal with them. My site is almost all anon. users so will benefit greatly from this module. I plan to investigate "pre-caching" also, maybe doing wget on the xml file from xml sitemap or something similar. And one day when I feel nervy I'll upgrade to version 6 (or maybe 7?) and use the newer features.
Thanks to everybody involved for such a great module and all the efforts in helping it to work in the variety of ways we need it to!