hey

is a drupal 7 port likely?
cacherouter is being split into several modules

Files: 
CommentFileSizeAuthor
#122 0001-Remove-Authcache.getValue-JavaScript-function.patch843 bytesznerol
#122 0002-Fix-_authcache_is_ajax-global-variable.patch1.6 KBznerol
#122 0003-Update-authcache-poll-stuff-for-drupal-7.patch3.63 KBznerol
#122 0004-Provide-support-for-tabs-and-local-tasks.patch3.98 KBznerol
#122 0005-Fix-blocks-cache-contains-render-array-not-markup.patch2.47 KBznerol
#122 0006-Fix-forums-for-drupal-7.patch4.09 KBznerol
#121 0001-Fix-comment-form-and-comment-edit-link-for-cached-pa.patch6.49 KBznerol
#120 0001-Do-not-leak-user-id-by-replacing-cache_uid-with-cach.patch5.21 KBznerol
#119 0001-Replace-monster-regex-copied-from-the-blocks-module-.patch3.21 KBznerol
#118 0001-Replace-monster-regex-copied-from-the-blocks-module-.patch3.19 KBznerol
#115 0001-Initialize-_authcache_info-within-authcache_init.patch1.01 KBznerol
#113 0002-Implement-hook_requirements.patch2.83 KBznerol
#112 0003-Use-_cache_get_object-instead-of-variable_get-to-det.patch1.55 KBznerol
#111 0001-No-need-to-list-files-in-info-if-none-of-them-includ.patch808 bytesznerol
#111 0002-Implement-hook_requirements.patch2.63 KBznerol
#111 0003-Use-_cache_get_object-instead-of-variable_get-to-det.patch1.55 KBznerol
#109 0001-Add-jquery.cookie-library.patch782 bytesznerol
#108 add-jquery-cookie-library.diff500 bytesznerol
#106 0001-Use-drupal_is_cli-to-check-whether-running-from-comm.patch1.71 KBznerol
#106 0002-Introduce-function-_authcache_debug_access-for-simpl.patch4.96 KBznerol
#106 0003-Remove-included-jQuery-cookie-plugin.patch1.6 KBznerol
#105 0001-Fix-unused-references-to-_authcache_debug_info.patch1.99 KBznerol
#95 fix-default-subtab.patch586 bytesznerol
#94 0001-Add-option-to-exclude-caching-of-admin-pages-based-o.patch2.27 KBznerol
#89 0001-Exclude-private-and-temporary-file-download-links-fr.patch1.29 KBznerol
#88 0001-Fix-generic-part-of-ajax-authcache.php_.patch3.85 KBznerol
#86 0001-Fix-site-wide-contact-form.patch2.29 KBznerol
#85 0001-Cleanup-authcache.inc-after-d7-migration.patch4.79 KBznerol
#32 authcache-7.x-1.x-dev.tar_.gz36.9 KBsimg
#31 authcache-7.x-1.x-dev.tar_.gz36.27 KBsimg
#30 authcache-7.x-1.x-dev.tar_.gz37.71 KBsimg

Comments

Yep, a Drupal 7 port will happen.

Thanks. Subscribing.

When? Drupal 7 release tomorrow.

Version:6.x-6.x-dev» 6.x-1.x-dev
Assigned:Unassigned» Jonah Ellison

Probably later this month.

Ok. thx.

For 7.x is there a good reason to have boost and authcache be different modules? We could combine them.

Title:drupal 7 portDrupal 7 port

Authcache and Boost are rather different modules... Authcache is on a different layer since it mainly just provides an Ajax interface and modifies HTML before placing into the cache bin (which could be anything, a database, memcached, APC, etc), while Boost provides a new caching engine for saving pages to disk.

Boost could serve to authenticated users. Right now I see boost having 3 cache variants for a wide array of sites: normal, auth, mobile. Thinking about this, boost/authcache should remain as separate modules. So the question is what can I do to make auth storage more accessible for you. I haven't built it, but I could see it being useful.

I'm searching for a cache solution to boost my small Drupal 7 site (blog, forum and pages).

Is it possible to speed up a Drupal website with authcache and use it with http://drupal.org/project/content_refresh to serve new contents immediate to the guests and members?

Subscribe

still not see the D7 branch yet..

subscribing

subscribing

subscribing

Title:Drupal 7 portAuthcache » Drupal 7 port

subscribe

subscribe

subscribing

Subscribing...

Any update here?

sub

sub

subscribing

subscribing

Is there something happening with this or has it been forgotten about? D7 is missing this kind of feature

subscribe

+1

+1

+1

+1

Please learn to login and press follow, instead of filling entire pages with "subscribe" and "+1".

StatusFileSize
new37.71 KB

Hi All,
Just thought I would alert you to the fact that I have started work on a D7 port of this module.

