Verision 5.4 Conversion: Install Process Aborts with Script Error.

[sissy]

Well, I got everything set up correctly to install Indexu v5.4. I created the database, assigned ownership to the appropriate user, uploaded all the files, set all the permissions as requested, and started and ran the install.php script exactly as described.

Everything ran smoothly through the first few steps. No errors. Nothing out of the ordinary at all. All files were found. The directory and file permissions were all correct, etc. etc. When it finally arrived at the screen where it said it was ready to create the database, I figured I was home free. But as soon as that process started, I got the following error:

        Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /home/www/myhome/indexu54/lib/link.class.php on line 1209

        Parse error: syntax error, unexpected T_STRING in /home/www/myhome/indexu54/lib/link.class.php on line 1209

After that happened, the script just stopped and that was the end of things.

So, next I logged in with my telnet client, fired up 'vi', went into the indexu54/lib directory and opened up link.class.php to look at it. What I found was that lines 1209 and 1210 in the component read as follows:

        $tpl->assign("$fields[$i]_upload", "<%\$$fields[$i]_upload%>");
        $tpl->assign("$fields[$i]_remove", "<%\$$fields[$i]_remove%>");

It's those two slashes highlighted in red that my version of php (4.4.4) is objecting to. So, next I copied the front portion of that error message and went to google to search for:

        Warning: Unexpected character in input: '\' (ASCII=92) state=1

I soon discovered that there are dozens (if not hundreds) of references to this error on the web; but although dozens of users and programmers encountered and complained about this issue (which seems to have appeared suddenly in PHP somewhere around version 4.0.3 and continued through roughly version 4.5), I only found one guy who ever claimed to have found a way around the problem and he never did say exactly how he solved it in his code. It appears the issue is that the appearance of the "\" before the dollar sign isn't being treated the expected way by PHP. But you can't leave it out or PHP assumes the $ that follows it is the beginning of a string field name.

Next, I went to the php.net site to see if THEY had anything to say about this error. I found that the error was reported 20 times over 3 years as a bug in PHP and 20 times out of 20 the PHP folks insisted that it was NOT a bug. But not ONCE did anyone ever suggest a way to work around it either.

I'm really NOT a php programmer, but realizing the issue was the appearance of the un-escaped slash in the code and in an effort to fix the problem, I tried removing the slashes. That didn't work because then I got a syntax error on the pair of $$ that followed the slash. Next, I tried "escaping" the slashes in both lines by bracketing them in single quotes so that the lines read like this:

        $tpl->assign("$fields[$i]_upload", "<%'\'$$fields[$i]_upload%>");
        $tpl->assign("$fields[$i]_remove", "<%'\'$$fields[$i]_remove%>");

But when I tried running the code that way, I got rid of the first error in line 1209 only to get a repeat of the same error in line 1210 even though the slash in both lines had been escaped the exact same way! In addition, I also got a brand new error in line 1216:

        Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /home/www/sissyland/indexu54/lib/link.class.php on line 1210

        Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in /home/www/sissyland/indexu54/lib/link.class.php on line 1216

In a final effort to work around the problem I left the escaped slash in for line 1209 but removed the escaping quotes from line 1210 so that the lines now read like this:

        $tpl->assign("$fields[$i]_upload", "<%'\'$$fields[$i]_upload%>");
        $tpl->assign("$fields[$i]_remove", "<%\$$fields[$i]_remove%>");

but that just gave me a new error on line 1224:

        Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in /home/www/sissyland/indexu54/lib/link.class.php on line 1216

So I threw up my hands and restored the original code and decided to appeal to you guys on Mount Olympus as the "higher authority" on how to fix this problem so that PHP 4.4.4 handles it correctly.

Oh, for the record, I also did a search with one of my tools here for every occurrence of the \$$ string anywhere in the index54 release and found it occurs 14 times in 8 distinct modules including:

add.php
become_editor.php
blocks\blocks.alphabar.php
lib\link.class.php
lib\nusoap\nusoap.php
lib\smarty\internals\core.write_compiled.php
soap\nusoap.php
soap\test\nusoap.php

Okay, Gurus, the ball is in your court now. I've told you what I know, what I learned in my research, and what I did to try to fix the error. Exactly What should I DO to work around this problem?

