51

(3 replies, posted in Support)

So does that mean that the thumbnail file does not exist (ie the thumbs/00/ directory is empty) ? What is the output of "ls -l thumbs" and "ls -l thumbs/00" ?

As sort of a brute force tactic, try:

chmod 777 thumbs
chmod 777 thumbs/00

and then try posting another picture.

The other possibility (if the thumnail file doesn't exist) is that there is a problem with convert... troubleshooting that would be more involved.

52

(3 replies, posted in Support)

Looks like there is some issue with permissions - can you tell me what the permissions and owner/group on thumbs/ and on thumbs/00, and if there's actually thumbnail files in that directory?

It should be something like rwxrwx--- apache:yourusername (ie mode 770; 'apache' may be some other name but refers to the web server process owner).

53

(1 replies, posted in Support)

Ahh, unfortunately there is no nice way to do so in the ochiba interface, owing to some technical complexities that I never fully addressed.

Here some detail, including some proposed solutions:

http://ochiba.x-maru.org/supportold/kar … 106329435/

54

(3 replies, posted in Support)

Great, I'm glad it worked for you. I should probably make the code do that by default since it comes up frequently, but I've been too lazy to issue a new release.

I hope you enjoy ochiba!

55

(3 replies, posted in Support)

Are you on dreamhost by any chance?

Check out this post and see if making the changes indicated make a difference:

http://ochiba.x-maru.org/support/viewto … pid=95#p95

Note that "<" means original line, and ">" means new line(s), in case you're not familiar with the notation.

Can you try using the SQLite type? You can just set the DSN like this:

define("DB","sqlite:////tmp/ochibatest");

This will help confirm if the PEAR::DB module is working in general. If you have Postgres available, that's another thing to try. If either SQLite or Postgres are available from your hoster, then I would strongly recommend using one of those and not MySQL.

Another thing to confirm: do your database connection parameters work in other software? For example, do you have some other blog software that uses your MySQL database, such as Wordpress? I'm not sure how much of the parameters you obfuscated in your post, but the "usr_**database**_2" part seems peculiar. How about if you put the following line into install.php, right below the "Checking for database connection" line:

$conn = mysql_connect  ('localhost', '**mylogin**','**myPass**');
mysql_select_db($conn,'usr_**database**_2') or die("Cant' select database");

If none of the above work, what PHP version do you have (the output of phpinfo() would be handy) and what hoster are you with?

57

(10 replies, posted in Support)

What kind of server environment are you on? What OS/web server/PHP version/MySQL version, etc

58

(10 replies, posted in Support)

Hmm, not really since mysql (or any database other than sqlite) is outside the scope of the hardware and more of an individual system configuration matter that will vary with each computer.

You tried the "mysql://dbusername:password@localhost/ochiba" string right?

59

(10 replies, posted in Support)

Does it work?

60

(10 replies, posted in Support)

I think most people would advise against such a setup for an Internet-facing web site given its security problems - you should create a separate user with access only to the ochiba database, for example.

In any case, to mirror how you are connecting via navicat, try "mysql://root@localhost/ochiba" (notice the @ instead of :)

61

(10 replies, posted in Support)

Hmm, is "mysql://root:localhost/ochiba" really what you have in your conf.php? If so, it should look more like "mysql://dbusername:password@localhost/ochiba", filling in your database username and password of course.

62

(2 replies, posted in Support)

Have a look at this post (and the thread in general), as I think your symptoms are the same:

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

63

(1 replies, posted in Support)

Unfortunately, your web host restricts what can be run from within a PHP script. The programs convert (and identify) are needed by ochiba for thumbnails and identifying images.

You can try checking with your hoster to see if they can allow convert/identify, but I don't think there's anything else you can do.

64

(1 replies, posted in Support)

Nothing obviously jumps out except is your database really named "file"?

In the install.php file, at line 83 you should see:

    echo "FAILED - please check connection settings (" . DB . ")\n";

After that line, add the following, to get a more informative error message:

    echo "    ERROR WAS: " . $db->getDebugInfo() . "\n\n";

Let me know what it says.

65

(7 replies, posted in Support)

Themes are based on CSS files, so the way it works is:

1. Put css file in css/mytheme.css
2. Add a stylesheet line to templates/site.tmpl - you will see others there already to give you and idea what it should look like
3. There is no step 3!

The menu in the prefs window is auto-generated from the stylesheet (<link>) definitions in site.tmpl, so that's all it takes. Other than actually creating the css file itself, which is really beyond the scope of a forum post. For a start on that, take a look at the included ones - ochiba.css, classic.css, and futallaby.css.

Puzzling! I'm not sure how to explain the unusual sequence of steps for you, but at least it's all good now- I figure it was a fluke thing.

67

(7 replies, posted in Support)

That should be:

define("MODERATORS",'Du1tKp/gkY,oFRnWPpZpN');

i.e. one long string with tripcodes separated by commas, rather than multiple tripcode strings separated by commas. Kinda confusing, I know.

And yes, you cannot submit without a name and a tripcode, by design. There some other posts here that describe altering this behavior, if you wish. Search for "anonymous".

68

(7 replies, posted in Support)

My favorite kind of ending :)

Does what should be line 157 of conf.php in v1.2 look like this?

if(TRIPCODE_SECRET=="changeme") {

70

(7 replies, posted in Support)

Can you take a look at the page source and look to see if the img URL is (a) what you think it should be and (b) actually works if open in the browser directly.

Another thing you could try is to turn off FEATURE_COUNT_VIEWS in conf.php, to see if the view counter is causing the problem.

This might be the kind of problem that is easily understood if I can get a look at the page myself - if you're willing, send me the URL of your site at ochiba @ x-maru.org.

Err, duh me. That should've been:

// Make sure the tripcode secret was set
var_dump(TRIPCODE_SECRET);exit;
...

(without the "x")

What does the line following that one read?

Did you just happen to do a global replace of "changeme" for "XXXXX" in conf.php? At the end of a the file, there is a check that is generating this error. Usually, it compares TRIPCODE_SECRET to "changeme" but if you did a mass replace, it would check against "XXXXX" which would match and generate the error you see.

If that's not it, try putting the following var_dump call as below (again, towards the end of the file) to see what's going on with the variable:

// Make sure the tripcode secret was set
var_dump(TRIPCODE_SECRETx);exit;
...

Hmm, if the test script worked, then it should work since it uses the same call (exec) that ochiba does. I'm not sure why it's giving a FAILED for the check at install time....

The HTML_Template_IT should've returned a helpful message if it couldn't find HTML_Template_IT, directing you to http://ochiba.x-maru.org/reqs, which discusses in detail.

Hah, that's is fantastic. I'm glad it wasn't a bug with ochiba :).

Is there anything showing up in the logs? What if you try uploading something like:

<?php
exec("/usr/bin/convert -version",$out);
echo $out[0];
?>