Custom fields to index

If you edit lib/common.php and find the line 396 (it looks like this: $a = preg_replace ('/<[^>]*>/', ' ', $a);) and add this before it:

var_dump($a); exit();

what do you get if you try building the index?

Thanks for your help Mikko.

It doesn’t fail on the first pass of that function, but the var_dump for the problem iteration can be seen here, https://screencast.com/t/Re2AsfnZ36. Not exactly sure how that object is getting in there, but this site did have a bunch of plugins before, a couple of them mention shortcodes in their description, Special Recent Posts PRO Edition, WP Compare Tables, and WP-Table Reloaded. The Post itself however has no shortcode and has been stripped down to just ‘test’ in the content, no custom fields or categories or anything.

For now, I’ve just added if ( ! is_string( $a ) ) { return; } to the top of the relevanssi_remove_punct function. This has the index building again, but obviously not the best solution for long-term.

Does that help point you in the right direction?

Thanks again!

Philip

Hmm, that’s strange, I can’t even find that “has_desktop_shortcode” mentioned in the WordPress source code.

I’d take a look at one step higher – what data is the relevanssi_tokenize() getting, before it’s tokenized and passed to relevanssi_remove_punct()? If you add a var_dump($str); in the relevanssi_tokenize(), right at the top of the function, what do you see?

I get the same problem. I think maybe the problem is that the relevanssi_remove_punct receive strings, NULL values, and objects. I also can get it working with if ( ! is_string( $a ) ) { return; }

Maybe the function should do some checking if type is not string?

Yes, that’s an easy thing to add, but on the other hand I don’t like that, as it’s then just covering another problem – the function should never receive anything but a string. There’s a problem if that happens, and covering the problem may lead to other problems elsewhere.

Sorry for the delay but was able to zero in on the problem. Adding var_dump at top of relevanssi_tokenize() gives pretty much the same thing when the problem iteration goes through, https://screencast.com/t/uj9IarzgeV.

I hunted down though the particular call to relevanssi_tokenize() which was line 292 of indexing.php, https://screencast.com/t/VXo3hrHD98 and looked at which post_id was throwing the error and then went and looked at the ACF fields for that post which included a Relationship field that specifically gives the option to either return a Post ID or Post Object, https://screencast.com/t/xLOIhp6uMpG. This was set to Post Object in my case.

I changed it to Post ID as a test and the indexing was then able to process (well, at least until it hit the next Relationship field). There are other ACF fields that let you choose a Post Object as well. Not sure what the right answer is from here but that’s where its coming from anyway.

Thanks much and keep up the good work!

Philip

Yeah, looks like custom fields can occasionally contain objects. Someone actually sent me a solution that doesn’t just discard the data, but instead reads it in a meaningful way. Next Relevanssi version shouldn’t have a problem with these cases.