I'm having some problems getting WSN Links 3.3.3 installed on a Windows server.
First, the PHP rename() function does not work on Windows when a file already exists with the same name. So I was getting an error in setup.php line 99, even though the setup script said the installation was successful.
Second, after installation, when I browse from the "setup succefful" page to "view wsnlinks" (index.php) I get three of these errors:
Warning: Variable passed to each() is not an array or object in e:\data\wwwroot\irn\links\templatefunctions.php on line 509
This appears to be related to language stuff. I did an English-only install, so I'm not sure what's going wrong there.
Then, if I click "Suggest a Category", I get a bunch more errors:
Notice: Undefined index: catid in e:\data\wwwroot\irn\links\suggest.php on line 2
Notice: Undefined index: backupcatid in e:\data\wwwroot\irn\links\suggest.php on line 2
Notice: Undefined index: backupcatid in e:\data\wwwroot\irn\links\suggest.php on line 2
Plus I get more of the aforementioned templatefunctions.php errors.
Is WSN Links really supposed to work on a Windows server?
Warning: Variable passed to each() is not an array or object in e:\data\wwwroot\irn\links\templatefunctions.php on line 509
Line 509 of templatefunctions.php is $pattern = "{FUNC\_(.*?)\[(.*?)\]}"; and there's no each() around there. It seems you must be using a different file than me. There shouldn't be any difference in templatefunctions.php between 3.3.3 and 3.3.4.
If you say it has to do with language though, did you upload a language? It may not have been able to place in /languages/ by itself, as noted in the setup instructions.
As far as renaming goes, it only tries to rename if there is no file:
if (!file_exists("config.php")) rename("config.php.txt", "config.php");
but I'll slap error supression on it anyhow.
I don't have a copy of Windows available to test on, but I don't see any reason it should have trouble outside of the backups mechanism (which uses a shell command). I know there are people sucessfully running WSN Links on Windows as they've mentioned it in support posts and emails.
What version of PHP are you using? I've heard a couple of reports of problems with 5.1.x, which still isn't released as a debian package so I haven't had a chance to look at it. (I'm on 5.0.5 for localhost, and most production web servers are still on PHP 4.)
Okay, well I'm very confused. I just downloaded and installed the new version, 3.3.4. In 3.3.3 I was getting the error in templatefunctions.php line 509, but in 3.3.4 I get the same error on line 512. That line is:
while(list($key, $value) = each($langarray))
So while that may not be what you have in your personal version of WSN Links, it is what I got when I downloaded the zip files.
The reason I thought it had to do with the language settings is because of the $langarray variable. Also, when I browse to index.php, the title is displayed as {LANG_TITLE_BASE} which would seem to indicate that some kind of replacement value is not being inserted.
I don't think this is simply a PHP configuration issue. I have duplicated this error on my local machine as well as my web host. I have other PHP applications running at both places and have not had issues with them. I am running PHP 4.4.1 locally and so is my host.
I have re-read the readme file and don't understand if there is something I need to do with language files. I have uploaded all of them, and they exist in /languages/setup as .lng files. In /languages I have one file called default.lng.
I'm still waiting for support with this and I'm very frustrated. Before I get all wound up, how soon should I expect replies to issues posted on this board?
Anyway, I've done some more troubleshooting, and this is what I've found. Bear in mind that I am relatively new to PHP, though I've been programming in ASP for several years.
The $language object appears to get set in prestart.php. It remains a valid object (a test for is_object($language)=1) until start.php lines 71-75 are executed. Then is_object($language) returns nothing, which is odd to me, I would think it would at least return 0.
I've found that testing $origlang and $language as objects in function langreplacements in templatefunctions.php at line 506 also returns nothing. So then I tried inserting this line into function langreplacements at line 509 just to see what would happen:
$language = new language('default');
What do you know... it works. No warning messages, and the language replacements appear to be working.
So for some reason the $language object is getting cleared by start.php, and that's causing the problem. I've found that commenting out lines 71-75 in start.php as well as my line that hard-codes the language in templatefunctions.php also solves the problem.
Is this a bug, or is there something in my configuration that could be causing this?
Emails I typically get to within a day, forum posts typically within 3 days.
I don't think this is simply a PHP configuration issue.
To have any "Notice:" message appearing on your screen is a PHP configuration issue, as covered in the article.
It remains a valid object (a test for is_object($language)=1) until start.php lines 71-75 are executed.
The code in that area of start.php, starting at line 71, is
// end cat permissions
// make compatable when register_globals is off... and secure against php code input $skip = " newpasswordquery newusergroupquery db skipvalidation "; $elim = explode(' ', $skip); foreach($elim as $rem) { if ($rem != '') { if ($_REQUEST[$rem]) { $$rem = ''; $_REQUEST[$rem] = ''; $_GET[$rem] = ''; $_POST[$rem] = ''; } } }
which has nothing to do with $language. I get the sense that your method of line numbering is somehow completely different from mine. Perhaps there are lines that are merged on windows due to the line break character difference?
while(list($key, $value) = each($langarray))
That's line 532. Maybe it's skipping the breaks between each function for you or something. Anyhow the code there already contains a test for the possibility that $language has been destroyed (there are several pages on which it could be IIRC), and uses $origlang as a backup. I don't see how anything could modify $origlang... perhaps if I knew what your lines 71-75 were.
Okay, for starters, I do agree that the notifications were a PHP configuration issue. I disabled those and so of course that particular problem has gone away.
I don't know what's going on with the line numbering. I use HomeSite 5.5 and have never had any issues with my line numbers not matching someone else's. But that doesn't matter, I will list the relevant code here for you.
If I do echo is_object($language); before the following code in start.php, the result is 1. If I do echo is_object($language); after it, I get nothing.
while(list($key, $value) = each($_COOKIE)) { // blank out cookies to prevent 12432 votes on link on submission and the like $cookievarslist[] = $key; if (!strstr($skip, " $key ")) { $newvalue = stripcode($value); $_COOKIE[$key] = $newvalue; $$key = ''; } }
In start.php, you set $origlang = $language; after the code above. So if that code is somehow clearing the language object, then $origlang is getting set to nothing.
So then, in function langreplacements in templatefunctions.php, you test for $origlang and $language, but both of them are set to nothing, so no language gets loaded. At least that's the way it appears to me. As I said before, if I hard-code $language = new language('default'); then everything seems to work.
Do you have a cookie named language? WSN doesn't set one, but the behavior suggests you have one. Perhaps some other script within the same cookie path on your site is setting it.
Anyhow I'll move $origlang = $language; to above that area, and for good form also add language to the list of ignored request values: $skip = " newpasswordquery newusergroupquery db skipvalidation language ";
Ah... that's it! I do already have a "language" cookie that gets set by another script. I made the changes you suggested above and so far things seem to be working.
WSN Links seems to check for a "wsn_language" cookie in prestart.php so I'm not sure why it would conflict with a "language" cookie.
Thank you very much for your help getting this resolved.
0/5
1
2
3
4
5
This thread is closed, so you cannot post a reply.
Comments on Problems with Installation on Windows
Member
Usergroup: Customer
Joined: Dec 12, 2005
Total Topics: 11
Total Comments: 19
I'm having some problems getting WSN Links 3.3.3 installed on a Windows server.
First, the PHP rename() function does not work on Windows when a file already exists with the same name. So I was getting an error in setup.php line 99, even though the setup script said the installation was successful.
Second, after installation, when I browse from the "setup succefful" page to "view wsnlinks" (index.php) I get three of these errors:
Warning: Variable passed to each() is not an array or object in e:\data\wwwroot\irn\links\templatefunctions.php on line 509
This appears to be related to language stuff. I did an English-only install, so I'm not sure what's going wrong there.
Then, if I click "Suggest a Category", I get a bunch more errors:
Notice: Undefined index: catid in e:\data\wwwroot\irn\links\suggest.php on line 2
Notice: Undefined index: backupcatid in e:\data\wwwroot\irn\links\suggest.php on line 2
Notice: Undefined index: backupcatid in e:\data\wwwroot\irn\links\suggest.php on line 2
Plus I get more of the aforementioned templatefunctions.php errors.
Is WSN Links really supposed to work on a Windows server?
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
As far as the notices go, you have a php configuration problem. Read scripts.webmastersite.net/w...nks/wsnmanual/articles/238
Warning: Variable passed to each() is not an array or object in e:\data\wwwroot\irn\links\templatefunctions.php on line 509
Line 509 of templatefunctions.php is $pattern = "{FUNC\_(.*?)\[(.*?)\]}"; and there's no each() around there. It seems you must be using a different file than me. There shouldn't be any difference in templatefunctions.php between 3.3.3 and 3.3.4.
If you say it has to do with language though, did you upload a language? It may not have been able to place in /languages/ by itself, as noted in the setup instructions.
As far as renaming goes, it only tries to rename if there is no file:
if (!file_exists("config.php")) rename("config.php.txt", "config.php");but I'll slap error supression on it anyhow.I don't have a copy of Windows available to test on, but I don't see any reason it should have trouble outside of the backups mechanism (which uses a shell command). I know there are people sucessfully running WSN Links on Windows as they've mentioned it in support posts and emails.
What version of PHP are you using? I've heard a couple of reports of problems with 5.1.x, which still isn't released as a debian package so I haven't had a chance to look at it. (I'm on 5.0.5 for localhost, and most production web servers are still on PHP 4.)
Member
Usergroup: Customer
Joined: Dec 12, 2005
Total Topics: 11
Total Comments: 19
Okay, well I'm very confused. I just downloaded and installed the new version, 3.3.4. In 3.3.3 I was getting the error in templatefunctions.php line 509, but in 3.3.4 I get the same error on line 512. That line is:
So while that may not be what you have in your personal version of WSN Links, it is what I got when I downloaded the zip files.
The reason I thought it had to do with the language settings is because of the $langarray variable. Also, when I browse to index.php, the title is displayed as {LANG_TITLE_BASE} which would seem to indicate that some kind of replacement value is not being inserted.
I don't think this is simply a PHP configuration issue. I have duplicated this error on my local machine as well as my web host. I have other PHP applications running at both places and have not had issues with them. I am running PHP 4.4.1 locally and so is my host.
I have re-read the readme file and don't understand if there is something I need to do with language files. I have uploaded all of them, and they exist in /languages/setup as .lng files. In /languages I have one file called default.lng.
Member
Usergroup: Customer
Joined: Dec 12, 2005
Total Topics: 11
Total Comments: 19
I'm still waiting for support with this and I'm very frustrated. Before I get all wound up, how soon should I expect replies to issues posted on this board?
Anyway, I've done some more troubleshooting, and this is what I've found. Bear in mind that I am relatively new to PHP, though I've been programming in ASP for several years.
The $language object appears to get set in prestart.php. It remains a valid object (a test for is_object($language)=1) until start.php lines 71-75 are executed. Then is_object($language) returns nothing, which is odd to me, I would think it would at least return 0.
I've found that testing $origlang and $language as objects in function langreplacements in templatefunctions.php at line 506 also returns nothing. So then I tried inserting this line into function langreplacements at line 509 just to see what would happen:
$language = new language('default');
What do you know... it works. No warning messages, and the language replacements appear to be working.
So for some reason the $language object is getting cleared by start.php, and that's causing the problem. I've found that commenting out lines 71-75 in start.php as well as my line that hard-codes the language in templatefunctions.php also solves the problem.
Is this a bug, or is there something in my configuration that could be causing this?
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
Emails I typically get to within a day, forum posts typically within 3 days.
I don't think this is simply a PHP configuration issue.
To have any "Notice:" message appearing on your screen is a PHP configuration issue, as covered in the article.
It remains a valid object (a test for is_object($language)=1) until start.php lines 71-75 are executed.
The code in that area of start.php, starting at line 71, is
which has nothing to do with $language. I get the sense that your method of line numbering is somehow completely different from mine. Perhaps there are lines that are merged on windows due to the line break character difference?
while(list($key, $value) = each($langarray))
That's line 532. Maybe it's skipping the breaks between each function for you or something. Anyhow the code there already contains a test for the possibility that $language has been destroyed (there are several pages on which it could be IIRC), and uses $origlang as a backup. I don't see how anything could modify $origlang... perhaps if I knew what your lines 71-75 were.
Member
Usergroup: Customer
Joined: Dec 12, 2005
Total Topics: 11
Total Comments: 19
Okay, for starters, I do agree that the notifications were a PHP configuration issue. I disabled those and so of course that particular problem has gone away.
I don't know what's going on with the line numbering. I use HomeSite 5.5 and have never had any issues with my line numbers not matching someone else's. But that doesn't matter, I will list the relevant code here for you.
If I do echo is_object($language); before the following code in start.php, the result is 1. If I do echo is_object($language); after it, I get nothing.
In start.php, you set $origlang = $language; after the code above. So if that code is somehow clearing the language object, then $origlang is getting set to nothing.
So then, in function langreplacements in templatefunctions.php, you test for $origlang and $language, but both of them are set to nothing, so no language gets loaded. At least that's the way it appears to me. As I said before, if I hard-code $language = new language('default'); then everything seems to work.
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
Do you have a cookie named language? WSN doesn't set one, but the behavior suggests you have one. Perhaps some other script within the same cookie path on your site is setting it.
Anyhow I'll move $origlang = $language; to above that area, and for good form also add language to the list of ignored request values:
$skip = " newpasswordquery newusergroupquery db skipvalidation language ";
Member
Usergroup: Customer
Joined: Dec 12, 2005
Total Topics: 11
Total Comments: 19
Ah... that's it! I do already have a "language" cookie that gets set by another script. I made the changes you suggested above and so far things seem to be working.
WSN Links seems to check for a "wsn_language" cookie in prestart.php so I'm not sure why it would conflict with a "language" cookie.
Thank you very much for your help getting this resolved.