workforpizza

Hey @annastaa ,
I’m plugging this thread instead of creating a new one, since I’ve got some similar problems. We have a filter-set with category, terms & a search box.
We also have ~2.000 products with about ~60k variations in total. So a lot to crunch through.

You’ve mentioned that there is some sort of caching used when filtering, right? Since I can’t really seem to notice this. Even when performing the same filters (without using the search input) multiple times they take the same amount of long load times.

Since our products aren’t tracked in stock we would be okay with just 1:1 caching the result of a filter, so it get’s returned instantly on a second request that is the same.

Secondly, would it be possible to only include the search-field if it’s actually populated, if the search is that performance heavy?

Thanks for a reply.

Best,
Florian

Hey Ben,

thanks for your answer. This seems to actually help, yes.
For anyone experiencing the same problem, here is how I split up my files:

function enqueue_gutenberg_attributes()
{
    // I took this conditional-code from the Kadence init.php, thanks a lot!
    if ( ! is_admin() ) {
        return;
    }
    global $pagenow;
    if ( 'post.php' === $pagenow || 'post-new.php' === $pagenow ) {
        $current_screen = get_current_screen();
        if ( method_exists( $current_screen, 'is_block_editor' ) && $current_screen->is_block_editor() ) {
            wp_enqueue_script(
                'wfp-gutenberg-attributes',
                get_template_directory_uri() . '/dist/js/pages/wp_gutenberg_attributes.js',
                [
                    'wp-editor',
                ],
                filemtime(get_stylesheet_directory() . '/dist/js/pages/wp_gutenberg_attributes.js')
            );
        }
    }
}

add_action('current_screen', 'enqueue_gutenberg_attributes');

and in the wp_gutenberg_attributes.js I only register the new attributes:

import { blocks_galleryStyles, blocks_insetBackground, blocks_textColumns } from "../components/wp_gutenberg_variables";

/**
 * Add Custom Attributes
 */
wp.hooks.addFilter(
    'blocks.registerBlockType',
    'cptx/addCustomAttributes',
    settings => {
        if ( blocks_textColumns.includes(settings.name) ) {
            settings.attributes = {
                ...settings.attributes,
                textColumnsCount: {
                    type:    'number',
                    default: 1
                }
            };
        }

        if ( blocks_insetBackground.includes(settings.name) ) {
            settings.attributes = {
                ...settings.attributes,
                useInsetBackground:   {
                    type: 'boolean',
                    default: false,
                },
                insetBackgroundColor: {
                    type:    'string',
                    default: '#c1c1c1'
                }
            };
        }

        if ( blocks_galleryStyles.includes(settings.name) ) {
            settings.attributes = {
                ...settings.attributes,
                cptxGalleryStyle: {
                    type:    'string',
                    default: 'default'
                }
            };
        }

        return settings;
    }
);

Two things to mention:
1. I had to still restore the faulty blocks and re-save them for it to work.
2. I had one attribute that I added globally to ALL blocks which caused for example the Gravity Forms-Block to break and not being able to load the requested form anymore (it said the attributes contained invalid props). So it should probably only be applied to whitelisted blocks.

The rest of my code from above (the blocks.getSaveContent.extraProps filter etc.) still gets enqueued on the enqueue_block_editor_assets action and works fine.

Thanks again for your help, I think this solution works for now ??

Flo,

• This reply was modified 4 years, 6 months ago by workforpizza. Reason: code highlighting
• This reply was modified 4 years, 6 months ago by workforpizza.

Okay I’ll try to expand on it. I don’t have it on GitHub, but I’ll share the necessary code-parts here.

First I’ll try to explain visually what I’m doing/want to be doing, and then I’ll show you the code that I’m using so far.

So this is the structure:

View post on imgur.com

* Red = Rowlayout
* Green = Column

Inside the column are some other blocks.

This is what I want to achieve:

View post on imgur.com

