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.
As reported http://drupal.ru/node/28903#comment-154286
21:41:10 FIREFOX.EXE
drupal.ru/node/28903
Рекламное объявление по ключевому слову Блокировка рекламы //english: ad2- blocked by pattern
/files/js/ad2d12fe46d75382d87261e798307998.js (*/ad2*)
So quickfix for D7 and D6 versions
Comment | File | Size | Author |
---|---|---|---|
#21 | prefix_cache_filename_D6.patch | 1.52 KB | andypost |
#20 | drupal-prefix-cache-filename-452704-20.patch | 1.49 KB | webchick |
#18 | prefix_cache_filename.patch | 1.52 KB | andypost |
#13 | prefix_cache_filename_D6.patch | 1.52 KB | andypost |
#13 | prefix_cache_filename.patch | 1.52 KB | andypost |
Comments
Comment #1
brianV CreditAttribution: brianV commentedGood idea - RTBC.
While I hate the fact that we more or less have to obey the naming conventions ABP allows us, ABP is too prevalent among Firefox users to ignore... Last week, I had to rename several dozen images on a client's site from 'adjoinment-.....jpg' to something else, because the 'ad' at the beginning triggered ABP, and users were complaining they couldn't see the pictures...
Comment #2
andypostIn my case files was blocked by corporate firewall so near 70 users lost some js-functionality
Comment #3
catchSeems like this should require the javascript cache to be cleared - an empty hook_update_N() would do this since hitting update.php does that anyway.
Also we need some documentation to explain why this is being added, otherwise it could get taken out just as easily as cruft. Seems like a tiny change to avoid a very annoying issue so that's good.
Comment #4
andypostReroll against current HEAD now with comment (please correct me my english is not good enough)
Is hook_update_N required? Maybe commit this with another update
Comment #5
brianV CreditAttribution: brianV commentedLooks good to me, but I will allow catch to determine RTBC, since he had the concerns.
Comment #6
brianV CreditAttribution: brianV commentedah, I see what catch means. Andy, because we are changing the naming conventions for the .js files, we need to ensure that all the old ones are removed.
A hook_update_N() function would force the JS cache to be cleared.
Comment #7
andypostToday in irc
[16:37] catch: andypost: we don't need a system_update for D7, so for that it just needs one line of docs.
empty hook is not good so I dont know what to do...
Comment #8
brianV CreditAttribution: brianV commentedIt's written in the docs that update.php should be run every time you upgrade Drupal. Given that update.php also flushes all the caches, it looks like everything should be fine, provided the user follows the upgrade documentation.
Of course, if none of the other changes between the previous release and the release this bug is included in implement a hook_update_N(), then the user may see that there are no updates, and back out. In that case, I would suggest we include the hook anyways so that the user will be guaranteed to see an update to system.module.
I would suggest doing something like:
Edit: Ignore the link filter messing up the URL in the comment....
Comment #9
catchSo if you run update.php the javascript cache gets cleared anyway, given this I don't think we need an empty update - it'll never get run if people don't visit update.php anyway.
There should be a space before 'Prefix', also we're not preventing ad-blocking, we're preventing our script being caught by those rules.
Something like
// Prefix filename to prevent blocking by firewalls which reject scripts starting with "ad*".
maybe?
Comment #10
andypostSo rename to extend this rule to compressed css
Modified comment and reroll against current HEAD
Comment #11
chx CreditAttribution: chx commentedWhile the D7 version does not require an update, I am fairly sure D6 does. Do you want to rely on people reading and obeying documentation? Then this must be news to you as well: sorry, there is no Santa Claus :p
Comment #12
andypostSuppose if this patch will be combined with #215080: Performance: change {system}.type: alter table system modify column type VARCHAR(32); so no _update_N is needed for D6
Comment #13
andypostagainst current HEAD and D6
Comment #14
catchThe issue with the update is this - if people visit update.php, it'll get fixed anyway. If they don't it won't. If we include an empty update, will that encourage people to hit update.php? Maybe it will via hook_requirements() but I dunno.
Comment #15
webchickReading through this, I think I would advocate the empty hook_update_N(). This will at least cause the status page to scream at them which otherwise it would not. This only needs to be added to the D6 version, cos people will definitely hit update.php for a D6 => D7 upgrade. ;)
Comment #16
webchickOh, but btw, I think you need to return array(); in the "empty" function or you'll get errors. I could be wrong. Needs testing.
Comment #17
webchickI'm sorry; I misread this patch. andypost set me straight on IRC.
I thought that what was going to happen is that initially 4a54s565as6546a56sas.css would be created and then, once Drupal was moved to version 6.13 (or whatever), it would start looking for css_4a54s565as6546a56sas.css and die in a horrible way.
Instead, what's actually going to happen is both 4a54s565as6546a56sas.css AND css_4a54s565as6546a56sas.css will exist, until the next cache_clear_all(). That seems reasonable, and will prevent being forced to rebuild the cache when it's not strictly required.
Comment #18
andypostSo here patch for current HEAD
For D6 suppose there's no need to rebuild cache because prefixing will happen ONLY before write to a new file (case when
So only when css or js files changes cache will update but only for js css
#17 cache rebuild is optional - agree exactly! no need update function for D6 (patch is the same)
Comment #19
sirkitree CreditAttribution: sirkitree commentedPatch applies and applied desired results. I'm not behind a firewall today to verify that this has any effect in that environment (never heard of this happening before today) but I definitely am getting the js_ and css_ prefixed files. Also the old ones are definitely cleared out after a cache clearing from ./admin/settings/performance
Comment #20
webchickAwesome! What an obscure little bug. I wrapped the comments at 80 characters and committed to HEAD.
Moving down to 6.x for consideration. Here's the patch I committed, which looks like it needs a quick re-roll.
Comment #21
andypostHere reroll D7 for D6 so need review
Comment #22
webchickNice! Even got the concatenation spacing change. :)
The only change between my patch and the existing one was the comment wrapping, so marking back to RTBC.
Comment #23
Gábor HojtsyThanks, committed to Drupal 6. Agreed, that rebuilding of the cache will happen sometime anyway, and the new files will just get created without the old ones being removed when people update without running update.php. Their bad.