Current status is that the module installs OK, most of the UI works (adding "rules" doesn't yet work) and I've fixed most of the issues reported by the coder module (and some other D7 compatibility issues).

I *think* authcache D7 is currently writing pages to the cache (I'm using memcached) but unfortunately not reading from the cache when generating pages. Caching seems to have changed significantly from D6 -> D7 so I need to port includes/authcache.inc to the D7 approach.

Plenty of work still to do, but I *need* this module to work so I'm going to be focused on making this happen over the next few days / weeks.

I've attached my code so far. Don't expect it to solve any performance problems but you're welcome to have a play with it. Any insight experienced authcache users / developers are able to offer will no doubt be useful (and certainly appreciated !)

StatusFileSize
new36.27 KB

just an update.

made excellent progress yesterday. have authenticated pages being served from cache and page generation times down from about 950ms to 5ms on my dev system :).

one minor (but significant) problem remains, and that is the data being written to the cache is blank :/

The problem is the following code in authcache.helpers.inc -> function _authcache_shutdown_save_page().

  // Get buffered HTML
  $buffer = ob_get_contents();

ob_get_contents() returns empty and therefore an empty $buffer is currently being written to cache.

I will no doubt get to the bottom of this, but any input / suggestions / feedback welcome.

Latest code attached.

StatusFileSize
new36.9 KB

Ok, this one is pretty damn close. The javascript personalisation bit isn't yet working and you need to make a small core hack to make it work (to get around the ob_get_contents problem described above) though I hope to work out a way to remove that requirement.

I'm currently getting approximately 750 authenticated requests a second from my development machine (quad core desktop running Apache with 8GB ram) (ie average of 1.3 milliseconds per request!)

There was some error during the plugin enabling process on line 23:
authcache_user_login('login', $user, $user);

And after enabling the plugin in settings.php there were two errors in admin/config/development/performance/authcache

So I couldn't get it working and when I tried to access the website itself there was just an ampty page with Array.

Just a feedback :)

Please continue your work, very many people are waiting for this module on D7, you would be a hero for us all.

>There was some error during the plugin enabling process on line 23:

the exact error would be very useful :)

Also worth running clear cache and logging out / in

Could you consider creating a sandbox project on d.o or on github or similar to track the changes you're making and also make it easier for users to pull the latest changes (rather than have to download and unpack/overwrite tarball contents) ?

Thanks for working on this!!

Error during the enabling process:

Fatal error: Only variables can be passed by reference in /htdocs/sites/all/modules/authcache/authcache.install on line 23
on admin/modules/list/confirm

@mig5 Sandbox project created http://drupal.org/sandbox/simg/1419168

@anybodywise: latest code (now in sandbox) should fix the error on #36. alternatively simply change line 23 of authcache.install from

authcache_user_login('login', $user, $user);

to
authcache_user_login($user, $user);

Notice: Undefined index: authcache_is_db in require_once() (line 112 of /htdocs/sites/all/modules/authcache/authcache.inc).
Notice: Undefined index: authcache_handler in require_once() (line 118 of /htdocs/sites/all/modules/authcache/authcache.inc).

while having the latest memcache (7.x-1.0) and this in settings.php:

$conf['cache_backends'][] = 'sites/all/modules/memcache/memcache.inc';
$conf['cache_backends'][] = 'sites/all/modules/authcache/authcache.inc';
$conf['cache_default_class'] = 'MemCacheDrupal';
$conf['memcache_key_prefix'] = 'myprefix';

But it really works. I have a very highly loaded page with a lot of bocks, modules and stuff, and it loads quite slow for auth users, enabling this module made the page load as fast as if it was anonymous user.

I can't wait to enable it for production.

fixed issues in #38. also fixed the javascript error.
in *theory* the module now "works" :)

one issue that has become apparent in porting the module is that there is currently a "security consideration". Authcache potentially makes all cached content available to anyone who has the appropriate cache_key cookie set. This makes it somewhat easy for a "curious" person to fake the appropriate cookie value and gain access to "private" content from the cache.

This means that authcache is currently only suitable if you want to speed up sites with roles used for "personalising" the content. Authcache currently only provides very "casual" protection to private information so if you want to keep certain content totally protected you will need to wait for a subsequent release of this module.

There is a solution to this problem which requires further work and most likely a small performance penalty. Will keep you informed.

latest version doesn't need memcache - though it's still a configurable option

I've created a new FileCache.inc which stores cache data in the local files folder.

As I suspected, FileCache is significantly faster than MemCache.

I'm now getting 2.54ms per request with FileCache compared to 5.4ms with MemCache.
FileCache also handling ~1400 authenticated requests per second.

Best of all, it's simple to set up and you can run it on *shared hosting* :)

Check out the README.txt - hopefully good instructions

can I use this in conjunction with the memcache and file cache modules in Drupal 7.

@SocialNicheGuru - yes. all explained in the README.txt

