[Resolved] Notice: Trying to get property 'query_type' of non-object

[Author]

Posts

[smileBeda]

This happens on several views:

Notice: Trying to get property 'query_type' of non-object in /toolset-blocks/vendor/toolset/dynamic-sources/server/Integrations/Views/Internals.php on line 227

I have no steps to replicate this, but the code clearly leaves room to fail, see error file on line 227 where:

  if ( 'posts' !== $view->query_type ) {

It never checks if $view is an object or exists at all. The error is self-explaining in regard.

I have no time to replicate it on clean, but it happens on several views built on a site.
I can't deliver duplicate to the site, it's too big, and the error is even if not replicable, adjustable in code by rewriting it without assuming object exist.
It seems however it happens only on Native WP Posts (at least in my online tests) which would also again confirm the line of code which is checking explicitly on post type "posts".
It happens both with blocks or views, as said the code is 100% indicating room for failure, the least would be to check if is object or exists, but DEV may want to know why there is no $view object to begin with.

It'd be nice if we could solve this without disabling error logging but instead fixing it in Toolset, thanks.

[smileBeda]

Just adding a detail, on the site I found that when loading the pages where the views are used and the error appears, if we pass any valid View URL argument like &wpv_aux_current_post_id=54106&wpv_aux_parent_post_id=54106&wpv_view_count=54183&wpv_paged=2, then the errors do not happen

My views use all "Do not update urls" and AJAX pagination/seraches, but I tried to switch back to static methods and the error happens as long there is no URL argument. As soon there is an URL argument the error disappears.

Maybe this can help narrowing down the core issue

[Christian Cox]

Thanks Beda, I'll run some quick tests and see if this is replicable on a test site.

[Christian Cox]

Okay I created a View of native WP posts but didn't see any errors in the logs. I added some post relationships:
one to many with posts as parent and cpt as child
one to many with cpt as parent and posts as child
many to many between posts and cpt
Still no errors in the logs.
I added some front-end filters by custom field and taxonomy term with no errors. Then I added front-end post relationship filters for each of the relationships above, testing one by one since you can only add one PR filter. Still no errors in logs.
I added a nested View of posts from the many-to-many cpt, with a post relationship filter set by the current post in the loop: no errors
I added a nested View of child posts with a post relationship filter set by the current post in the loop: no errors
I added a nested View of parent posts with a post relationship filter set by the current post in the loop: no errors.

So I'm not having much luck. Can you include screenshots of one of the error-causing Views on the front-end? Can you include screenshots from the same View's editor in wp-admin? From the View editor screen, can you copy + paste the code from the Loop Editor, the Search and Pagination panel, and the Output editor panel? Can you export Views from Toolset > Export and attach that export file here?

[smileBeda]

Hi Christian

I can give you access to the site, where I inserted a Fresh View with Blocks in the page hidden link
That View uses AJAX pagination, has a limit set (because otherwise it will load 15k posts), and simple loop output.

The error is visible on the front end twice (hidden link)

However just as you I was not able to replicate it yet clean either.

I already tried to disable all plugins which did not bring any change.
(Inclusive removing Elementor and using another theme)

I am certain the code is error prone, but of course, it is tricky if we do not know what precisely triggers it.

Please enable private area if you think this will help to narrow the issue down.
Note, I do not use any relationships or similar, and translation is not yet made, this somehow happens as soon I add a pretty basic View.
It Does also not disappear with no pagination, but I can't test "no limit", the site will crash (too many posts)
I also tried switching the post type queried, it also did not solve the issue.

[smileBeda]

There is another similar error, this time Notice: Undefined index: id in /toolset-blocks/backend/Services/WPMLService.php on line 33
The steps are the exact same, just that this time I use a Taxonomy View, which is inserted in a Post View, which is inserted in an Author Archive.

Again, the code is prone to errors; it assumes like the error mentioned first that data exists.
Line 33:
$id = $view_data['general']['id'];
It is never checked if the populating code (get_post_meta( $id, '_wpv_view_data', true );) actually gives some results.

Yes, my approach may be unusual of nesting views, but, if an unusual approach triggers an error in php it is because the php is not ready to handle all cases or/and the GUI should not allow for it. I think, that code can be optimised as it is not safely checking if data is/exists before accessing properties of it.

Such code is almost granted to fail sooner or later, no matter how we (may or may not) replicate it.
It is not safe to access data without checking if it exists or providing fallbacks.

A debug tool will tell when and why that data could be used indicating what settings affect it, so maybe it will not even be required to replicate the actual issue.

I have unfortunately not time for deeper debug, I will simply fix it in the plugin copy of this site for now by checking if data exists. This will resolve the notices on our site, but not the potential issue in Toolset of course.

I start to think both errors may be connected to WPML Toolset since the last error happens in a WPML related part of the Toolset code.
But I did not yet figure out how it would relate.

[smileBeda]

PS:
I cannot export the views, because it is Toolset Blocks, even if activating "legacy" mode the export for views is disabled/not there.
Exporting as Reusable Block also does not work, because if you import that to your site it will tell the view does not exist.

Anyway, I was not able to replicate the issue on a clean vanilla install. It seems a very edgy case, but definitely somehow I managed to trigger it without any Custom PHP application hooked to the views or any part of the site.
We use vanilla Theme (and I tried with other theme like 2020), and I tried without other plugins, in which case the main reported error still appears.

Logically in this case locally it should happen too, but as you found as well, it does not.
I also tried nesting Views into each other, playing with limits, offers, and all such, at no avail, the errors where not happening.

Worse, locally that line does not even trigger on any View I created.
Meaning the logic never reaches the line on any of the Views I tested locally.

I then saw the whole class there is used to handle dynamic sources.
So I need fields, with dynamic sources, maybe in the view loop.
This seemed to have at least triggered the line of code, so I could dump its content which is always the WPV_View Object as the code expects, so I still cannot trigger the error...

Eventually this happens only when the View has a CT styled with Blocks Dynamic Sources and maybe only if one of those fields somehow returns no content, or else, I did not yet spot the precise difference, but it must be there, the error does not trigger itself because of a mood, I just can't put my finger on the exact detail yet.

The code also handles Content Template assignment, which is again something I did not consider in local testing...

I've had bugs like that in past and usually, when the code lets room to fail, and we don't know why - it still is a bug, that somehow is triggered, and sometimes adjusting the code may be faster than finding the steps.

Please let me know if you want to login - I can provide the login data in the private forms.
Or if I can help with any other detail, please let me know.

Also added screenshots as requested, and below the code of the block, since this is a fully vanilla Block View...

<!-- wp:toolset-views/view-editor {"reduxStoreId":"views-editor-1600321737335","viewId":54493,"viewSlug":"testing-support","previewId":54494,"insertExisting":"0","wizardDone":true,"wizardStep":3,"cached":false} -->
<div class="wp-block-toolset-views-view-editor wpv-gutenberg-view-wrapper-54493"><!-- wp:toolset-views/view-layout-block -->
<!-- wp:toolset-views/view-template-block {"storeId":"views-editor-1600235970368","style":{"cssClasses":[]}} -->
<div class="wp-block-toolset-views-view-template-block wpv-block-loop-item php-to-be-replaced-with-shortcode" data-toolset-views-view-template-block="1"><!-- wp:toolset-blocks/heading {"dynamic":{"content":{"isActive":true,"provider":"__current_post","source":"post-title-with-link"}}} -->
[tb-dynamic-container provider='__current_post' source='post-title-with-link' field='']<h2 class="tb-heading" data-toolset-blocks-heading="1">[tb-dynamic provider='__current_post' post='current' source='post-title-with-link' force-string='first' ]</h2>[/tb-dynamic-container]
<!-- /wp:toolset-blocks/heading --></div>
<!-- /wp:toolset-views/view-template-block -->

<!-- wp:toolset-views/view-pagination-block /-->
<!-- /wp:toolset-views/view-layout-block --></div>
<!-- /wp:toolset-views/view-editor -->

[smileBeda]

Error One:
Notice: Trying to get property 'query_type' of non-object in .../toolset-blocks/vendor/toolset/dynamic-sources/server/Integrations/Views/Internals.php on line 227

This happens because the actual $view_id in the file line 215 returns a View ID that does NOT exist.
In our site for example it is View ID 54367, and that is not a view. If you try to edit such post with that ID all you get is You attempted to edit an item that doesn’t exist. Perhaps it was deleted?

So, for whatever reason that is not my place to find out the code gets a ID of a View that does not exist (may have existed?)
I checked the page with the error and there is no left over View with ID 54367 or any reference of 54367 in the source code.
I am at a loss why Toolset Views source code delivers a View ID that does not exist (anymore?).
But precisely for this reason the subsequent code then fails.

So the issue the developers need to figure out is why they get inexistent View IDs in that code, rather than check if the object of it exists, as an inexistent View never will have an object.

This View ID is somehow, mystery, added to the $block in the same code. If you analyse that, you will see that $block has viewId equal to 54367, but that does not exist!!

It says as slug that view has autres-articles-qui-pourraient-vous-interesser-meme-rubriques-single-posts, but that is a View that is not included on this page, and as I can check in the backend, again does not exist.

But at least this lead me to the reason why this mess happens.
The Single Post Content template at some point held a view autres-articles-qui-pourraient-vous-interesser-meme-rubriques-single-posts, but that view changed to autres-articles-qui-pourraient-vous-interesser-single-post-section.

I can see in the debug data that the TITLE of the view is correct, whereas the ID and slug are not.

I think at this point I gave enough hints to DEV to find out what is going on even without steps (which might implicate to change CTs
assignments and names of views during the process).

I can NOT fix this with a dirty hack because further down the line, Views again requires actual data to be provided, and will fail if I just skip the line.

Please forward this to the developers, if possible.

For the second error instead:
Notice: Undefined index: id in .../toolset-blocks/backend/Services/WPMLService.php on line 34

Here, the debug tells me that $view_data is structured like so:

array(2) { 
  ["id"]=> int(0) 
  ["general"]=> array(4) {
    ["preview_id"]=> int(0)  
    ["parent_post_id"]=> int(0) 
    ["initial_parent_post_id"]=> int(0) 
    ["view_template"]=> string(0) "" 
  }
} 

But Toolset tries to access this data like so:

$id = $view_data['general']['id'];

I am not sure what is expected from that but errors are expected.
It tries to access a ID of General, while these are not nested arrays but 2 items of the same array.

This as well should not require any further steps unless a fix in the code. I can fix this one, but it also worries me that the ID here is 0, I am 99% this is not expected, and probably the same BUG as the previous one, where Toolset tries to access data of views that do not exist (anymore?).
This obviously is happening only when WPML is used, which may be the reason you did not yet run into that issue.

Thanks, it is relatively urgent.

[Christian Cox]

Private fields are enabled here, please provide login credentials and I will take a closer look. Thanks Beda!

[Christian Cox]

Okay I've spoken to Nigel and I will assign to him. He can share details of where in the code the points of failure seem to be that Beda highlights (where a simple test to check something exists before trying to use it should suffice) with the developers to see if we can make minor edits for that.

[Nigel]

Hi Beda

I had a brief discussion this morning with the devs about this, and agreed I'd look into it more to confirm steps and if possible reproduce.

I've been busy escalating and reporting issues all day and didn't get chance to do that yet, I will tomorrow. I took a dump of your database and have it installed locally which should help with testing.

[Nigel]

Sorry Beda, you'll note I haven't done that yet. We had an outage in the forum for several hours and are still trying to catch up.

This is a somewhat esoteric issue, I'll get to it as soon as I can.

[smileBeda]

Don't worry Nigel.

The last update of Toolset messed up everything so heavily that you actually can close this ticket.
Also, the client of this specific site chose to use WP GRID BUILDER over Toolset because that plugin can do a Post Date Search, and layout posts in a grid without slowing the TTFB to some 2 seconds and more.

This means, the site we discussed in this ticket is not anymore on Toolset development path.

Additionally issues with the latest update of Toolset are majorly more important and for now I have to remove Toolset from the equation on other sites, because it is producing me more work than saving it right now, unfortunately 🙁

I leave it to you to close/keep open here, for me this particular ticket/issue has no urgency anymore.

[Nigel]

OK, well, I won't worry, but I will look into it.

I've been poking around on the copy of the site I have installed locally, and I've just put some questions to the devs, and I'll see whether there is much more I can do without it costing too much in time...

[Nigel]

Hi Beda

We've had a spell of very busy weeks compounded by absences so this completely fell by the wayside and I haven't been able to return to it. Given the edge-case-ness of it and that your client has moved on to use another tool I will just close here after all.

Sorry I didn't get back with something concrete.