Clearing CSS Cache (http://static.ning.com)

[Charles Coleman]

Hi there,

I'm developing my own widget and created 2 css stylesheets for the widget:
xn_resourses/widgets/WIDGETNAME/css/component.css
xn_resourses/widgets/WIDGETNAME/css/module.css

I made some changes to the initial component.css that aren't updating. It keeps calling the
https://static.ning.com/xn/css?host=http%3A%2F%2NETWORK_URL&href=%2Fxn_resources%2Fwidgets%2FWIDGET%2Fcss%2Fcomponent.css";

How can I reset the cache on https://static.ning.com/?

Thanks!

[Charles Coleman]

Thanks Atonitis.

But what I meant was the css file itself isn't updating,

[Charles Coleman]

The change I made wasn't due to an error, I simply wanted the change the look of my custom widget's page.

If I download the page (html source, and css), change the css of the component.css section it displays fine. I've uploaded the new change to the site.

The thing is if I go to
http://static.ning.com/xn/css?host=http%3A%2F%2NETWORK_URL&href=%2Fxn_resources%2Fwidgets%2FWIDGET%2Fcss%2Fcomponent.css
the old css file still displays, not the updated one.

The above mentioned file is created from
xn_resourses/widgets/WIDGET/css/component.css
The way I understand it this is done for improved speed. But now I can't get it to recreated the static.ning.com file.

So even though I changed the css file on my side, the change hasn't been taken through to the css file that is called in the browser.

[Derrick O.]

Hi Charles,

Try logging into your network as the Network Creator and go to:

http://YOURNETWORKNAME.ning.com/lib/scripts/invalidateCache.php

Cheers!
Derrick

[Charles Coleman]

Thanks for the suggestion Derrick, but it didn't help.

I got the message that the cache was invalidated but it doesn't invalidate the css files on http://static.ning.com.

The version of Ning I'm working on is from mid/late Feb, if that makes any difference.

[Marcio Camurati]

Hi,

I have the same problem and found this post.

Anyone have any solution for it? Another question how much time is need to Ning remove this cache?

Regards.

[Ernie H.]

Hi Charles -- after talking with some developers, they suggested that you do the following as you have a version of your source code:

in /lib/XG_Version.php, try bumping up the XG_Version::$revision variable. That should re-cache everything properly.

Thanks, Ernie

[Charles Coleman]

Thanks Ernie, but still no luck.

Maybe I'm misunderstanding you. What do you mean by bumping up the XG_Version::$revision variable?

What I did was modify the following line from:
protected static $revision = '$Revision: 3066 $'; /*1202797057*/
to:
protected static $revision = '$Revision: 3067 $'; /*1202797057*/

Is that what you meant, or am I misunderstanding?

Thanks, Charles

[Martin]

Hey Charles (and everyone else),

I'm still having a hell of a time with this myself but might have come up with what seems like a workaround.

First, I was surprised to discover that right off the bat, Ning will take (for example) a css declaration you've snuck into /widgets/index/index/templates/embed/header.php and rewrite it into an @import statement that goes through static.ning.com. I mean it makes sense from a caching standpoint, but certainly it's going to stymie us as developers trying to test out our own custom code. The whole thing of updating the revision # hasn't worked for me either, although even if it did, this doesn't seem like a very efficient way to do development either.

The one thing I've found that SEEMS to work is tossing a nonsense query string onto the end of your CSS declaration. So something like this:

< link rel="stylesheet" type="text/css" href="/hcss/global.css?i=foo" />

seems to be ignored by Ning's cache-o-matron. Once the changes are stable and ready to go, I'm thinking I can just remove this extra query string and it will proceed to cache it as usual.

Ernie, does this seem logical? Is there anything a little less hacky that can be done here?

Oh and thanks to the whole Ning team for a really sweet platform overall.

[Ernie H.]

Hi Martin! While technically it's a bug, I've confirmed that adding a parameter to the query does get ignored by cache. Of course, the i=foo gets cached so you can always hack it by adding something dynamic each time.

Again, it's not ideal. We've filed a bug against this to see if there's a way to make this easier for developers that want to go in directly to their CSS (as opposed to a non-developer who elects to change their CSS through the WYSIWYG interfaces.)

Thanks! -Ernie

[Martin]

Hey Ernie,

Thanks for the quick response. Just to check, when you're talking about the css getting cached, you're referring to just each user's browser caching that url, correct? At least based on what I'm seeing, adding a query string at least seems to keep this particular CSS link tag clear of being rewritten as a static.ning.com @import statement.

But if this is a bug that we'd be exploiting, I guess maybe it's not worth relying on for now? Or is this something that you think your engineers won't be changing soon so we can at least use for now?

[Charles Coleman]

Thanks Martin!

That worked perfectly. I added an extra query string to the css declaration and my site updated with the newest css.

I can now continue with my customizations without worrying about my css code!

[Erik Oberhausen]

Wish any of these methods could work for me. :(
I have a css page I'm setting up to create dropdowns, and it's starting to come in, but any changes I make are getting ignored. Even more bizarre, I stripped out the link reference to the css page completely, removed the css file and no sign of it is in the source code, but my old dropdown css is still getting rendered. Tried invalidating cached as well as moving the version number as described above and adding the nonsense css reference. No dice...

Any other methods out there, so I could move forward would be apreciated.