(wish I'd known about the FileCache module, that might have saved me a days work yesterday :/ )

Update: Now that I know about the FileCache module, I would recommend people go with that (run your own benchmarks though). The FileCache.inc that I've included with Authcache isn't complete (can't clear cache for example) and I don't see any point in maintaining / fixing it if there is already an existing FileCache module.

I posted some comparative performance benchmarks if you're interested:

http://groups.drupal.org/node/206138

Thanks for sharing the results simg. Looking good so far.

I suggest we can open a D7 branch and release the development version now, then more users can find and test it, especially users not using git.

>I suggest we can open a D7 branch

I'm not the maintainer for this module so I can't do this. I've contacted the maintainer (Jonah Ellison) but not heard anything back yet.

I'm going to try and get the module onto a production site this week which will give me a bit more confidence that's there's nothing major that I've forgotten.

(The "security consideration" in #40 would be nice to solve)

Assigned:Jonah Ellison» simg

Hi Simon, thanks for the great work on the D7 port and apologies for the late reply. I've made you co-maintainer so you can put it up and people can start creating separate issues (I also sent you an email with a few questions/notes).

Security issues shouldn't be a concern since each cached page needs to be exactly the same for each user within a role. Personalized content should never be cached on the page level (admins can exclude URLs). The Ajax phase can also be used to retrieve any sensitive content, since it validates against the session. Finally, users only have access to the cache key when they log-in. (Anonymous users cannot guess the key for different roles.)

Hi Jonah, thanks for the email :)

The "security consideration" is as follows (not sure if this applies to D6 version, but this is how D7 version currently works):

1. Authenticated user requests a page with cache key of say "e38ce7" which corresponds to groups "admin" and "sales".
2. Drupal bootstrap calls Authcache which gets a cache hit and delivers the page from the cache.

At this point, the user has not actually been authenticated to check they are who they say they are.

This means that anyone who could work out that creating a cookie with an authcache_key of e38ce7 will have view access to all content on the site viewable to the "admin" and "sales" groups.

This may (or may not) be tolerable in order to get fast response times.

What also needs to happen (I think as an optional extra) is for session data to be loaded (from a fast cache) to check the users session is valid. This will obviously incur some kind of additional overhead.

But the user needs to aquire the cache key first, and the only way to do this is if they can log-in as a user that has an "admin" and "sales" role, or steal the user's cookie (if someone can do that, then there are much bigger problems).

Validating the session for each page requires connecting to the database and performing queries, so there is a performance hit. But if you want to include an option to do this, that's fine.

>or steal the user's cookie (if someone can do that, then there are much bigger problems).

all it needs is for a knowledgeable person to take a very quick look at someones (ie their boss?) browser settings (ie cookies), get the cache key (easy to remember) and add that to their own browser (or other information retrieval software). trivially easy to do and this gives the "curious" person access to view all the information belonging to the groups of "the boss". A very real security consideration for some types of website.

edit: this may be a bad example since the same curious person could simply steal their bosses session cookie (if they had a bit more time and pencil / paper). still can't help feeling that a "site/group wide" unchanging authentication cookie (which is what the authcache_key basically is) would be a security issue for many sites.

>Validating the session for each page requires connecting to the database and performing queries, so there is a performance hit.

My suggestion is to store session state in a fast cache like FileCache or Memcache*. That way there will be no need to connect to the database. There will of course still be a performance hit but it won't be anything like as bad as hitting the database. There should be an option to enable or disable "session validation" so that users can trade reduced security (if they don't need it) for increased speed.

*Apparently work is afoot elsewhere to enable this (I don't currently know why it requires additional development to enable this)

Yes, what I meant is that if someone wants to steal cookies, they would target the Drupal session cookie, which would give them full access to someone's account. This type of security concern is beyond the scope of this module.

If a site has private content, admins should just not cache the pages or roles. Caching pages works best when hundreds of users have access to the exact same content.

Sessions can be stored in cached, though the dilemma is that cache is meant to be temporary, while sessions are not (e.g. if cache is lost, it needs to be rebuilt/regenerated easily), so some type of database fallback is usually needed. This is a good read: http://dormando.livejournal.com/495593.html

hi all, you might notice there is now a 7.x-1.x-dev release available.

it's early days. it meets my needs (and I'll be putting it on a production site very soon) but it requires testing and I would *expect* you to find errors and functionality that I haven't ported across properly (I haven't tested the javascript functionality at all for example).

report problems. you should get a pretty quick fix :)

Version:6.x-1.x-dev» 7.x-1.x-dev

@simg Thanks for porting this module!

I'd like to give this module a try. Alas, I can't, because the documentation is so bad. Usually I just read the code, but even the code is extremely bad: lots of commented out logic makes it very confusing, and makes the entire module seem like one massive hack.

So … the instructions say I should add the following lines to my settings.php file:

  $conf['cache_backends'][] = 'sites/all/modules/filecache/filecache.inc';
  $conf['cache_backends'][] = 'sites/all/modules/authcache/authcache.inc';
  $conf['cache_class_cache_page'] = 'DrupalFileCache';

But that doesn't stop it from complaining about a missing cache_inc configuration. Should I add that too? Or is it a leftover from D6? Why is it not documented?
Don't get me wrong, I do appreciate the time you've put into this, but right now, it's near impossible to figure out what works properly and what is a hack, and consequently: how one can configure this module to work reliably. If you can help me get started, I'll be able to contribute back, but until then, I won't be able to even try this module properly…

