This may seem like a strange question... but have you recently attempted to change to UTF-8 encoding from ISO-8859 ?

Nope, I haven't touched anything like that. Cant speak for what the official VB patches will have done.

For the sake of completeness, over on vb.com it was suggested that the following should be added to the config.php

I already had that line in my config.php. My changelog shows this as being there for over a year now (it was added to prevent some PHP error displaying after an upgrade)

Hmm, okay. Sadly, I'm at a loss. So no idea at all what may have led to your search functionality problem? Did anything that might be significant happen before you noticed it failing? Have you considered restoring the database to a point from before you noticed the search function was broken?

Yeah, I've seen that before. They tend to gravitate toward not addressing actual causes for errors, but rather hiding them. And another favorite fix of theirs seems to be telling people to re-upload all of their source files to the hosting server. I suppose that can fix things sometimes... but still :(

For the sake of completeness and as a preemptive measure I have just done that (everything but the images and install folders) :)

Stupid question but.... is your Search Type set to DB Search or Sphinx Search?

If it's set to DB Search, how many rows in your searchcore and searchcore_text tables?

Are there any errors in your error_logs (if you don't know where they are, ask your host) when you try to search?

Has anything changed on your server lately?

The fact you said that shows that you simply don't understand what adding that line of code does. It's nothing whatsoever to do with "hiding errors rather than fixing them".
So if it can fix things sometimes, what's the problem with suggesting it?

There are no "magic wands" in software support. If, for instance, someone has a corrupted file, whether it got corrupted in the download or the upload, how do you propose to fix that without uploading a fresh copy of the files?

It's one of the first things that gets suggested in cases like this, especially where someone has recently upgraded, because, in my personal experience, it fixes the issue in roughly 40% of cases. If it doesn't...well fine, we''ll try something else.

Support staff aren't magicians. We have to try a series of diagnostics to get to the bottom of what the problem is.

As for the case in hand, it's looking likely that a support ticket will be needed so we can have a look at what's going on in more detail.

Well, I know that it disables warnings. Are you telling me that it doesn't? Disable, conceal, hide... same difference, really.

It was merely an observation. Please calm down.

Perhaps by identifying which file is corrupted and replacing that file alone? But I understand that's not very easy to do or practical in many cases. Hence I get the reasoning behind the recommendation.

My point is that it seems the preferred approach in many cases rather than to try and identify which file(s)/code sections aren't working properly. Ok, granted, it makes sense in that uploading all of the files can be the shortest path to resolving a corrupted system and thus save a significant amount of time. I guess I'm just saying that it's an extremely common recommendation from vB support staff and that it's kind of reminiscent of OS support techs telling folks with OS issues they're not able to resolve to reformat and reinstall.

Sorry, I wasn't trying to offend anyone. I was merely replying to the OP with my spontaneous thoughts. Probably shouldn't have done that.

Three things....

1) Being somebody who works in IT I entirely get the "look at the basics / frequent / common issue first" way of approaching issues.

2) No point in turning this into yet another he said she said

3) Search on my site is working, no idea why. It started to work after a server reboot which I was doing for entirely different issues.

It's absolutely nothing like telling people to reformat and reinstall their Operating System!

It's asking people to dowbnload a fresh copy of the files, and upload them to the server. It doesn't wipe out the forum and start it from scratch, it merely replaces the existing files with new copies.

It's more similar to asking a computer user to reboot their computer and see if the problem continues.

If we were to site down and analyze every single file to establish if any of them were corrupt, this would be hours if not days of work. Would you be willing to be many thousands of pounds for your license in order that sufficient support staff could be recruited and trained in order to make this feasible while retaining realistic response times? Or would it be better to carry on saying "you may have a corrupt file, please donwload a fresh copy of the files from the members area and upload them to the server"?

Just because a solution is suggested a lot, doesn't make it an invalid solution. It's suggested a lot because it often works.

--------------- Added [DATE]1423564788[/DATE] at [TIME]1423564788[/TIME] ---------------

You're now saying "warnings" when previously you said "errors". The very fact that you're interchanging two entirely unrelated terms proves that you don't really understand what that line of code does, or why we use it. I don't mean that nastily, I'm just stating facts.

A php ERROR will, in most cases, stop execution of the code. Meaning, the page won't load, you'll usually either see just a white screen, or else you'll see a white screen with the actual error in black text, and usually little else. An error means there is an actual error in the code, of some sort, could be a syntax error, or calling an undefined function, or any number of different programming errors in the code.

A php WARNING is telling you something, but it does not normally stop the execution of the code (though if displayed on screen it may cause some functions to break or not operate correctly). The "something" it is telling you, is commonly that the function being used is "deprecated" - it will still work, but it may be removed in a future version of php. It os absolutely NOT an error, it's not rmeotely related to an error. A production server should, if it is set up correctly, be configured NOT to display these. However, many servers are not set up correctly, and thus display them. Ever since it started, vBulletin used to add code that supressed these php warnings in the event that the server was not configured to suppress them itself. In vBulletin 4.2.2, we stopped doing this. All that the line of code mentioned (SKIP_DS_ERRORS) does, is restore the previous behaviour.

The only confusing thing is that the word "ERRORS" is used in SKIP_DS_ERRORS, really it ought to be SKIP_DS_WARNINGS and then we wouldn't have this discussion coming up endelssly.

Short version: They aren't errors, and nobody's hiding any errors, there is nothing to "fix rather than hide", it's all perfectly legitimate.

The description by a number of your colleagues for the function of the SKIP_DS_ERRORS code string, including that from certain vB developers, has been that it "turns off the extra error reporting in php 5.3 & 5.4 (for strict & deprecated warnings)". The frequent use of this description -or others like it- demonstrates a common interchangeability of the two terms during discussion of said code string's function and purpose. Since even developers refer to the purpose of said code string as it "turns off the extra error reporting", I'm inclined to consider my reference to "hiding errors" as a completely appropriate statement. But even in view of this, I initially intended to type the word "warnings" instead of "errors"... I really did! And that's precisely why I used the term "warnings" instead of "errors" in my following reply. I think the mere fact that those two terms are interchanged on a frequent basis, even by software developers, tends to inspire some inadvertent interchangeability from many of us on occasion. And by the way, I've noticed that some developers even refer to said warnings as "less important errors". So in my opinion your focus on my semantical tendencies in order to try and belittle my qualification to comment has been uncalled for (at best).

As for the blanket file replacement troubleshooting measure, you've made your point. It makes sense and I agree with the reasons involved. Hence, I apologize for voicing my impulsive thought concerning the many times this step is suggested by vBulletin support folks. After all, as I've said, and as you've elaborated upon, it's not practical or time/cost efficient to identify corrupt files or code sections within a system when a direct blanket replacement of files is often able to solve the problems.