Search not working after upgrade to vBulletin 4.2.2 Patch Level 4

[MrEyes]

Hello all,

After upgrading from 4.2.2 PL1 to 4.2.2 PL 4 the site searching no longer work, i.e. when users visit the following link (New Posts):

mysite.co.uk/search.php?do=getnew&contenttype=vBForum_Post

They following message:

Sorry, there are no new posts to view.

You may search for posts updated during the previous 24 hours, here

Also worth noting that the word 'here' in the message above links to:

mysite.co.uk/search.php?do=getdaily

and that results in the following message:

Sorry - no matches. Please try some different terms.

Worth noting that there definitely are new posts

As another example, the site is motorbike related so it is a word that is used very often. If I search 'motorbike' I get:

Sorry - no matches. Please try some different terms.

Queue Search Updates is set to yes and the scheduled job is active and set to trigger every 10 minutes. As per usual I have disabled all plugins and still get exactly the same behaviour. I have also run command line mysqlcheck against the DB and this has not highlighted any issues

Any ideas?

EDIT: When running mysqlcheck I did notice a number of tables I don't recall seeing before. All with names as follows (the number at the end changes):

taggregate_temp_1410699360

Is this potential and indication of a failed upgrade? i.e. temp tables being left behind?

[kh99]

EDIT: When running mysqlcheck I did notice a number of tables I don't recall seeing before. All with names as follows (the number at the end changes):

taggregate_temp_1410699360

Is this potential and indication of a failed upgrade? i.e. temp tables being left behind?

Those are created by the scheduled task that updates thread view counts. They shouldn't really be hanging around, but it doesn't have to do with search or with upgrading.

[Gio~Logist]

Try rebuilding your search index and see if that helps. I would also clear my "searchlog" table if you're familiar with doing so.

[MrEyes]

Rightio, I have rebuilt the searchindexes using the command line utility as this is a mid to large site and doing this via ACP isn't really viable.

Unfortunately this made no difference, the problem still remains.

Regarding the suggestion of clearing the search log. Are you talking about done a delete from / truncate of the searchlog table? Fairly simple to do via SQL admin but thought it better to check before I wade in with a delete command :)

For reference, here is the output from the reindex:

[root@s17738471 temp]# php searchindex.php
PHP Warning: PHP Startup: apc.shm_size now uses M/G suffixes, please update your ini files in Unknown on line 0
Please enter the path to your vBulletin directory: /var/www/vhosts/mysite.co.uk/httpdocs/
Rebuild Search Index
--------------------
Note:
You should not normally need to empty the search index, however if items are showing in search results after they have been permanently deleted then emptying the index and rebuilding the search index will fix this. Search will not work correctly after emptying the index until the index is fully rebuilt.
Click Here to empty the search index.
Empty Index [0/1,Default=0]:

0) All
3) Forums
1) Posts
7) Groups
5) Group Messages
11) Visitor Messages
16) Blog Comments
15) Blog Entries
Content type to index [Default=0]: 0
Turn off DB indexes during rebuild [0/1,Default=0]: 0
Item id to start at [Default=0]:
Number of items to process per batch [Default=10000]:

Building Search Index Forums ...
IDs 0-140 ... Done (0.22 sec)
Building Search Index Forums: Done
Building Search Index Posts ...
IDs 0-10000 ... Done (26.08 sec)
IDs 10000-20000 ... Done (26.84 sec)
IDs 20000-30000 ... Done (25.90 sec)
<snip>


My SSH connection timed out at around 140k, so after logon I restarted the index at 140k - the only difference was that I set the rerun to use 1000 batches rather than 10000 as this made progress more obvious. The following is the last few lines of the output


IDs 2346000-2347000 ... Done (4.88 sec)
IDs 2347000-2348000 ... Done (2.38 sec)
IDs 2348000-2348538 ... Done (1.53 sec)
Building Search Index Posts: Done
Building Search Index Groups ...
Building Search Index Groups: Done
Building Search Index Group Messages ...
Building Search Index Group Messages: Done
Building Search Index Visitor Messages ...
Building Search Index Visitor Messages: Done
Building Search Index Blog Comments ...
Building Search Index Blog Comments: Done
Building Search Index Blog Entries ...
Building Search Index Blog Entries: Done
Building Search Index: 0 hours, 59 minutes and 00 seconds