This is the “Background-Decoration” settings-toggle (and color select) I added to the kadence/rowlayout (last panel):

View post on imgur.com

What should happen:
If the toggle is enabled it should add the class inset-background to the row-layout-wrapper and add the selected HEX-Color as --inset-background-color CSS variable into the style-tag.

Here you can see that I got it pretty much working: https://imgur.com/7RtNHc9
But once it is saved and the editor reloaded the Kadence-Row-Block shows invalid content.

This is what the validation-console-output shows:

View post on imgur.com

As you can see the save-function does not include the CSS-variable, but the post-body does. What I just noticed, does the kt-row-layout-inner has an extra space in the save-function output? Why could that be?

Interesting note here: You will see in a minute, that I use this feature on the kadence/rowlayout AND core/group block, with the exact same code. But on the core/group-block this validation error doesn’t happen.

Ok now to the code:
https://pastebin.com/WZWRJAAs

I’ve tried to comment a little what I’m doing.
As mentioned above you can see the same code is used for kadence/rowlayout and core/group but the second blocks doesn’t seem to have any problems with it.

I hope this helps with the understanding of my problem and thanks a lot for your help ??

To add another thing: I tried using the render_block server-side filter, to add a wrapper around the row-layout with my data added to it. But it doesn’t seem like my custom attributes are getting passed into this filter.

Thank you very much! ?? I will happily report back once it hits live. Time to leave a 5 star rating for this great support!

We’re currently sitting on the wp_wrc_caches at around 24MB, nothing to incredible compared to the wp_post or wp_post_meta. wrc_relactions only at 3,4MB. It just got really impractical, since after saving a post it seems to “check” all 70k+ entries for invalidation. (One of the updates thankfully fixed the long loading on post save, but it still needs a lot of time to clear the caches). Even clicking the “Clear Cache”-Button manually is currently running for about 1,5 hours and displaying 14%.

I would highly appreciate an option to only store the currently active/valid entries – if someone (like us) doesn’t really need the nr. of hits.

It’s probably unusual to have such large amounts, so if I can assist with anything else, let me know ??

• This reply was modified 5 years, 3 months ago by workforpizza.

Ok I think that’ll do for now. Just curious: Isn’t there a cronjob that deletes all invalidated cache entries once in a while, or is the cronjob on my site just not working?

• This reply was modified 5 years, 3 months ago by workforpizza. Reason: spelling

Thanks for the quick reply. So this means if I fully clear both wp_wrc_caches and wp_wrc_relations – I should be back to a fresh start? Or are there any entries I shouldn’t delete?

@boldfish correct, nothing in the code tells wordpress to display the field anywhere. You have to do the displaying through regular custom fields groups.

The code only looks for any field anywhere with the given name and prefills it.

@boldfish the code in my example has nothing to do with specifically an options page, it just prefills a custom field that has the key “current_invoice_id” with the current ID when its loaded.

