I am developing a style.css to use with wymeditor, but I guess the problem is potentially valid for all editors.

The .css file is set at admin/settings/wysiwyg/profile/4/edit (i.e. the wymeditor profile). Editor css is "Define CSS" and CSS path is the path to my stylesheet in my module folder.

As I am developing the css file to use with the editor, I often need to clear the cache to see changes. However, short of changing the file name, I cannot see any way to clear the cache. I tried the 'reload' browser button, I tried editing and saving again the afore mentioned settings, I go in and out of node edit mode, etc. but all to no avail: the new stylesheet does not take effect.

The only way I found to get the updated stylesheet to apply is to rename the file incrementally: style1.css, style2.css, etc. and adjust the settings accordingly. Then I do see the changes.

Where is the original file cached? How can I clear the cache?

CommentFileSizeAuthor
#26 wysiwyg-file-cache-828718-26.patch7.91 KBjonraedeke
#25 wysiwyg-file-cache-828718-25.patch8.68 KBBrightBold
#21 wysiwyg-file-cache-828718-21.patch8.65 KBcolinstillwell
#18 wysiwyg-file-cache-828718-18.patch8.73 KBdddbbb
#11 wysiwyg-file-cache-828718-11.patch8.14 KBtheunraveler
#9 wysiwyg-file-cache-828718-9.patch650 bytestheunraveler
#8 wysiwyg-file-cache-828718-8.patch712 bytestheunraveler
#7 wysiwyg-file-cache-828718-7.patch420 bytestheunraveler
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jennifer.chang’s picture

jennifer.chang CreditAttribution: jennifer.chang commented
Status: Active » Closed (fixed)

can't reproduce anymore. I don't know what I did wrong.

jennifer.chang’s picture

jennifer.chang CreditAttribution: jennifer.chang commented
Status: Closed (fixed) » Active

How strange!
When I use 5.css, I can go out of node edit mode and come back in and see the changes in the css.
when I use mymodulename.css, it's always old classes and old css definition showing.

I have copied the exact same content of 5.css to mymodulename.css and the problem is still the same.
I made sure that mymodulename.css is not output by my module.
Css pre-processing is set to OFF.

So now, I am developing with 5.css because strangely that file name works as expected, but not the other file.... Does using the module name matter?