[edgeless]

Did you issue the REPAIR TABLE quick commands for searchcore_text and searchgroup_text, and then rebiuld the FULLTEXT indexes, and then drop the old indexes from the tables, and then create new FULLTEXT indexes for searchcore_text (title, keywordtext) and searchgroup_text (title)? That has worked for me in the past to straighten out various db search issues.

[Lynne]

Try disabling your server caching (apc?) and see if search works then.

[MrEyes]

Short story, still no worky

Long story....

I have stopped APC* by disabling at both PHP (via apc.ini and then restarting httpd) and also vBulletin (config.php). I also confirmed it was stopped by loading the APC admin panel and getting the following:

No cache info available. APC does not appear to be running.

I have also issued the following two SQL commands:

REPAIR TABLE searchcore_text QUICK
REPAIR TABLE searchgroup_text QUICK

Per SQL docs these should rebuild the full text indexes.

As mentioned, neither solution fixed the issue.

* As an APC related aside I have fixed the PHP warning warning that came up when running searchindex.php via the command line (i.e. PHP Warning: PHP Startup: apc.shm_size now uses M/G suffixes, please update your ini files in Unknown on line 0)

[edgeless]

This is what has worked for me...

Temporarily turn off forum access from the vB ACP... at Settings > Turn Your vBulletin On and Off.

If you have modified full-text variables that affect indexing or changed the stopword file itself, you must rebuild your FULLTEXT indexes after making those changes and restarting the MySQL server.

To restart the MySQL server, use the following command:

service mysql restart

Next, log into a MySQL terminal session.

To rebuild the indexes it is usually sufficient to do a QUICK repair operation with:

mysql> REPAIR TABLE searchcore_text QUICK;
mysql> REPAIR TABLE searchgroup_text QUICK;

Next, restart the MySQL server again:

service mysql restart

Next, rebuild your FULLTEXT indexes. To rebuild your indexes, you need to run the follow queries in sequence...

But before doing so, emptying your search tables will speed things up. The queries to empty the tables are:

truncate searchcore;
truncate searchcore_text;
truncate searchgroup;
truncate searchgroup_text;

Next you need to drop the old indexes off the tables. To drop the indexes, use the following commands:

drop index text on searchcore_text;
drop index grouptitle on searchgroup_text;

Finally, you need to build new indexes. To recreate the specific indexes, use the following commands:

CREATE FULLTEXT INDEX text ON searchcore_text (title, keywordtext);
CREATE FULLTEXT INDEX grouptitle ON searchgroup_text (title);

You can then go to your vB ACP and do an interface-executed rebuild session from there. To do this, go to the Maintenance > General Update Tools section of your vBulletin ACP. You optionally may want to empty the indexes from there before starting the rebuild process.


Note: My search functionality wouldn't fully return until I did the following.

Go to the Maintenance > Repair / Optimize Tables section of your vBulletin ACP and optimize the post and thread word tables.

Next, you should probably then go to the Forums & Moderators > Forum Blocks Manager section of your vB ACP and click on Reload Block Types.

Finally, re-enable your general forum access from the vB ACP at Settings > Turn Your vBulletin On and Off.

Done.

--------------- Added 1423066500 at 1423066500 ---------------

One more noteworthy observation... I have noticed that after performing the above steps, there has been a significant latency period before the search function returned to normal. I'm assuming that such 'lag' to gain back correct search functionality is related to size of the particular database and the processor speed of the hosting machine in conjunction and how quickly those elements can complete the necessary work to restructure the indexes for the entire database. But that's merely a guess on my part. The main point is that once you've performed the above steps, you may want to give it a bit of time before concluding that things haven't changed.

[Gio~Logist]

Wow, that's quite the headache. Glad you're finally sorted though :up:

[MrEyes]

