kbrownatp

Nevermind. Didn’t realize it was CSS driven, not an icon. For some reason you can’t delete a topic, even if you created it.

@danielsantoro Can I copy the storefront/assets/sass/utils/_variables.scss directory to my child theme and edit it there so it’s update-overwrite proof?

@bluetower, yes we resolved it by using the Woo session handler(which uses WP Session manager), instead of our own WP Session Manager plugin, that uses the built-in “add_option” functions. Those functions write the data to the wp_options (obvious once you look at the code) table instead of the wp_woocommerce_sessions table.

After re-coding everything to use the woo session handler, data is going to the woo session table as desired.

We have the new table (wp_woocommerce_sessions), but it is only storing SOME data. We are using wp_session for our other session coding, so I’m guessing that’s where the issue is.

Thanks

@mikejolley Mike, his version is 2.5.5 though (shown in OP)… according to the WooCommerce blog post here, the session data should be storing in the wp_woocommerce_sessions table and not the wp_options table, correct? Why is his wp_options table receiving the data meant for the wp_woocommerce_sessions table?

I ask, because I manage a site experiencing the same behavior. Our site does leverage some extra session coding, but if our issues are identical, it could be a bug somewhere. We are running v2.6.4, so it shouldn’t be storing any session data in wp_options… at least that’s what I’ve been lead to believe.