About three years ago, I attempted a port of Sphider to WordPress. What did result was buggy and incomplete. The Search tab on this blog actually contains a sample of what came out of the effort.
Among the MANY problems:
1. It gives more results that is really desired, making it pretty useless.
2. If the number of results goes beyond one page… well, it breaks if you try go to the next page!
3. Suggestions don’t even begin to work.
4. The effort was based on Sphider 1.5.1, and PHP has advanced since then. Now I can’t even get a screen to do a re-index if I wanted to.
5. It is VERY difficult to integrate into a WordPress theme.
6. There are other issues, but they don’t come to mind off hand.
So, in a nutshell, that attempted port was a dud. An laughable and unmitigated disaster might be a good way to describe it.
Now, Sphider seems to be stable (famous last words?), and I am often a glutton for punishment, so I am THINKING about trying again… kind of a Sphider for WordPress, Take 2, pre-alpha…
This would have to be thought out before actually doing anything, but these are my considerations so far:
1. History has taught that not all hosts provide the MySQLnd module for PHP. Therefore any future WordPress port would need to be based on the PDO Sphider. Version 2 supports PHP 7.1, so that would be the beginning basis.
2. WordPress uses its own class, the wpdb Class, to interact with the database. So code would need to be changed to use wpdb. That is a LOT of code… BUT… why would the spider part of Sphider need to use the wpdb class? Spidering (indexing) itself really doesn’t need to be integrated into WordPress, does it? All it is doing is populating the sphider database. So why couldn’t the spider and search functions of Sphider be separated? The only thing those two functions currently share with each other is the database connection. The current spider part could remain as is (with some modifications specific to WordPress page needs), and only the search function be rewritten to use the wpdb class (with its own database connection). Both functions would connect to the same database but in different manners.
3. Would a WordPress Sphider really need to use categories as used in Sphider? I am thinking not. So scratch that capability. I don’t think we need RSS feed indexing or image indexing, so those can also be cut. We are only concerned with a single site (the blog on which it would be installed), so more code simplification. This all reduces the size and complexity of spidering (indexing).
4. Perhaps embedded into the indexing function would be the elimination of looking it unnecessary places, like /wp-json, /category, /feed… This would reduce the size of the database and eliminated some of the redundant “finds” when a search is performed.
5. Naturally, the search function would eliminate RSS and image search functions and retain the keyword search.
6. Try to get the search page to more easily integrate with themes.
7. Get the multipage search returns to function, forward and backward, without producing an error.
8. Get suggestions to work.
Okay. Before I get in too deep…
1. Is there any real interest in a Sphider for WordPress?
2. Anything I’m missing in thinking ahead?
3. Anybody have any experience integrating content into WordPress themes? Care to share?
Feedback would be appreciated. In fact, without feedback, I may conclude the whole idea is more trouble than it’s worth.
UPDATE: So… I got brave and changed my theme. And the theme had the ability to add a Search widget. And playing around with this simple search, it seems to work just fine. Granted, it is just a simple search, not one with and/or or phrase options, but quite functional nonetheless. I have to imagine any decent theme can do the same thing. Unless there is really a big need for a Sphider for WordPress, I think I’ll save myself the trouble and pass. 🙂