Had to wait for the weekend to try the above...

Drum roll please....

It didn't work, still the same issue as described above (for more info on the steps performed see below)

As a curious aside, one member was reporting that search was working for them. Turns out what they were doing was going into Advanced Search and under single content types selecting "show results as posts". Which is curious.


VB ACP -> Settings -> Options -> Turn Your vBulletin On and Off -> Turn site off

[usr@xxxxxx ~]# /etc/init.d/mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]

[usr@xxxxxx ~]# mysql -h 127.0.0.1 -p -u USERNAME DATABASENAME
Enter password:

mysql> REPAIR TABLE searchcore_text QUICK;
+--------------------------------+--------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------------------------------+--------+----------+----------+
| mydb.searchcore_text | repair | status | OK |
+--------------------------------+--------+----------+----------+
1 row in set (40.89 sec)

mysql> REPAIR TABLE searchgroup_text QUICK;
+---------------------------------+--------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+---------------------------------+--------+----------+----------+
| mydb.searchgroup_text | repair | status | OK |
+---------------------------------+--------+----------+----------+
1 row in set (0.10 sec)

mysql> exit
Bye
[usr@xxxxxx ~]# /etc/init.d/mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]

[usr@xxxxxx ~]# mysql -h 127.0.0.1 -p -u USERNAME DATABASENAME
Enter password:

mysql> truncate searchcore;
Query OK, 0 rows affected (0.00 sec)

mysql> truncate searchcore_text;
Query OK, 0 rows affected (0.11 sec)

mysql> truncate searchgroup;
Query OK, 0 rows affected (0.01 sec)

mysql> truncate searchgroup_text;
Query OK, 0 rows affected (0.00 sec)

mysql> drop index text on searchcore_text;
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> drop index grouptitle on searchgroup_text;
Query OK, 0 rows affected (0.00 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> CREATE FULLTEXT INDEX text ON searchcore_text (title, keywordtext);
Query OK, 0 rows affected (0.00 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> CREATE FULLTEXT INDEX grouptitle ON searchgroup_text (title);
Query OK, 0 rows affected (0.00 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> exit
Bye

[usr@xxxxxx]# php searchindex.php
Please enter the path to your vBulletin directory: /var/www/vhosts/mysite.co.uk/httpdocs/
Rebuild Search Index
--------------------
Note:
You should not normally need to empty the search index, however if items are showing in search results after they have been permanently deleted then emptying the index and rebuilding the search index will fix this. Search will not work correctly after emptying the index until the index is fully rebuilt.
Click Here to empty the search index.
Empty Index [0/1,Default=0]: 1

0) All
3) Forums
1) Posts
7) Groups
5) Group Messages
11) Visitor Messages
16) Blog Comments
15) Blog Entries
Content type to index [Default=0]: 0
Turn off DB indexes during rebuild [0/1,Default=0]: 0
Item id to start at [Default=0]: 0
Number of items to process per batch [Default=10000]: 1000

