Jump to content

Profile Error


Midnight Modding

Recommended Posts

The following line from Search/Results.php...

return static::current();

is causing an error on "some" member profiles. it's hard for me to tell if it's my app causing it, since the error is so general (due to Search not having our own files in the trace).

Error: Class name must be a valid object or a string (0)

Any idea what on my end could lead to that? Could it be related to my content item where a dummy row is added on install and that one row is always used as the parent? Search has worked fine elsewhere.

This only happens on some members' profiles, not all.

I posted about this same issue a while back, but I can't find it and I thought I fixed it.

Link to comment
Share on other sites

Rebuilding the index solves it for me too... for awhile until it happens again.  Then I rebuild the index and wait.

But like you said, my issue might be totally different from yours, we just happening to be getting the same error. 

Hopefully it won't happen again for you, but if it does let me know.

Link to comment
Share on other sites

Well, I remember reading where yours was happening with some third party app, I think? So I want to be sure my app isn't causing this somehow, but I didn't set up any particular logging. I'm hoping it is indeed just something related to uninstalling/re-installing the app, because that's the only times I've seen it happen on mine, so far.

Link to comment
Share on other sites

Uninstalling an app should remove its content from the search index, but as a first trouble shooting step I would indeed rebuild the search index manually and see if it happens again. If it does, you'll want to find out if you're somehow leaving orphaned results in the search index (which is what causes the error you're seeing).

Link to comment
Share on other sites

4 hours ago, bfarber said:

Uninstalling an app should remove its content from the search index, but as a first trouble shooting step I would indeed rebuild the search index manually and see if it happens again. If it does, you'll want to find out if you're somehow leaving orphaned results in the search index (which is what causes the error you're seeing).

Deleting a content item or node will automatically remove them, right? And I do nothing unusual with uninstall or search myself.

Link to comment
Share on other sites

Typically, yes, deleting content items and nodes will remove associated data from the search index automatically.

But if you overrode the delete() method in your content item class, for instance, and didn't call the parent method then it might not. All I can tell you is what will typically happen - it is possible to inadvertently (or intentionally) "break" that behavior in a custom app.

Link to comment
Share on other sites

Nah, I didn't forget to call the parent any time I overrode function delete() (just checked to be sure). But this has only happened after an uninstall and re-install. I'd assume it's got to be a bug in the suite software somewhere since I didn't do anything to stop those methods. If it only happened once, I'd have thought well maybe it was some fluke due to a server issue or something, but when it's happened on my test site and his, I would doubt that.

Hopefully it's only in that one situation involving uninstall, though, that way at least it would be fixed with one search index rebuild.

Link to comment
Share on other sites

This is one I really think just has to be a bug in the IPS uninstall process. I know what you said as far as me needing to create a ticket if I do end up feeling it's a bug, so I'll just see how things go, in case it's something else. But since I call those parent methods and don't do any of my own uninstall code etc... I can't think of a way it could be on my end.

If somehow it does end up on my end, the only thing I can think of is maybe something odd about my one content item class that uses the same dummy node as the parent for all items in that class. I doubt that's an issue, though.

Link to comment
Share on other sites

Can you reproduce the issue with any of our default applications (all of which leverage the search index)?

If not, it's probably not a bug in the core software. 😉 If the only place an issue is experienced is with your custom application, the bug is probably in your custom application somewhere. 

Link to comment
Share on other sites

I "think" it's because I put my item classes in $embeddableContent in my ContentRouter. The dev docs on here didn't explain it back then and I misinterpreted the doc block in the file and thought it meant to add classes only IF they are embeddable, when it really means to add classes if they are ONLY embeddable (not the content item classes).

I still don't see in the code where that would have caused it, but I ended up in that file after backtracking through files, starting with:

\IPS\Content\Search\Index::i()->removeApplicationContent( $this );

While I agree issues only experienced with a custom app are likely to be something in the app, I've found quite a few later confirmed board/suite bugs over the years where the first party apps weren't affected, as well.

This one I wasn't 100% sure if it was a bug, but many I am.... those dev center ones are bugs. (sure it could be said anything in dev center isn't technically a bug, but it's a bug to anyone using dev center). They can easily be reproduced.

Speaking of bugs on my end... I've had an annoying number of them be due to a typo here or there because of not being used to this keyboard...

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...