I humbly await the wise words of the Olympian Gods with bated breath... (Bruce: Please tell the Almighty Zeus/Dody it's time to strike his anvil with his hammer and make lightning happen!)

Thanks!
sissy

[Bruceper]

To fix the issue with Unexpected character in input: '\' (ASCII=92) state=1 add the following to your .htaccess file
php_flag asp_tags off

If you are not able to run that in .htaccess then ask your host to do it for you. If you receive a 500 error after adding that to your .htaccess then you are not allowed to do this. Ask your host to do it for you.

If you are on a windows server then you cannot use .htaccess and MUST ask the host to do this for you.

If in the end your host will not do this for you, then find a new host. This is not an issue with IndexU, rather it is an issue of the HOST.

There have been a number of posts about this recently, if you searched the forum you would have saved yourself the time of writing all that out.

[sissy]

Hurray! Bruce YOU get the Zeus' Hammer Award for the day. You're now MY HERO!

The change to .htaccess fixed the problem with installing 5.4 completely. All I had to do was reupload all the files again - because the installation process aborted right in the middle. Then I reran the installation process and everything worked flawlessly from beginning to end. I even got the license key installed and the password changed and am IN and can see the control panel now. And what a thing of beauty it is too!

But the BEST part is this SAME fix also repaired my old version so that it's running again now too! Yipppeee!!! Hooooray! Way to Go! Yahooooo!!!! Thanks a BUNCH GUY! I hereby officially and publicly kiss your magic programmer's ring!

As you may recall from my earlier post, since my server got hacked back in November, and they rebuilt the server's base software and upgraded it to MySQL 3.23.58, and PHP 4.4.4, PHP had completely refused to run my old version of Indexu, which had run flawlessly for nearly 4 years. Now, suddenly it's working again too. Obviously the new PHP needed the same laxative to make Indexu 3.1 work that it needed to allow the new version to work.

That's great. It takes the pressure off me to be in a big hurry to get the new version working ASAP and buys me the time I need to carefully study the new version and get it configured exactly the way I want without the need to feel under HUGE pressure to get it up FAST! Heck, I might even be able to take Christmas day off now, too!

You know, the one thing that puzzles me about this is if all those users were having this same problem why is it that NOONE ever explained what to do to fix it before? If it was that damned easy, you'd think SOMEONE would surely have had the forethought to publish the solution SOMEWHERE so that guys like me could find it later... Jeez!! Do you have any clue as to why this was such a deep dark secret?

Anyway, thanks a lot Bruce. You've saved the day for me. And now, I think I'll do what's needed to get the old version working again and then go to bed and call it a day!

Thanks again for the help!

Gratefully yours,
sissy

[Bruceper]

It's interesting that it fixed your old version, I would have never have known that unless you mentioned it.

It's not a secret, it's just that so few people run version 3 anymore. Plus I'll be honest and say that most hosts do not have asp_tags set to on.

[sissy]

Okay. So I've got 3.1 up and running again except that I've lost the vbulletin side of the indexu-to-vbulletin custom integration I had built because I've just upgraded from vBulletin 3.0.8 to 3.5.8 and haven't yet found and retrofitted the custom mods on the vbulletin side yet.

They should of course, still BE there on the Indexu side.

Questions on the v5.4 install:

1. Now that the install is finished and the required parameters have been placed in application.php, is there any good reason to leave that particular file set with permissions of 777 since the installation and configuration are now complete? It seems to me leaving the permissions on a key configuration file at 777 leaves the entire application fairly vulnerable to outside hacking or sabotage by someone who knows the app.

2. I've also taken the time to password protect the admin directory so that the admin area is protected from hacking. I've also deleted the install directory. Are there any other hacking vulnerabilities yo know of that I should be seriously concerned about?

3. Now that indexu31 is running again, how would you suggest I export the key data tables from the old app to the new one? Should I try to use the built in table level exports and import features in the Indexu 3.1 and 5.4 admin panels? Or would simple MySQLdumps and MySQL imports of the idx_categories, idx_members and idx_links tables be sufficient? Are there any other major tables beyond those three that I should be concerned about bringing over as well?

4. The first time I accessed the Indexu v5.4 opening screen, my copy of I.E. 7.0 warned that the site might be a phishing site and recommended that I NOT give it any of my "personal data". What is it about Idexu v5.4 that causes I.E. to do that? I've NEVER seen that warning on Indexu v3.1! Finally, is there anything I can (or should) do from MY end to ensure that my visitors do not receive the same warning?

Thanks again. I'm headed to bed now. I'll tackle the re-integration wit vbulletin 3.5.8 when I'm fresh in the morning.

[sissy]

There have been a number of posts about this recently, if you searched the forum you would have saved yourself the time of writing all that out.

I did try searching this forum for the error message I originally got from Indexu v3.1 and did not find it here. When I posted a message about the problem I was having, the advice I got was, "The version you're running is no longer supported we recommend you upgrade." or words to that effect.

I'm not sure why, but I assumed the second message was identical to the first one. In comparing the two messages now, I see the v5.4 message wasn't exactly the same as the one I got in v3.1. Obviously the cause of the message originates from the fact that the webhosting company that hosts my dedicated server upgraded my version of PHP when they rebuilt my server drive without telling me they had done so. In my defense, it was practically the same line number in the same module (link.class.php) where I got the two messages in v3.1 and v5.4 (line 1214 in one and line 1209 in the other). Perhaps because I'd already done the search here previously and failed to get any help, I didn't bother to repeat the search when I got what I thought was the same message in the same module while installing 5.4.

We all tend to make assumptions. In this case, my assumption was obviously incorrect. I'm sorry, Bruce.

Any feedback you can provide on my v5.4 questions from my earlier post would certainly be appreciated. That phishing site warning I received for v5.4 particularly bothers me. For obvious reasons, I'm not eager to jump over to 5.4 if I.E. is going to be warning everyone who visits my site that "this may be a phishing site!"

Thanks.

[Bruceper]

Application.php can be changed to 644 after it has been modified. Just remember that if you try to modify it later you won't be able to unless you CHMOD it to 666 or 777 again.

The most common hacking issues are weak passwords. Use at least a combination of uppercase, lowercase, numbers and symbols (#, $, !) and a length of at least 10 characters.

Export via the admin panel for the old links/categories. A mySQL dump will be good to have as a backup, but you can't import it to the new version without modifications.

IE7 sucks monkies. That phishing crap is the worst idea ive ever seen. Turn off the yahoo feed and that will go away.

[Bruceper]

No need to apologize, if you didn't realize they were the same issue then you didn't realize it. Not a big deal.

[FSGDAG]

That phishing site warning I received for v5.4 particularly bothers me. For obvious reasons, I'm not eager to jump over to 5.4 if I.E. is going to be warning everyone who visits my site that "this may be a phishing site!"

Thanks.

Submitt the site to MS to have it removed from the phising warnings. They usually have it removed within 24 hours

[sissy]

Application.php can be changed to 644 after it has been modified. Just remember that if you try to modify it later you won't be able to unless you CHMOD it to 666 or 777 again.

The most common hacking issues are weak passwords. Use at least a combination of uppercase, lowercase, numbers and symbols (#, $, !) and a length of at least 10 characters.

Export via the admin panel for the old links/categories. A mySQL dump will be good to have as a backup, but you can't import it to the new version without modifications.

IE7 sucks monkies. That phishing crap is the worst idea ive ever seen. Turn off the yahoo feed and that will go away.

No sweat on the application.php permissions.

Yes. Since the server hack, I'm using C2 compliant passwords so long and complex even I can't remember them without looking them up. And on all my sites there's a different password for telnet login than for email and a different login for the control panel and a different login and password for every application as well. I also seized control of mysql from my webhost so that even THEY can't get in there without my approval!

I figured as much on the data table export/import. No problema. I can handle the data port. As I said in an earlier post, I built this database from scratch originally and Indexu never knew the difference.

IMHO, IE actually sucks dead bears. Still, there's no denying the fact that 80% of all our visitors arrive using I.E. no matter how many dead bears and monkies it sucks. So, we're stuck with it no matter WHAT we do. I continue to USE it for site testing because that's the way most of my visitors (except the AOHELL ones) actually see my site. For the record, I also have 3 other browsers installed and use THEM when I want a more accurate view of "reality".

Thanks again, Bruce. I sincerely appreciate the support and feedback!

My next goal is to convert that database.

Then I'm going to try to figure out how to build a custom template.

Thanks again.

[Bruceper]

Telnet is bad, you should be using SSH2, uless you just said telnet and really meant ssh2

[sissy]

Telnet is bad, you should be using SSH2, uless you just said telnet and really meant ssh2

I did in fact. I use putty as my SSH client. I know it's secure and telnet wasn't. But to me I'm afraid putty will ALWAYS be called telnet. I started working on Unix systems back when the internet was only being used in colleges and military installations. Indeed, my early experience as a Unix and AIX admin predates the birth of Html by 10 years or so and in those days there was only telnet.

At age 57 and after 40 years in the computer business (That's 20 operating systems 15 hardware generations, 4 generations of programmers and at least 30 computers ago), trying to convince me I should now call telnet SSH is akin to telling me that good now means bad and bad now means good and I should now call dogs cats and cats should now be called pigs and great now means lousy... and to suck is now a BAD thing... and a group of women must no longer referred to as girls and... Oh never mind!

No matter how hard I try, it isn't likely to happen because my language skills and lexicon mappings were laid down over half a century ago. At this point in my life, I'm lucky if I can still remember my kid's names and not get them confused by calling our daughter Tom and our son Ella. And with 2 young grandsons and 1 great nephew ALL of whose names start with "C" it's an utterly hopeless proposition for me to ever get their names straight!

If that makes me an old fart, so BE it! One day you too will reach the ripe old age of 57 (May you be so lucky!) and I'll bet you too will have given up trying to completely reprogram your language paths every few years because the generations of youngsters behind you are constantly redefining the meaning of everything. Mark my words. Your day is coming too, Bruce.

Yep, I meant SSH. You caught me in a senior moment. Sorry!

[sissy]

Submitt the site to MS to have it removed from the phising warnings. They usually have it removed within 24 hours

I already did that last night. But thanks for the suggestion anyway, FSGDAG!

[Bruceper]

Have no fear, I'm only 37 and I already get my kids names mixed up

[sissy]

Have no fear, I'm only 37 and I already get my kids names mixed up

ROFLMSAO!! Thanks for making an "old fart" laugh, Bruce. I REALLY needed that! I've spent the whole afternoon digging through vBulletin's latest code trying to figure out how I made the integration between vBulletin 3.08 and Indexu 3.1 work as well as I did 4 years ago. So far I've made little progress. Sigh...

Happy Holidays to you and your family, friend!