Building Search Index Forums ...
IDs 0-140 ... Done (0.11 sec)
Building Search Index Forums: Done
Building Search Index Posts ...
IDs 0-1000 ... Done (2.94 sec)
IDs 1000-2000 ... Done (2.44 sec)
IDs 2000-3000 ... Done (2.61 sec)
IDs 3000-4000 ... Done (2.97 sec)
<SNIP SNIP SNIP>
<SNIP SNIP SNIP>
<SNIP SNIP SNIP>
<SNIP SNIP SNIP>
<SNIP SNIP SNIP>
IDs 2347000-2348000 ... Done (3.50 sec)
IDs 2348000-2349000 ... Done (3.88 sec)
IDs 2349000-2350000 ... Done (2.75 sec)
IDs 2350000-2350784 ... Done (2.58 sec)
Building Search Index Posts: Done
Building Search Index Groups ...
IDs 0-48 ... Done (0.14 sec)
Building Search Index Groups: Done
Building Search Index Group Messages ...
IDs 0-1000 ... Done (3.30 sec)
IDs 1000-2000 ... Done (3.14 sec)
IDs 2000-3000 ... Done (3.87 sec)
IDs 3000-4000 ... Done (3.48 sec)
IDs 4000-5000 ... Done (2.17 sec)
IDs 5000-6000 ... Done (3.24 sec)
IDs 6000-7000 ... Done (3.05 sec)
IDs 7000-8000 ... Done (1.84 sec)
IDs 8000-9000 ... Done (3.54 sec)
IDs 9000-9584 ... Done (0.33 sec)
Building Search Index Group Messages: Done
Building Search Index Visitor Messages ...
IDs 0-1000 ... Done (3.10 sec)
IDs 1000-2000 ... Done (3.42 sec)
IDs 2000-3000 ... Done (3.36 sec)
IDs 3000-3882 ... Done (2.81 sec)
Building Search Index Visitor Messages: Done
Building Search Index Blog Comments ...
IDs 0-1000 ... Done (0.85 sec)
IDs 1000-2000 ... Done (1.13 sec)
IDs 2000-3000 ... Done (3.13 sec)
IDs 3000-3345 ... Done (0.83 sec)
Building Search Index Blog Comments: Done
Building Search Index Blog Entries ...
IDs 0-1000 ... Done (2.89 sec)
IDs 1000-1265 ... Done (0.94 sec)
Building Search Index Blog Entries: Done
Building Search Index: 2 hours, 22 minutes and 35 seconds
[usr@xxxxxx]#



VB ACP -> Maintenance -> Repair / Optimize Tables -> Select POST table -> Continue
post Check Status: OK
post Optimize Status: OK

VB ACP -> Maintenance -> Repair / Optimize Tables -> Select all thread tables -> Continue
thread Check Status: OK
thread Optimize Status: OK
thread_serviceupdate Check Status: OK
thread_serviceupdate Optimize Note: Table does not support optimize, doing recreate + analyze instead
thread_serviceupdate Optimize Status: OK
threadrate Check Status: OK
threadrate Optimize Status: OK
threadread Check Status: OK
threadread Optimize Status: OK
threadredirect Check Status: OK
threadredirect Optimize Status: OK
threadviews Check Status: OK
threadviews Optimize Status: OK

VB ACP -> Forums & Moderators -> Forum Blocks Manager -> Reload Block Types


VB ACP -> Settings -> Options -> Turn Your vBulletin On and Off -> Turn site on

[edgeless]

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

[MrEyes]

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

define('SKIP_DS_ERRORS', true);

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)

[edgeless]

Nope, I haven't touched anything like that. Cant speak for what the official VB patches will have done.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?

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

