New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve "unsupported" theme experience #13087

Closed
mikejolley opened this Issue Feb 6, 2017 · 8 comments

Comments

Projects
None yet
6 participants
@mikejolley
Member

mikejolley commented Feb 6, 2017

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.
Either solution may work so some experimentation might be in order.

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.

The problem

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:

https://docs.woocommerce.com/document/third-party-custom-theme-compatibility/

The options being:

  • Adding correct 'wrappers' so our templates know how to format the headers and footers
  • Using the woocommerce_content() function in a page.
  • Theming it fully.

The main reasons for these are:

  • WooCommerce uses custom post type archives, single post type, and real archive templates for the shop/category archives/single pages. These require a template to work in most cases.
  • Shop and product content is not something we'd usually format like a post, and the content of a product for example can span the whole page. Same for the archives; we'd usually show sidebars and widgets related to the shop content.

Currently, the main non-pages WooCommerce generates are:

  • Category, tag, and attribute archives.
  • The product post archive (shop page).
  • Single product pages.

Potential solution

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:

  • Generate pages for the shop content
  • Add a shortcode, possibly a wrapper for woocommerce_content() (?) and add this to the pages.
  • Make sure conditonal tags and permalinks still work as best as we can.
  • Filter 'post titles' so we can give the page a correct title, similar to how we do the account page right now.

Pros:

  • Better experience out of the box
  • No loss of theming ability should they want something better
  • Less theming tickets

Cons:

  • The pages won't be a 'full featured'
  • The shop content will need to fit with the 'page' content
  • Adjusting titles on the fly can be a little 'hacky'

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.

@mikejolley mikejolley added this to the 2.8 milestone Feb 6, 2017

@mikejolley mikejolley modified the milestones: 4.0.0, 3.1.0 Mar 17, 2017

@mikejolley mikejolley modified the milestone: 4.0.0 Mar 17, 2017

@jameskoster

This comment has been minimized.

Show comment
Hide comment
@jameskoster

jameskoster Jun 13, 2017

Member

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;

  1. Create a shortcode for displaying the product loop, including pagination, sorting etc.
  2. When the wc pages are created in the setup wizard check if the current theme supports wc, if not - add the aforementioned shortcode to the 'shop' page content and set a flag specifying that when WC was set up the theme didn't declare support (this will be used when switching themes).
  3. Only specify has_archive when the product post type is registered if the current theme declares wc support. This ensures that the actual shop page is displayed rather than the post type archive. Also tweak our wc_template_redirect() function to not redirect to the post type archive (again when the theme doesn't support wc). Category / tag / attribute archives will probably need attention to.
  4. Ideally single product pages should just use the themes single.php template. We'd need to ensure comments etc are removed though. Really not sure how to tackle this.
  5. Filter page titles to display relevant text.
  6. Add a check after_switch_theme. This will compare whether the new theme declares wc support vs the flag we set in the wizard. If the new theme supports wc we'd need to inform the user that they no longer need to use the shortcode. Perhaps we could strip it automatically?
  7. We should probably have a vice-versa version of the check in 5 as well, in case the theme they were running when wc was set up did support it, but then they switch to one that doesn't.

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.

Member

jameskoster commented Jun 13, 2017

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;

  1. Create a shortcode for displaying the product loop, including pagination, sorting etc.
  2. When the wc pages are created in the setup wizard check if the current theme supports wc, if not - add the aforementioned shortcode to the 'shop' page content and set a flag specifying that when WC was set up the theme didn't declare support (this will be used when switching themes).
  3. Only specify has_archive when the product post type is registered if the current theme declares wc support. This ensures that the actual shop page is displayed rather than the post type archive. Also tweak our wc_template_redirect() function to not redirect to the post type archive (again when the theme doesn't support wc). Category / tag / attribute archives will probably need attention to.
  4. Ideally single product pages should just use the themes single.php template. We'd need to ensure comments etc are removed though. Really not sure how to tackle this.
  5. Filter page titles to display relevant text.
  6. Add a check after_switch_theme. This will compare whether the new theme declares wc support vs the flag we set in the wizard. If the new theme supports wc we'd need to inform the user that they no longer need to use the shortcode. Perhaps we could strip it automatically?
  7. We should probably have a vice-versa version of the check in 5 as well, in case the theme they were running when wc was set up did support it, but then they switch to one that doesn't.

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.

@mikejolley mikejolley modified the milestone: 3.2.0 Jun 29, 2017

@claudiulodro

This comment has been minimized.

Show comment
Hide comment
@claudiulodro

claudiulodro Jun 30, 2017

Contributor

We should consider changing this to match _s instead seeing as many themes use this as a base.

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. :)

Contributor

claudiulodro commented Jun 30, 2017

We should consider changing this to match _s instead seeing as many themes use this as a base.

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. :)

@jameskoster

This comment has been minimized.

Show comment
Hide comment
@jameskoster

jameskoster Jul 3, 2017

Member

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 class_exists() for bootstrap, but the _s generator prefixes everything so that won't work there. I don't think we can change our default wrappers without breaking existing themes either.

instead of targeting every theme in the world

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.

Member

jameskoster commented Jul 3, 2017

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 class_exists() for bootstrap, but the _s generator prefixes everything so that won't work there. I don't think we can change our default wrappers without breaking existing themes either.

instead of targeting every theme in the world

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.

@jeffikus

This comment has been minimized.

Show comment
Hide comment
@jeffikus

jeffikus Jul 4, 2017

Member

@jameskoster @mikejolley we are looking into something like this for _s

@tiagonoronha is currently looking into this.

Member

jeffikus commented Jul 4, 2017

@jameskoster @mikejolley we are looking into something like this for _s

@tiagonoronha is currently looking into this.

@mikejolley mikejolley removed this from the 3.2.0 milestone Jul 5, 2017

@mikejolley

This comment has been minimized.

Show comment
Hide comment
Member

mikejolley commented Jul 15, 2017

@jeffikus

This comment has been minimized.

Show comment
Hide comment
@jeffikus
Member

jeffikus commented Aug 1, 2017

@douglsmith

This comment has been minimized.

Show comment
Hide comment
@douglsmith

douglsmith Nov 14, 2017

Contributor

@JJJ, You did a lot of work on making bbPress work within any theme. Any wisdom you could offer on this issue?

Contributor

douglsmith commented Nov 14, 2017

@JJJ, You did a lot of work on making bbPress work within any theme. Any wisdom you could offer on this issue?

@JJJ

This comment has been minimized.

Show comment
Hide comment
@JJJ

JJJ Nov 14, 2017

Contributor

Any wisdom you could offer on this issue?

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.


Start here: https://bbpress.trac.wordpress.org/browser/branches/2.5/includes/core

Use what's in these 3 files:

  • template-functions.php - functions used to load template parts and enqueue scripts/styles
  • template-loader.php - functions used to define the template hierarchy for each part
  • theme-compat.php - class & functions used to override various parts of $wp_query assumptions

Bonus:

  • sub-actions.php - bbPress specific hook-namespace, to avoid other plugin collisions

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.

Contributor

JJJ commented Nov 14, 2017

Any wisdom you could offer on this issue?

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.


Start here: https://bbpress.trac.wordpress.org/browser/branches/2.5/includes/core

Use what's in these 3 files:

  • template-functions.php - functions used to load template parts and enqueue scripts/styles
  • template-loader.php - functions used to define the template hierarchy for each part
  • theme-compat.php - class & functions used to override various parts of $wp_query assumptions

Bonus:

  • sub-actions.php - bbPress specific hook-namespace, to avoid other plugin collisions

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment