Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve "unsupported" theme experience #13087
To improve basic appearance when using a non-wc compatible theme (this can be detected) we should offer a cut-down, content area only view for store pages. This avoids the need to work with wrappers.
We could use shortcodes, but I think we could also filter on the_content and the_title of the shop page to do what we need without changing page content to a shortcode as suggested here.
If theme supports WooCommerce, do nothing different. Use the current template system, and archives etc.
This was the result of a discussion with Jay about how we can make the 'default' WooCommerce theme experience better, if not using a WooTheme such as Storefront.
Currently, if you're using a third party theme, due to the way templates work in WooCommerce, pages like the shop page will have odd layouts until these steps are performed:
The options being:
The main reasons for these are:
Currently, the main non-pages WooCommerce generates are:
We'd like to experiment with a shortcode based approuch so that the theme's page.php file will be responsible for shop content, and the wrappers will work out of the box.
The simplest idea being we:
This is semi-related to #13088 where we want to push Storefront to users during setup for the best possible experience if setting up a dedicated store.
I took a stab at this yesterday afternoon / this morning but ran into some walls, notably around pulling components like pagination, sorting and the 'no products found' message into the shop page using the 'shortcode approach' and getting them to work properly.
It did get me thinking about whether we need to include those features with this 'automatic integration'. It probably wouldn't be the end of the world if they weren't there. A functional layout is worth the trade-off imo. But then you'd have to resort to pulling in all the products... could get hairy.
I thought I'd share my thought-process for this anyway, in case I pick it up again later, or if someone else wants to take it on;
I might be missing something (or, more likely there's a better approach for this xD) but I think that would cover most of our issues.
One other idea I had to improve our out-of-the-box theme compatibility, particularly for WordPress.com:
The default wrappers in our wrapper start and wrapper end templates were created to match Twenty Ten. We should consider changing this to match _s instead seeing as many themes use this as a base. This could cause backwards compatibility issues though.
Yeah I think the easiest way is going to be to target some widely-used theme base(s) instead of targeting every theme in the world. It won't give us full compatibility, but it will increase compatibility a lot. For example, if we can get it looking good on _s and on Bootstrap-based themes that's hundreds of themes right there.
Just my 2 cents. :)
Yup, that could certainly be a quick & easy win. Is there a bulletproof way of identifying a theme based on these frameworks though? We could probably do a
I don't think we need to target themes individually. We just need a fallback for those that don't declare wc support.
If there are technical hurdles then it doesn't have to be 100% full featured. IE we could just display all products via shortcode on the shop page - no pagination/sorting. I think that would be better than the current broken experience.
It's kinda gnarly. and evolved slightly over the years. I wrote the first version of what's in bbPress & BuddyPress now in a single weekend with a thorough understanding of WordPress internals.
Use what's in these 3 files:
bbPress goes above and beyond the "bare minimum compatibility" though, and really relies on the concept of "template packs" so that full bbPress themes are never a requirement and Template Pack Plugins could be activated to provide dedicated bbPress support for any theme. The demand is relatively high, but without a practical example in the wild, support is basically nil.
IMO, WooCommerce should leverage the same exact approach as what's in bbPress. It's its own economy and ecosystem, if and when people start saying "here is a great theme, and WooCommerce support is $49.99, bbPress support is $39.99, etc..."
I can't prioritize helping build this until after January 1, but if someone is eager to move the ball forward, I'm happy to answer questions as they come up. On the off chance there is any desire to pay me to fast-track a pull request for this, reach out privately for a price.