Thanks for posting this, it's how we've got our Sphinx set up: using the ranged queries is critical. Also, if you are running a particularly large board you would do well to actually run Sphinx on a separate server entirely: something from Amazon Cloud or Rackspace works very well and completely eliminates any danger of high disk IO killing your web server's performance.
I've got a board in Simple:Press whose topics and posts I'd like to import into an existing IP.Board. I don't have access to the member database of the Simple:Press forum, so I need new users created during the process. It's not clear to me how to approach this problem: does the available converter require a complete forum? Can it import into an existing database, or do I need to start by converting to a dummy IP.Board installation and then merge the two IP.B installations together?
"Open date" is not the timestamp of the post, it's literally just when the topic is open. You should see that the topic is currently closed/locked, and on the specified date it will tick over to "open" automatically. That said, I'd love to see that feature change to actually modify the post date itself, so the topic would show up in "View New Content" when it opens.
We use Simple Tag Management as well, but it's not a help when doing large-scale changes. There aren't a lot of built in features in the tag system, but 3rd party developers have come up with some good stuff. I have no relationship with either of the developers of those add-ons, but in my opinion they're well worth the expense if you want to be serious about using tags.
Very nice work: I have a few suggestions for features you could consider adding...
One feature I'd really like to see is that rather than scaling the images to the exact dimensions, crop them to those dimensions (just a simple centered crop would be fine). This way you get the nice, orderly image display that you would get using the scale feature, but prevent the distortion the way that turning off the scaling does. Obviously not everyone will want cropped images, but for some of us it's better than scaling.
I'd also love to see an option where the title of the discussion topic the image is from could be displayed, either below the image or as the tooltip for the image.
A way to limit it to only one image per post, so that when someone posts a lot of images in one post they don't take over the whole display.
A way to limit the random selection to just the last X days (or images, etc.) so that the images are always at least somewhat recent.
Thanks for the suggestion Kirito: with our current setup we are limited to MySQL, but I'll keep that option in mind for the future. Can anyone give me a ballpark estimate of how long converting a 2.4GiB table might take? Are we talking about seconds, minutes, or hours here?
Out forum is mostly MyISAM, with just the posts, topics, and messages tables as MyISAM. Our host was helping with some issues the other day and noticed that those large tables were still MyISAM and suggested that we switch to InnoDB for performance reasons. On the surface this seems reasonable, but I'm wondering if there is a better way of determining whether we would see any benefit from going to MyISAM (for the record, we use Sphinx for searching, so fulltext is not an issue). What factors do I need to consider when deciding whether to do this switch, and what sorts of things could I measure or look for in the logs to see if it would matter to us?
Looking through the forums here is seems that there have been several others with this issue: for some, converting to UTF-8 is no big deal, and for others when we try to enable
$INFO['sql_charset'] = 'utf8';
it returns an error that it cannot load the settings cache. Does anyone have any tricks for how to figure out what's going on with this cache? It seems to me that issuing a "SET NAMES utf8" should work fine, since phpMyAdmin is running with effectively those settings and returning what appear to be correct database entries, including for the settings cache.
I've just run the script here to convert my database to UTF-8, with somewhat mixed results. The characters that actually got converted are now in the DB correctly (accessed via phpMyAdmin), but don't render correctly on the screen when viewed in the forums (just show as a question mark), and don't cooperate with functions like json_encode() (which requires UTF-8 data). I'm trying to understand what's going on here: presumably there are just some settings that need to be modified? The only place in the ACP that I was aware needed a change was switching "Document character set" to UTF-8. Are there other settings that need modification?
I don't know if it's related, but I was under the impression that if I put
$INFO['sql_charset'] = 'utf8';
in my conf_global.php file things should still work, and instead I get a message from IP.Board that it can't read my settings from the DB and is bailing out. Any ideas, suggestions, or debugging techniques?