Search options (Page 2 of 7)

I'm afraid there is no way to embed it into another framework such as a forum currently. One option is alter the ochiba site template to mirror that of the your forum, but that would still not be a real integration.

I checked and they are identical to the files as in ochiba-1.2.

I'm afraid I have no explanation and without being able to work on the system, I can't offer anything in the way of useful suggestions.

The nature of the problem is very strange as  I mentioned and has never been reported so I have to put it down to some strange quirks in the PHP/Apache environment on your host. If you have an alternate host available to you, give that a try.

Beyond that, though, I'm afraid there's nothing more I can tell you at this point.

Your database looks fine, and your image board *mostly* looks fine. I still don't understand why the ID is working on most parts of the page, but not on others.

This is what image.tmpl should look like.

[img]http://ochiba.x-maru.org/imgboard/view/000154/image.tmpl.png[/img]

I've highlighted the places where ID is filled in. For you, the 1st, 5th, and 6th {id} are working, but 2nd, 3rd, and 4th are not. Since it's all the same template, they should all work, or they should all not work.

Can you confirm all of the IDs in your image.tmpl are the same as shown, and if you haven't already, start over with a brand new image.tmpl just as a starting point.

I take it you mean "anonymous" posting? A couple of different options are covered here: http://ochiba.x-maru.org/support/viewtopic.php?id=32 - it also covers disabling the javascript alert/warning.

I advise against posting without a tripcode - it eliminates the ability to delete your own posts. If you must, you can give it the same treatment as above for the name.

This looks to me like a problem with permissions on your thumbs and img directories. Make sure they are set to be writable by the web server processing. From a shell, you could do

chmod 770 img thumbs

if your directories are in the web server group, or

chmod 777 img thumbs

as a last resort.

Hmm, your ochiba install isn't working quite properly - have you made a lot of changes to it? First of all, I see that the reply links do not include the parent post/thread ID number. If you hold your mouse over a reply link and look at the URL in the status bar, it looks like

http://pinkweb.org/post?id=

with the ID missing. There should be a number after the "id=" part. You can look at the test boards here and see what that should look like.

Secondly, your posting window is not normal either- yours has the site menu for some reason, and does not automatically select the category depending on what category you were looking at when you clicked the "post" link. Again, you can go check out the test board and see that the posting window should not have a site menu, and should automatically select the category based on where you are when you clicked it. This addresses your 2nd item - if this feature was working, you could eliminate the category choices.

Anyway, my suspicion is that modification of the ochiba code has led to the loss of these normal functions, so I would advise rolling back your edits or re-installing ochiba and being more methodical about making changes so that you don't lose these features.

Hmm, that's pretty clean - nicely done. The next version of ochiba I'm working on is going to use a different template system (Smarty) so the implementation will be different but your code above has given me some ideas. Thanks!

Just a warning: this is a bit uglier than I'd like:

Out of the box, ochiba will escape (htmlspecialchars) the description of a category, but if you "disable" that, you can use any HTML you desire. Since most likely it will be just you editing this, it should be safe from attack as long as you know what you're doing (ie basic HTML).

To disable the escaping, you would make the following change to includes/images.php:

--- includes/images.php    3 Feb 2006 02:37:38 -0000    1.48
+++ includes/images.php    14 Jul 2009 01:39:23 -0000
@@ -361,7 +361,7 @@
 if($category == "Stats") {
     $vars["category"] = "Top " . LIMIT . " Most Viewed Images";
 }
-$vars["description"] = $category == "Stats" ? "" : htmlspecialchars(stripslashes($categories[0]["description"]));
+$vars["description"] = $category == "Stats" ? "" : stripslashes($categories[0]["description"]);
 if (!is_numeric($category) && count($images)>=1) {
     $vars["pager_top"] = $pager;
     $vars["pager_bottom"] = $pager;

In other words, on line 364, remove the htmlspecialchars() call.

The other place the description appears is as a tooltip (title attribute) in the menu of categories. Since you are using these descriptions for more than just "my cat pics", you should probably just disable those. In includes/functions.php:

--- includes/functions.php    30 Aug 2005 08:06:08 -0000    1.42
+++ includes/functions.php    14 Jul 2009 01:41:41 -0000
@@ -99,10 +99,9 @@
     $result = $db->query($sql);
     $menu = "";
     while($row = $result->fetchRow()) {
-        $menu .= sprintf('<a href="%s/%s" title="%s">%s</a>%s',
+        $menu .= sprintf('<a href="%s/%s">%s</a>%s',
                             ROOT,
                             $row["abbr"],
-                            $row["description"],
                             $row["category"],
                             "\n");
     }

In other words, remove the references that display the description.

After those two changes, you should be able to edit the description using HTML. Hope this helps.

Boy, I'm stumped. The idea is this: when you request http://music.mcgill.ca/~chris/ochiba/admin, the rewriterule is supposed to recognize that there is no file that matches that URL, so instead rewrites the request to http://music.mcgill.ca/~chris/ochiba/index.php/admin, thereby giving the request to index.php with "/admin" as an argument. In the latter attempt, it would rewrite it as http://music.mcgill.ca/~chris/ochiba/in … est=admin. Either way, index.php would get run, detect what was being asked and act accordingly.

It doesn't get that far though. I have servers running the same OS as you, and they're not having this kind of issue with rewrite rule, and I don't mess with any configuration pertaining to mod_rewrite, so I'm left to conclude your sysadmins do. Perhaps you can point them at this discussion and something will make sense to them why this isn't working as intended.

Yep, your hunch is correct, URLs such as /admin, etc don't actually map to the file system but is parsed by the index.php to decide what is being requested. This uses Apache's rewrite technique but you've run into what appears to be a common issue.

Anyway, the change I would point you to is in the thread you seem to have discovered (the issue with the tilde should be fixed and a non-issue). In particular these two changes are where I'd start,

.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);

If you haven't already tried that, give it a shot and let me know how it goes. If that doesn't work, can you check with your sysadmin and confirm that mod_rewrite is available to you?

Hmm, actually it looks like you're in luck as your host apparently has Postgres support, so ochiba will function the same. Unlike sqlite you need a database created for you, a database username, and a database password, and only your support/sysadmin can provide those, but once you have all three of those, you can plug them into your connect string - examples of the postgres form are in conf.php.

Could you try the little test/debug script in post#6  of that thread? It'll give a more informative error message (obviously, changing the connect string to yours).

Looks like your PEAR.php file is not in the expected places. This really is something that should probably be addressed at the hoster level (specifically, the include_path should point to a directory that contains PEAR.php) so you may want to contact them and ask where it might be. Another thing you can do is find it yourself. If you have shell access, the command "locate PEAR.php" might turn up the exact path; from there you have to tweak the scripts in question to that exact path.

The final option is to get the PEAR.php file directly from http://pear.php.net and upload it manually to the ochiba directory, as you appear to have done for the DB.php file.

Oh, I see, I thought you meant in the posting form. This is the tripcode hash, you can get rid of it by editing templates/image.tmpl. Look for and delete these two lines:

<em class="tripcode"><{tripcode}></em>

and

<em class="tripcode"><{comment_tripcode}></em>

Should be lines 45 and 60.