johnflufin

Awesome, thanks Pothi.

Also, I just remembered where I was checking for the “.gzip” extension… the W3TC “min” cache directory. Looks like the CSS min cache is named correctly (default.include.819aac.css.gzip) but the page cache file names look odd. They’re named “_index.html_gzip”.

Is this right? If so why is it “_gzip” instead of “.gzip”?

Pothi – Thanks for the GTMetrix tip

GTMetrix scored 100 on “Enable gzip compression”. Interestingly YSlow via GTMetrix also scored 100 on “Compress components with gzip” and 84 overall despite my previous YSlow test via Firefox + Firebug + YSlow (F on “Compress components with gzip” and 78 overall score). Weird. This makes me wonder if this is a browser issue (Firefox).

In any case, shouldn’t there be a “.gzip” extension on gzipped files? Maybe I’m misunderstanding of how GZIP works.

Thoughts?

Are you using “Auto” Minify mode? (check W3TC General Settings in the Minify section) If so, try disabling Minify and clearing W3TC cache to see if this fixes Thickbox. If Thickbox is fixed, try “Manual” Minify mode.

Auto Minify combines all javascript files it finds into one file. Some scripts won’t work as intended when combined.

Manual Minify allows you to choose which CSS and JS files to combine.

I recommend starting from scratch and deleting all W3TC files. Especially if you’ve been having problems. It can’t hurt anyway.

In my experience, W3TC does a pretty good job of cleaning up after itself when you use the “Deactivate” function followed by the “Delete” function on the plugins page. Doing this should remove all W3TC rules, files and folders except the W3TC config file in the wp-content folder.

Just tested with YSlow and it reports that the CSS and JS files are not GZIP compressed. The W3TC GZIP settings appear to be enabled. What am I doing wrong?

Sorry, dismiss my post. I just noticed the new “Show Dashboard To Admin” setting defaults to yes.

@mozakdesign

Try clearing your browser cache and making sure TMCE Adv and WP are up to date. Otherwise I’m sure there’s more than one way for this problem to occur (not WLCMS).

Good to hear. Thanks.

Awesome. Thanks!

Note that Hans in this thread has also confirmed this.

Upon further testing, I discovered that the latest version of the White Label CMS plugin is preventing the editor-style.css file from loading. Disabling WLCMS allows editor-style.css to load. I have posted this issue in the WLCMS forum.

Whether this is related to the latest WP upgrade I can’t say but since I’m also having other issues with the latest WLCMS, I’d have to say that it’s the culprit. However I’m sure it’s possible other plugins could cause the same issue.

BINGO! Looks like the latest version of White Label CMS (1.4.X) is the culprit. Guess I’ll take it up with them.

Doing some more testing. Looks like it’s plugin related. Just trying to narrow it down. Will report back later.

Same problem here using TMCE Adv 3.4.5 and WP 3.3.X. editor-style.css is not being loaded as evident in the edit page source. After some investigating this could be related to the latest WP 3.3.x upgrades…

• Disabling TinyMCE Adv plugin does not fix
• Another site running WP 3.2.1 loads editor-style.css just fine. This site also uses the same plugins although some have not been updated recently so there could be a conflict with a plugin update.

I can’t be sure but I’m guessing this problem is related to WP 3.3.X upgrades or a plugin conflict.

Did some testing. Any combination of menu hiding that includes hiding the Posts menu seems to cause editors to go to their Profile page upon login.

However I also noticed other wonky behavior…

• Clicking the WLCMS “Reset” button results in some menus being hidden despite all the menus being reset to unchecked. Clicking “Save Changes” seems to actually apply the reset changes (all menus shown).
• Hiding Posts only also hides Comments, Tools and the Contact 7 “Contact” menu.
• Hiding Comments only does not hide the Comments menu