Installation woes

stuhartley

I found a link to vanilla late last night and immediately proceeded to download the thing. It looks great.

Unfortunately I can't install it. When using the installer and choose to continue from step 2 to what is presumably step 3, I get the error:

Fatal error: Call to undefined function: html_entity_decode() in /home/httpd/vhosts/zenapproach.co.uk/subdomains/boards/httpdocs/library/Utility.Constant.class.php on line 69

...its all greek to me. Is my PHP version too old?

I can't do a manual install because I don't know how to process the vanilla.sql file - I don't have SQL command line.

Here's the proverbial phpinfo page

Thanks in advance

Stu

lech

Hmmm, no shell access or some hosted mysql admin features where you can execute/create sql entries of your own?

stuhartley

Wow that was quick. The answer is 'possibly' I shall have to check. Can you do this in phpmyadmin?

Mark

stuhartley: I know exactly what is causing that bug, and I will have that bug fixed in the next release (Friday). I could have sworn I already accomodated for that shortcoming of pre-php4.3.0 versions, but I guess not. Sorry about that.

Mark

If you want a quick-fix, open up the library/utility.functions.php and add this to the bottom of the page (before the ?>):

// Create the html_entity_decode function for users prior to PHP 4.3.0
if (!function_exists("html_entity_decode")) {
	function html_entity_decode($String) {
		$TranslationTable = get_html_translation_table(HTML_ENTITIES);
		$TranslationTable = array_flip($TranslationTable);
		return strtr($String, $TranslationTable);
	}
}

stuhartley

Ah I found it. I'm so used to getting things to install for me I've never forayed into the world of SQL. However here, I can make an exception and get my hands dirty. Sadly, more problems. On every page theres lots of errors, mostly about headers being sent already <a href="http://boards.zenapproach.co.uk">see here</a>. Any suggestions?

stuhartley

Oops, messed up the html there sorry. try http://boards.zenapproach.co.uk Ah the curse of writing posts at the same time. Mark, does your previous post about the quick fix apply to my new problem. I forgot to mention I *can* sign in and have successfully changed my password, so from what I can see there are no errors preventing me from doing my stuff

ithcy

all those "headers already sent" messages are caused by the first error - "open_basedir restriction in effect". your host is restricting script includes to the directories shown in your phpinfo() page, in the "open_basedir" variable. you may have to put vanilla into one of those folders. but, i defer to mark.

Mark

Okay, one step at a time:

1. My fix applies to that original error message you were talking about (html_entity_decode). My fix will not repair all of those "Warning: open_basedir restriction in effect." errors.

2. I think you are getting that "Warning: open_basedir restriction in effect." error because I am including all of my files absolutely from the root of your server. I bet that if you included everything relatively, it would fix the problem:

Open up appg/settings.php and edit line 21 from this:

define("agAPPLICATION_PATH", "/path/to/vanilla/");

to this:

define("agAPPLICATION_PATH", "./");

and see if that works.

stuhartley

Sadly not. I've still got the errors.

stuhartley

Oh and as for deja vu, that post was originally for installation woes. Its installed now, so no more installation woes... it just doesn't work properly edit: oops wrong discussion

lech

I've noticed that with some vhosting setups, what you see in ftp as the relative or in some cases, the absolute path are not always correct so to speak. The best way to figure out the actual path is by digging around manually through an error log if you can access it. Usually this will reveal the REAL path to the filed in question.

Typically, an absolute path on a properly setup host will appear as one of the following two ways:
/home/lech/domain.com/wwwdocs/vanilla/

you'll notice that the domain.com bit in that example is bolded out. In many cases, this is a relative link to the real location (like in my case) in your home directory which points it to the actual path. Many times your ftp program will treat this as transparently as possible just to not confuse you. But that would look something like this in the servers actual file directory structure:

/www/domain.com/wwwdocs/vanilla/

In my case, It's safe to use either of those paths to get vanilla working. Now this is where you're head will probably pop trying to locate the actual path. On several large vhosts (I'll be using MT in this example) they truely try to mask the absolute and relative paths because many of them use virtual server environments. Simply to say, it acts like it's own machine.

However there's still the deal of the real absolute paths that go back to the REAL root file system. So what you might see like in my previous examples is only the end of the whole real path. This is probably the piece you need, and the only way to do it is by scraping through the error logs. The real path might look something like this:

/customer12938/vhost4/block10/lech/www/domain.com/wwwdocs/vanilla/

While it might be good for them, it doesn't really help you if you're trying to setup your own software I hope that helps someone.

deel

wow that is some good info.

thx lech.

lech

yeah, upon trying to execute some perl on one of their servers I was skooled into figuring it out myself on what the real path was. Scraping through the error logs to locate the problem, the real path to the file was revealed. Needless to say I learned something that day and figured it *might* apply in this case as well.

stuhartley

thats great lech, I would have never thought to look in the error logs. The only way I found my path was because my wordpress install *suggested* the path to me for file uploads, and as I never had problems with that I figured it was a winner. As for my problems with vanilla, they were finally solved http://www.lussumo.com/community/comments.php?DiscussionID=390&page=1 At the moment I'm using the relative paths mark suggested above... if it ain't broke, don't fix it.

lech

No problem :) & good call. Mark knows his stuff, listen to him. Figured I might at least throw that one out there if it's ever necessary.