FAKTOR VIER

Thats strange. As we’ve removed all z-index values (so the tree has a z-index of 0 now, thats the default), the .us-paste-section-window should be always on top, because there should be nothing from our plugin above this window. We’ve testet this as good as possible with WP Bakery (and the newest tree plugin version), and there is actually nothing that has a higher z-index than 13 (expect for the other overlays from WP Bakery). Just to be sure: You’ve updated to the latest version of the tree plugin (1.1.12)? And have you cleared the browser cache for the page to be sure that the latest stylesheet is loaded?

We can’t really test this because we don’t have access to this theme. If you can send us access to a staging environment, we could analyze it better.

Hi again @synormedia

We’ve just released a new version that contains our z-index changes. Let us know if this fixes your problem or if it makes it even worse.

Hi @synormedia

We’ve tried some small changes. Can you help us test this in your installation? Since you are familiar with the developer tools, could you remove the z-index properties from the following elements: #wpbody (1000), #adminmenumain (2000) and #f4-tree-container (1100) and tell me if this breaks anything in your installation? Or if everything looks fine with this changes? We would appreciate that!

Hi @synormedia

We’re currently trying some changes related to the z-index problem. Its really hard to find a solution that works with every plugins (especially page builders), but we’re working on a good solution. Keep an eye out for one the next plugin versions, hopefully that will fix it for you too.

Yes our plugin is on Github. You can find it here: https://github.com/faktorvier/f4-woocommerce-salutation-fields

Hi Nick

Currently we’re not working on this integration but it’s on our todo list with a high priority. If you’re interested, feel free to contribute to this feature. We would appreciate that very much.

We may have a look at this integration in the next days to see how much work that would be, so we may add it ASAP.

Hi @varunsaimatla1237

Keep an eye out for the future releases.

Hi @suntower

YOu can bulk assign at any time after the upload, but its omly available in the media library list view. So you have to make sure that you ar enot in the grid view. Check the small circle in the following screenshot. If you are in the correct view you can toggle tags with the bulk dropdown (see screenshot). This bulk action toggles tags. If the tag is already assigned, the tag will be unassigned, if its not assigned, it will be assigned.

Screenshot: https://imgur.com/a/fUFNYAZ

I hope that helps.

Hi @varunsaimatla1237

We already answered you on your previously created issue. Please have a look here:
https://www.ads-software.com/support/topic/brand-wise-total-stock/

Hi @varunsaimatla

Thanks we appreciate it.

You’re talking about some kind of brands taxonomy I guess? That can be assigned to products? We may implement more such filters in the future, but I can’t tell you when exactly. Just keep an eye out for any future updates.

Hi @asierrajr

We changed the behaviour of the taxonomy selection in the last update and this should also fix the problem with ACF Pro you mentioned. We no longer load all terms in advance, that led to slow loading and performance problems for many users. I tested it with your use case today and it seems to work fine now. Let me know if you still run into any issues.

Hi again @ogdsgn

We’ve made some optimisations. Looks like it fixed the performance problem at least on our test environment (with about 700 terms). I hope this solves it on your installation as well. Thanks for helping us optimise and test this issue!

Hi @ogdsgn

We’ll have a closer look again, we should be able to optimise this even further. Also we kinda broke the ability to filter taxonomies in the grid overview. We’ll release new version as soon as possible, this time we hope to fix the performance problem once and for all.

Hi @ogdsgn

We’ve just released a new optimized version. We think its useful for most of the people that the terms are only loaded if needed. So we generally changed the selection to a “lazy” ajax solution. Let me know if you run into any trouble, if something not works correctly or if its still slow. Maybe we can improvise this even further if necessary.

Thanks again for the input!

Hi @ogdsgn

Thanks for the hint, that may be the problem that causes the issue. We look into that and hope we can provice a good solutions for installations with a lot of terms, like loading the terms asynchronously.

You’ll hear from us as soon as we fixed that problem.