@Wim

latest code now has "debug" comments removed so you should find it easier to read.
you also should find the "missing cache_inc" message is now fixed. (pretty sure this check is no longer needed in D7 but not entirely sure)

if you have any specific feedback about the documentation rather than "it's bad" that would be appreciated :)

Apologies I've been away from Authcache for a while but am now back on the case.

The latest dev version contains quite a few fixes and improvements.

1. Previously, authcache was hard coded to not cache for the admin user (ie uid 1). This has caught a number of people out (including me). If authcache doesn't appear to work for you, this is most likely the reason. I've removed this hard coded restriction in favour of using the role based enabling functionality.

2. I've improved the Authcache debug feature so that a) it works all (more?) of the time and b) if the page is not cacheable for any reason, the reason is shown is the debug "dialog".

3. A few minor documentation changes to fill in a few gaps and make it easier for beginners

I have some free time over the next few days, so I should be able to respond to questions / issues and we can push Authcache D7 forward. Bear in mind, I'm somewhat new to Authcache, I haven't even used Authcache D6 so I'm reliant on feedback from the community (that's you!) to tell me what doesn't work. Constructive criticism very welcome :)

FWIW, I did a lot of work on authcache last night. Lots of bugs found / fixed and the latest dev version now has *much* better and more consistent debugging info which should help.

Just for info, I'm now running Authcache on a production site (albeit only my personal blog). It installed very smoothly (core hack still needed, sadly) with Filecache. So far, everything works including forms and Rulesets for disabling caching on specific paths.

Javacript call back isn't yet tested, but I'm going to implement this on my blog in the next few days to test it. Watch this space.

I'm currently getting cached pages generated for all users in just less than 15ms on a very cheap (but good) shared server :)

just removed the need for the core hack :)

Just started testing new 7.1x Authcache from yesterday. I have NOT installed the core hack (as you have recommended in the last release), but on every page I get the following error.

"Trying to get property of non-object in authcache_preprocess() (line 498 of /var/www/mydomain/sites/all/modules/authcache/authcache.module." Yes, the error appears with or without APC code.

It seems to be working, including a combined APC + Filecache + Authcache config other than the error. Did I do something wrong on the install? Also here is a sample of settings.php with the APC running before the filecache and authcache.

$conf['cache_backends'] = array('sites/all/modules/apc/drupal_apc_cache.inc');
$conf['cache_default_class'] = 'DrupalAPCCache';
$conf['page_cache_without_database'] = TRUE;
$conf['page_cache_invoke_hooks'] = FALSE;

$conf['cache_backends'][] = 'sites/all/modules/filecache/filecache.inc';
$conf['cache_backends'][] = 'sites/all/modules/authcache/authcache.inc';
$conf['cache_class_cache_page'] = 'DrupalFileCache';

Glad you are working on this and now with Admin user 1 to boot.

