Issues after Canvas Update - Help & Support / Codex
#1 Updated by scott voth about 6 years ago
- Subject changed from Issues after Canvas Update - Help & to Issues after Canvas Update - Help & Support / Codex
- Category name set to WordPress Themes
The Commons Codex and Help & Support each use a child theme of Canvas and are acting very strangely after the upgrade. Sliders not working (on both) and content pushed to the left and navigation displayed weirdly (Codex). I notice the "Commons News" is displaying as expected (and it uses Canvas, but not a child theme). Wondering if the child theme needs some tweaks??
#4 Updated by Daniel Jones about 6 years ago
Sure thing I can look more into this. One thing I noticed recently when working on the issue with the layering on the modal dialogues is that at least on my install the Help & Support site is just using the regular Canvas theme, not the child theme, and that there are very few changes made in the child theme. I think I'm all up to date from Github - am I missing something?
#5 Updated by scott voth about 6 years ago
Hi Dan - Thanks for looking into this. The only change in the child theme was to create a header that had the CAC logo that links back to the Commons home page. It is being used on the Codex and Help & Support in prod. Maybe in Dev we never switched the sites to use the new child theme?? Not sure.
#6 Updated by Daniel Jones about 6 years ago
I wasn't able to reproduce this locally, but have you tried the fix suggested here: https://support.woothemes.com/hc/en-us/articles/203321803-Business-Slider-Images-Not-Showing-Up ?
Right now the slides and everything are working, and all the right HTML is being produced, but the images themselves aren't being requested correctly. It looks like what's happening is for some reason the theme is trying to use the TimThumb script that used to be included with the Woo Framework to get the thumbnail, but in the most recent version of the framework the thumb.php file is empty, so it isn't able to pull anything in. Canvas is supposed some native functions now, but that ends up being dependent on some options that hopefully the fix above can get straight. I noticed that on my local install, the src for the images doesn't include the reference to the TimThumb script, which makes me think this is some kind of issue with the settings, even if it isn't the one above. Let me know if you try that and it still doesn't work and I can keep looking.
#7 Updated by scott voth about 6 years ago
Hi Dan - I tried the fix you suggested - and that did seem to work. Then I started refreshing cache on all browsers (I swear I tried this before :) ) and things are looking much better - navigation is back, sidebar is back - the only thing I notice now that is screwed up is the business slider. I could play around with this myself, or if you want to - that's cool - I don't know how important it is since we were talking about getting rid of it at the last meeting.
Unfortunately, I don't know if our user base will know to clear its cache.
Thanks again for your help!
#8 Updated by Boone Gorges about 6 years ago
Thanks for your work on this so far, everyone.
Regarding script/style caches: I've been meaning to do something about this for a while, so this seems like as good an opportunity as any. When WP enqueues a script or style, it uses a query var
?ver=4.2.2, where "4.2.2" is the current WP version. When that version number is bumped, the URL of the asset changes, causing the asset to be reloaded from the server (ie, the cache is busted). This gets a bit funky on the Commons, because our release cycle doesn't line up with (and is much more frequent than) WP core releases. I've put a fix into place that makes the 'ver' string look like this:
?ver=4.2.2-1.8.3, where "4.2.2" is the WP version and "1.8.3" is the CAC version. This should ensure that browser caches are properly busted when CAC updates.
Note that WP has a disparity between the way script tags and style tags are filtered, which requires a less-than-ideal regular expression in the CAC filter. I've opened a WP ticket to fix the disparity https://core.trac.wordpress.org/ticket/32660#ticket - it's an easy one, so I imagine someone will pick it up for the 4.3 release.
#9 Updated by Daniel Jones about 6 years ago
Thanks for that, Boone!
I'd be happy to play around with this. Just a heads up it looks like a very similar issue has come up with the Simplicity theme on GCDI - https://redmine.gc.cuny.edu/issues/4151
I found a quick fix for that for now but I think it probably isn't a coincidence that both are having the same weird issue with generating thumbnails, though I guess it could be.
#10 Updated by Boone Gorges about 6 years ago
Just a heads up it looks like a very similar issue has come up with the Simplicity theme on GCDI - https://redmine.gc.cuny.edu/issues/4151
Yeah, this is almost definitely the same problem.
It does seem to have to do with generating thumbnails. There was a problem a few years ago where Timthumb, the library used for on-the-fly image resizing that's packaged with WooThemes, was breaking because it didn't have write permissions to its own directory. So I wrote a script that created a timthumb-config.php file to define a custom cache directory. The related tickets that I see are #1099, #1449, and #3242. Dan, I'm not sure if these are related, but it's probably worth taking a look through those tickets and related changesets to see if you get any leads.
#14 Updated by Boone Gorges about 6 years ago
It looks like this is the culprit: http://www.woothemes.com/2014/12/goodbye-timthumb-thanks-memories/
We had a similar problem at #4315. Running the "Remove TimThumb" tool seems to have fixed everything. Could you please try it and let me know?
I don't see an obvious way to force this routine to be run, in the background, for all relevant sites. So either (a) someone will have to do it manually for all sites running WooThemes themes, or (b) we do nothing, but direct people to run the tool themselves if they run into any problems.