Sorry, I got hit again by the lack of an e-mail notification. I just saw this now, but am headed out the door. In two hours or so, I should be back, investigate and respond. Again, sorry for the delay!
No worries, I will be around all day. 🙂
I have just re-created this problem on my Test System, and will figure out what is going wrong and fix it ASAP.
I’ll update this thread with progress reports.
I was not aware of this issue.
Great. Thanks. Is the problem WooCommerce specific or would this happen with any custom post type?
My testing to this point indicates that this is a problem with WooCommerce overriding my plugin’s use of WordPress “hooks” to change the name of the Theme, at least for the Single Product page.
Although I have not actually tested Custom Post Types, the results of the tests I’m doing with this particular problem show that my plugin is returning the correct Theme for this Single Product page, which would indicate that Custom Post Types are not a problem. Of course, with WooCommerce activated, WooCommerce might override my plugin for all Custom Post Types.
That’s my Progress Report for now. I’ll update as soon as I know more. But, this may take a while as it will probably involve figuring out what WooCommerce is doing, and that means looking through a lot of code inside WooCommerce.
I have a Workaround that hopefully will not cause you any unexpected issues. And that is to use “URL Prefix” instead of “URL” on the plugin’s Settings page for your entry for the Single Product Page.
What I said in the previous post is not entirely correct, it turns out. WooCommerce is making a lot of calls to get_option(‘stylesheet’) or ‘template’ before WordPress is fully loaded. My plugin uses the WordPress function url_to_postid() for Custom Post Types, but that function returns zero until WordPress is fully loaded, rather than the Post ID. For Pages, Posts, Custom Post Types and a few other things, my plugin uses Post ID to store “URL” (but not “URL Prefix”) entries in Settings.
The plugin was built this way to try and preserve Settings when Permalinks are changed. In a future version, I plan to sacrifice that portability for better URL matching, by using the approach used in my jonradio Private Site plugin. Unfortunately, that is a lot of work, so we’ll have to settle for this Workaround for now.
Of course, if it creates nasty issues for you, please let me know and I’ll reconsider the options available to fix this.
That works. thanks so much for the workaround.
Good News! Thanks so much for working with me on this.
