Search options (Page 7 of 7)

Oh, I see. Yeah, I had started on something like this originally because I really wanted users to be able to specify their time zone.

However, any user-customized output makes the caching system invalid, so I abandoned the idea. I dunno, I guess these can be features you can enable if you want to give up the caching.

As for css selection, you can add your own to the menu (templates/site.tmpl) and use something like the following for each stylesheet offered:

<a href="javascript:void null" onclick="setActiveStyleSheet('ochiba'); return false;">ochiba</a>

It'll cookie and save the selection.

Aah, the template files are not PHP files, so code won't work. If you could give me more details about what you're trying to do, I can make a suggestion (which template, which page, what you are including, etc).

Aah, I had a hunch that occurred to me after I last posted.

I think the problem is that ochiba isn't finding HTML_Template_IT. Do you have it installed? If not, check the requirements page for help getting it installed.

The line I think it chokes on is in includes/page.php:

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

BTW, is this a system you have admin access on?

That looks correct, which makes me scratch my head as to why index.php isn't working.

Unfortunately, I'm out of general ideas. The thing I would try if I could would be to put break points into index.php to see how far it gets. For example, put a line such as:

echo "GOT TO THIS BREAKPOINT";exit

into index.php, reload the page, and if it got to the breakpoint, move the line down to the next block of code.

If you can do this, it'll help isolate where it's failing.

That is strange that install.php worked but index.php comes up blank.

Just to make sure I understand the scenario: this is Apache, right? And what version of PHP?

What happens if you upload the following in a file named "test.php" and then you try to access it?

<pre>
<?php var_dump($_SERVER["PATH_INFO"]); ?>
</pre>

Wow, I haven't given much thought to trying to make ochiba work under Windows. I don't have access to a Windows server nor know much about it, so these are just going to be stabs in the dark.

When you say you tried pointing CONVERT to the convert.exe, did you put the full Windows path, such as:

define("CONVERT","C:\Progra~1\ImageM~1\convert.exe -quality 90 -geometry %s %s[0] %s");

(or wherever it is)?

Also, what happens if you copy the convert.exe into the ochiba directory and just:

define("CONVERT","convert.exe -quality 90 -geometry %s %s[0] %s");

?

WOW, what madness.

Thanks for the access. I think I kind of got it working. The Dreamhost build of PHP is whacked- apparently, it chokes on trying to find "index.php/blah" as per the RewriteRule- it never finds it and ochiba never "runs". I don't know if the "cgi.fix_pathinfo" param would fix this, but you don't have access to php.ini to try it out.

Anyway, two seemingly minor modifications makes it work:

.htaccess
This sends PHP the "path_info" as part of the GET string, instead of a real PATH_INFO. Thank god for the Apache folks.

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

index.php
This converts the path_info kludge from the .htaccess into what ochiba expects.

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

Another thing I noticed is that the caching doesn't work for some strange reason. You have to turn it off, or else you'll get stale cache reads.

Also, there are issues with the setuid behavior when it creates directories; I had to manually chmod 755 on thumbs and thumbs/00/. images/ and images/00/ don't need it in the default because of the way it works. This can be addressed by adding a umask call prior to the mkdir()s in post.php and process_image.php. Otherwise, you'll have errors when it gets to thumbs/01/.

Finally, /stats doesn't work because it appears Dreamhost has set that up as a special URL so ochiba never even gets that request. Madness, I tell you!

I left it set up at the site you provided- let me know if you notice any oddities I missed.

Drat.

OK, one last idea: in .htaccess, change the rewrite rule lines near the end from:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

to

RewriteCond %{SCRIPT_NAME} !-f
RewriteCond %{SCRIPT_NAME} !-d

or

RewriteCond %{DOCUMENT_ROOT}%{SCRIPT_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}%{SCRIPT_FILENAME} !-d

I'll try to set up a php-as-cgi system to tinker with this more directly if that doesnt' work out.

Hmm, some things to try (these are just off the top of my head, or from notes mentioned in the discussions linked above)

* cgi.fix_pathinfo=1 in your php.ini

* fiddle with the path-discovery variables at the end of conf.php. In particular, it seems like PHP run in cgi mode will not set certain $_SERVER variables relating to path to the correct path to the php file - instead, it is set to the php.cig binary, apparently. See the note by dasil003 at the end of the dreamhost knowledge base page. Try putting "echo"s in there with various variables and load /conf.php to see that they are being set correctly ($fileroot, $docroot, ROOT, __FILE__, etc).

* Try running PHP as a module rather than CGI, if only to see if this clears things up.

Personally, I think Dreamhost's "warnings" are a little overstated. You don't run any additional risk to yourself by running PHP as a module, and if anything it can make your stuff a little more secure if done properly. However, you do increase the risk to others on a shared hosting server, which is Dreamhost's perspective.

Actually, ImageMagick isn't a part of the php build, but rather a separate set of programs that ochiba will run using exec(). So, if you have shell login (ie ssh) access to your server, you could type something like

which convert

to see if the ImageMagick program convert is available.