m00dawg

Ah but they actually can in a way. The problem is our site doesn’t come up correctly using HTTPS to view any of the non-admin pages. So when we go to Preview, things end up being a bit of a mess.

I think you’re right in that this is likely caused by a plugin (W3 Total Cache I’d bet). Trouble is, we can’t just up and turn that off as it makes a huge difference in the amount of traffic that ends up hitting our website and, thus, to performance.

Where it gets really weird is with the top WordPress admin bar. That will get served on non HTTP. If I recall, the problem is noticed when you try to use that bar in that configuration.

Generally, I agree with you as far as HTTPS goes though we’re not quite ready to do HTTPS-on-everything just yet even though it’s an epically good idea.

Can’t you just add a mode to turn that off (optionally with a big red warning)? The problem in my case is the front-end is crazy cached using a CDN which doesn’t support CNAMEs with SSLs. Technically I suppose this is an issue with W3 Total Cache for not being able to specify HTTP and HTTPS URLs for the CDN.

That said, having Duo in place is surely better than the converse so I’d rather risk the HTTP vs HTTPS issue.

I’m having the same problem, just to chime in.

Hah yes you’re absolutely right. I meant ‘text-color’. The work-around seems to work though only for the headers. Something is up with trying to use the span within content but that’s likely to do with our (very customized) theme.

Everything is looking great thanks again! If you’re going to be at the MySQL Conference next week, we should meet up some time – I’ll buy you a beer ??

Ah that explains that. Sure enough, upgraded and it works like a champ! Thanks!

I did notice one issue, and perhaps it’s just my setup or WordPress itself, but I am trying to add:

<span style=”text-align: #ffff00;”>

To the “Before keyword” settings and something is escaping the quotes and mangling the field in the admin panel. I haven’t looked into the cause yet so it could very well be my setup (though magic_quotes_gpc is off) but wanted to share.

Otherwise, it’s working great and is SOOOO much faster than the built-in search features. Thanks for all your help!

0.9.8.1-2 (the version that ships with Ubuntu 10.04)

We have the Search Everything plugin. The old Sphinx plugin seemed to co-exist with that one though I have tried disabling it and leaving it enabled with the new Sphinx plugin – same results. I haven’t yet tried totally removing the Search Everything plugin though I would have thought just disabling would have been sufficient?

I do indeed have the status field:

mysql> show create table wp_sph_stats\G
*************************** 1. row ***************************
Table: wp_sph_stats
Create Table: CREATE TABLE wp_sph_stats (
id int(11) unsigned NOT NULL AUTO_INCREMENT,
keywords varchar(255) NOT NULL DEFAULT ”,
date_added datetime NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
keywords_full varchar(255) NOT NULL DEFAULT ”,
status tinyint(1) NOT NULL DEFAULT ‘0’,
PRIMARY KEY (id),
KEY keywords (keywords),
FULLTEXT KEY ft_keywords (keywords)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

The above was from the live blog and was a new install of the latest plugin. Dev looks identical though (and I did see the alert in the plugin page to alter the table). I do see that the FULLTEXT index is there but reading the docs it sounds like that is no longer needed (which is preferred since we use InnoDB across the board). Otherwise I didn’t really find much in the readme.

I haven’t modified our template to use the custom sphinx functions – I didn’t have to do that in the older plugin and was hoping to avoid that case (for now anyway) – could that be the issue?

Doh spoke too soon! Looks like my config got wiped is all. Reconfigured and we’re back in business ??

Fair enough. I went ahead and fired off an e-mail. For the public arena, to elaborate a bit, I tried the WordPress 3.1.1 update and that did not fix things. I also confirmed that the old version of the Sphinx plugin *did* work correctly. So it’s something to do with the new version not working with our current setup, though I’m not sure what that is.

searchd is indeed running and the plugin can see that it is as well:

root@Blog:~# netstat -nptl | grep search
tcp 0 0 127.0.0.1:3312 0.0.0.0:* LISTEN 23419/searchd

I have tried running the wizard several times. Everything appears all good as far as the plugin is concerned. I thought maybe it was a ‘localhost’ versus ‘127.0.0.1’ thing so I tried that but no dice.

Hmm I’m having issues with the latest plugin it seems. It installs fine but when I go to search for something on the blog, I get no results. The content is in Sphinx because I can see it run through pages in the indexer and can query search terms via the command-line ‘search’ tool.

I don’t see any queries in the Sphinx query log so that makes me thing that the blog isn’t issuing the search terms to Sphinx. The PHP error log doesn’t show anything. Is there any way I can troubleshoot this more directly?

Note that I have tried a “standard” install (using the PHP generated sphinx.conf as we’ve been talking about previously in this thread) as well as a static install using my own config file and locations. Neither seems to work through the plugin.

Oh wow, I didn’t know that. That’s very very cool! I’ll go ahead and give that a go. Thank you very much for all the help!

Sorry I meant to say WordPress 3.1 – oops!

I know I can specify the config path, but does that work if using the standard Sphinx system-wide init script? I noticed that the config has PHP wrapped around it so I wasn’t sure how to use that with the Sphinx system-wide instance?

By the way, I noticed that this plugin seems to work flawlessly with ‘Search Everything’ (which we use for search term highlighting) so that’s very cool!

That’s odd, I thought I tried that before but the deactivating and re-activiating the plugin did create the tables. The original problem was that I did not give the WordPress MySQL user privileges to create tables during the original install.

After that and realizing I had to run ‘indexer –all’ before starting the daemon, all seems to be working.

I am still using the standard system install and just pulled what I needed from the custom-config. I just don’t like the idea of having WordPress control the instance and prefer to handle it myself (plus I can use init scripts and things that way).

Otherwise, works great on 3.1 so far!