I’m using the SOW Hero Widget successfully on my local machine and then when I deployed to the production server (database and `/uploads` folder) the CSS that’s written into `/wp-content/uploads/siteorigin-widgets/` seems to not be loading.
I dug into the code a bit and it looks like the script looks to enqueue
`sow-hero-default-#{widget_instance_id}.css`
if it exists.
So I’m a little stumped. That file exists on the production server and I’ve tried to recursively modify all the appropriate folders and even `chown` them to the correct user. All this to no avail.
It’s especially odd b/c I’m pushing the DB with the uploads so it’s not like the widget instance would be different on the remote DB.
Anyway, any help resolving this would be fantastic. I’m happy to provide a link to the site in a PM.
Eli
Hi Eli
The Widgets Bundle should check that the CSS file exists, and if it doesn’t, recreate the file. So one suggestion I’d have here is to completely delete the siteorigin-widgets folder and let the plugin regenerate all the files. This might take care of all the permission issues.
Yea I saw that logic in the code but it doesn’t seem to work. I already tried deleting that uploads folder (and I tried it again just now for good measure) and it recreates the folder but doesn’t write any css.
Just tried creating a totally new test page on the production server, adding a new hero widget, and saving, and still nothing. Any other suggestions?
My only guess here is that the Widgets Bundle isn’t getting the access rights it needs from WP_Filesystem to actually write the files. This is the general logic for CSS saving function.
https://github.com/siteorigin/so-widgets-bundle/blob/develop/base/siteorigin-widget.class.php#L490-L516
If it can’t get a WP_Filesystem object, then it just quits out. Although this should have some sort of fallback to properly deal with WP_Filesystem errors.
I’ve logged this as an issue on our side. If we don’t get a pull request for this issue, we’ll probably fix it ourselves early next year.
https://github.com/siteorigin/so-widgets-bundle/issues/62
For now, all I can suggest is checking what WP_Filesystem is returning on your production server.
Solved! Thanks for the thorough response and putting me on the right track…
I feel like a complete idiot because the problem was totally my fault! I use a grunt+rsync deploy method and generally exclude all *.less files from being pushed (when I deploy my themes) and when I used it to sync the /plugins folder of my production box with my local wp install it wasn’t pushing the default.less file required to write the SO Widget dynamic CSS.
Despite the fact that I totally screwed up the plugin file structure, it could be helpful in the future to log an error at run time if a crucial dependency like that is missing. And I still believe there should be some sort of error logged if the WP_Filesystem isn’t accessible, but that had nothing to do with this issue. Obviously, neither of those things are high priority…
Thank you!