Archives Calendar Widget doesn't work after Upgrade

Ready!

Done: ampmsi.com.ar

OK, you can set back to the previous version, Thanks!

The problem is that the css files were not updated. I think that it’s because of server caching.

I will fix it by including the pluign’s version in style enqueue.

server caching? The site is using W3 Total Cache and Cloudfront, but the problem is there even if I refresh those caches.
ok, I deactivated the plugin until you publish a fix to try.
Happy of being helpful.

I dont realy know why your css file is from the 0.4.7 version. The structure was changed in 0.9.9 and .cal-nav class does not exist anymore and it is present in the css file loaded on your page.

Interesting. But if I look into your CSS files, cal-nav class are defined everywhere within custom.css. Are you sure you have correctly deleted from this distribution?

Ooops, custom.css should not be there, I uploaded it by error!
Custom themes are edited with the new “theme editor” and are generated when you save changes in the editor. Those themes are named arw-theme1.css and arw-theme2.css (but named Custom 1 and Custom 2 in the settings).

The new update is comming today. In 1 or 2 hours. Hope it will not be more buggy ??

Interesting. Looks like CloudFront is not taking seriously the order of empty cache. I’ll do that manually and if successful, these two files should be the same:

https://ampmsi.com.ar/wp-content/plugins/archives-calendar-widget/themes/twentythirteen.css
and
https://cdn54642.ampmsi.com.ar/wp-content/plugins/archives-calendar-widget/themes/twentythirteen.css

Ever more interesting, this is not an issue because of Cloudfront. I upgraded the plugin in another site not using CloudFront, and the problem is still there. Look at the footer here:
https://gip-rrhh.com.ar/noticias/

I don have any styling problem on the link you provided.

However, the broken navigation problem is caused in most of cases by an unchecked option “Include jQuery library” in the settings. So I removed it in the update, jQuery will be always included by dependency.

ok… Is there any css file should I keep out of the cache?

With the 0.9.92 update the .css and .js files will be included with the version of the plugin :

<link rel='stylesheet' id='archives-cal-twentythirteen-css' href='https://localhost/wpdev/wp-content/plugins/arcw-dev/themes/twentythirteen.css?ver=0.9.92' type='text/css' media='all' />

So I think there wont be any problem with caching anymore. (I don’t know how the CloundFront works.)

mmm nope. Because CloudFront strips the parameters to cache only one version of the files. I think the best option is to exclude “/wp-content/plugins/arcw-dev/themes/” patterns from cache.

I don’t think that I would make a lot of changes to the existing themes after 0.9.92 update (maybe adding new ones).
But the arw-theme1.css and arw-theme2.css should not be in cache if you want to use custom themes.

and…. yes, it worked like a breeze.
The trick to add to your documentation is: when using W3 Total Cache, you need to exclude the following:

If W3TC is used with CloudFront, you have to add this to the Rejected Files textarea under the CDN section:
{plugins_dir}/archives-calendar-widget/themes/*

If W3TC is only using Page Caching, you have to add this to the “Never cache the following pages”:
/archives-calendar-widget/themes/*

And voila, you’ll now see your plugin working in both websites.