101

(5 replies, posted in Support)

Hmm, does it work with the verification turned off? Looks like you've removed ochiba at the moment.

102

(2 replies, posted in Support)

Wow, you got me on that one. /cgi-system/ must be some kind of oddity with Dreamhost - I've never heard of that URL part before.

I would recommend contacting the Dreamhost folks and asking what the hell they are doing (they have a history of URL intercepting).

103

(1 replies, posted in Support)

"convert" is a part of the ImageMagick suite of programs and is used by ochiba to generate thumbnails. More information on ImageMagick can be found here:

http://www.imagemagick.org/

As far as installing for use by ochiba - you need to have "convert" installed somewhere on the server and the configuration setting CONVERT (should be around line 121 in conf.php) be set to the path and parameters for the convert command. On Linux systems, the stock settings should do. If you are having problems and you are on a Linux (or other Un*x-like) system, then it may be the path that needs to be changed (for example, rather than /usr/bin/convert, it maybe /usr/local/bin/convert - ask your sysadmin if you're not sure how to locate it). It may also be possible to install it local to your account and adjust the path accordingly.

If you are on a Windows server - I'm not sure what the specific details are, but the general idea described above should apply.

104

(0 replies, posted in News)

Ochiba version 11 - stupid dollar sign

This version includes minor bug fixes, the most significant of which is the issue with how HTML_Template_IT handles dollar signs.

Please read the release notes at http://ochiba.x-maru.org/notes for details.

105

(3 replies, posted in Discuss)

Deleting images wouldn't be a problem. The other idea I had was not allowing deletion until all images within a category were first deleted (more work for user).

The hard bit is that an image/thread can be in multiple categories, so in those cases, I'd like not to delete them but to just remove the category assignment. Unfortunately, the way I structured the database, this isn't so easy (I didn't use a join table between images and categories).

My debate is whether to do one of the above, or just go for a proper join table in ochiba 2...

Thanks for your feedback!

106

(3 replies, posted in Discuss)

Category deletion gets kinda hairy- there's no built-in way at the moment. The problem being what to do with the images that are assigned to a category that you are deleting.

If you are just getting started, though, and you don't have any images in a category, then you can simply enter the following SQL command using which ever SQL backend's client you are using:

delete from categories where abbr='something';

If you don't have command-line client access, you can upload a file such as below (name "deletecat.php", for example) to the ochiba directory and then load it in a browser:

<?php
require_once("conf.php");
$db = DB::connect(DB);
$sql = "delete from categories where abbr='something'";
$result = $db->query($sql);
?>

107

(4 replies, posted in Support)

I'm glad you got it figured out - sorry that the part about PEAR::DB wasn't clear. I'll try to write up something a little more detailed.

108

(4 replies, posted in Support)

Hmm. "randomhost" is "localhost", I take it?

Can you try modify install.php as follows and report what it outputs?

Change Line #83 from

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

to

    echo "FAILED - please check connection settings (" . $db->getDebugInfo(). ")\n\n";

109

(0 replies, posted in News)

Ochiba version 1.0 - cuz otherwise it'll never happen

This version includes minor tweaks and fixes to stabilize the codebase.

Please read the release notes at http://ochiba.x-maru.org/notes for details.

Extra processing of comments can be enabled by uncommenting the following line in index.php (should be line 12):

#require(INCLUDES_DIR . "/custom.php");

ie remove the "#".

Take a look at includes/custom.php for details on the additional processing that occurs (you can comment out stuff you don't want).

Well, without being able to execute an outside binary, the "convert" call would have to be rewritten to use a bunch of internal PHP commands. It's possible, but not really worth it, to be honest. There are a great many hosters out there without such draconian policies.

As far as localization, many of the strings are in includes/strings.php, so you could start there. The templates in templates/ should cover the rest. Unfortunately, it is still scattered about, but you won't have to go into the actual code too much for this.

If you do make some headway in this effort, then I would definitely appreciate a contribution back of the localized (Spanish) versions of these files.

Kaze wrote:

well, at last i managed to convince the web host admin to install ImageMagick onto the server.

Whew, good thing. The use of convert would've been tricky to get around.

<b>Fatal error</b>:  main(): Failed opening required 'DB.php' (include_path='.:/opt/apache/lib/php') in <b>install.php</b> on line <b>62</b><br />

I think this one shouldn't be too bad - it doesn't look like your hoster has the PEAR::DB module installed (which is weird, since they have HTML_Template_IT). You can install a local copy as described at the bottom of the requirements page

113

(3 replies, posted in Support)

I've never heard of that syntax ("200-infinity"). What are effect are you trying to accomplish?

Hmm, I'm not sure why the permissions were not set improperly - that's really odd. Maybe your hoster has some suexec wrapper and things are getting stored with your account as an owner, not the not web process's.

I guess one thing to try is to look in process_image.php and change the permissions used for the mkdir commands (should be lines 62 and 67) from 0700 to 0777.

Are things working OK now once you fixed permissions on the 00/ directories?

For some reason, your img/ and thumbs/ directories don't appear to have a "00/" directory in them. It should've been automatically created when the first image was uploaded.

A simple thing to try would be to manually create those directories and give them mode 777 and try to post a new picture. This doesn't answer why the directory wasn't created, but you won't have to worry about that again until the 1001st post...

If you don't mind, could you email me the URL for your site? Perhaps something wil occur to me if I see the problem "in person".

ochiba @ x-maru . org

Hmm. Can you describe your setup (Apache? Version? PHP version? MySQL?) and provide the output of showing ownership and permissions for your ochiba folder?

Everything else appears to be working?

118

(33 replies, posted in Support)

Lonestar wrote:

Now I get a undefined function error for escapesimple() when trying to add a board

Eeep, you must have an old PEAR::DB. I would pursue either:
1) Contacting your hoster and asking them to upgrade PEAR::DB
2) Install a local copy of it for ochiba to use (see http://ochiba.x-maru.org/reqs)

119

(33 replies, posted in Support)

My host is HostRocket

I think I got it working. The fixes were same, regarding the mod_rewrite stuff. However, in your case, there was a problem detecting the URL because of the tilde account. This is an ochiba problem and I need to fix it.

In any case, in addition to the now-standard hacks as mentioned above, I hardcoded ROOT in your conf.php and added a RewriteBase line in your .htaccess.

120

(33 replies, posted in Support)

Sure- this is becoming an interesting excursion into the whacked-out configs that hosters are using these days :).

121

(33 replies, posted in Support)

Sure, no problem. If you really want stats at a later date, you could always change the ochiba URL for it, to something like "/statistics" or "/top" or something. It'll require changing a few lines of code, but shouldn't be too bad.

122

(33 replies, posted in Support)

Yeah, the stats page I don't think I can do anything about. Dreamhost has Apache configured to intercept "/stats" URLs before it can even get to ochiba, so other than asking for them to turn that off, I can't think of anything that can be done.

123

(33 replies, posted in Support)

Hontaiyo wrote:

//----- Get $path. Should be a letter, if a category filter is requested
//        or a number, if a specific image is requested. Then there are
//        special action keywords (post,comment,delete)

$path_parts = explode("/","/" . $_SERVER["argv"][0]);
array_pop($path_parts);
$page_num = is_numeric($_GET["p"]) && $_GET["p"]>0 ? $_GET["p"] : 1;
switch ($path) {

I think I found the problem. There needs to be a "$path = $path_parts[1]" in there, after the array_pop(). Dunno how that got lost.

In your case, I've made the following edits from the distributed (0.9.3) files:

.htaccess

< RewriteRule ^(.*)$ index.php/$1 [L,QSA]
---
> RewriteRule ^(.*)$ index.php?$1/ [L,QSA]

index.php

< $path_parts = explode("/",$_SERVER["PATH_INFO"]);
---
> $path_parts = explode("/", "/" . $_SERVER["argv"][0]);
> array_pop($path_parts);

I believe it is working now, as apparently you have discovered ;)

Based on a suggestion here: http://ochiba.x-maru.org/support/viewto … pid=81#p81

The idea is just get rid of the pictures, which turns out easier than I thought it'd be. This can be done in a variety of ways, but I prefer the CSS hackery method, so I don't have to change templates or code or anything. The core bit is to add the following in CSS:

<style type="text/css">
td.image, div.cimage span {
    display:none;
}
</style>

To avoid hacking the distribution files, I would tack this into site.tmpl, below all the stylesheet links.

The other thing to do is to get rid of file upload widgets in post.tmpl and set MAXIMUM_SIZE to 0 or something in conf.php.

I think that should do it.

125

(33 replies, posted in Support)

Hontaiyo wrote:

array(3) { [0]=>  string(0) "" [1]=>  string(6) "ochiba" [2]=>  string(9) "index.php" }

Oh, I think I see what's going on. The line in .htaccess should be:

RewriteRule ^(.*)$ index.php/$1 [L,QSA]

Notice that there is no slash before "index.php". In 7hs's case, my notes were specific to his case, in which ochiba was installed at the top level of the domain, but in your case, it is within a subdirectory, so the slash is messing it up.