[Support request] Element display rules very slow to populate

[Natalie]

Hi

I have a large number of ‘pages’ defined in the display rules for some of my header elements.

When you click on ‘display rules’ for that header, it is very slow for the page names to be filled in.
On my dev site it is OK, but on the client site, this process is timing out, so the page names don’t display and when the client clicks on ‘update’, a whole lot of blank pages get saved instead of the correct pages.

The client has more pages than I do on my dev site, as they have been translating the English pages.

There are no caching plugins active.

I also notice on my dev server that my CPU usage went up to 100% when it was showing the ‘display rules’ (It may actually be when you click on ‘edit’ on the element)

I tried disabling all the plugins and it was definitely quicker, but you could still see the page names being filled in – .i.e it wasn’t instant and the CPU usage still went to 100%

I have a video showing what it looks like (you may need to go to full screen to see the detail)
In the bottom right hand corner of the video is my CPU usgae monitor – normally a white sqaure but it fills up to a blue square signifying 100% usage

video of issue

Thanks for your help

[David]

Hi there,

how many pages do you have added to the Element?

[Natalie]

The element in the video has 22 display page rules, but the client is having problems with elements with a lot fewer rules – one with only 7 display page rules.

I’m wondering if the problem is the total number of pages available, as some of the drop-down boxes don’t even get populated with the page list. On the client site there are currently 127 pages

See these images
in this one the dropdown doesn’t show any pages at all

This is what the dropdown should look like

[Natalie]

Sorry there is something wrong with your img tag – here are the image links again

https://my.pcloud.com/publink/show?code=XZpOYA7ZrCI7e4JF65fde0fJRlisxVVTfGLy

https://my.pcloud.com/publink/show?code=XZQOYA7ZYRa7gPN7au80sgkkmFQAAB695wPX

[David]

I have never experience the issue myself but I assume there are a lot of pages on the site, and the PC is having memory issues with the a large number of pages to be filtered.

I wonder if we could remove the need for you to add each individual page to the various header elements. Instead we could register Categories for pages. Then use them for your display rules. Then your client would just have to select the category in the Page editor and not go near Elements. Let us know if you want to test that out … i would suggest on a staging site.

[Natalie]

Thanks for your reply David

Elements is the replacement for Page Headers, which was working fine. As a replacement, I would expect that it should work on a site with 127 pages, in the same way that Page Headers did.

My PC is NOT having memory issues. Also the client is having the same problem on proper commercial hosting. Two completely different systems with the same symptom – hence it is logical to suspect the software and not the hardware.

Have you tried reproducing this with a large number of pages? I don’t think it’s unreasonable to expect this to work with 127 pages.

My preference would be for display rules based on page templates, however categories could work, but I would need to go in and add a category to all 127 pages, whereas they already have their page templates assigned so no extra work for that.

Thanks

[Tom]

That’s a lot of pages, but you’re right that is should work regardless of the number of pages. We’ll do some tests and see if we can implement some sort of lazy loading in the list in GPP 1.9.

[Natalie]

Thanks Tom. In the meantime is there any code I can add to do it manually?

I actually would far rather that the client doesn’t have to choose the page header and that it is based on the page template (or potentially a category as David suggested).
The trouble at the moment is that we can’t assign the header elements at all, so any code that would accomplish this would be useful.

I have a child theme that is heavilly customised so no problem to put some code in somewhere or in a hook?

[Tom]

Unfortunately it’s not a simple solution. It’s going to take some research and will likely be a significant amount of code.

You could use a filter to set the Display Rules for now? Happy to help with that if needed.

[Natalie]

Thanks Tom

I have done this

function sav_add_headers($display, $element_id) {
    global $post;

    if ( 1993 === $element_id && is_page_template( 'my-template1.php' ) ) {
        return true;
    }

    $pc_exceptions = array(2259, 374);
    $pp_exceptions = array(2259, 374, 1017, 1240, 1210);
    if ( 1953 === $element_id && is_page_template( 'my-template2.php' ) && !in_array($post->post_parent, $pc_exceptions) && !in_array($post->ID , $pp_exceptions) ) {
        return true;
    }

    return $display;
}

add_filter( 'generate_header_element_display', 'sav_add_headers', 10, 2 );

So for most of the pages I am setting the element header based on the page template.

But there are some exceptions in the second page template which I have specified. These exceptions I have managed to set display rules for properly.

Is there any way I can know if a page already has an element header defined correctly without having to list the page IDs?

Thanks

[Tom]

Good question. You might be able to check the $display variable to check if it’s already set to true.

if ( $display ) {
    // This Element is set to display.
}

[Natalie]

thanks

yes and no.

It seems all the header elements are processed for evey page – is this correct?
They are sorted ASC

So for example in my code above, if I don’t sepcify the exception page IDs but use if ( $display ) to try to capture pages with element header rules already assigned, then if one of the exception pages has an element header with ID greater than 1953, then my page-template rule would kick-in first and assign the 1953 element header thus overriding the one in the display rules. When we get to the actual element header ID for that exception page, it is too late and the real header is not used.

So anyway, it does mean I have to specify the exceptions by ID.

[Tom]

Ah, you’re right. The Header Elements go by date added, so if it was created first, it will take priority over a newer Header Element with the same Display Rules.

I can’t think of another way to check if a different Header Element is displaying, unfortunately.

[Natalie]

Thanks for your help Tom. I have managed with code to make sure all the pages have headers so the immediate crisis is averted
Any idea when v1.9 may be coming out if you manage to sort out lazy-loading the page lists?

[Tom]

No problem! We don’t have a set date yet, but we will begin working on it once GP 2.3 is released.

[Author]

Posts