Well, it seems the Sphider Forum wasn’t fixed after all. Superficially it looked okay. You could log on and see what topics there were. But you couldn’t actually view any of the posts to the topics, or create a new topic. So a rebuild is being undertaken, since the repair didn’t work. I really hope the uploaded data is safe. Apologies to anyone wanting to use the forum.
Holiday VPS woes
On Sunday morning, December 23, one of the worst nightmares of a web host came true. A VPS server suffered a hardware failure. The hardware was repaired quickly enough, but restoration of the VPS server was another matter. The nightmares of the web host begat the nightmare of a webmaster. All four of the worldspaceflight sites went down. As restoration by the web host proceeded, worldspaceflight.com and sphider.worldspaceflight.com were functioning again Monday afternoon. Blog.worldspaceflight.com and forum.worldspaceflight.com were not so fortunate. There really wasn’t much that could be done until the VPS server restore was completed. For the uninitiated, restoring a VPS server is nowhere as simple of just copying a bunch of files back. IF ONLY! That restore was FINALLY completed Friday evening. Then it was discovered that the blog and forum were STILL not working. It turns out that for the blog (this site), there was a simple permissions problems which was quickly fixed. Three down, one to go. The forum is being stubborn. First, the entire cache directory (with needed driver files) was devoid of content. I THINK that is fixed, but now there may be ANOTHER permissions problem. We are working to resolve that. No guarantee there won’t be something else next, but hope springs eternal. The forum WILL be back.
Yeah, it has been fun, but PLEASE, let’s not EVER do this again!
Securing your Sphider
You may have read before that I have suggested securing the Sphider admin directory with password protection. After all, you don’t want to take a chance of someone else gaining access and changing all of your settings… or worse!
But Sphider has a number of other directories within it. What about those? Well, MOST of them can also be password protected. The rule is, if files in the directory only need to be accessed by PHP, it can be password protected. If any file in a directory needs to be accessed by a web browser, it shouldn’t be password protected. For example, the templates directory should not be password protected. It contains css files, which the browser needs to display search forms and results properly. Js_suggest should not be password protected, It contains javascript which the browser needs to access. The tmp directory (not the one in admin) should not be password protected as the browser needs to be able to read and write there. Other than that, go ahead and add password protection.
Oh! One more thing. Add SSL. That is something that at one time was expensive and primarily used by sites like businesses with checkout pages and such. Today, SSL in some cases can be free. DreamHost offers “Let’s Encrypt SSL” for free. Then there are self-signed certificates, also free (but not as trustworthy). The advantage of SSL is that when you do need to enter user name/password to one of your password protected directories, it can’t be intercepted.
Typo in Sphider 2.2 install script
A typo has been discovered in ‘install.php’ for Sphider 2.2.0 (classic). This will affect those who have 1) already downloaded ‘sphider-2.2.0.zip’, and 2) are trying to do a clean install. Any downloads after right now already have the file corrected.
This does not warrant a new release, but simply instructions on how to fix the problem if you have it.
Line 23 currently has:
error_reporting(E_ALL0../settings”;
Change this to:
error_reporting(0);
$settings_dir = “../settings”;
This does NOT affect the PDO edition.
Sphider 2.2.0 released
Sphider 2.2.0 was released today in both the Classic and PDO editions.
There are currently no plans to release this update in PostgreSQL or SQLite editions. Those remain at 2.1.0. There seems to be little demand for these.
Sphider 2.2.0 has the search interface redesigned to be more mobile friendly. The code was rewritten to be more responsive to CSS instruction, made to detect the use of mobile browsers, and present a mobile friendly version of the standard template.
A minor security problem was also addressed, as well as the ability of the administrator to easily switch between the tabbed search (traditional, RSS, and image) and just the basic traditional text search.
—————-
There are plans for the next release (February 2019 ???) to expand this ability so that the administrator can pick and choose which search interfaces to present. If they want both traditional and image, but not RSS, they will be able to do so.
Also, the templates will be reworked so mobile browsers can experience friendly versions of ALL the templates.