Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
hey
is a drupal 7 port likely?
cacherouter is being split into several modules
Comments
Comment #1
Jonah Ellison CreditAttribution: Jonah Ellison commentedYep, a Drupal 7 port will happen.
Comment #2
ramper CreditAttribution: ramper commentedThanks. Subscribing.
Comment #3
vitok-dupe CreditAttribution: vitok-dupe commentedWhen? Drupal 7 release tomorrow.
Comment #4
Jonah Ellison CreditAttribution: Jonah Ellison commentedProbably later this month.
Comment #5
vitok-dupe CreditAttribution: vitok-dupe commentedOk. thx.
Comment #6
mikeytown2 CreditAttribution: mikeytown2 commentedFor 7.x is there a good reason to have boost and authcache be different modules? We could combine them.
Comment #7
Jonah Ellison CreditAttribution: Jonah Ellison commentedAuthcache 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.
Comment #8
mikeytown2 CreditAttribution: mikeytown2 commentedBoost 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.
Comment #9
JohnnyX CreditAttribution: JohnnyX commentedI'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
Comment #10
rogical CreditAttribution: rogical commentedstill not see the D7 branch yet..
Comment #11
RAFA3L CreditAttribution: RAFA3L commentedsubscribing
Comment #12
chriz001 CreditAttribution: chriz001 commentedsubscribing
Comment #13
W32 CreditAttribution: W32 commentedsubscribing
Comment #14
momper CreditAttribution: momper commentedsubscribe
Comment #15
vedariy CreditAttribution: vedariy commentedsubscribe
Comment #16
nurmuhammad CreditAttribution: nurmuhammad commentedsubscribing
Comment #17
Fidelix CreditAttribution: Fidelix commentedSubscribing...
Comment #18
JohnnyX CreditAttribution: JohnnyX commentedAny update here?
Comment #19
Docc CreditAttribution: Docc commentedsub
Comment #20
Kiphaas7 CreditAttribution: Kiphaas7 commentedsub
Comment #21
Anonymous (not verified) CreditAttribution: Anonymous commentedsubscribing
Comment #22
Toxid CreditAttribution: Toxid commentedsubscribing
Comment #23
Adam Clarey CreditAttribution: Adam Clarey commentedIs there something happening with this or has it been forgotten about? D7 is missing this kind of feature
Comment #24
bgilhome CreditAttribution: bgilhome commentedsubscribe
Comment #25
drnikki CreditAttribution: drnikki commented+1
Comment #26
Coupon Code Swap CreditAttribution: Coupon Code Swap commented+1
Comment #27
drupalninja99 CreditAttribution: drupalninja99 commented+1
Comment #28
x_tra06 CreditAttribution: x_tra06 commented+1
Comment #29
KoCo CreditAttribution: KoCo commentedPlease learn to login and press follow, instead of filling entire pages with "subscribe" and "+1".
Comment #30
simg CreditAttribution: simg commentedHi 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 !)
Comment #31
simg CreditAttribution: simg commentedjust 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().
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.
Comment #32
simg CreditAttribution: simg commentedOk, 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!)
Comment #33
anybodywise CreditAttribution: anybodywise commentedThere 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.
Comment #34
simg CreditAttribution: simg commented>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
Comment #35
Anonymous (not verified) CreditAttribution: Anonymous commentedCould 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!!
Comment #36
anybodywise CreditAttribution: anybodywise commentedError during the enabling process:
Comment #37
simg CreditAttribution: simg commented@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
to
Comment #38
anybodywise CreditAttribution: anybodywise commentedwhile having the latest memcache (7.x-1.0) and this in settings.php:
Comment #39
anybodywise CreditAttribution: anybodywise commentedBut 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.
Comment #40
simg CreditAttribution: simg commentedfixed 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.
Comment #41
simg CreditAttribution: simg commentedlatest 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
Comment #42
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedcan I use this in conjunction with the memcache and file cache modules in Drupal 7.
Comment #43
simg CreditAttribution: simg commented@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 :/ )
Comment #44
simg CreditAttribution: simg commentedUpdate: 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.
Comment #45
simg CreditAttribution: simg commentedI posted some comparative performance benchmarks if you're interested:
http://groups.drupal.org/node/206138
Comment #46
Coupon Code Swap CreditAttribution: Coupon Code Swap commentedThanks for sharing the results simg. Looking good so far.
Comment #47
rogical CreditAttribution: rogical commentedI 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.
Comment #48
simg CreditAttribution: simg commented>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)
Comment #49
Jonah Ellison CreditAttribution: Jonah Ellison commentedHi 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.)
Comment #50
simg CreditAttribution: simg commentedHi 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.
Comment #51
Jonah Ellison CreditAttribution: Jonah Ellison commentedBut 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.
Comment #52
simg CreditAttribution: simg commented>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)
Comment #53
Jonah Ellison CreditAttribution: Jonah Ellison commentedYes, 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
Comment #54
simg CreditAttribution: simg commentedhi 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 :)
Comment #55
Wim Leers@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:
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…
Comment #56
simg CreditAttribution: simg commented@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 :)
Comment #57
simg CreditAttribution: simg commentedApologies 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 :)
Comment #58
simg CreditAttribution: simg commentedFWIW, 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.
Comment #59
simg CreditAttribution: simg commentedJust 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 :)
Comment #60
simg CreditAttribution: simg commentedjust removed the need for the core hack :)
Comment #61
vidichannel CreditAttribution: vidichannel commentedJust 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.
Comment #62
simg CreditAttribution: simg commentedVidchannel:
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 :) )
Comment #63
vidichannel CreditAttribution: vidichannel commentedI 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.
Comment #64
vidichannel CreditAttribution: vidichannel commentedIt 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).
Comment #65
simg CreditAttribution: simg commentedVidi: 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.
Comment #66
vidichannel CreditAttribution: vidichannel commentedYES. 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.
Comment #67
tripper54 CreditAttribution: tripper54 commentedBig 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!
Comment #68
vidichannel CreditAttribution: vidichannel commentedIf 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
Comment #69
simg CreditAttribution: simg commentedA 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 :)
Comment #70
simg CreditAttribution: simg commentedauthcache 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
Comment #71
simg CreditAttribution: simg commentedjust 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.
Comment #72
simg CreditAttribution: simg commentedWorth 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)
Comment #73
ojchris CreditAttribution: ojchris commentedI'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.
Comment #74
simg CreditAttribution: simg commentedThanks 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.
Comment #75
caschbre CreditAttribution: caschbre commentedI'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. :-)
Comment #76
ojchris CreditAttribution: ojchris commentedHello 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
Comment #77
ojchris CreditAttribution: ojchris commentedHello 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:
What could be missing?
Comment #78
simg CreditAttribution: simg commented@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)
Comment #79
ojchris CreditAttribution: ojchris commentedHey 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
Comment #80
fbdo CreditAttribution: fbdo commentedHi 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.
Comment #81
simg CreditAttribution: simg commentedI'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.
Comment #82
fbdo CreditAttribution: fbdo commentedHi 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!
Comment #83
simg CreditAttribution: simg commented1.0 release now available.
many thanks to znerol (http://drupal.org/user/63999) for assistance :)
Comment #84
simg CreditAttribution: simg commentedEncouraged 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:
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 :)
Comment #85
znerol CreditAttribution: znerol commentedI'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: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 callslock_acquire
Comment #86
znerol CreditAttribution: znerol commentedThe
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
fromajax/authcache.php
.Comment #87
simg CreditAttribution: simg commentedpatch(es) applied to dev.
keep 'em coming, thx :)
Comment #88
znerol CreditAttribution: znerol commented_authcache_shutdown
function from ajax handler.XHProf
does not interfere with non-HTML responses anymore.variable_initialize
. Variables are already present inDRUPAL_BOOTSTRAP_SESSION
drupal_to_js
Regarding item 2, see #1485190: XHProf link breaks JSON responses as well as the referenced commit.
Comment #89
znerol CreditAttribution: znerol commentedAnother 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.
Comment #90
simg CreditAttribution: simg commentedthx 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?
Comment #91
znerol CreditAttribution: znerol commentedRegarding 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:
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.Comment #92
simg CreditAttribution: simg commented>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.
Comment #93
znerol CreditAttribution: znerol commentedThat's perfect, sorry for the noise. I will have to cleanup my working copy.
Comment #94
znerol CreditAttribution: znerol commentedAdd 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.
Comment #95
znerol CreditAttribution: znerol commentedBringing 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 aMENU_DEFAULT_LOCAL_TASK
to this level, the problem is solved.Comment #96
znerol CreditAttribution: znerol commentedI 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.
Comment #97
simg CreditAttribution: simg commented#94 why is this any different / better (other than being slightly prettier) than the existing path based exclusion?
Comment #98
znerol CreditAttribution: znerol commentedBecause 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.
Comment #99
simg CreditAttribution: simg commentedpatch 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* ?
Comment #100
simg CreditAttribution: simg commented#98. excellent then. patch applied.
Comment #101
znerol CreditAttribution: znerol commentedI'm all for a release now.
Regarding gzip: You are right, gzip compression works.
Comment #102
mkalbere CreditAttribution: mkalbere commented#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 =>
2. in authcache.inc
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 !
Comment #103
simg CreditAttribution: simg commented#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.
Comment #104
simg CreditAttribution: simg commented7-1.1 released.
anyone wanting (or willing) to contribute documentation would be very welcome :)
Comment #105
znerol CreditAttribution: znerol commentedSeems 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
Comment #106
znerol CreditAttribution: znerol commentedAnother serie of code improvements:
drupal_is_cli
function to check whether running from command line.Comment #107
znerol CreditAttribution: znerol commentedComment #108
znerol CreditAttribution: znerol commentedOops, forgot to actually load drupals built-in jquery cookie library. Patch attached.
Comment #109
znerol CreditAttribution: znerol commentedSorry, ignore 108. That was against the wrong branch.
Comment #110
simg CreditAttribution: simg commentedcool stuff Z.
busy ... but will take a look at applying these over the weekend :)
Comment #111
znerol CreditAttribution: znerol commentedSome other minor things:
hook_requirements
in order to enhance feedback when authcache is not configured properlyget_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']
.Comment #112
znerol CreditAttribution: znerol commentedReplacement 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.
Comment #113
znerol CreditAttribution: znerol commentedWrong patch in #112, sorry. Correct one here.
Comment #114
simg CreditAttribution: simg commentedThanks 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.
Comment #115
znerol CreditAttribution: znerol commentedThat happens when
Authcache.info
is not around.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 intohook_init
.Comment #116
simg CreditAttribution: simg commentedpatch in #115 fixed both errors in #114
:)
Comment #117
simg CreditAttribution: simg commentedpatches applied to dev, thx
Comment #118
znerol CreditAttribution: znerol commentedOk, 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 :)
Comment #119
znerol CreditAttribution: znerol commentedUpdated patch from #118,
preg_split
need thePREG_SPLIT_NO_EMPTY
flag.Comment #120
znerol CreditAttribution: znerol commentedInstead 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.
Comment #121
znerol CreditAttribution: znerol commentedSeems that comment-form and comment-edit-link logic was not ported completely to Drupal 7. Changed various things in this patch:
hook_link_alter
andhook_preprocess_comment_folded
, these are Drupal 6 only.theme_authcache_comment_view
authcache_form_comment_form_alter
because we cannot handle comment forms in generichook_form_alter
(comment_form is the base form id, the actual form-id is something involving the content type etc.)hook_comment_view_alter
and implement the link-altering business thereComment #122
znerol CreditAttribution: znerol commented_authcache_is_ajax
global variableSome 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
andcache_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.Comment #123
znerol CreditAttribution: znerol commentedApplied 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?
Comment #124
simg CreditAttribution: simg commentedjust 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" ... :)
Comment #125
znerol CreditAttribution: znerol commentedI'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)?Comment #126
simg CreditAttribution: simg commentedit'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:
any architecture that supported namespaces would include authcache_ in the name of any submodules.
Authcache would be the exception by not following this convention.
Comment #127
caschbre CreditAttribution: caschbre commentedGreat 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.
Comment #128
znerol CreditAttribution: znerol commented#127 is addressed in 2.x-7.x. I settled with the
authcache_
prefix. Thanks for the input.