I have looked at this code more thoroughly, and it's a really really bad design. The DB connection, using the mysql extension, is apparently (there's a connection being made in the setup code, but I doubt the main code is using it) being made in the encrypted logic, so, this code will fail with a runtime error on any system that doesn't have the mysql extension present. The encrypted code is also querying the general settings db table and is where the built-in pagination() function is at, which is also running a query. Until the author updates it to use any other database extension, this won't change, no matter what you do to the code.
What's really sad about this, someone updated the code to php5.3 level, but didn't bother to update the database extension. There is a database abstraction class being used in the setup code, that if all the code used, changing the database extension would have been simple, just update the extension the class is using.
So, if you still want to add the ability to do an 'all' search (if the author updates the db extension, you would still need this logic), for videos and images, here are some notes. This ignores the code for all the types except for videos and images.
1) The only place any db string escape function should be used is on the submitted keyword value, right before it gets used in an sql statement. All the other uses of the string escape function in this code are nonsense or noneffective. The submitted keyword value should also be trimmed before doing any validation on it, to make sure it isn't all white-space characters.
2) The first switch/case statement, on the type value, is setting up 'global' values that are used throughout the code when processing the data from the query. This means that the current code can only deal with one type at a time. The 'fix' for this is to add a literal value in the SELECT list in each query that identifies the type of the row, i.e. SELECT ..., 'video' as type, ... This will allow the processing code to make decisions using the type on a row by row basis.
3) The first switch/case statement would get an 'all' case and is where the UNION query would be formed to get data from both the videos and images tables. In the logic leading up to running the video/image db query, you would add the 'all' choice to the list of conditions so that the correct branch of code runs.
The same meaning columns in the queries being UNION'ed must be in the same position in each query. Any unique columns, such as the video_length, should be at the end of the SELECT list, with a dummy/filler literal value in the query that the data doesn't exist in.
4) There is a query inside the main while(){} loop that is only getting a count of comments for the current row being looped over. This can be replaced with a sub-query in the SELECT list in the main query to get the same count value. This will eliminate all the 'comments' code inside the while(){} loop.
5) The 'stars' code inside the main while(){} loop is running another query to get the updated_rating column value from the current row being looped over. By adding the updated_rating column to the SELECT list in the main query, there's no need to run a separate query. The stars code, a function call for videos and some logic in an included file for images, can all be made the same code and greatly simplified. I'll post an example below.
6) The template sections for the videos and images has some inconstant handling of the data. Cleaning this up will make adding a common template for the 'all' choice easier. In the case of the videos, the template has path information hard coded into it and the php code is only supplying the video_id value to the template. In the case of the images, the php code has path information hard coded into it and is supplying a complete url to the template. The 'fix' for this would be to add a 'video' section to the switch/case statement in the php code to build the complete url in the php code and supply just the complete url to the template.
There is also the leading part of a path in a href = '...' that's different between videos and images. This would be supplied by the php code to the template.
The only other difference between videos and images, is videos have a video_length section in the template. This should be handled with some conditional logic in the template, i.e. if there is a value, output that section of markup.
7) Loose-ends. There are some php variables that get displayed by the template. When the type choice is 'all', this would result in 'All' being display, rather than 'Videos' or 'Images'. There is also a $url_link variable that would need to be resolved as to how it is being used/displayed and what happens if it contains the 'all' value.
The following attached file is the search.php code, with all but the video/image logic removed, with code that's not needed/replaced commented out. This is incomplete and untested, basically, just thinking through the problem.
[ATTACH]5339[/ATTACH]
search.notes.php.txt
