1

(1 replies, posted in Support)

Sorry I didn't see this until now!

I can't tell for certain what's going on for you but a couple of things to test include:

- is PEAR::DB working in general?
- does PEAR::DB have the sqlite extension available (having sqlite on the box is not enough, this extension must be built as well)
- have you tried in a directory other than /tmp/ ? (while I'm not sure why this wouldn't work in /tmp, I would strongly recommend not using it for production purposes- perhaps you are only testing for now).

Let me know if any of the above leads anywhere...

Hmm, I see it differently. If I had a Honda and I tried to add an aftermarket turbo and it didn't work, I would go to the turbo manufacturer for help. I wouldn't think it is Honda's responsibility to make their cars work with aftermarket parts.

For what it is worth, I *have* taken a look (again) and tried to see if I can find anything odd about what's going on, but I can't even reproduce the problem. The following is a copy of your "all" page:

http://ochiba.x-maru.org/pushthenet/all.html

I changed *nothing* from your site, it's just a local dump. Sometimes, the dock will work. Sometimes, it will "stick" and not do a smooth fisheye, just little popups. (this is with Firefox 3.5x)

Even on your site, if I clear my cookies, it occasionally will work. If it doesn't work, if I increase the font size for the page, it will start working. If I reduce it back to the original size - still working.

All this is evidence to me that this plugin is pretty flakey. Again, I think the author of it is who you should seek answers from.

Hmm, I don't know what else to suggest. This isn't an ochiba issue and I'm not familiar with this code you're using. Have you tried asking the author of it?

Hmm, well I don't know if this is the answer but the script that you have there can be moved into the <head> section. In fact, that's a better place for it in general.

FWIW, though, the docks behave the same way whether or not I pop up the reply dialog (ie, the top one works in fisheye, the bottom one doesn't).

Oooo, I like that idea - a "My Boards" option. Should be pretty easy to do, too. Consider it included!

Hmm, I'm kind of out of my element on this one as I've never used the fisheye thing before but it looks like on certain pages, the "hot spot" for activating the effect is not where you'd expect (sometimes it's above the dock, sometimes it's below). This suggest some confusion about positioning to me, so one thing to try is making the bottom dock's container have position:absolute, and then see if getting rid of floats helps.

Whoa, that's a pretty neat customization- hat's off to you, very well done.

On the /all page, it looks OK to me. The only thing I noticed is that the menu on the bottom doesn't fish-eye like it does on the top one. Is this what's broken?

I do notice there's one HTML tag problem, unmatched </div> between the two docks, this kind of error can cause weird box/container issues so that's a quick fix I would recommend to start with.

If that's not it, can you point me to the specific problem?

8

(10 replies, posted in Discuss)

Tahko wrote:

- an option to make the menu a static toolbar at the top of the screen with drop down menus

This is probably best done via custom mods to the site template. The auto-generation of the menu is a convenience and may serve for basic imageboards, but that's always been left open to customization.

Tahko wrote:

- instead of pages, when someone scrolls to the bottom of the page it displays the next page of content I saw this with a ipod hack and it was really cool.

Ahhh, I've heard that called "infinite scrolling". It's an interesting idea and certainly for busy imageboards that might be nice. I wonder though - I've seen it used mostly in text-heavy contexts so I don't know how well it would work in a image-heavy site (those thumbnails really add up), with the RAM usage skyrocketing as the page elongates.

Something to think about though.

Definitely, I'll pretty up the admin area a bit. That part is so boring I never really gave it much attention, but part of the purpose of v2 is to polish a lot of the rough edges I let linger in v1.

9

(10 replies, posted in Discuss)

I've tried IRC before and it just never works for me - I'm just not suited to it somehow. If you'd like to chat via IM, let me know.

And there's also this forum if you've thought out some features. Actually, I'm at a stage in the development where feature requests would be good - I got the basics down so I'm working on new features at the moment.

10

(10 replies, posted in Discuss)

Haha, just a teaser:

[img=TEASED]http://ochiba.x-maru.org/imgboard/view/000161/youtube.png[/img]

http://ochiba.x-maru.org/imgboard/161

11

(10 replies, posted in Discuss)

That's interesting and it's given me an idea. ochiba has an option to specify URLs for fetching images (instead of uploading them). It's disabled by default, but it can be used for special URL handling when youtube or other desired URLs are given.

12

(10 replies, posted in Discuss)

Coincidentally, just last week I was working on ochiba 2 again, specifically code to allow extensions to handle file types other than images (in my case, I was working on PDF uploads, specifically, which is nice because you can still generate a thumbnail from it). This requires quite a bit of change to how ochiba 1 works so I don't see it being available as a feature until ochiba 2 is done (no, I don't have a timeline for that!).

