[Resolved] Slow Loading next views: Debug won't load

[Author]

Posts

[briana-5]

I have built a page with nested views, which is here:
hidden link

When I'm logged in as an admin, there is additional information display as well as links to edit the data.

The page loads pretty slowly compared to most other pages on the site. I suspect it may have something to do with the way in which I have constructed the nested views. Also, when I turn on the Enable Views debug mode and load the page, the popup window never loads (it works on other pages on the site so it's not a popup blocker issue) and the WP admin bar at the top never appears.

My question is:

(1) why is this happening with the debug tool?
(2) Possibly related to (1), is there a way to construct the views on that page to load faster?

[Christian Cox]

(1) why is this happening with the debug tool?
Hard for me to say without logging in and taking a look, but this could happen if there is a JavaScript error on the page or if the page markup is incomplete, or if the server times out trying to load some information.

(2) Possibly related to (1), is there a way to construct the views on that page to load faster?
Not sure, but I could take a look at your setup in wp-admin and see if there's anything we can do to help speed things up. You could also consider a caching plugin.

[Christian Cox]

Okay when I'm logged in and try to load that page, I can see two main issues.
1. There is a JavaScript error in the console:

knockout-3.4.0.js?ver=3.4.0:72 Uncaught ReferenceError: Unable to process binding "with: function(){return cred_form_context_18f0 }"
Message: Unable to process binding "value: function(){return post_id_observable_bf6fae21 }"
Message: post_id_observable_bf6fae21 is not defined
    at value (eval at parseBindingsString (knockout-3.4.0.js?ver=3.4.0:68), <anonymous>:3:58)
    at m (knockout-3.4.0.js?ver=3.4.0:102)
    at Function.Pc (knockout-3.4.0.js?ver=3.4.0:51)
    at Function.Qc (knockout-3.4.0.js?ver=3.4.0:51)
    at Function.aa (knockout-3.4.0.js?ver=3.4.0:50)
    at Object.a.m.a.B (knockout-3.4.0.js?ver=3.4.0:49)
    at init (knockout-3.4.0.js?ver=3.4.0:103)
    at knockout-3.4.0.js?ver=3.4.0:72
    at Object.w (knockout-3.4.0.js?ver=3.4.0:39)
    at knockout-3.4.0.js?ver=3.4.0:71

This error is most likely blocking the debug popup and the wp-admin bar.

2. The source code for this page is over 8Mb (WOW!) That's really too much information for a browser to handle directly in the DOM, and regardless of whether or not Toolset is involved that would bog down any site and lead to unexpected browser performance issues. So the first thing I would suggest is to add pagination to this main View so we can work with a more manageable chunk of data:
hidden link
Scroll up to the top right corner of the editor and click "Screen Options" to enable the Search and Pagination panel, as well as the Pagination and Slider settings panel. Use the controls in these two panels to insert some basic pagination. For now, use page refreshes instead of AJAX updates. Limit to 1 or 2 results per page at first until we can figure out what's going on. Once pagination is added, we can try to pin down the source of that JavaScript error by analyzing this one page at a time.

Let me know once you have added some pagination and I'll take another look.

[briana-5]

I've added the pagination. Looking forward to hearing any thoughts you have.

[Christian Cox]

Okay thanks, it's a more manageable chunk of data now on each page, around 1 Mb. The JavaScript error is not appearing anymore, and I paginated through maybe ten pages of content. In debug mode, the page source code is incomplete - the body and HTML tags are not closed. This indicates the server stopped sending data unexpectedly. If debug is turned off, the source code is complete. So something strange is going on here. Not sure if it's a failure in the debug system or a problem at the server level that prevents the page contents from being delivered completely.

Do you have access to server logs? Is anything logged that might explain what is happening here? If you're not familiar with server logs I can show you how to temporarily activate one. Go in your wp-config.php file and look for

define('WP_DEBUG', false);

Change it to:

define('WP_DEBUG', true);

Then add these lines, just before it says 'stop editing here':

ini_set('log_errors',TRUE);
ini_set('error_reporting', E_ALL);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');

Update wp-config.php on the server, then reload the agenda-3 page while logged in with debug active. If any server-side errors are generated, this will create an error_log.txt file in your site's root directory (you may have to refresh in FTP to see this file). Please copy + paste its contents in your next reply. Once that is done, you can revert the changes you made to wp-config.php and delete the log file.

[briana-5]

Thanks. Here is what the log provided:

[07-Jul-2019 22:24:27 UTC] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php71/lib/php/extensions/pdo_mysql.so' - /usr/local/php71/lib/php/extensions/pdo_mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0
[07-Jul-2019 22:24:27 UTC] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php71/lib/php/extensions/pdo_sqlite.so' - /usr/local/php71/lib/php/extensions/pdo_sqlite.so: cannot open shared object file: No such file or directory in Unknown on line 0
[07-Jul-2019 22:24:27 UTC] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php71/lib/php/extensions/pdo_pgsql.so' - /usr/local/php71/lib/php/extensions/pdo_pgsql.so: cannot open shared object file: No such file or directory in Unknown on line 0
[07-Jul-2019 22:24:27 UTC] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php71/lib/php/extensions/pdo_mysql.so' - /usr/local/php71/lib/php/extensions/pdo_mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0
[07-Jul-2019 22:24:27 UTC] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php71/lib/php/extensions/pdo_sqlite.so' - /usr/local/php71/lib/php/extensions/pdo_sqlite.so: cannot open shared object file: No such file or directory in Unknown on line 0
[07-Jul-2019 22:24:27 UTC] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php71/lib/php/extensions/pdo_pgsql.so' - /usr/local/php71/lib/php/extensions/pdo_pgsql.so: cannot open shared object file: No such file or directory in Unknown on line 0

[Christian Cox]

Let me ask my team if these extensions are required. I'll let you know what I find out.

[Christian Cox]

These warnings indicate a configuration problem on your server that needs to be addressed by your host. However, I wasn't able to get a definitive answer about whether they are directly causing the problem. I would need to be able to log in to your wp-admin area, make a clone of your site, and install it locally to see if the same problem exists. If you approve, I can install the Duplicator Pro plugin to create a site clone and run those tests.

[briana-5]

Yes i approve. That would be great. Thank you.

[Christian Cox]

Well the debug information does load on my local site, but it takes a long time because there is a lot of information from several nested Views. It's possible your server is just timing out trying to assemble all the debug information. If you're working and need to run the debug tool, consider adding a limit to each nested View so that it only returns 1 result. Otherwise, the debug information will continue to grow as the number of nested results grows, and eventually your server might time out.

In terms of performance, I don't see anything obvious that you could do here to speed up the results from a Views perspective. In order to achieve what you want, nested Views are required and those nested, filtered Views are server intensive. I would consider implementing a caching plugin to help speed things up a bit if you find that your site visitors are experiencing long wait times. But locally, the search is quite fast when I'm logged out or debug is turned off.

I can also see an error in your Layouts JS. If you scroll down to the bottom of the Layouts JS editor, you can see a script tag included at the very end. You should delete the opening and closing script tags here, they are unnecessary and causing a problem in the JavaScript parser.

[briana-5]

Thanks. I'll fix the JS error. Related to the multiple nested views, is there any prospect of Toolset implementing a more global, less cumbersome way of defining relationships between posts? For example, you could say "wherever the value in Field1 of Post Type A, matches the value in Field1 of Post Type B, display these fields from Post Type A and these Fields from Post Type B" it would make the process and flexibility much easier.

You would define the relationship globally once when creating the post type, and then whenever you insert the view, the fields of the related post or posts that match are always available to be displayed. I know this relationship can be established manually post-by-post, but that is too tedious when you have lots of data being added daily. So for example if you had a "venue" post type, anytime you added data to your "performances" post type in which the "venue" field in "performances" matched the "venue" field in the "venue" post type, the relationship would automatically be established.

[Shane]

Hi Briana,

Thank you for the patience, as Christian is currently on vacation I will be handling this ticket for him.

Related to the multiple nested views, is there any prospect of Toolset implementing a more global

Unfortunately not at the moment. Some setups will require multiple nested views and as such I would recommend the use of caching so that data doesn't need to be pulled from the database each time.

Since the recent update of our views plugin we have really tried to allow views to cache the posts better.

Take a look at the article below.
https://toolset.com/2019/05/toolset-views-2-8-1-with-performance-improvements/

Thanks,
Shane