Closed (fixed)
Project:
Boost
Version:
6.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
4 Jun 2009 at 14:11 UTC
Updated:
3 Jan 2014 at 00:29 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
vacilando commented(Sorry, by 'this thread' I meant #428942: AHAH update textarea for .htaccess rules on performance >> boost page..)
Comment #2
mikeytown2 commentedRemove all the boost code from your .htaccess file then copy the generated code over it. Boost does not write to your htaccess file.
Boost stopped working because it won't cache if there are php errors or a drupal message is shown. Run this code in a php block, it should let you know whats causing the error.
The latest dev makes this an option that can be turned off.
Comment #3
vacilando commentedGreat - things work fine again after copying the suggested code from /admin/settings/performance to .htaccess. It was just a question of documentation, it appears. Thanks, this is an amazing module!
Comment #4
vacilando commentedHi again --
So things worked fine on a standard LAMP install on CentOS 5, but on my sites hosted at Mosso I still cannot get beta1 to work with the new .htaccess.
To explain, also in the previous version of .htaccess (alpha versions), I had to adapt the .htaccess to run at Mosso. Specifically, I had to use absolute path like this:
%{DOCUMENT_ROOT}/cache/to
/mnt/path-to-my-site/web/content/cache/Now, in the new code, I've tried without any change, and then with this change, but pages are not being saved (cache folder remains empty).
Maybe in the new .htaccess I have to do other modifications to get it running on Mosso? Any suggestions, things to try?
Comment #5
vacilando commentedWorks with the above change also on Mosso when using the latest dev release. Thanks!
Comment #6
mikeytown2 commentedin regards to #4
try the latest patch out and let me know if it gives you the correct directory.
#428942: AHAH update textarea for .htaccess rules on performance >> boost page.
Comment #8
capellicThanks for the Mosso tip, I needed it.
Comment #9
vacilando commented@mikeytown2 re: #6 - tried to use the generated code in beta2 in my .htaccess on Mosso as you asked. Cleared all cache at /admin/settings/performance, then browsed anonymously and refreshed /admin/settings/performance The count of cached pages kept increasing there BUT on the anonymous pages, no matter how many times I cleared browser cache and tried different browsers, I am not getting the footer info in page source about the page being cached! For example this page - when I look at it logged in, the Boost status block tells me it is cached. But when I look at its source (give it a try!) it does not have the footer that would confirm it. (FYI, the setting to not cache on error is off.)
Please advise.. I am now not sure whether pages are served from cache. I leave this for some time for you to check but if not solved I'll get back to the old .htaccess code I know works for me (from beta1 and with #4 fix). Thanks for having a look at this.
Comment #10
capellic@vacilando re: #9: A couple of things you can do to narrow the problem down.
1. Confirm that the cached pages are really being created by looking through the sub-directories in the /cache directory. I suspect the pages are there, but checking never hurts.
2. Double check your .htaccess paths. It feels like Drupal isn't picking up the cache files because the paths are invalid. I'm also on Mosso and it wasn't clear to me what my full path was until I looked at the options on the Boost Settings page (admin/settings/performance/boost). Expand the "Boost Apache .htaccess settings generation" field group and then, in your .htaccess file, replace any instances of "%{DOCUMENT_ROOT}" with the Mosso path that is "Document Root" radio list. It should look something like this: /mnt/stor2-wc1-dfw1/3903020/3903020/www.sitename.com/web/content. I then changed any instance of "%{SERVER_NAME}" or "%{HTTP_HOST}" to "sitename.com". Works like a charm.
Comment #11
vacilando commented@capellic -- thanks for your message.
(1) I confirm the cache dir is getting filled with pages.
(2) Well, you are repeating what I said in post #4 above and which you yourself used in #8. :-)
The idea is not to have to do this manual change on Mosso (or other similar) servers. mikeytown2 in #6 suggested a patch which I did not use, but I did use beta 2. In #9 I reported that without changing %{DOCUMENT_ROOT} I seem to be using cached versions (boost block says, and the anonymous pages seem fast) but that there was no confirmation in the source footer.
To this, I am hoping for an answer from mikeytown2. At this moment I am still running the beta 2 generated .htaccess and the footer does not show. Hope mikeytown2 can have a look and ask me for further info if needed. I would like to get this solved rather than give up and live with the need for manual changes.
Comment #12
mikeytown2 commentedThe boost block only checks if the pages cache got generated. It would be hard to make it check to see if apache is serving it as well. If it's not in the footer then your not getting the cached page. Check in different browser to be sure. Changing %{DOCUMENT_ROOT} is there for a reason, some setups might need it in order to work.
What's going on is apache's
%{DOCUMENT_ROOT}is different from php'sgetcwd();. getcwd() holds the correct dir for the static files. So for some reason on Mosso, apache's%{DOCUMENT_ROOT}isn't set right.http://www.cyberciti.biz/faq/howto-find-unix-linux-apache-documentroot/
I would ask them (Mosso) about this difference between apache and php. Reference this thread.
Comment #13
vacilando commentedAll right; did that. See the transcript below. They recommend using %{PHP_DOCUMENT_ROOT}. I confirm that that variable correctly renders the path in Mosso. mikeytown2, is this something you can work into the module expecting it will work on all systems? Or can the module detect being on such a system and use %{PHP_DOCUMENT_ROOT} under some conditions? Hoping for a generic fix.
Tomas Fulopp: OK, working with Drupal community on an issue that is affecting websites installed on Mosso.
Tomas Fulopp: The problem is that a module sets .htaccess rewrite rules that rely on %{DOCUMENT_ROOT}
Tomas Fulopp: On all other known servers tested this variable provides path to the, well, document root.
Tomas Fulopp: In my case it is /mnt/path-to-my-site/web/content/
Tomas Fulopp: But that does not work.
Tomas Fulopp: Another user confirms this finding at http://drupal.org/node/482000#comment-1825828
Miguel S.: yeah, document root won't provide the valid document root path, it's best to use php document root, you can override that though so it always provides the path you need.
Tomas Fulopp: I've spoken with the developer of the module and I would like you to have a careful look at his response at http://drupal.org/node/482000#comment-1839464
Tomas Fulopp: What exactly should we use instead of %{DOCUMENT_ROOT} ?
Miguel S.: one minute.
Tomas Fulopp: Sure, take your time. Note we need a solution for .htaccess - PHP does not come into play in that case.
Miguel S.: i know, i just want to confirm it.
Tomas Fulopp: Thx.
Miguel S.: it should be: %{PHP_DOCUMENT_ROOT }
Miguel S.: If you take a look at the data from a phpinfo(); you'll see that DOCUMENT_ROOT points to /var/www/html where as PHP_DOCUMENT_ROOT will point to the correct server address.
Tomas Fulopp: All right, we'll try that. Thanks a lot.
Miguel S.: You're welcome.
Comment #14
mikeytown2 commented%{PHP_DOCUMENT_ROOT} is not part of the apache reserved variables, which means it is a server specific thing that was done using the SetEnv Directive. In short I will add it as an option to the .htaccess generating function but I can not use that instead of %{DOCUMENT_ROOT}.
Comment #15
vacilando commentedOK, great; looking forward!
In order for me to understand: do you plan to add some kind of checkbox saying "generate .htaccess paths using php_document_root instead of document_root" or suchlike? Or are you able to detect the correct one for the given system?
Comment #16
mikeytown2 commentedI can detect it, here's the patch
Comment #17
vacilando commentedWell.. not out of the woods yet.
I tried replacing %{DOCUMENT_ROOT} by %{PHP_DOCUMENT_ROOT} in the generated .htaccess, but despite running cron, flushing the tested page, trying different browsers with flushed caches, the boost footer did not appear in the source!
When I look at phpinfo() there is a section headed "Apache Environment" and one of the lines indeed is:
PHP_DOCUMENT_ROOT /mnt/path-to-my-site/web/content
(btw, there is also: REDIRECT_PHP_DOCUMENT_ROOT /mnt/path-to-my-site/web/content)
Which is the correct path.
Then I went in and replaced %{PHP_DOCUMENT_ROOT} in the .htaccess by that /mnt/path-to-my-site/web/content. Flushed and... the footer appeared in page source!
Any idea why is this... seems like the variable is set but it cannot be invoked by %{PHP_DOCUMENT_ROOT}? How then?
Comment #18
mikeytown2 commentedforgot to say that this patch is for the latest dev. Made this compatible on windows now and slightly smarter.
Comment #19
mikeytown2 commented@vacilando
Try %{REDIRECT_PHP_DOCUMENT_ROOT}
in the mean time you gave me an idea. search the $_SERVER array for any matches to getcwd().
Comment #20
mikeytown2 commentedAlso try
%{ENV:PHP_DOCUMENT_ROOT}%{ENV:REDIRECT_PHP_DOCUMENT_ROOT}Comment #21
vacilando commentedRe #19. Did that. No match for 'getcwd' :-(
Interestingly, FYI, in that array there are three mentions of that full path of mine (/mnt/path-to-my-site/web/content), namely in:
["REDIRECT_PHP_DOCUMENT_ROOT"]
["PHP_DOCUMENT_ROOT"]
but also
["DOCUMENT_ROOT"]
Comment #22
mikeytown2 commentedwhats the diff between ["PHP_DOCUMENT_ROOT"] and getcwd() on your server?
Comment #23
vacilando commentedmikeytown2! It works!
#20 did it -- I used
%{ENV:PHP_DOCUMENT_ROOT}, then actually deleted the cache dir and created a new one, flushed Boost cache in Performance, flushed browser caches... one try, no footer (normal), reload, and the footer is there, consistently, on any page I try!Do you think you could roll this into the dev version so that I can try it that way?
It would be good if capellic could try it as well, but I am pretty sure it's a solution.
Comment #24
vacilando commented@mikeytown2 re #22 ... in case you still need to know that for some reason: there is no difference, they are precisely the same (slashes and all).
Comment #25
mikeytown2 commentedHere is a generalized solution, please test on your server and let me know if it works.
Comment #26
mikeytown2 commentedFixed an issue with the recommendation in the description.
Comment #27
vacilando commentedWe're very close but not there yet...
The generated .htaccess is headed by:
So the path to my web directory is correct, but the problem is that it is not automatically selected (and the recommendation is incorrect), so the .htaccess code still uses %{DOCUMENT_ROOT}. (Could this be because this is not a new install? I did however run update.php after installing the dev. Or what can be the problem?)
Let me know how can I help.
(Edit: Note that if I set the second option, apply, and then use the resulting .htaccess code, Boost works OK on Mosso!)
Comment #28
mikeytown2 commentedThe above patch is supposed to search the $_SERVER array for any kind of matches to getcwd(). It appears to not be working in your case... it should output %{ENV:PHP_DOCUMENT_ROOT} if I made some correct assumptions.
Would you mind giving me the output of this?
Comment #29
vacilando commentedSee #24... There was no match for 'getcwd' in the $_SERVER array.
Your code returns ( precise path censored, as always :-) the following:
Comment #30
mikeytown2 commentedtry this for kicks...
Comment #31
vacilando commentedboost_print_r was producing array, so I changed it to var_dump($options) etc.
Comment #32
mikeytown2 commentedThe reason why it's not giving the correct recommendation is the fact that according to PHP's point of view DOCUMENT_ROOT is set correctly. Do you get %{ENV:PHP_DOCUMENT_ROOT} as an option with the patch?
Comment #33
vacilando commentedNo, I get only %{DOCUMENT_ROOT} and the correct path, but not %{ENV:PHP_DOCUMENT_ROOT} as an option (see #27).
:-{
Comment #34
mikeytown2 commentedTry this patch. It's nothing new for the most part, as I can't think of a good generalized solution to your problem since DOCUMENT_ROOT in apache is different then it is in PHP. More options should show up.
Comment #35
mikeytown2 commentedcommitted
Comment #36
vacilando commentedI wanted to report on this, so I uninstalled Boost completely, then installed the newest dev.
Got a wholly new problem: these two error messages after enabling the module:
Then I went to the performance settings, and got another warning:
user warning: Table 'mydatabase.boost_cache' doesn't exist query: SELECT COUNT(*) FROM boost_cache in /mnt/path-to-my-site/web/content/sites/all/modules/boost/boost.admin.inc on line 534.Did run update.php - no improvement.
Eventually went back to beta2 and ran update.php, which finally installed the missing tables.
FYI: as for the document root settings, there still are the two items:
of which the second is my correct path, but it is NOT selected.
So - I think the Mosso issue is now satisfactory (even though not automatic), but the db install problems in dev are grave and do need attention (therefore marking this as a critical bug).
Comment #37
mikeytown2 commentedIt was a bone-head move by me. I originally named the column mime_type but then I changed it to extension. Forgot to change the database index. Here's the patch that fixes that as well as some minor things in the install file. Thanks for reporting this!
Comment #38
mikeytown2 commentedcommitted above patch. Fix should be in Aug 1st dev.
Comment #39
vacilando commentedOK, went again through the whole disable > uninstall > enable > configure procedure -- the problem described in #36 is fixed, excellent, yay!
Comment #40
mikeytown2 commented@vacilando
Thanks for confirming this is fixed