The youtube embed idea is kinda doable now- the custom parsing functionality should allow for you to take some post syntax like <youtube:abc123> and convert it into the embed code. I would imagine embedded video for other sites would work the same way.

It would be nice to have a thumbnail for the video appear as the posted file, then onclick it would show it in a lightbox, but I haven't figured out a way to structure the user interface for this. What would the user upload, if anything? How would the parser recognize this was a video embed? etc.

If you are able to install from scratch, I would recommend grabbing the new release (v1.2.1) as it deals with the issue by including the correct versions of the extensions.

14

(0 replies, posted in News)

Ochiba version 1.2.1 - "Code breaks after 5 years"

This version includes a few minor bug fixes

  • this release now includes PEAR::DB and PEAR::HTML_Template_IT modules that are compatible with ochiba

  • fix in zip file processing

  • fix error condition when no tripcode is given

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

15

(11 replies, posted in Support)

It looks like you got hit with the HTML_Template_IT problem (your reply links don't have the proper reply ID number). Please see this post that describes how to fix it.

I found the problem.

HTML_Template_IT changed it's behavior. On my system(s), ochiba has v1.2 of HTML_Template_IT and I just noticed that it is up to v1.3 now (I thought it was a dead project...). When I tried running ochiba against v1.3, this problem arose.

To fix this, use HTML_Template_IT v1.2.1, the last stable release. It is at:

http://download.pear.php.net/package/HT … -1.2.1.tgz

Take the file IT.php from that archive and put it into your ochiba's includes/ directory. Then edit your includes/page.php, to replace line 19, which reads:

require_once("HTML/Template/IT.php");

with

require_once("includes/IT.php");

Hmm, can't really tell the distro on that one- that kernel version number looks a little weird to me. It probably doesn't matter though.

As far as hosting recommendations- although there is a specific issue with Dreamhost, I think once the tweak mentioned elsewhere is in place (and I really should roll that into the distribution), I think it works fine there. I don't have any direct experience with shared hosting however.

I have a dedicated box with theplanet.com and have been very pleased with them. Dedicateds are expensive compared to shared hosting of course. I also recently started playing around with a virtual private server with prgmr.com - resources are a bit thin but it's cheap. I've heard good things about linode and slicehost. Problem with VPSs are the really small disk allocations you get - running something like ochiba, it can start eating through that quickly. Plus, you also have to handle the syadmin side of things.

This was probably not at all helpful (' . .)

Ok, good luck - I'm afraid you're on your own.

Do you happen to know the details of the OS you are running under? Which Linux distro, specifically. I'm thinking I could try to recreate the environment to see if I can reproduce the issue on my end so that I have something to work with.

Ooops there should be a semi-colon at the end:

$vars['id'] = $row['id'];

How weird - it was a stab in the dark since I can't reproduce your problem at all, so I guess I'm not too surprised it didn't work. However, the thing you did seems to trigger 1 extra/phantom post block to appear (both on that page in the image and on other pages, it always appears on the bottom) and I'm not sure why that would be.

Unfortunately, there's an interplay between php and template file so I don't think this is actually a fix you'll make in the template file...

Instead of your line, how about:

$vars['id'] = $row['id']

(leaving image.tmpl as the default of course)

Again, a blind stab in the dark...

I'm completely baffled. This is still on servage.net?

Can you try this: at line 348 of include/images.php is the following line:

$tmpl->touchblock("reply_link");

Right before it, add the following:

$tmpl->setVariable("id",$vars["id"]);

Yeah, changing to modify_id will only make it work for mods/admins.

The problem is most likely not within that code so I think it'd be better to track to track down the source rather than patch up somewhere else. Can you try reverting back to original files? You can back up all the files you've edited and then replace them all with original ochiba source (except for conf.php). You won't lose anything - the database/img/thumbs can stay in place, but as this appears to be some funny interaction between code and templates and I'm pretty sure default ochiba doesn't do this, I think that's the best way to trace this problem.

Wow, how bizarre- the bug that was caused by that mod was very obscure and I still don't really understand why it broke in the way that it did, so for someone else to run into the same symptom is extremely puzzling.

What changes did you make to index.php? Of the files you listed, that seems the most likely to have caused an issue. Can you try flushing the cache directory (you can do this from /admin)?

Hmm, your reply links lack the id in the URL - they should end with

id=123

but yours are ending with

id=

This is exactly what happened over in this forum post. Did you happen to make a modification to the code as described there (to page.php) ?

Actually, it's been discovered that the example code as given causes ochiba to malfunction for reasons that are not immediately obvious, so please do not use it.