Search options (Page 4 of 7)

I was afraid of that.

Ochiba was written when IE7 wasn't yet out, but I made the assumption that it would fix all the problems IE6 had, and be standards compliant. This was rather naive of me.

Since it's not possible to have IE6 and IE7 installed at the same time, I'm unable to test things in IE7 and I can't tell you what the problem is. The best I can suggest at this time is to look at the templates/site.tmpl file and change the line that reads:

<!--[if lt IE 7]><link rel="stylesheet" type="text/css" href="{ROOT}/css/iesux.css" /><[endif]-->

and change the 7 to an 8. Maybe IE8 will be standards compatible.

Do you have terminal (ssh) access? If so, try logging in and entering the command which convert. That should tell you the path the convert on your system.

If not, try asking your provider what the path to the binary is.

Ahh, pruning.

This is one of those things that is pretty easy in something like kareha, where "boards" are self-contained, but a lot more complicated in ochiba where "boards" are really just label filters. I also had a a bunch of new ideas in mind (prune by date, prune by space on disk, prune by thread count, prune by post count). Plus, this kinda thing is harder to test for obvious reasons.

Anyway, those are my excuses. Here's some stop-gap code to provide pruning until the time I do this properly (probably ochiba v2).

conf.php

--- release/ochiba-1.1/conf.php 2005-09-21 19:46:39.000000000 -0700
+++ conf.php    2007-01-28 14:51:42.000000000 -0800
@@ -67,6 +67,7 @@
 define("FEATURE_RSS",true);                    // Enable RSS feed?
 define("FEATURE_FETCH",false);         // Enable URL fetch instead of upload?
 define("FEATURE_SAGE",20);                 // Number of replies before no longer bumped, or false
+define("FEATURE_PRUNE",35);         // Number of threads to retain; false to retain all
 define("FEATURE_MULTIPLE_CATEGORY",true);   // Allow multiple categories per post?
 
 // Restrict posting? If so, only tripcodes provided in a comma-separated list will

includes/post.php

--- release/ochiba-1.1/includes/post.php   2006-01-07 11:40:39.000000000 -0800
+++ includes/post.php   2007-01-28 14:52:46.000000000 -0800
@@ -313,6 +315,11 @@
         }
     }
 
+    //----- Prune? If FEATURE_PRUNE is set to a number, delete off old stuff
+    if(is_numeric(FEATURE_PRUNE) && FEATURE_PRUNE>0) {
+        prune($_POST['categories']);
+    }
+
     echo $STRINGS["postthanks"];
     echo JS_AUTO_CLOSE;

includes/functions.php - add the following function to the file

function prune($categories) {
    global $db;
    // Have to do this for each category posted...
    foreach($categories as $c) {
        // Get threads to delete, if any
        $q = "select id from images where category like '%/$c/%' order by date desc";
        if(eregi("^mysql",DB)) {
            // Fuck you mysql
            $q .= " limit " . FEATURE_PRUNE . ",10";
        } else {
            $q .= " limit 10 offset " . FEATURE_PRUNE;
        }
        $threads = $db->getCol($q);
        $allchildren = getComments($threads);
        foreach($allchildren as $children) {
            foreach($children as $child) {
                deleteImage($child["id"]);
            }
        }
        foreach($threads as $thread) {
            deleteImage($thread);
        }
    }
}

There isn't a warning- there's no way for the pre-submit checks to get at the size of the file, so it will post anyway. Once it hits the server, there should be some sort of error- something I fixed in 1.1 I thought.

If you set it to false, it will always bump regardless of the number of replies. It won't die.

Hmm, having a fixed number of characters greatly increases the machine-readability of captchas, whose sole purpose to defeat machine readability, so the idea seemed ill-advised to me at the time I was working on it.

Still, it's pretty easily done. In includes/functions.php line 790:

    $code = strtoupper(substr($code,0,6));
    $code = ereg_replace("[^A-z]","",$code);

Flip these two lines around and change that "6" to whatever length you want. Also, change line 817 from

    return substr($x,0,10);

to

    return $x;

This won't guarantee 100% of the time it'll be the set length (has to do with the way the "random" strings are generated) but it should work most of the time. For better coverage, you can change the md5() call on line 811 to sha1().

Oops, thanks.

Well, ,the "O" vs zero thing is moot because numbers are not used. The O vs Q is an issue and I actually did try removing Qs from use but that created really subtle bugs that were maddeningly hard to track down. Also, since XmlHttpRequest is used to "pre-verify" before submitted a form, you get immediate feedback if the captcha doesn't match, before having to wait for a file upload, so the cost of trying a second guess isn't too high.

Having said all that, the existing captcha code was supposed to be a proof-of-concept kind of thing and stop spammers, but isn't the best. If you have other code for generating captcha images, it should be easy to drop-in. Just replace includes/verification.php with the image generating code (but keep the first two lines).

As for requesting a new captcha: I've been meaning to look into this.

If you know of captcha generating code, I can take a look at making the modification.

Hmm interesting. I've mentioned my feelings on so-called "Anonymous" posting before:
http://ochiba.x-maru.org/supportold/kar … 106307785/

However, your idea seems like it might be easy to add and make it configurable by the site owner.

Thanks for the note and tip. I'm reconsidering my initial intentions with the collapse/expand thing and will probably drop that "functionality" in the next major update.

Hmm, sounds like a mod_rewrite issue. Give the following thread a read, and try out some of the changes indicated:

http://ochiba.x-maru.org/support/viewto … pid=19#p19

Let me know if that helps.