I have a variable product with 3 attributes. The total number of variations generated is 900. This will make the admin page incredibly slow and hard to work with, so I need to find a workaround. I thought about replacing the dynamically generated dropdowns(for attribute values) with static ones, but the shopping cart expects to receive a variation number, which is non-existent in this case. I'd also like to mention that the variations are identical in all parameters, besides the attributes. How can I solve this?
Thanks.
Related
We have a requirement to retrieve 3 kinds of search suggestions:
Product suggestions
Category suggestions
Brand suggestions
Its important to note here that the brand suggestions should come from a custom attribute named Brand.
So far we have tried 2 different approaches, both unsuccessful for different reasons:
Approach 1 - SF Object Suggest Search
By using the SF Object Suggest Search we almost got what we needed. The product and category suggestions are working as expected. The problem lies with the brand suggestions. According to the documentation the brand suggestions come from the ManufacturerName attribute:
The brand suggestions are collected from the ManufacturerName index attribute of the SFProductSearch index.
Besides it being a very bad practice from Intershop to name something Brand whilst it is actually the ManufacturerName our real problem with this is that
all our products have a custom attribute named Brand which specifies the brand, and we use the default ManufacturerName field for the actual manufacturer of the product.
What we would like to achieve is that the brand suggestions are collected from the Brand index attribute of the SFProductSearch index instead of from the ManufacturerName index attribute.
The documentation also specifies that one of the downsides of the SFObjectSuggestSearch is that it has:
A limited hard-coded set of supported attributes
This made us believe that it will never be possible to modify the SFObjectSuggestSearch in such a way that it behaves in the way we want. So we tried approach 2.
Approach 2 - SFProduct Search Suggest
By using the SFProduct Search Suggest and adding the autosuggest attributes to the SFProductSearch product index we are able to retrieve all the attributes we need.
The downside of this approach is however that all SolrSuggestResultItem objects that are created have the type of Unspecified, which makes it impossible for us to group the products, categories and brands together in a nice way.
The documentation on this point is extremely poor/vague as it reads:
The custom values in the suggest index at search index configuration
level can configure custom values with the prefix SuggestType_
followed by a type.
So we suspect we have to do something with SuggestType_ but we can't seem to figure it out. The search index configuration options in the backoffice don't seem to provide anything like it. As a last resort we also tried to make the changes directly into the ISH-Config.xml but any changes in these files are overridden every time the search index is build.
Summary
Approach 1 is unsuccessful since it suggests manufacturers instead of brands.
Approach 2 is unsuccessful since the returned SolrSuggestResultItems all have a type of Unspecified.
Is there any way to get this working with either of these approaches? At this point we don't have a preference for approach 1 or 2, so a solution for either one, or guidance towards a more suitable approach, would be greatly appreciated.
To answer my own question:
After some experimentation we got it to work by making a modification to approach 1.
Inside the ISH-Config.xml we changed this:
<custom-value name="ObjectSuggestType_brand" type="string">
<value>ManufacturerName</value>
</custom-value>
To this:
<custom-value name="ObjectSuggestType_brand" type="string">
<value>Brand</value>
</custom-value>
With this configuration the brand suggestions are now collected from the Brand index attribute of the SFProductSearch index instead of from the ManufacturerName index attribute.
By redeploying the server directly after making this change the configuration won't be overridden when you make changes to the SF Object Suggest Search later on.
I have a site using woocommerce, I have imported products from an old oscommerce site, some of the products have several attributes, woocommerce threats those attributes as combinations, the problem is that each product come imported with thousands of combinations and my site crashes.
One example (Not real site):
I have one product with two attributes, color y size,
Colour has Red(+$50), Black(+$150), White ($+30)
Sizes has M(+$25), L(+15),XL(+58)
And you'll have multiple variations, in this case, 9 I think.
Now you have 10 different attributes, each with 20 or 30 possible values.
You'll have thousands of variations, this is what makes the site crash. I need to find a way to code or modify the system queries so this variation are less heavy and have fewer iterations, since if as soon as I try to load the product on the site, my database just dies.
Thank you.
I've been handed over a woocommerce website and a majority of the products are missing a sku number.
What would be the best way to go about updating products without a sku number?
Also keeping the skus unique?
Best practice for SKU's is to use small, (mostly) meaningless codes with a uniform fixed length and pattern.
So suppose you sell less than 1000 products, take a code of 5 characters. And assign the codes automatically using a script:
10001 first product
10002 second product
etc
How these codes should be generated depends on you (business) domain model / woocommerce configuration (using variants yes/no). For inspiration see this project: https://github.com/tamarazuk/woocommerce-product-sku-generator
For a WordPress project I'm looking for a better solution to this problem:
The query should get a set of different post_types and taxonomies (like categories), based on the site visitors choice. For example, the user want to get results from normal posts, but also products (from WooCommerce) and other post_types like events and news (both separate post_types. The tricky part is, that the user wants to assign a weight factor to each. So if they select like posts = 1, products = 3, news = 4, they should get a number of posts, three times more products and 4 times more news.
Next step will be to include categories, also with the weight factor, which will make it even more complex, because for posts, I need to query another taxonomy than for products.
The only way I found to solve this, is to run a separate query for each post_type, like fetching 10 items from posts, 30 items from products and 40 from news, to match the weight factors, then combine the results. But this will not scale very well when I need pagination (for example, I want to show 50 entries on the first page, next 50 on second page).
I thought about collecting these single queries into a temporary table, but such a table will be available for the current session only, so it won't help with the pagination (as the temporary table would no longer exist, when the second page is shown).
Does anybody have an idea, how I could approach this task? I would like it according to the WordPress coding standards, so I would like to use WP_Query and the provided filters, because the site is also using geolocating and WPML for translation, so I really would like to avoid writing a low-level query where I have to include all these manually.
I'm not looking for a final solution, just want to collect some ideas.
I'm going to go ahead with what i'm suggesting here, but i thought i'd try and get someones thoughts at the same time
Cutting off the fat
I've got several products with 700+ variations. This becomes an issue with wordpress saving that product because it panics when it tries to save 8000+ fields and causes intermittent saving and ends up losing data.
However, looking at the variations in the backend, there are several fields that i'm not using in each variation:
weight
dimensions
virtual
downloadable
stock qty
sale price (and schedule)
etc.
If i remove these, thats at least 6 x 700 field = 4200 less fields that wordpress has to deal with, which would make saving an actual possibility.
I'm going to just defy the gods for this one and edit the woo commerce template directly to test it out.
I'm not 100% sure how to create a function that would remove these fields without harming woocommerce at this moment in time, if anyone know how, that'd be fantastic
I'll let you know my results.
I just dug around in the class-wc-meta-box-product-data.php file and there does not seem to be any easy way to remove built-in input fields. You would probably have to re-write the entire metabox.
What might be possible is a JS solution whereby you remove the fields you don't want. I am not sure at all, but if WooCommerce has proper isset() checks on all the variables its save routine then it shouldn't crash.
Or you could remove Woo's save routine and replace it with your own?
Woo's save action:
add_action( 'woocommerce_process_product_meta', 'WC_Meta_Box_Product_Data::save', 10, 2 );
This, like re-writing the entire metabox, puts you at risk of things breaking whenever WC is updated.
Just out of curiosity, how does one get 700+ variations?