Integrating WooCommerce into Beans

Hi all,

Is there a proper way to integrate WooCommerce into a Beans-based child theme ?

This article on the WooCommerce site, shows how to do it by using hooks .

Defining the theme's 'wrapper' that will be used for WooCommerce content , as shown on their example :

add_action('woocommerce_before_main_content', 'my_theme_wrapper_start', 10);
add_action('woocommerce_after_main_content', 'my_theme_wrapper_end', 10);

function my_theme_wrapper_start() {
  echo '<section id="main">';
}

function my_theme_wrapper_end() {
  echo '</section>';
}

and it seems that in my Beans child theme

<div class="tm-content" role="main" itemprop="mainEntityOfPage" data-markup-id="beans_content">

is the best candidate, to use instead of

 <section id="main">

But I'm unsure how to go about the 'itemprop' and the 'data-markup-id'.

I know that turning the 'Developer mode' is what tells Beans to generate the data-markup-id for page elements. But this will not be used in the production.

I don't know where the 'itemprop' is coming from, and whether that should also be included in the 'wrapper'.

Could someone shed some light on this, pleese ? 🙂

Hey Yuna,

The data-markup-id is only there in development to help you identify hooks and actions available (refer to this reply for more info).

While Beans doesn't declare WooCommerce support, it should work fine out of the box and you should not have to do anything. In fact, many website built with Beans are running WooCommerce.

Do you have WooCommerce installed and are you experiencing issues?

Hi Thierry,

When I sent my inquiry above, I was actually just about to install WooCommerce on my local testing site. Being such a large install, I thought I should prepare everything first. Based on my previous experience with custom themes and various frameworks, I just assumed that I needed to do some stomping around and dancing around the pole, and maybe some ululating first ( especially the ululating 🙂 🙂 🙂 ).

I just didn't expect it to work just like that, out of the box !

Which is what it did. No muss, no fuss. Hah !

Unheard of, I didn't even have to 'declare support', it seems. 😉

I am curious though. It looks like the WooCommerce content basically replaces

<div class="tm-content" role="main" itemprop="mainEntityOfPage" data-markup-id="beans_content">

perhaps because of its declared role as "main" ?

Thanks a ton 🙂

Yuna M.

Hey Yuna,

You are correct the say that WooCommerce replace beans_content which is done on purpose. If you look at their markup, they have a div <div id="content" role="main">.

Everything within that div belongs to the univers of WooCommerce so Beans as not impact on it, you will have to digg in the Woo World to find answers (feel free to ask here if you want, maybe we can help). I know many Beans lovers wish WooCommerce could be built the Beans way as the makurp control is addictive. @chris has been working on making WooCommerce HTML the Beans (see this discussion) way but the project is in progress and I am not sure how active it is (not ready for production at this stage).

Happy coding,

Hey Thierry, thanks for your reply.

Yes, I realize that the Woo world is sort of a 'Woe is me' world, with its own strange rules, and wild beasts waiting in ambush 🙂 .

I did some more testing, and tried Chris's plugin . It looks very promising, and I really hope it could be made to work, so that the Woo pages could be customized the 'Beans-way'.

While it was easy to set up WooCommerce with a Beans-based child theme, I'm now finding a number of problems with the way things are working / or not.

What seems to be the most 'disturbing' for me, however, is that the test site runs much slower - since I installed Woo ( I'm running a portable XAMPP, which is usually quite fast ) .

Also, the WooCommerce Shop page , which is powered by archive-product.php doesn't respond to layout change in the back end. It only shows the default layout - one sidebar on the right, but ignores any change that I would try to make, like having both left and right sidebar showing. The other pages that WooCommerce installs on set-up, the Checkout, Cart and Account respond to layout change in the back end just fine. They are powered by page.php. So I guess the problem is with the archive-product.php.

Another thing is that the fixed navbar that I set up, using UIkit 'sticky' component , also doesn't work on the Shop page ( again - archive-product.php ). It works fine on other WooCommerce pages.

I guess I will have to make a new template for the archive-product.php and fiddle with it.

Do you know how and if this was handled by other sites that use both Beans and WooCommerce ?

Cheers,

YunaM

Hey Yuna,

The layout part is actually why we don't declare that Beans has Woo Support, Woo has a funny way of changing the query in some cases which unfortunately means themes have to do special adjustments. We still have to decide if we want to add Woo Support in Beans Core or in a separate plugin, imagine if every plugins had to do that and themes had to add support for all plugins who thinks they are alone in this world.

Performance wise, yes you are right to say that Woo will slow down your website, in fact it is much much more ressource heavy than Beans all together for example. But hey, WooCommerce does a lot 🙂

Regarding your layout, you would have to filter Beans layout and add a condition to get the Shop page ID set in Woo in order to fetch and assign the layout. Sounds hard, but it isn't 😉

Here is the code snippet you can add you your child theme functions.php:

add_filter( 'beans_layout', 'example_woocommerce_layout' );

function example_woocommerce_layout( $layout ) {

 // Get the layout post meta from woo shop page.
 if ( is_shop() ) {
    return beans_get_post_meta( 'beans_layout', beans_get_default_layout(), wc_get_page_id( 'shop' ) );
 }

 return $layout;

}

Regarding your sticky header, it should work throughout your website with no problem! Do you perhaps have an action called beans_before_load_document in your child theme functions.php? If yes, please replace it with wp which you should always do.

Hope that helps,

Hey Thierry,

Thank you very much for your reply.

I will try the snippet you included, will do more testing, and will post my findings here.

I wanted to touch on the general subject of the Woo's 'funny ways', as you put it, and on the subject of the Beans' support for Woo, which I think is an important topic.

I've customized several themes, to use with WooCommerce, and every time it was a very 'funny' experience 😉 .

Even trying to do something that should be simple - like changing the number of products in a row, on the Shop page, would turn into a tricky challenge, especially to make the layout responsive.

When I'm asked to put together an e-commerce WP site, the next thing to decide is what theme I can use, that would give me some level of control over WooCommerce, even if many other things are not quite perfect with the theme.

I think that for most 'end users' ( meaning - folks who set up websites for other people or businesses, or the do-it-yourselvers ) - it NOT is necessary to have a complete granular control over every aspect of WooCommerce layout and page element arrangements.

Just to know that a theme would not throw an error after installing Woo, and that what worked before installing Woo - continues to work after, would probably be just enough to say that a theme 'supports WooCommerce'.

I think that the 'WooCommerce overrides plugin' would be amazing to have - if it worked really smoothly. And in a long run - it's definitely something to aspire towards.

But in the meantime, a much less ambitious plugin, which would just make sure that the Beans layouts work fine with Woo, and perhaps being able to change the number of products per row, on the Shop / Product Category pages, would - IMHO - be enough to weigh the scale in Beans' favor, when it comes to choosing a theme for an e-commerce site.

In my experience, most business owners are very particular about the layout and the nuber of products per row, on their Shop page. So being able to do something that basic ( which WooThemes keeps to itself, with a plugin that only works with their own themes ) would make it a very useful plugin indeed. Most people's ambitions when it comes to customizing WooCommerce would only go that far.

That's my twobits and a bit.

Cheers,

YunaM

Hey Thierry,

I tried the snippet you posted, and the layouts on the Shop page are working now. Also, yes - you were right, I was using beans_before_load_document in the child theme. I replaced it with wp and now the sticky header is sticky again, on the Shop page.

Thanks a bunch. 🙂

P.S. I edited my previous post. It's still a rant, but a bit shorter one. I'd really like to know what other people's opinion is on all this.