Boost Port to 7.x

Boost is a very technical module and quite non-trivial to set up. Given how much trouble people have setting it up in its current form (witness the issue queue), I'm not sure that it makes a particularly good candidate for core inclusion at this time. Feature-wise it'd be nice to have it in core, of course, but realistically the module would have to mature to a stage where an average user is able to set it up, and it would also have to work with a very wide variety of web server configurations, which may quite possibly be an inherently insoluble problem.

Anybody who wants to push this agenda is welcome to try, though :-)

postponed until we get a stable 6.x-1.0 release
#326515: Roadmap For stable 6.x-1.0

Some work that is made into core D7 related to boost: #370454: Simplify page caching
I disagree including Boost into core, because this way you won't get new features but only 1 per year.

Dries just strongly suggested that we need a file based cache solution. He specifically mentions boost. Thats our call to arms, folks. Hope someone can take this on. A guiding principle needs to be - keep it simple.

The roadmap from #4 is almost done. Once http://drupal.org/node/428942#comment-1633210 (not the patch from #30, it was too aggressive) goes in, and I get #443736: Smarter boost_cache_expire(). Path Changes & Wildcard Support done, I will release a beta 1 of this module; whats left from #326515: Roadmap For stable 6.x-1.0 are UI changes then. Currently testing on XP/Linux Apache 1.3/2.0. So far no 404's so thats a good sign.

Degrading this to a 7.x port, as I don't see this getting in before September, and I'm the only one actively doing commits at this point in time.

Drupal 7 code freeze is coming soon, and I'd consider Boost 6.x-1.13 pretty stable. We might want to consider creating a patch off of DRUPAL-6--1 for HEAD in the next couple weeks.

Just wondering if you had an idea of when you might look at porting to D7? Thanks for all your hard work.

I'll probably start to port it once 7.x is in a late phase alpha/early beta. I would like to make the 7.x version modular, but I do realize that a quick and dirty port before 7 goes "gold" would be a good thing.

Drupal 7 brought about a lot of new functionality in terms of how content is organized; I would like to take advantage of that in the expiration logic side of boost. Hacking a simple functional version of Boost for 7.x could be done fairly quickly; so I'm not worried about it too much.

subscribing

subscribing too...

subscribing

Yeah it would be great to have a simple working version for Drupal 7 since at the moment Drupal is slow on my webhost. I would love to use D7 beta on a small live site, since it will have the upgrade path working.

Simple 7.x port. Doesn't keep track of css/js files so your on your own in that regard. More of a proof of concept; to take advantage of the new stuff that is in 7.x. Also to rework some of the core ideas behind the functions & hopefully reduce some of the unnecessarily complex parts of this module.

I think I want to store more info in the $_boost global; use hook_init to set it all. Push the module weight down to something like 10 (6.x it was -90).

Still need to push the module weight down; I think I have a good start for the simplification rewrite. Also have some nice hooks and plan to use more.

I want to make the storage type a hook, so with the defaults it will do html/json/xml but with this make it very trivial to add in stuff like pdf's; simply pass in a couple variables into a hook and your ready to go. This should reduce code complexity even more.

Example hook

array(
  'extension' => 'xml',
  'content-type' => 'text/xml',
  'content-type-variants' => array(
    'application/xml',
  ),
  'title' => 'XML',
  'description' => 'Used for things like feeds',
)

Need to be able to do all things to the cache by full URL or by drupal internal paths (API).

subscribe

Subscribing. Thanks

Barely functional 7.x port
http://drupal.org/node/937552

Functionality that is in right now

Cache html, xml & json.
Boost cacheability settings - Just like the block visibility settings.
Clear expired cache on cron.
Clear all cached items on a cache flush.
Cookie is set for logged in users; removed when logged out.
Extracts a lot of info about the page it just cached (doesn't do anything with it so far; but that will soon change)

Functionality that is NOT in right now

Missing any kind of smart cache expiration.
No Caching of css/js
Missing the Crawler
Missing htaccess rules (use the ones from 6.x, should work fine)
No database tables
No Gzip Support
No php error or drupal message checks
No asynchronous operations
No anonymous stat counter

Boost hooks that are implemented

hook_boost_is_cacheable - Tell boost to not cache a page via code
hook_boost_menu_router - Custom cache handler for your custom page
hook_boost_storage_types - Tell boost to cache other things besides html, xml or json (example: PDFs)

Goal of this:

Code simplification; splitting up what can be into sub modules (example: enable the boost crawler module). 6k+ lines of code in a single module file is a bit too much... I hope to bring this down by at least 1k.

Question

I think I already have the answer to this; but is there any reason to not call this 7.x-2.x?

I'm really not familiar with Boost at all (but I do need it real bad), but I was wondering--why can't it flush the cache of just one page, when it's edited say? Or is that smart cache expiration you mentioned? Theoretically, it seems possible to listen to what gets affected by what change, so it that too impractical? (and I mean basic use like changing page contents should flush cache of that page, not talking about crazy algorithms) With that feature, Drupal would probably work great even on real cheap hosts.

Thanks for all your work!

@Ildar Samit
6.x has the best cache expiration logic I've seen in any CMS out there. 7.x will get there soon.

subscribing

subcribed

subscribing

subscribe

Subscribing.

subscribe

And another subscribe!

+1 Subscribing

subscribe

anyone try the stripped down 7.x version?
http://drupal.org/node/937552

Downloading and testing now.

Definitely needs work. Immediate notices were:

Notice: Undefined index: path in _boost_get_menu_router() (line 426 of /home/gharvey/workspace/drupaler/trunk/www/sites/all/modules/boost/boost.module).
Notice: Undefined index: page_callback in boost_boost_menu_router() (line 494 of /home/gharvey/workspace/drupaler/trunk/www/sites/all/modules/boost/boost.module).
Notice: Undefined index: page_callback in boost_boost_menu_router() (line 506 of /home/gharvey/workspace/drupaler/trunk/www/sites/all/modules/boost/boost.module).
Notice: Undefined index: page_arguments in boost_boost_menu_router() (line 519 of /home/gharvey/workspace/drupaler/trunk/www/sites/all/modules/boost/boost.module).

I'm not sure what these mean - they are only notices, so I guess they're not show-stoppers, but I have no real way of telling if Boost was actually doing anything. Unless I missed it, there's no reporting yet, and I couldn't find any evidence anywhere on my system of Boost actually creating any files, so I'm pretty sure it's totally fubar'ed for now.

lol; it did work locally on my box back in October; so it's one step above fubar. Looks like I need to get D7.0 and fix some things.

Cool - btw, didn't mean to sound harsh there... fubar is too much. Sorry. ;-)

Looking at the code; what was the path when you got the above notices? Also you need to manually create the cache dir and give the webserver write permissions for it. Use the rules from boost 6.x & it should work; it's working for me.

Config under admin/config/development/performance/boost

I get the notices on a 404; will fix

Ran boost through coder; came back with a lot of minor fixes. Also fixed 404 throwing notices.

This has been committed.

Hi,

I get these notices on every page. At the config page there is nothing I can see to indicate the location of the cache directory or be able to set it in admin. See attached.

Edit: I've left this set up on dev, so feel free to use me as a guinea pig... ;-)

Added more changes. Dev should be updated in 3-4 hours.
http://drupal.org/cvs?commit=481964
Flush the cache after installing the new version.

FYI: 2.x version of boost will use the Drupal Cache Interface... Thats a little ways away. Got to get 1.0 out the door first.

subscribe

subscribe

subscribe

sub

Sweet Baby Ray's, this module would be nice to have in D7. Subscribe.

Give it a try; let me know what's broken
http://drupal.org/node/937552

subscribe

subscribe

Subscribing.

7.x branch seems to work well, with a few rough edges - I presume this issue won't be closed until an alpha is released? (Just opened #1045664: Breadcrumbs overlap secondary tabs... should we post bugs to this issue, or open up new issues?).

I was going to close it once I make the 7.x dev available on the project front page... which probably means an alpha release. I know the htaccess stuff could use some polish; besides this, what else is needing help?

In my preliminary testing (only one site so far), nothing... I'm going to expand to a couple other sites on a multisite install to make sure it's all working well.

I'm adding this comment to this thread to keep the 7.x issues together.

Using Boost with Panels in D7.x can result in a 500 Internal Server Error.

The patch given here for 6.x (http://drupal.org/node/928200) helped when using Boost in conjunction with a Panels/Ctools page. It doesn't look like that patch has made it into the 7.x version.

As well, it needs to be updated slightly because the key in $router_item has been renamed. Specifically, this bit of code needs to be inserted before $parts['menu_item'] = $router_item; in the _boost_get_menu_router() function.

  if ($router_item['include_file']) {
    require_once $router_item['include_file'];
  }  

Note that $router_item['file'] is now $router_item['include_file'] in D7.

Hope that helps someone!

Kendall
Invisible Threads :: http://invisiblethreads.com ::

Ok, so that makes it need to be set back to "needs work", since it's a regression from 6.x-1.x-dev - thanks for testing.

Hope folk don't mind me marking it such, so the necessary changes in #58 go in? =)

committed a patch for 7.x #928200: Call to undefined function page_manager_page_load()

Using the E= rule, I think there should be three folders, checked in this order: role, btype (browser type), asset.

The cheapest check to start or stop processing is by role: anonymous, authenticated, etc.

Then browser type for type of browser and version, such as ie6, firefox, dolphin (android browser), to setup headers via htaccess if needed. Simpler method initially is to make two folders, default or mobile. This would also make embedded images work better.

Finally asset type, like gzip, nogzipunspecifiedforthiscommenttype.

So combining the folders together, with a default folder of the document root being /var/www and the default configurable cache folder being boost, you have an example like: /var/www/boost/anon/android/gzip

Thoughts?

EDIT: Here's an abstracted example: RewriteCond %{DOCUMENT_ROOT}/%{ENV:boostpath}/%{ENV:role}/%{ENV:btype}/%{ENV:asset}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s

[E=boostpath:boost]
[E=role:anon]
[E=btype:android]
[E=asset:gzip]

EDIT2: Thinking about Varnish and ESI is a good idea at this point.
RewriteCond %{DOCUMENT_ROOT}/%{ENV:boostpath}/%{ENV:role}/%{ENV:ptype}/%{ENV:btype}/%{ENV:asset}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s

Ptype for proxy type. Varnish can store items in expensive memory, so that's a good decision point.

EDIT3: Stats would be great too... Making a patch for the rewrite portion doesn't seem difficult. Also at, http://www.example.com/#overlay=admin/config/development/performance/boo... ...the page could be setup to use vertical tabs since breadcrumbs can cover up the boost setting tabs.

EDIT4: ptype can also be for CDNs.

EDIT5: Mike's parallel module can also be used for ptype.

EDIT6: Having new tabs for the E rules can provide more granularity in control.

EDIT7: Site and language needs to be thought of, I can't think of anything else [url encoding/display problems, a big reason]:

RewriteCond %{DOCUMENT_ROOT}/%{ENV:boostpath}/%{ENV:site}/%{ENV:i18n}/%{ENV:role}/%{ENV:ptype}/%{ENV:btype}/%{ENV:asset}/%{REQUEST_URI}_%{QUERY_STRING}\.html -s

[E=boostpath:boost]
[E=site:example.org]
[E=i18n:en]
[E=ptype:varnish]
[E=role:premium_member]
[E=btype:safari]
[E=asset:js]

EDIT8: captcha management within role or asset directory.

gzip folder is getting removed (already is with the default config of boost) as having the .html.gz file next to the .html file makes nginx gzip integration easy.

Don't think asset separation (json, xml, html) is necessary. JS/CSS caching is no longer needed in 7 because css/js clear caches use drupal_delete_file_if_stale. All that's needed is to do is set the drupal_stale_file_threshold variable to be longer then cron + page cache lifetime.

ptype is pointless IMHO. parallel is a 6.x only module. CDN can now do everything parallel did.

Stats will be a different module. That's useful for other things besides boost; like varnish or squid.

That being said here is how I could see the cache dir structured.

%{DOCUMENT_ROOT}/cache/%{ENV:rand}/%{ENV:role}/%{ENV:i18n}/%{ENV:browser}/%{HTTP_HOST}%{REQUEST_URI}_%{QUERY_STRING}\.html -s

And the defaults

[E=rand:boost] #random 8 ascii char's to prevent directory guessing - Default is boost for easy setup.
[E=role:anonymous] #or authenticated 
[E=i18n:en] #site's default language code
[E=browser:all] #mobile would go in here

Due to multisite and the fact that the settings from one database can be different from another, we have to keep the defaults; removal of them isn't a good idea. rand will be figured out by the other boost installs via looking at the dir structure.

These 3 settings (role, i18n, browser) can then be set via htaccess rules. role will be handled by boost; each role will get a cookie which is md5(role name + salt); will need to come up with something smart for this; right now authenticated is the only type... likely use permissions for this. in order to use role one must set rand. Will need to come up with a method for changing the salt every X days to keep the cookie for that role a secret. Also need some JS to remove the boost role cookie if the session cookie is gone. Role is a big issue. Or authcache integration...

Thoughts on the above stuff? Remember less is more; unless I see a need for it, I don't need to spend time making it happen. Boost auth cache; better i18n; and mobile browser are all requests that are a good idea. Put the place holders in and develop the features later.

Yeah, I was thinking that some rough structure would be good to put in place to finish up for later. Contributed patches can come in with making some placeholders by the captain of the ship, but vertical tabs can come in earlier. I'll try and see if I can make that happen. For ptype, it comes to mind that delivery by nginx, java could cause some issues, and also it could be used by payloads for further processing depending on the destination, but d7 already has a lot of headaches out the way. I guess there's more to learn.

Edit: Redis or Membase can be used for session handling, with fallback to the db, also with the entitycache module, along with other forked codes. That's something I'm considering writing, to get knowledgeable in those fields. Anyway, time to get back to work. Thanks for the update.

Thought about this more

Move HTTP_HOST closer to the cache root. Will allow cache flushing by folder rename.

%{DOCUMENT_ROOT}/cache/%{ENV:rand}/%{HTTP_HOST}/%{ENV:role}/%{ENV:i18n}/%{ENV:browser}/%{REQUEST_URI}_%{QUERY_STRING}\.html -s

rand should be a 32 char random string.

[E=rand:boost]

Can I get a real example for the need for ptype? java or javascript?

Proxy type could be objects that are setup for 3rd party apis as well. One usage I can think of is for pdfs, where the html could be sent off to a 3rd party api. If the html is already in the folder, but the pdf is not, ptype routing logic could make the check to make a boosted html or not. So whatever's in a ptype section, the objects could be continuously deleted or subject to cron runs. Export RDF/sparql, etc. Setup delivery of items for java servers or for file conveyor. It's a bit of an interface section for non-native or special native server processing. It can be as simple as a box where it is originally left blank, but someone could put in php code there. There could be security implications, but if so, there's probably better ideas.

The rand idea I never considered, but it's a good security idea for authenticated users - it took me awhile to find out that
Options -Index gives me a little bit more security. Not user friendly at it's current location, but that's where it is most effective.

I took a look at mod_rewrite directives available - http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html

Another option is combining the types for easier management and folder traversal:

RewriteRule .* - [E=role_rand:role012345_rand012345]
RewriteRule .* - [E=i18n_browser:i18nCode_browsertype]

# Process 1
RewriteCond %{ENV:role_rand}

and

# Process 2
RewriteCond %{ENV:i18n_browser}

is an example. But this adds cognitive overhead into development.

Roles can be truncated to 5-10 letters, and i18n ISO 639-2 Codes make for easier parsing and legibility.

sorry I still don't see the advantage of have a ptype section. file extensions work great IMHO and one can define their own storage type and extension using hook_boost_storage_types (line 880 of 7.x boost.module). Here is the XML storage type.

  $types['text/xml'] = array(
    'title'           => t('XML'),
    'description'     => t('XML output, usually a feed'),
    'extension'       => 'xml',
    'enabled'         => FALSE,
    'gzip'            => TRUE,
    'lifetime_max'    => 3600,
    'lifetime_min'    => 0,
    'commment_start'  => '<!-- ',
    'commment_end'    => ' -->',
    'variants'        => array(
      'application/xml',
      'application/rss',
      'application/rss+xml',
    ),
  );

Define a new storage type and the correct htaccess rules will be generated for it. variants means that if drupal sends out content using one of these content types then it can be sent out using the parent type (text/xml) in this case. Adding support for PDFs and other things to boost should be trivial. Just make sure to have a unique extension.

The rationale is fair enough. I'm using Apache2 mpm-event, fastcgi socket, php5-fpm, so I was giving myself some wiggle room just in case because of the setup mentioned here needed a prepend.php file: http://blog.foaa.de/2010/11/php-apache-and-fastcgi-a-comprehensive-overview

Other than that, the d6 xsend module's idea of headers for private downloads comes to mind, and how xhprof required prepend/append files but this ain't my call, thanks. Those are my last thoughts on that matter.

Sounds like the d7 version of boost is shaping up nicely.

xsend for authenticated pages; that could get interesting. Reading up on it and it doesn't look like a good idea.

subscribe

Subscribe.

I am a newbie at this so it is likely that something basic has been missed. I've installed boost-7.x-1.x-dev.tar.gz from the Jan 27 version. In general, all has been working well.

However, when cron runs, the entire boost cache is always completely cleared, even non-expired pages.

In a debug environment I see that the hook boost_cron() is called which does only remove expired pages. This is just what I would have expected.

However, this call is followed later by a call to the hook boost_flush_caches() which flushes everything. I think that the two hooks are doing just what they should be doing. The problem is that the boost_flush_caches() is being called on all cron runs when it should not.

Is there something that I need to set elsewhere to prevent drupal from excecuting hook_flush_caches() during cron runs?

Setting category back to what it should be. This issue is for testing the D7 port.

Currently testing #42.

@David4514
That's a feature I haven't ported to 7.x yet... BTW it's good to hear those 2 hooks are working as they should. Sounds like Drupal core still likes to flush all caches on cron runs; so that needs to be accounted for. Luckily with 7.x I don't need a css/js cache like I did in 6.x.

Patch added in an ignore flush on cron setting. It will be a setting; question is does it really need a checkbox in the GUI. Default will be to ignore flushes from cron.

Other changes:
Path has changed to admin/config/system/boost
reworked some functions

http://drupal.org/cvs?commit=499092
Committed patch

Thanks for all of your work! Boost will be exactly what I need. I am brand new to Drupal and am stumbling around a little... a lot! With futher snooping what I find is:

The hook_flush_caches is being invoked from two places in D7 Core:

function drupal_flush_all_caches() (common.inc)
function system_cron() (system.module)

In both cases it appears that the expectations is that hook_flush_caches should now be returning table names to be used by the new cache system in D7 rather than to be performing the actual flush operation. Those names are later used to request the flushes to occur as part of the newer D7 cache system. Obviously that will have to be part of a future Boost 7.x-2.x!

In the meantime, your patch will do!

@mikeytown2 - do you think you could publish a 7.x-dev release on the home page, so more people could start playing around with it? It's already working well—but could use more testing before a beta/final release...

With the 02-13-2011 patch, two undefined constant errors are appearing on the Boost File System configuration page:

Notice: Use of undefined constant BOOST_PERMISSIONS_FILE - assumed 'BOOST_PERMISSIONS_FILE' in boost_admin_filesystem_settings() (line 35 of /var/www/gah/web/sites/all/modules/boost/boost.admin.filesystem.inc).
Notice: Use of undefined constant BOOST_PERMISSIONS_DIR - assumed 'BOOST_PERMISSIONS_DIR' in boost_admin_filesystem_settings() (line 41 of /var/www/gah/web/sites/all/modules/boost/boost.admin.filesystem.inc).

BOOST_PERMISSIONS_FILE & BOOST_PERMISSIONS_DIR are not needed; using cores new chmod function http://api.drupal.org/api/drupal/includes--file.inc/function/drupal_chmod/7

I'll update with a patch in about 4 hours; or if someone else wants to create the patch I'll commit it.

been thinking about #64. Instead of browser call it theme. Change i18n to i18n_geo Also change the order around of the 3 "variants". I think flushing the cache due to theme changes happen the most often so it should be higher in the directory hierarchy allowing for easier theme related cache flushes to happen.

%{DOCUMENT_ROOT}/cache/%{ENV:rand}/%{HTTP_HOST}/%{ENV:theme}/%{ENV:role}/%{ENV:i18n_geo}/%{REQUEST_URI}_%{QUERY_STRING}\.html -s

So the dir structure for a url like example.com/about-us would be /var/www/cache/boost/example.com/bartik/anonymous_user/none_none/about-us_.html.

I have zero experience with i18n sites so any insight into the best way to do it would be nice.

Choosing theme as a path variable could make that section more flexible, since it's a broader category based on that analysis - if it's inclusive of browser specifics in terms of taxonomy it sounds good. As for D7 i18n sites, you have to enable the Locale module (drush -y en locale), then go to example.com/admin/config/regional/language ...then add a language for testing (this generally requires an AA addition to your DNS server, and obviously a configuration addition to the web server). You can also click Configuration button, and then, under the Regional and language box, you'll see Languages.

Afterwards, choose the detection and selection tab, and it gives you a choice of the user interface based on:
URL, Session, User, Browser, or Default (the default site language). You can enable or disable, and also order the choices; for example: User first, Browser second, Session third, the others disabled.

Content selection is independent of the user interface options. This is useful for automatically selecting content. For example, a Frenchman at a French site can be served English content (with a machine translation button available) because the content may not have been translated yet, but can navigate with a French user interface. You have to "drush dl i18n" module, then enable the Internationalization module (drush -y en i18n). The content selection page is available at example.com/admin/config/regional/i18n ...so both modules available on the left side under the configuration button admin button, where the Multilingual settings link will appear in the Regional and Language box. There are five choices for content selection.

The Locale and i18n module should be the superset/originating modules for everything else. So this suggests at least two functions. That should help out a little, but also, looking into contributed modules can prevent refactoring down the road.

Edit: drush dl l10n_update && drush -y en l10n_update
That will allow you propagate user interface translations (to the database...) at example.com/admin/config/regional/translate/update

I noticed that recent boost has tabs. You're very productive. Thanks! =)

Last 2 things that needs to happen before I put this as a download link on the main page as a dev release:
- .htaccess patch button if server has write access to the drupal root .htaccess file.
- generate the .htaccess file in the cache folder.

Follow up to the cache folder .htaccess file
- Have a all in 1 generate option so this file isn't needed if desired
- httpd.conf version that uses < directory > for what would have gone in the cache dir.

Just saw this blog post and ouch. D7's DB layer is a lot slower... I need to step this up.
#1064212: Page caching performance has regressed by 30-40%

normal page cache; APC; minimal install.
D6 - 214.20 reqs/sec
D7 - 142.19 reqs/sec

Older thread: http://groups.drupal.org/node/61793

Applicable to MySQL as well, but if Drupal 7 is made to use persistent connections, it will throw an error because of this: http://php.net/manual/en/pdo.setattribute.php

PDO::ATTR_STATEMENT_CLASS: Set user-supplied statement class derived from PDOStatement. Cannot be used with persistent PDO instances. Requires array(string classname, array(mixed constructor_args)).

I wasn't able to dig in too far after that. Not sure if performance will get back to d6 levels or better with such changes though.

Edit: http://dealnews.com/developers/php-mysql.html

It appears that using PDO penalizes SELECT queries, which happens the majority of the time.

The prepared statements should help with writes if there is a persistent connection with PDO, so it's primarily about speeding up PDO SELECTs somehow.

Yeah, I'm going to be testing Boost on a few more (slightly higher traffic) sites in the next month or two, and I'm sure Boost's profile will grow quite a bit on shared hosting... I still think we're ready for, at a minimum, a -dev release to be posted to the project page, if not an alpha.

I really do think that will help get a bit more interest, and maybe bring in a few more patches for issues like those mentioned in #81...

.htaccess auto generation in the cache dir now happens. Look for it in the base_dir level.
cache/normal/example.com/.htaccess
Still haven't done auto patching if permissions are loose on the webroot .htaccess file (think FTP); but this isn't a show stopper for dev branch. Once it is generated I plan on putting this up on the front page.

patch file for anyone who cares:

Awesome! And I can see the point to auto-patching the .htaccess file, but in some ways, I think that it's almost better to require users to patch the file manually, if for no other reason than to help them understand that any content expiry/updating problems they might have should be approached on the Apache/filesystem level before looking into Drupal. I've found some people using Boost have confusion as to why the content they see (logged in) isn't the same as what an anonymous user sees...

Auto as in they do a form submit. So it's still a manual process in that sense. They don't have to ftp up their modified .htaccess file. It's similar to this #418302: Copy default.settings.php to settings.php during install IFF webserver owns files (FTP on shared hosting)

After enabling module, it completely replaced my main .htaccess file in my folder with drupal, so my site went down
step to reproduce: copy paste .htaccess file from fresh drupal

@TNmoxa
Can I get more information as to what happened in your case? What was the directory structure and what does the cache dir look like.

I think this will fix the issue reported by TNmoxa.
patch has been committed.

In regards to #78 I need to account for https - see this issue for an example of what can go wrong
#1066220: Image paths are being prefixed with HTTPS

@mikeytown2 - do you think you could mark this issue is fixed/closed, and start opening some separate issues (just so the S/N ratio dies down?).

opened up a new issue for the new file naming scheme.
#1070048: New folder structure
Marking this as fixed.

Changed title of issue to be more descriptive for subscribers.