Where you add this custom field is up to you. You could add it to a regular set of custom fields on a page or create an options page (see on: https://www.advancedcustomfields.com/resources/acf_add_options_page/) and then display your set of custom fields on that options page.

I hope this makes sense for you.

@boldfish the initial value doesn’t work because it uses the add_option function, which only works if the option does not exist yet.

So you just create a function and use the update_option function to reset it to your starting value, for example:

function wfp_reset_id() {
  update_option('custom_invoice_id', '0001');
}

And then call this function whenever you want to reset the ID.

• This reply was modified 5 years, 4 months ago by workforpizza.

Just put that code into the functions.php of your theme, or include it in a plugin.

I did something similar a while ago for an invoice system, which had to count up to the next unique invoice id. I haven’t found a build in solution so I made my own. I tried my best to comment on whats happening – you obviously need to update the code with your field-, function and id-names:

<?php

function wfp_documents_setup_id_incr()
{

    // Check if user has rights to set it up and ACF is enabled.
    if (current_user_can('administrator') && function_exists('get_field')):

        // Initial value
        // === YOU NEED TO UPDATE HERE ===
        // Replace <code>custom_invoice_id</code> with your desired id name.
        add_option('custom_invoice_id', '0001', '', 'yes');

        /**
         * Wrapper to get the id (if i would need to add something to it)
         * @return mixed|void – stored next available id
         */
        function wfp_get_current_invoice_id()
        {
            return get_option('custom_invoice_id');
        }

        /**
         * Count up the id by one and update the globally stored id
         */
        function wfp_increase_invoice_id()
        {
            $curr_invoice_id    = get_option('custom_invoice_id');
            $next_invoice_id    = intval($curr_invoice_id) + 1;
            update_option('custom_invoice_id', $next_invoice_id);
        }

        /**
         * Populate the acf field when loading it.
         */
        function wfp_auto_get_current_document_id($value, $post_id, $field)
        {
            // If the custom field already has a value in it, just return this one (we don't want to overwrite it every single time)
            if ($value !== null && $value !== "") {
                return $value;
            }

            // If the field is empty, get the currently stored next available id and fill it in the field.
            $value = wfp_get_current_invoice_id();
            return $value;
        }

        // Use ACF hooks to populate the field on load
        // ==== YOU NEED TO UPDATE HERE ====
        // Replace <code>invoice_id</code> with the name of your field.
        add_filter('acf/load_value/name=invoice_id', 'wfp_auto_get_current_document_id', 10, 3);

        /**
         * Registers function to check if the globally stored id needs to be updated after a post is saved.
         */
        function wfp_acf_save_post($post_id)
        {
            // Check if the post had any ACF to begin with.
            if (!isset($_POST['acf'])) {
                return;
            }

            $fields = $_POST['acf'];

            // Only move to the next id when any ACF fields were added to that post, otherwise this might be an accident and would skip an id.
            if ($_POST['_acf_changed'] == 0) {
                return;
            }

            // Next we need to find the field out id is stored in
            foreach ($fields as $field_key => $value) {
                $field_object = get_field_object($field_key);

                /**
                 * If we found our field and the value of that field is the same as our currently "next available id" –
                 * we need to increase this id, so the next post doesn't use the same id.
                 */
                if ($field_object['name'] == "invoice_id"
                    && wfp_get_current_invoice_id() == $value) {
                    wfp_increase_invoice_id();

                    return;
                }
            }
        }

        // Use a hook to run this function every time a post is saved.
        add_action('acf/save_post', 'wfp_acf_save_post', 20);

        /**
         * The code below just displays the currently stored next id on an acf-options-page,
         * so it's easy to see which id you're on. The field is disabled to prevent easy tinkering with the id.
         */
        function wfp_load_current_document_ids_settingspage($value, $postid, $field)
        {
            if ($field['name'] == "document_ids-group_current_invoice_id") {
                return wfp_get_current_invoice_id();
            }
            return $value;
        }

        function wfp_disable_acf_field($field)
        {
            $field['disabled'] = 1;

            return $field;
        }

        add_filter('acf/load_field/name=current_invoice_id', 'wfp_disable_acf_field', 10, 3);
        add_filter('acf/load_value/name=current_invoice_id', 'wfp_load_current_document_ids_settingspage', 10, 3);

    endif;
}

add_action('init', 'wfp_documents_setup_id_incr');

It worked perfectly for me, I hope it helps you too.

Hello,
thanks for the quick answer.
I traced the problem down to the following action that is registered inside the Angelley_PayPal_Express_Checkout_Helper – “angelleye_optional_billing_fields”
This sets all billing fields to optional when a user returns from express checkout. I fixed this issue for now by removing this action in my themes function.php
I don’t exactly know why this action is needed in the first place, maybe because usually you get the name and address returned from paypal (which somehow wasn’t the case for me, and I wouldn’t want to use the returned name anyway), so having an option to disable this action would be the best option for the future.

If you’ve got other insights for this, I’m up for another view.

Thanks again,