Yes very helpful indeed, it was quit the hasle to integrate it into Sage 9 and the blade templates.
Thanks a lot!
Thanks, hambos22, that saves a lot of pain!
Hi, hambos, what is the best way to remove Bootstrap form your git clone (Woocommerce) ? Many Thanks
Hi, Hambos, I am getting error about soberwp ( ! )
Fatal error: Uncaught ReflectionException: Class App\Controllers\app does not exist in /var/www/vhost4.com/wordpress/wp-content/themes/sage-woo/vendor/soberwp/controller/src/Loader.php on line 119
Any tips at all? Thanks
Hi! This was a controller issue. Go to composer.json
file and change this line
"autoload": {
"psr-4": {
"App\\": "app/",
}
},
to
"autoload": {
"psr-4": {
"App\\": "app/",
"App\\Controllers\\":"app/controllers/"
}
},
after that do a composer dump-autoload
As for removing Bootstrap, its a lot of SCSS and markup work. First remove bootstrap from package.json. Then add your framework (or not). The SCSS files are using classes and mixins from bootstrap so you must delete or modify them incrementally. Finally change the markup on blade files to suit your needs. Much of the markup uses Bootstrap classes and its tightly coupled with the current design.
Anyway be ready for many scss errors and breaks on design. I was anti-bootstrap too but after the 4v I changed my mind. The markup is minimal, its flexible because of the SCSS and its much safer than foundation which I used to work (foundation has default styling right to the element without classes, on Bootstrap you need to add a class).
Thanks again @hambos22, this really helped me a lot!
This snippet might be a nice addition to lower the amount of http requests on non-woocommerce pages:
// dequeue wc scripts & styles on non-woocommerce pages
public function manageWoocommerceStyles() {
// remove generator meta tag
remove_action('wp_head', array($GLOBALS['woocommerce'], 'generator'));
// first check that woo exists to prevent fatal errors
if (function_exists('is_woocommerce')) {
// dequeue scripts and styles
if (!is_woocommerce() && !is_cart() && !is_checkout()) {
# WooCommerce Styles
wp_dequeue_style('woocommerce-general');
wp_dequeue_style('woocommerce-layout');
wp_dequeue_style('woocommerce-smallscreen');
wp_dequeue_style('woocommerce_frontend_styles');
wp_dequeue_style('woocommerce_fancybox_styles');
wp_dequeue_style('woocommerce_chosen_styles');
wp_dequeue_style('woocommerce_prettyPhoto_css');
# WooCommerce Scripts
wp_dequeue_script('wc_price_slider');
wp_dequeue_script('wc-single-product');
wp_dequeue_script('wc-add-to-cart');
wp_dequeue_script('wc-cart-fragments');
wp_dequeue_script('wc-checkout');
wp_dequeue_script('wc-add-to-cart-variation');
wp_dequeue_script('wc-single-product');
wp_dequeue_script('wc-cart');
wp_dequeue_script('wc-chosen');
wp_dequeue_script('woocommerce');
wp_dequeue_script('prettyPhoto');
wp_dequeue_script('prettyPhoto-init');
wp_dequeue_script('jquery-blockui');
wp_dequeue_script('jquery-placeholder');
wp_dequeue_script('fancybox');
wp_dequeue_script('jqueryui');
# WooCommerce Multilingal scripts
wp_dequeue_script('wcml-front-scripts');
wp_dequeue_script('cart-widget');
}
}
}
add_action('wp_enqueue_scripts', 'manageWoocommerceStyles', 99);
And this one to add support for the default product gallery zoom, lightbox & slider functionalities:
add_theme_support('wc-product-gallery-zoom');
add_theme_support('wc-product-gallery-lightbox');
add_theme_support('wc-product-gallery-slider');
Cheers!
I’m happy that it helped you!
As for the scripts I’ve already included something for dequeueing scripts as you can see in the docs. But not conditionally. I believe this is developer’s choice. But I’ll add for sure the second snippet Thanks
PS
I’m not using the default woo slider and zoom. I made up my own plugin for this, using Slick and jQuery zoom, with multiple variation images support, lazy loading and lightgallery for lightbox. Much more flexible than the default one. I’ll open source it someday
Hi, Hambos, great Ill do a Bootstrap 4 version, (you are right its OK anyway) and a vanilla one, Is there a Navwalker in it ? Thanks
Νο I didn’t include one. I’ve used extends via scss.
Hi again,
I just wanted to try out your option to use radio buttons for the product options in variable products.
As your documentation states:
Radio for product options in variable products!
To enable it
single_product:
radio_variations:
- slug
- slug
I presumed the - slug
should be your product attribute right?
So for example if I have 2 product attributes color and size, I would have to add the slugs like this?
single_product:
radio_variations:
- pa_color
- pa_size
Unfortunately that is not working, am I missing something?
What exactly should the slug be here?
Thanks!
EDIT: Got it, it obviously had to be:
single_product:
radio_variations:
- color
- size
In the current documentation, it mentions that the Bootstrap initialisation has been disabled. If I need bootstrap to be included and initialized how do I do that?
Hi
It’s already included. In the docs, I mean that I disabled the choice to initialise frameworks (bootstrap, foundation etc) to protect scss from breaking.
How were these problems not thought of before shifting Sage to Blade templating?
The fact that this is such a mess seems like a major oversight in the rush to make Sage as ‘modern’ as possible.
Pretty frustrating - particularly the lack of response from those officially involved.
Why is there no guidance in the (paid) docs or at least a Blog post like there was for the original Sage versions?
This is open source. Feel free to help out.
Demonstrating a sense of ownership rather than entitlement is a greater motivator for everyone involved.
Thanks, but this is nothing to do with entitlement. It doesn’t diminish how much I appreciate the Sage theme and the entire Roots project.
But for me this is about the importance of releasing something that’s production ready and commercially viable… As I say, not allowing for or planning an easy WooCommerce integration seems like a huge oversight.
We’re seriously considering rolling back to 8.4.2 at this rate.
What problems?
How come Sage is at fault here?
Not sure what you’re looking for here
Look, clearly you’re having trouble with integrating WooCommerce with Sage. What’s not cool is how you’re expecting everything to be a certain way… maybe try and remember that this is open-source software?
You’ve done a whole lot of complaining without mentioning any specific issues.
Sure looks that way.
Seriously still waiting for you to mention any sort of specific issue.
What, specifically, doesn’t work? Have you reviewed the other threads addressing Woo integration? Others are having good luck integrating the two. Where are you getting stuck? Is there an error you can share?
I have checked other threads regarding Woo integration, there is a common thread of frustration. The fact that a completely seperate theme has been created to easily facilitate the integration seems to highlight a problem?
Lack of Woo Blade template support, duplicate content occurrences, inconsistent information on where to place template override files. I can see that the frustration stems from the lack of support offered by the Roots team.
Why isn’t there a single source of truth or resource that describes where to place these files or integrate efficiently? Surely asking for consistency shouldn’t result in being labeled ‘entitled.’
I feel like there’s a lack of compassion and air of superiority that is conveyed by some which really isn’t helpful.
Anyway, in the meantime I’ll give the completely seperate 3rd party theme a try I guess.
There are several popular plugins that don’t work well with Sage 9. It’s not the best tool for every project depending on your plugin needs, however working with Woo is definitely possible and has been accomplished by many users.
You are continuing to express frustration with the process, but you’ve yet to explain where and how you are getting stuck. Have you tried the methods in the other threads, despite the fact there might be a couple of different suggestions for where to place the templates? Did you receive an error we could see and help troubleshoot?
The Roots team and the volunteer forum support crew are here to help with Roots products. We’re enthusiastic and eager to assist with these tools we feel make WordPress development easier and better. Unfortunately the Roots team cannot anticipate all users’ plugin needs and as such some plugins, even popular ones, are not yet canonically documented. If you are able to determine a best practice for working with Woo, I’m sure the team would appreciate an article submitted for the Guides section of the site.