eGullet

+Clients
  • Content count

    61
  • Joined

  • Last visited


eGullet's Activity

  1. eGullet added a bug in IPS4 Bug Tracker   

    [Beta 2] About Me not showing on profile page
    After creating an "About Me" in the Profile Editor screen, the "About Me" tab should show in the main profile viewing screen. It is not doing so (here at IPS) right now.
    • 0 replies
    • 0 views
  2. eGullet added a comment on a blog entry: 4.0: Quick Translating   

    Fantastic idea, this will make customization *so* much faster.
  3. eGullet added a post in a topic: Making Sphinx more bareable   

    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.
  4. eGullet added a post in a topic: Importing topics/posts from Simple:Press into existing IP.Board   

    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?
  5. eGullet added a post in a topic: Post date (in Moderator Options) doesn´t work.   

    "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.
  6. eGullet added a post in a topic: Delete tags   

    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.
  7. eGullet added a post in a topic: Delete tags   

    We use the Advanced Tags & Prefixes mod.
  8. eGullet added a post in a topic: Determining whether InnoDB is a good fit   

    A related question: for speed reasons up to this point we've had "Update topic views immediately" set to "No". Does switching to InnoDB obviate this setting? 
  9. eGullet added a post in a topic: (NB34) Recent Forum Images (Attachments)   

    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.
  10. eGullet added a post in a topic: Determining whether InnoDB is a good fit   

    Thanks: in the end the whole process took about 45 minutes, most of which was spent backing up the tables as a "just in case" measure.
  11. eGullet added a post in a topic: Determining whether InnoDB is a good fit   

    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?
  12. eGullet added a post in a topic: Correct settings for a UTF-8 DB?   

    Many thanks to Keith C at Invision for the following fix: I resolved this issue by setting the sql_charset and then running the upgradeFinish tool provided with IP.Board (in the Tools directory).
  13. eGullet added a post in a topic: Determining whether InnoDB is a good fit   

    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?
  14. eGullet added a post in a topic: Correct settings for a UTF-8 DB?   

    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. 
  15. eGullet added a post in a topic: Correct settings for a UTF-8 DB?   

    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?