I just tried with
mymodulename2.css . I edit it, refresh the node edit form (which breaks the wysiwyg editor, so I go out and come back in the node edit form, and I see the changes.
I do the same with mymodulename.css and I still get an old version of the file!

jennifer.chang’s picture

jennifer.chang CreditAttribution: jennifer.chang commented

And to be thorough, the only code in my module is this:

/**
 * Implementation of hook_init().
 */
function mymodulename_init() {
  // drupal_add_css(drupal_get_path('module', 'mymodulename') .'/mymodulename.css');
}

and note it's commented out, because I wanted to make sure it didn't interfere.

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented
Category: bug » support
Status: Active » Fixed

The stylesheet files aren't cached by Wysiwyg at all and since you've disabled "Optimize CSS", Drupal itself doesn't cache the files either.

Your browser caches the files and you'll need to clear its cache in order for it to use the updated version. Simply reloading the page will not do, but in some browsers like IE and FF you can press Ctrl+F5 to bypass the cache for a single request. However, I have found that cache is often not bypassed for files included by other documents loaded at the same time, like the one inside the editor's editing iframe. To get around this, I use Firebug's or Web Developer toolbar's option to disable the cache completely and always fetch files from the sever. (In Firebug it can be found if you click the "down arrow" on the "Net" tab, and in Web Developer toolbar it's below the "Disable" menu.) Other browsers have similar options or extensions which are really helpful when dealing with cache issues.

jennifer.chang’s picture

jennifer.chang CreditAttribution: jennifer.chang commented

Thank you for the detailed explanation and help. I am checking all this.
:)

Status: Fixed » Closed (fixed)

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

theunraveler’s picture

theunraveler CreditAttribution: theunraveler commented
Version: 6.x-2.x-dev » 7.x-2.x-dev
Status: Closed (fixed) » Needs review
FileSize
wysiwyg-file-cache-828718-7.patch420 bytes

However, I have found that cache is often not bypassed for files included by other documents loaded at the same time, like the one inside the editor's editing iframe.

Sorry to reopen this extremely old issue, but here is a patch for the 7.x-2.x branch that appends a hash of each CSS file to the URL included in the editor iframe. That way, when the file changes, the URL to the file will also change, thus busting the cache even if the file is included from within the iframe.

theunraveler’s picture

theunraveler CreditAttribution: theunraveler commented
FileSize
wysiwyg-file-cache-828718-8.patch712 bytes

Actually, I realized that the previous patch may have a performance impact, since the file hash would be calculated on each request. Here's another patch that uses Drupal's css_js_query_string variable to manage cache-busting. That way, the files will be re-downloaded on every Drupal cache clear.

theunraveler’s picture

theunraveler CreditAttribution: theunraveler commented
FileSize
wysiwyg-file-cache-828718-9.patch650 bytes

Sorry once again: my last patch was diffed from the patch before. Here's one that will apply cleanly to 7.x-2.x.

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

I don't mean to sound negative (and I'm away from home so I can't easily test and commit it yet anyway), but is this really that useful?
I'm just thinking about all the other files which get cached by the browser too (scripts). On the other hand, those are not changed as often as stylesheets...

theunraveler’s picture

theunraveler CreditAttribution: theunraveler commented
FileSize
wysiwyg-file-cache-828718-11.patch8.14 KB

I don't mean to sound negative (and I'm away from home so I can't easily test and commit it yet anyway), but is this really that useful? I'm just thinking about all the other files which get cached by the browser too (scripts). On the other hand, those are not changed as often as stylesheets...

I see what you mean, but I was running into lots of issues with CSS files specifically. In my particular use case, we were using Sass/Compass, and whenever an image sprite changed, the path to the file changed in the CSS, and we had no way of clearing these cached CSS files in the wysiwyg, so images actually weren't appearing. I can't think of anything similar that would happen with cached JS files as often as this happens.

Also, here is a patch that adds a %q token to external stylesheets that are included by the wysiwyg. That way, when defining external stylesheets, site builders can add the %q token to the path/URL to get cache-busting functionality. It is essentially the same as above, but applies to external CSS files as well.

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

Oh, that is a good point, and I like the cache-busting token! I'll take another look at this when I get home.

rosell.dk’s picture

rosell.dk CreditAttribution: rosell.dk commented

Drupal appends such cache-busting token to theme files automatically. The token only change when you empty the cache (admin/config/development/performance) - so there is performance hit there. Could you do the same? (edit: I see that the patch already does it "the Drupal way", by using the 'css_js_query_string' variable)

I also ran into trouble. In our project we use the option "Use theme css" in tinymce profile. We changed the style so body has background-color: black to get black borders. Now the background is black in tinymce, which means the customer can't see what he is writing :) So added a "body#tinymce {background-color:white} to our style.css and flushed cache in drupal. Customer still complains. I then discovered that "style.css" is loaded without appended cache-busting token. - That explains!

rosell.dk’s picture

rosell.dk CreditAttribution: rosell.dk commented

I see that the patch by theunraveler only patches the case where the user links to specific css.
To also add token when user selects "theme", the function wysiwyg_get_css() should be modified too (file: wysiwyg.module)

Here is my shot at it:

I changed this line:
$files[] = base_path() . $filepath;

to this:
$files[] = base_path() . $filepath . '?' . variable_get('css_js_query_string', '');

It works for me. I'm however not sure if $filepath in some circumstances have a "?" in it? If that is the case, I guess the fix would do damage.

mike503’s picture

mike503 CreditAttribution: mike503 commented

I did what is described in #14 as well - was coming here to submit a patch. That's all that is needed, is to force the wysiwyg styles to emulate standard theme behavior of adding on the css_js_query_string cache busting option.

Having an empty query string after won't hurt anything anyway, if that variable happens to be empty too. :)

mike503’s picture

mike503 CreditAttribution: mike503 commented

Looking at this, patch #11 is required (and slightly smarter than our approach), and #9 could be a nice bonus as well. Please merge. :)

mike503’s picture

mike503 CreditAttribution: mike503 commented
Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

patch #9 and #11 work well, RTBC as far as I'm concerned.

dddbbb’s picture

dddbbb CreditAttribution: dddbbb commented
FileSize
wysiwyg-file-cache-828718-18.patch8.73 KB

This patch is an attempted merge of #9 & #11 as suggested.

sheldonkreger’s picture

sheldonkreger CreditAttribution: sheldonkreger commented

Awesome, #18 applies to DEV branch as of today. #11 doesn't any more.

dddbbb’s picture

dddbbb CreditAttribution: dddbbb commented

So, can we get this in before dev fundamentally changes again again?

colinstillwell’s picture

colinstillwell CreditAttribution: colinstillwell commented
FileSize
wysiwyg-file-cache-828718-21.patch8.65 KB

This attached patch applies to commit "c1fee97857df06d4d1514427f8439330f16c86c6" as of today.

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD commented

Thanks for the reroll, will look at it before committing anything else affecting CSS.

Rob_Feature’s picture

Rob_Feature CreditAttribution: Rob_Feature commented

Just a 'me too' here....this really should be something included in the module as soon as possible. Developing a custom wysiwyg stylesheet is next to impossible otherwise :) Would love to see this committed.

