### EDIT ###
This is not an issue now! It looks like the pages were getting cached in my browser and not showing the boost html. I've got to investigate further and will post if it turns into another rabbit hole.
The hack below for to get provision_boost working with Boost version 7.x-1.x-dev is still relevant.
##########
Hello there,
Hope you can help. I've been banging my head against a brick wall trying to get this to work.
I'm running Aegir on Debian Squeeze installed as per the instructions http://community.aegirproject.org/installing/debian.
I'm running a Drupal 7 platform with Boost version 7.x-1.x-dev. The boost api has changed slightly so I updated verify.provision.inc (will try to write a patch if I can get this to work).
// $htaccess = boost_admin_generate_htaccess($host, $root);
// New Boost API
$htaccess = boost_admin_htaccess_generate_htaccess();
// return "RewriteEngine on\n" . $htaccess . "\n";
return file_get_contents(dirname(__FILE__) . "/boosted2.txt");
$config = new provisionConfig_drushrc_site(d()->name);
if ($config->data['packages']['modules']['boost']['status'] == 1) {
// boost_cache_clear_all();
// New Boost API
boost_flush_caches();
drush_log(dt('boost: Flushed ALL files from static page cache.'));
}
I reverify the site and the REWRITE rules are written the the vhost file for the site and look fine. The cache files are being written to the cache dir.
cache/
└── normal
└── boost.prod.mysite.net.nz
└── _.html
2 directories, 1 file
Looking at the cache files the boost comment is at the bottom of the page:
</div></div> <!-- /.section, /#footer-wrapper -->
</div></div> <!-- /#page, /#page-wrapper -->
</body>
</html>
<!-- Page cached by Boost @ 2011-10-25 12:47:15, expires @ 2011-10-25 12:47:15, lifetime 0 sec -->
I've tried boosted1.txt and boosted2.txt to no avail. The pages that I'm recieving in my browser are not coming from the boost cache as the boost comment isn't appearing at the bottom. Tested in Firefox and Chrome.
The README.txt in provision_boost is a bit confusing. I tried the platform instructions using the node id for the platform as the platform id? But didn't get any feedback from the command so not sure what it did? I re-verified the platform as well, but still not working?
I've also attached my vhost.
Any pointers much appreciated!
Thanks
Sam
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | drupal7_support_provision_boost-6.x-1.0-1320346.patch | 1.51 KB | pauleb |
| #1 | drupal7_support_provision_boost-HEAD-1320346.patch | 1.84 KB | pauleb |
| boost.prod_.mysite.net_.nz_.txt | 4.63 KB | sambojambo |
Comments
Comment #0.0
sambojambo commentedRemoved url
Comment #1
pauleb commentedI ran into the same issue.
After getting
function boost_admin_generate_htaccess() not foundduring verifying I looked into the boost module and realized the API changes. After playing around a while I found this issue with this nice howto. I'm so bold to change the issue title, at least I would have looked into it a lot earlier and saved myself some worries.Using sam's changes I wrote a patch that recognizes D7 and runs the appropriate functions. After realizing, that the provision_boost-6.x-1.0 has changed to the current HEAD of the git repository I created a second patch for HEAD.
I also looked into the "comment not in the browser" - issue. I, just like sam, couldn't find the boost comment in the code in the browser, although I saw it on the server. So I tried to change the HTML of the cached site and recognized, that it gets delivered to the browser. It seems that the comments are ripped out somehow.
I hope this is useful and thanks to sam for the code!
Comment #2
bgm commentedI did a bit of cleaning in the code and committed a few fixes based on pauleb's patch.
One of the bugs was caused by code whose result wasn't actually used: boost_admin_generate_htaccess() can't be trusted, because it's code from the module itself. In some Aegir environments where users can upload modules, that provides them a way to write their own function and therefore inject any code they wish in the Apache vhost.
So the code's result was not used, but it was still executed. i.e. there was no security risk since provision_boost didn't use the resulting vhost directives, but it was still causing a PHP error because the name of the function has changed in boost.
It's now committed to the new 7.x-1.x branch. Note that this branch supports all Drupal versions.
Feel free to ping me on #aegir (bgm) if you run into any issues.
Comment #3
bgm commentedI also updated the README.txt in the module, since it was still referring to the old method of configuring boost.
Comment #4.0
(not verified) commentedEdit with explanation of fix