define('SKIP_DS_ERRORS', true);

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)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 :(

[MrEyes]

.....telling people to re-upload all of their source files to the hosting server....

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

[Lynne]

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?

[Mark.B]

Yeah, I've seen that before. They tend to gravitate toward not addressing actual causes for errors but rather hiding them
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".
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 :(
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.

[edgeless]

The fact you said that shows that you simply don't understand what adding that line of code does.Well, I know that it disables warnings. Are you telling me that it doesn't? Disable, conceal, hide... same difference, really.

So if it can fix things sometimes, what's the problem with suggesting it?It was merely an observation. Please calm down.

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?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.

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.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.

[MrEyes]

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.

[Mark.B]

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.
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 1423564788 at 1423564788 ---------------

Well, I know that it disables warnings. Are you telling me that it doesn't? Disable, conceal, hide... same difference, really.
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.

[edgeless]

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.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.

[Lynne]

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.
Awesome! That is odd though, but very good!

[Mark.B]

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.
To clarify: nobody's belittling anyone.

However, whenever people say "vBulletin is rubbish because it hides errors rather than fixes them" - which is what started to get implied in this thread, as it does in many others -that inaccuracy needs to be corrected, or at the very least, the true facts explained. many do not have the required knowledge to understand what is actually happening, they simply read "vBulletin hides errors rather than fixes them" and assume that to be factual. That perception needs to be corrected.

Some people make the statement because they genuinely think that's what happens - it is right that they should be corrected.
Others make the statement because they have a certain agenda - again it is right that they should be corrected.

I too get frustrated at the apparent interchangeability of the term "errors". When developers do it it's even more annoying. And as I already mentioned, vBulletin themselves compounded the issue by using "SKIP_DS_ERRORS" so I can fully understand why some people jump to the conclusion that we are "hiding errors rather than fixing them".

I also understand that, to an ordinary person using the software, an ugly line of text appearing on the page with the word "WARNING" at the front is, as far they are concerned, an error....you would say "I'm getting an error message on screen" not "I am getting a warning message on screen" if describing the problem.

What does frustrate me is when people such as Paul, who are actual php programmers, state what is really happening (and we as the support team often do also), and people argue and complain still (I'm not suggesting you do this by the way).

[edgeless]

To clarify: nobody's belittling anyone.

Ah, but you were. It was your first line of response to me.

However, whenever people say "vBulletin is rubbish because it hides errors rather than fixes them" - which is what started to get implied in this thread, as it does in many others -that inaccuracy needs to be corrected, or at the very least, the true facts explained. many do not have the required knowledge to understand what is actually happening, they simply read "vBulletin hides errors rather than fixes them" and assume that to be factual. That perception needs to be corrected.

But the way you go about correcting that perception indeed matters! Your persistent response to my initial use of the terms "errors" and "hiding them" was to assert that I simply don't understand what the SKIP_DS_ERRORS code directive actually does. And then in my subsequent reply when I termed what's being disabled by said code directive as "warnings", you condescendingly went on to imply that my interchanging of the terms confirms my failure to understand what the directive is in fact doing. I think that's quite a leap of an assumption on your part.

So the impression I've taken from your replies in this thread is why I've pointed out that certain vB developers themselves are inclined to characterize the role of the SKIP_DS_ERRORS code line as that of turning off the extra "error reporting". And by the way, fyi, I do understand that non-fatal run-time warnings don't halt the execution of associated functions, and that fatal run-time errors are unrecoverable (i.e., they result in termination of associated functions). It's not a very difficult concept to grasp in my opinion.

Lastly, I think you should be mindful that if I thought vB was "rubbish" I wouldn't likely be using it as a community platform. I hope that's at least some food for thought.

[MrEyes]

Awesome! That is odd though, but very good!

Indeed, very odd - thanks for noticing ;)

As for Mark and Edge, thanks but read point #2 in the post above ;)

[Eq4bits]

Did anyone ever figure out how to get the 'new posts' search to work? Topic got a bit derailed.......
My 'new posts' isn't working and I urgently need a FIX
no response at vB.com forums either.

[ForceHSS]

This is what I have and it works
search.php?{session.sessionurl}do=getnew&amp;contentty pe=vBForum_Post

[Eq4bits]

Thanks, where do I put that?

[kh99]

Well, you could just try typing in that url (with your forum root at the beginning) without the session stuff, like:
www.mydomain.com/forum/search.php?do=getnew&amp;contenttype=vBForum_Post

and see if that works. It should be the same as clicking the "new posts" link though.

[ForceHSS]

Thanks, where do I put that?
Sorry I thought you knew go to admincp/settings/Navigation Manager edit new posts tab and put it into Target URL do make sure you put it into the correct one as there are more than one if you click forum in the Navigation Manager you will see more so make sure you pick the right one

[Eq4bits]

n/m i found it in Navigation... it's what was already in there...
any other ideas?
Bueller? Bueller?

[kh99]

I just repsonded on vbulletin.com, but this is probably a better place to discuss the kind of thing I was talking about. What I posted over there is:

The only thing I can think of offhand is that when the forum is in debug mode, you can display the queries that were done when building a page, and if you click "new posts" you can then see the query of the thread table and what the cutoff timestamp is. I'm not sure if that will help figure it out or not. I suppose if you're not getting any results then it must be that the cutoff time is in the future, or there's an error of some sort.

OK, I looked at the code a little and looking at the query might help, because the other possibility is that some forums are being excluded for some reason.