dddbbb’s picture

dddbbb CreditAttribution: dddbbb commented
Category: Support request » Feature request

Just tried the patch in #21 again but with wysiwyg latest dev (7.x-2.2+75-dev - 2016-01-25) and it still works just fine.

RTBC++

BrightBold’s picture

BrightBold
she/her
Primary language English
Location Boston, MA
CreditAttribution: BrightBold commented
FileSize
wysiwyg-file-cache-828718-25.patch8.68 KB

The patch in #21 now fails with the latest dev. I think the attached fixes it.

jonraedeke’s picture

jonraedeke CreditAttribution: jonraedeke commented
FileSize
wysiwyg-file-cache-828718-26.patch7.91 KB

Another reroll without the openWYSIWYG include. It was removed in https://www.drupal.org/node/970892 .

  • TwoD committed d46d6dd on 6.x-2.x authored by theunraveler 
    - #828718 by theunraveler, danbohea, BrightBold, jonraedeke,...
  • TwoD committed 2192f88 on 7.x-2.x authored by theunraveler
    - #828718 by theunraveler, danbohea, BrightBold, jonraedeke,...
TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD as a volunteer commented
Status: Reviewed & tested by the community » Fixed

Thank you all for reporting, patching, rerolling, reviewing and testing. Sorry it took so long to get this committed. Having help keeping patches fresh and easy to apply really helps, especially when the changes are "isolated", easy to test/verify so I can do it even with just half an hour or less over between other things.

dddbbb’s picture

dddbbb CreditAttribution: dddbbb commented

Hooray! Thanks @TwoD for committing.

TwoD’s picture

TwoD
Primary language Swedish
Location Sweden
CreditAttribution: TwoD as a volunteer commented

Btw, beware that changes in #2289683: Select in-editor theme and get all stylesheets will overwrite some of the changes here, but I've ensured that the method used there to get the stylesheet filenames does ensure the querystring is intact. (Basically, we get the filenames after Core has alread added it, so that responsibility is is no longer ours.)

A side note though: We are currently not adding the query string to stylesheets loadded from editor plugin metadata. I see that as less of a problem though since you won't be changing them as often.

  • TwoD committed 507c503 on 7.x-2.x authored by Miles Ulrich 
    - #2829260 by Miles Ulrich: Fixed #828718 is generating 404 errors for...

Status: Fixed » Closed (fixed)

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