Vidchannel:
That error is now fixed in the latest version. (*Amazed* that you get this error and I've never seen it before :) )

It's nothing you've done wrong !

If you don't want to download the entire module, just change line 498 to:
if (isset($variables['user']) && $variables['user']->uid) {

(Also, glad you've got it working :) )

I have the latest version installed and that is my line 498. Will try it on another site and see if it throws the same error.

Thank you.

It seems that error (see above) is related to one Drupal 7 theme with Delta + Omega + Context. On 3 different sites and 2 different servers running FileCache, APC or Memcached (running each independently, not in aggregate); always the same result. It throws the error as soon as you activate the module.

I have also tested with two other responsive Drupal 7 sites without the Delta + Omega combo and it runs like butta. Awesome speed even with admin enabled.

IMHO, this is really imperative for the growth of Drupal. Really important for any serious site with actual users. Kudos to Simon for the latest push (simg).

Vidi: Could you change your line 498 to:

if (isset($variables['user']) && is_object($variables['user']) && $variables['user']->uid) {

Does that fix your problem?

If it works, I'm not sure if Authcache should attempt to work around some problem that probably exists in Delta / Omega but at least we'll know.

YES. You are the man. That fixed the error.

My working settings.php runs Authcache, APC and then FileCache. Also running Boost (for anonymous only, of course).

There is probably some duplication here, but since Boost only runs in anonymous mode, I think I need FileCache to substitute for "authed" users. Looking good.

Big thanks to simg for moving this forward.

A quick test on a sandbox site last night showed a 2000% performance improvement (on my dev laptop - core2duo 8GB RAM w memcache)!!

I'll have a closer look tonight, but at this stage I'm pumped!

If you are using Administration Menu (as many admins are) please turn off the option below.

[ ] Cache menu in client-side browser

Failure to do so will result in many funny looking garbage characters at the end of every page and strange errors.

Luckily It's a simple fix for you. (I wasted days figuring out the culprit). Here is shortcut to the menu.

admin/config/administration/admin_menu

A new dev version is available which amongst other things has the database fallback caching working.

I'm currently getting pages generated in 2.5ms from the default database cache handler and 1.5ms using FileCache :)

authcache now uses the same (or similar) code to drupal anonymous caching. (ie calls drupal_server_page_from_cache) this has some handy effects like:

* solving this #1693368: can't set Page compression when caching for anonymous users is enabled problem
* re-enabling the checkbox to enable or disable page compression
* greatly simplifying authcache.inc
* authcache should be more compatible with external caches

just fixed a long standing issue (in the d7 version) which I'd previously had trouble replicating where the anonymous user was getting content for the previously logged in authenticated user.

Worth noting the existence of the Authcache Actions module.

Creates an action to clear the cache based on rules.

(I'd like to see it have an action that would build the cache for a page allowing for a simple yet powerful cache warmer)

I'm yet to use this. But big thanks to you simg. God bless.

I've being having this error: PDOException: SQLSTATE[42000] [1203] User vesanige_badman already has more than 'max_user_connections' active connections in lock_may_be_available() (line 167 of /home2/mydir/public_html/sitefolder/includes/lock.inc).

On a site I just uploaded two days ago. After many hours of searching, saw a post that recommended this module, memcache, and boost.

When I saw there was full release for D7, i fainted. But seeing you've been hard at work on this since January, I can't be less relieved. I already believe it should help resolve my current challenge.

And then we think about supporting this further cause I read somewhere someone with even a dedicated server having similar error. So it's not entirelyt a shared host illness.

Thanks Christian,

I lieu of actually getting paid, people saying thank you is very encouraging....

Personally, I would say use FileCache rather than memcache. My experiences is that filecache is easier to set up and actually faster than memcache. Memcache potentially becomes more useful in multi-server set ups.

It's also worth bearing in mind that Authcache is not a magic bullet. There is still the problem of managing the cache (ie clearing it and "warming it" at appropriate times). Takes some understanding if you're new to caching.

I'm planning to give this module a go very soon. It's great reading the progress you're making simg! Great work!

I'll report back any issues I experience. FYI... I'm not a performance guy so I'll see what my normal non-performance-guy stuff can pull out. :-)

Hello Simon,

Contacted my host (shared server) said their serve don't support memcached. Good I checked to see your reply was going to begin a search for another host (ignorant me).

I'm new to caching but would like to understand the inner workings, can you lead me to any resource, drupal based or not.

With FileCache will I still need to worry about: "There is still the problem of managing the cache (ie clearing it and "warming it" at appropriate times)."

Thanks

Hello once again. I tried installing FileCache on local machine (WAMP stack) but the install instruction is not very clear to me (maybe for my ignorance again).

After installing the module, I pasted this lines into the settings.php file ($conf['cache_backends'] = array('sites/all/modules/filecache/filecache.inc'); $conf['cache_default_class'] = 'DrupalFileCache';) and saved after clearing cache. When I viewed I got this error message:

( ! ) Fatal error: require_once() [function.require]: Failed opening required 'C:\wamp\www\bellsauce/sites/all/modules/filecache/filecache.inc' (include_path='.;C:\php\pear') in C:\wamp\www\bellsauce\includes\bootstrap.inc on line 2297 Call Stack # Time Memory Function Location 1 0.0016 673376 {main}( ) ..\index.php:0 2 0.0414 1447464 drupal_bootstrap( ) ..\index.php:20 3 0.0479 1461296 _drupal_bootstrap_page_cache( ) ..\bootstrap.inc:2175

What could be missing?

@ojchris37.

WAMP uses "\" as it's "path separator" rather than the "/" as on LAMP, so you should change your config line to:

$conf['cache_backends'] = array('sites\all\modules\filecache\filecache.inc');

You might also find the suggestions on Issue Queue etiquette useful for future posts (in particular, the points on not hijacking issues). (They will help you get better, quicker answers to your questions)

Hey simg! I'm sorry for my bad or wrong manners, and mostly for perhaps taking your recom for granted. Lesson taken.

Tried your recom, still no joy, I have opened a new case: http://drupal.org/node/1840160.

Thanks

Hi simg!

Thank you very much for your effort, I would like to know if there´s a estimate for when will be published a D7 production ready version. Sorry to bother you with this, but I have a client with very restrictive rules about what modules we can/can´t use, so this is a important issue for my group.

I already tested in my site, applying the latest patches, and everything worked, so it´s only a matter of have a official "approval" by the community saying this module is ready to use.

Thank you guys again for your great work, I expect to contribute soon.

I've had another request for a 1.0 release elsewhere. Fact is I don't really push the module that hard myself (I just made the D7 port), so I haven't personally tested all the options / use cases and rely on "the community" to test it and feedback any issues.

Generally speaking, it seems to work and the bug reports have dropped to almost nothing so on that basis I guess I can probably make 1.0 release.

I'll try and do this in the next few days (really!) when I have some free time.

Hi simg,

Thanks for your reply. I don´t want to let you do everything alone, so I´m a volunteer to help fix things, document, review, everything what will be necessary to make things happen. Please, let me know if you need any assistance. I know you are a very experienced PHP/Drupal developer, and I´m only starting now, but I´ll be happy to help with even the boring tasks.

Thanks again!

1.0 release now available.

many thanks to znerol (http://drupal.org/user/63999) for assistance :)

Encouraged by the recent "community activity", I've added a neat feature to the 7.x-1.x.dev branch.

That is, the ability to have custom authcache keys. This might be useful for example if you have a lot of roles on your site but you don't want to cache different content for each of them. It would also be useful if you wanted to cache different content for different devices eg mobile / desktop etc.

It's very easy and powerful.

To use, you just need to set a configuration variable in settings.php to point to the name of a function you want to use and then write that function to generate your cache keys.

eg:

$conf['cache_backends'][] = 'sites/all/modules/contrib/filecache/filecache.inc';
$conf['cache_backends'][] = 'sites/all/modules/contrib/authcache/authcache.inc';
$conf['cache_default_class'] = 'DrupalFileCache';
$conf['cache_class_cache_page'] = 'DrupalFileCache';
$conf['authcache_key_generator'] = 'authcache_samecontentforall';
// Sample key generator functions
function authcache_samecontentforall($user) {
  if ($user->uid != 1) {
    return '';// all non-admin users get the same content
  } else {
    return substr(md5(drupal_get_private_key()), 0, 6); //except "admin" who has a hard to guess cache key
  }
}
function authcache_mobilecache($user) {
  $device_group = writeyourownbrowsersniffer(); // you need to write your own browser sniffer
  $keys = implode('.', array_keys($account->roles));
  return substr(md5($device_group . $keys . drupal_get_private_key()), 0, 6);
}

You can put your functions anywhere you like. I'm lazy, so I've left mine in settings.php but you could include them via a module or whatever.

Using this technique is very powerful in that you can cache separate content for different groups of users based on any criteria you like. You could for example use this for caching content separately for mobile users for example (or any combination of roles / devices / whatever) as per the above example.

If you don't set an authcache_key_generator, authcache will use it's default setting and carry on working exactly as before.

Enjoy :)

I'm now in the process of cleaning up some d6 remains in the current code. I'm beginning with authcache.inc. The patch contains the following changes:

  1. Clarify header documentation
  2. Replace references to DRUPAL_BOOTSTRAP_EARLY_PAGE_CACHE with new name DRUPAL_BOOTSTRAP_PAGE_CACHE.
  3. Remove special handling when memcache is in use.
  4. Use drupal_bootstrap to initialize database.
  5. Add X-Drupal-Cache HTTP headers in the spirit of 7 core.

Item 3 should also resolve #1851388: Authcahce with memcache: Fatal error: Call to undefined function lock_acquire(). because I was able to remove the call to variable_initialize which actually calls lock_acquire

StatusFileSize
new2.29 KB

The form_id of the site-wide contact from has changed. Also the contact form does not use a special token anymore. Therefore we can drop support for that special case in _authcache_form_token_id from ajax/authcache.php.

patch(es) applied to dev.

keep 'em coming, thx :)

  1. Adapt headerdoc comments.
  2. Remove _authcache_shutdown function from ajax handler. XHProf does not interfere with non-HTML responses anymore.
  3. Remove call to variable_initialize. Variables are already present in DRUPAL_BOOTSTRAP_SESSION
  4. Use drupal 7 version of drupal_to_js

Regarding item 2, see #1485190: XHProf link breaks JSON responses as well as the referenced commit.

Another one, trivial but sort of important. Exclude files served from the private file directory from being mangled by authcache. E.g. if you allow storing HTML pages as file attachments, authcache should not cache them - more important it should not inject the JSON into the attachment.

Edit: Another change sneaked into this patch: Display a default sub-tab for general configuration settings such that one can navigate easily between generic configuration, page caching settings and block settings in the authcache configuration.

thx znerol.

applied the part of the patch #89 to do with files.

didn't apply the part about the sub-tabs as there were some others patches posted a while ago in this area that I applied yesterday. Could be that you don't have the latest dev code? Maybe you could get the latest code and check whether it already does what you're suggesting?

Regarding being up-to-date: I have troubles rebasing my git working branch onto your 7.x-1.x branch. Actually that's because there are both, a tag as well as a branch named 7.x-1.x. Please delete the tag 7.x-1.x from the repository:

git push origin :7.x-1.x

Details see: http://stackoverflow.com/questions/5480258/how-to-delete-a-remote-git-tag

Regarding #89: Perhaps you could also throw out filefield/* pattern. That one comes from the D6-only filefields module.

>Please delete the tag 7.x-1.x from the repository:

I thought I already had, but I used

git push origin :refs/tags/7.x-1.x

I thought git push origin :7.x-1.x would delete the branch?

Filefield/* removed in dev.

I thought I already had, but I used

git push origin :refs/tags/7.x-1.x

That's perfect, sorry for the noise. I will have to cleanup my working copy.

Add an option to exclude admin-pages from authcache. If this option is enabled for a given ruleset, requests matching path_is_admin are not cached.

StatusFileSize
new586 bytes

Bringing the subtab issue up again from #89. The current administrative interface adds top-level tabs for "Performance" and "Authcache". That is what I'd expect.

However under "Authcache" only two sub-tabs are added ("Page caching settings" and "Blocks") despite the fact that there are actually three pages of configuration forms. Because there is no MENU_DEFAULT_LOCAL_TASK on the sub-tab level, there is no easy way to navigate back to the generic settings from "Blocks" or "Page caching settings". By adding a MENU_DEFAULT_LOCAL_TASK to this level, the problem is solved.

I suggest putting together another release, especially because 7.x-1.0 suffers from #1881982: _authcache_node_history -> PHP Fatal error: Class name must be a valid object or a string in includes/common.inc on line 7749 and #1881998: New comments do not show up.

I'd like to work on some more issues, especially bringing back gzip compression and if possible extract the debug stuff into a separate module, such that it can be disabled on production systems. Also I'd like to implement a cleaner way for adding the JSON stuff to the page (Probably via drupal_add_js and settings. That would free us from content-type inspection and stuff like that. But all those things will take time and some discussion. The issues mentioned above which are fixed now in dev should IMHO go into a release soon.

#94 why is this any different / better (other than being slightly prettier) than the existing path based exclusion?

Because of hook_admin_paths. All sorts of modules implement that hook already.

Edit: Probably I should add, that this option is not intended to replace the existing list. There still are non-admin pages no one will want to cache (i assume) like e.g. /user.

patch in #95 applied, thx.

#96 pretty sure the gzip compression is working.

it's just that because authcache uses drupal_serve_page_from_cache() it's no longer sending the "authcache_compression" cookie to tell the debug dialog what is going on. (For now, I've just disabled the line in the debug dialog)

any reason you can see why there shouldn't be a 1.1 release *now* ?

#98. excellent then. patch applied.

I'm all for a release now.

Regarding gzip: You are right, gzip compression works.

#84 is great, but not working for anonymous in the 7.x-1.0-dev

Sorry no time to make a patch

1. in authcache.helpers =>

function _authcache_key ($account) {
   if (!$account->uid) {  // <= has to be move after the authcache_key_generator check otherwise anonymous are ignored
       return '';
  }
.....

2. in authcache.inc

if ($authcache_keygen = variable_get('authcache_key_generator', FALSE))
   $key = (isset($_COOKIE['authcache']) && $_COOKIE['authcache']) ? $_COOKIE['authcache'] : $authcache_keygen();
else
   $key = (isset($_COOKIE['authcache']) && $_COOKIE['authcache']) ? $_COOKIE['authcache'] : '';

3. no ui found to specify variable_get('authcache_key_generator', FALSE)

With those changes I was able to generate different cache depending on visitor geographical location ! Just Perfect .
Thanks to simg !

#102. good catch. added to dev (and the 1.1 release)

the reason for the lack of ui is that the authcache_key_generator config has to go into settings.php because the database connection is generally not available at the time authcache does it's thing.

7-1.1 released.

anyone wanting (or willing) to contribute documentation would be very welcome :)

Seems like $_authcache_debug_info<code> was dropped in favor of <code>$_authcache_info during the D7 conversion. However in some spots the old variable is still assigned. This patch converts all occurences of $_authcache_debug_info to $_authcache_info

Another serie of code improvements:

  • Use drupal_is_cli function to check whether running from command line.
  • Simplify access check for the debug function.
  • Remove included jQuery.cookie plugin. It is shipped with Drupal 7.

Status:Active» Needs review

StatusFileSize
new500 bytes

Oops, forgot to actually load drupals built-in jquery cookie library. Patch attached.

StatusFileSize
new782 bytes

Sorry, ignore 108. That was against the wrong branch.

cool stuff Z.

busy ... but will take a look at applying these over the weekend :)

Some other minor things:

  • Only files containing classes or interfaces need to be listed in the info-file.
  • Implement hook_requirements in order to enhance feedback when authcache is not configured properly
  • Instead of looking up the cache-class used for the cache_page bin using variable_get('cache_class_cache_page'), we simply can retrieve it using get_class(_cache_get_object('cache_page')). If the admin decides that every bin should live in one cache-class, she might just want to specify $conf['cache_default_class'].

Replacement for the hook_requirements patch. Drush will simply refuse to enable the module if requirement severity is set to error during the install phase. Therefore we only set severity to error on runtime. During other phases severity is set to warning.

StatusFileSize
new2.83 KB

Wrong patch in #112, sorry. Correct one here.

Thanks Lorenz, your efforts are seriously appreciated :)

patches applied to my local copy, but now getting a couple of errors.

1. In javascript console: Uncaught TypeError: Cannot read property 'debug_users' of null authcache.js:350

2. Warning: array_merge(): Argument #1 is not an array in _authcache_shutdown_save_page() (line 256 of /var/aegir/platforms/drupal-7/sites/all/modules/contrib/authcache/authcache.helpers.inc).
Warning: array_merge_recursive(): Argument #1 is not an array in _authcache_invoke_hook() (line 400 of /var/aegir/platforms/drupal-7/sites/all/modules/contrib/authcache/authcache.helpers.inc).

I suspect the two errors are related. Error 2 happens when the page needs to be generated (ie a cache miss). Error 1 happens when 2 doesn't.

1. In javascript console: Uncaught TypeError: Cannot read property 'debug_users' of null authcache.js:350

That happens when Authcache.info is not around.

Warning: array_merge(): Argument #1 is not an array in _authcache_shutdown_save_page()

Also seen that in another issue. I had that flashing up once but was not able to track it down. Can you reproduce it reliably?

Patch attached which moves initialization of _authcache_info back into hook_init.

patch in #115 fixed both errors in #114

:)

patches applied to dev, thx

Ok, there is another one (I keep posting the minor patches here, while I'm working on major things over at #1890564: Get rid of authcache footer JSON in favor of Drupal.settings). There is a monstrous regular expression used for matching the path-rules against the aliased path of the current page. I've compared those expressions byte-by-byte to the ones from drupal_match_path and they're identical. My guess is that this regex are debris from when drupal_match_path did only exist buried deep in the blocks.module (see #183690: drupal_path_match() utility function).

Also extracted the non-html content-types to a constant wrapping a function call around it so someone can add a variable_get and an UI if here should be need for it. It is now rather clear how this part of the code works :)

Updated patch from #118, preg_split need the PREG_SPLIT_NO_EMPTY flag.

Instead of leaking the uid into cached pages, we may better store a session-bound value which does not reveal user data. This is exactly what drupal_get_token is for. Therefore I recommend to use a token instead of the uid in order to detect if the user looking at the page also was the one triggering the last cache-build.

Seems that comment-form and comment-edit-link logic was not ported completely to Drupal 7. Changed various things in this patch:

  • Remove hook_link_alter and hook_preprocess_comment_folded, these are Drupal 6 only.
  • Remove theme-registry hack and associated theme_authcache_comment_view
  • Add authcache_form_comment_form_alter because we cannot handle comment forms in generic hook_form_alter (comment_form is the base form id, the actual form-id is something involving the content type etc.)
  • Add hook_comment_view_alter and implement the link-altering business there
  • Adapt JavaScript

  • Remove Authcache.getValue JavaScript function
  • Fix _authcache_is_ajax global variable
  • Update authcache poll stuff for drupal 7
  • Provide support for tabs and local-tasks
  • Fix blocks: cache contains render array, not markup.
  • Fix forums for drupal 7

Some remarks: Poll and forums is not perfect. That's mainly because the signaling for browser-side caching (max_age) is not implemented correctly at the moment.

Regarding #120. We could get away with just removing cache_uid and cache_token respectively. That variable only exists for an edge-case check when flagging new comments as well as in the ajax phase when loading local tasks.

Applied everything except #120. I now would like to concentrate fully on 7.x-2.x.

@simg: I propose to release a final 7.x-1.2. Any other things we should include?

just had a very quick skim over the 7.2-dev code. excellent work znerol, a big improvement :)

totally agree that 7.2 is the way forward. can't think of anything that should be added for a final 7.12 release.

my only reservation is using that the "ace" prefix for sub-modules is potentially a little confusing. my personal preference would be for (say) authcache_ajax rather than aceajax, however, I could easily live with this and it's totally your decision. it doesn't help that in the UK "ace" is a slightly uncool way of saying "fabulous" ... :)

my only reservation is using that the "ace" prefix for sub-modules is potentially a little confusing. my personal preference would be for (say) authcache_ajax rather than aceajax, however, I could easily live with this and it's totally your decision. it doesn't help that in the UK "ace" is a slightly uncool way of saying "fabulous" ... :)

I'm totally open for another prefix. However I'd prefer to have a short one and if possible one without an underscore (see #367355: Module names should not contain an underscore(_) for some reasons). In the case of authcache submodules I see some potential for function name vs hook-implementation conflicts.

How about auc (authenticated user caching)?

it's simply your choice. I certainly wouldn't bother changing to "auc", maybe authcache can make "ace" cool again :) ?

there are however countless modules / sub modules that use underscores in their name and include the name of the parent module.

a list of the submodule prefixes in use in the modules I currently use:

  • backup_migrate_
  • block_
  • commerce_
  • context_
  • field_
  • imce_
  • menu_
  • media_
  • node_
  • path_
  • pathauto_
  • search_
  • simplenews_
  • taxonomy_
  • variable_
  • views_
  • wysiwyg_

any architecture that supported namespaces would include authcache_ in the name of any submodules.

Authcache would be the exception by not following this convention.

Great work on all of this! Awesome to see this module progressing.

As far as the underscores go, it's simply a best practice to avoid potential namespace conflicts. The potential is probably remote at best so I wouldn't worry about it.

Status:Needs review» Fixed

#127 is addressed in 2.x-7.x. I settled with the authcache_ prefix. Thanks for the input.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.