I just tried to upgrade my install of WSNlinks from version 3.x to the newest 4.x. Had a couple of minor error messages during install (the last one was the script complaining that it wanted write access to the language file). Install ends on a white page that has a white box (thin black frame) at the top, and a "WSN Links 4.1.39" underneath. No error message in the apache log.
So is that it? Does it mean it's a successful install, or should I go and shoot myself? Thanks for the insight.
Given that you'd already seen a permissions error about languages, it probably died from permissions problems.
Ideally, a host these days should be using suexec so that there are never any permissions issues. Those that for whatever reason don't use suexec and don't run php as cgi should provide the FTP extension, so that you can type your FTP info at Admin -> Settings -> System to let the script handle chmoding for you. Coming from 3.x though I don't believe the FTP options were implimented yet, so there were a mess of permissions which could be issues in such an upgrade... though it should normally give appropriate messages.
Of course, to say anything more useful I would have to know what version you were upgrading from. "3.x" could refer to any of approximately 70 releases.
To find out whether the install was at least somewhat successful, of course, you'll need to have a look at your website and see whether it's running or not.
Thanks for the quick reply. Not sure why you think the script died from permission problems. Of course I don't make all my files world-writeable by default, and since the update instructions didn't say to make the language file writeable, I was bound to run into this error. I fixed the permissions, and here I am.
[rant]I hope you do realize that your comments about what hosts should or should not do these days aren't very helpful. You are obviously well aware that different hosts offer all kinds of environments, and that your update script seems to break in some of them. I guess it's not too much asked for if your script would at least throw some sort of meaningful error if it breaks - hell it could at least say it's broken when it's broken. There's no error message whatsoever in the log files, so if the script intercepts errors and then dies gracefully without a word, that only makes things worse.[/rant]
On to the constructive stuff. I'm updating from 3.15 (at least if the readme file in the old directory is to be trusted). And I'm aware that I should have updated a long time ago, but I guess it's too late now, so I'm trying to make the best of it. As far as looking at the website, the admin interface seems to be working flawlessly, but the website is a mess. That's what I'd have expected with a perfect install, since with the old install I've modfied the templates and some of the code to fit my needs, and I still need to apply those changes to the new install. Doing so however will be an uphill battle if after banging my head against the screen for days I realize that the update script didn't finish and important stuff is missing.
Probably needless to say that it's a live site, which is why the problem neither puts me in a pleasant situation nor mood (you probably noticed ). Thanks again.
Not sure why you think the script died from permission problems.
Simply because I'm operating completely in the dark and that's the most common way I've seen people have troubles coming from 3.x.
I hope you do realize that your comments about what hosts should or should not do these days aren't very helpful
If you can't be bothered to ask your host to fix something they've broken, then you're going to have to do everything the hard way. That's how it goes. This isn't a matter of personal taste, it's a matter of making it logically possible to accomplish things. I do hope you realize I can't hack into your server to tell it to allow the script to set permissions. All I can do is handle everything automatically for properly set up hosts, and spit out a list of manual instructions which are easy to mess up for those stuck on broken hosts.
There's no error message whatsoever in the log files, so if the script intercepts errors and then dies gracefully without a word, that only makes things worse.
When the script dies without a message, that's because PHP is configured to suppress the message (which I actually try to override), or PHP dies before it's able to generate a message. The latter has tended to happen with people using ancient versions with PHP 5, but it's always concievable that something else could cause it.
A lack of log entry presumably means there's no PHP-based error, though it doesn't preclude the chance that some upgrade operation failed which didn't have any message to give since the circumstance created by 3.15 was unanticipated. Most likely everything worked though.
You are obviously well aware that different hosts offer all kinds of environments, and that your update script seems to break in some of them.
The update works with all hosting environments on the supported list (PHP+MySQL) for any reasonable instance of an upgrade, even if it is much more complicated and thus prone to user error for broken PHP setups. There are no issues in any hosting environment upgrading from 4.0.42 to 4.1.39 right now, for example. 3.15 to 4.1.39, however, is unreasonable and impossible to test so who knows what could go wrong with it in certain environments.
I cannot possibly test upgrading from each of the many hundreds of releases to each new release every time I make a release. I don't intentionally break compatibility with ancient upgrades, but if you're doing something nobody else has ever done before -- like 3.15 -> 4.1.39 -- then you can expect the unexpected.
The last time I did a 3.15 upgrade was probably to 3.3 several years ago, and I don't have a copy of 3.15 on hand. Even if I had a copy I couldn't run it since all my testing and hosting environments are PHP 5.
That's what I'd have expected with a perfect install, since with the old install I've modfied the templates and some of the code to fit my needs, and I still need to apply those changes to the new install.
If you didn't follow the upgrade instructions when they said to overwrite your templates, then yes, it's going to be a mess. It sounds like everything went properly without error. The lack of message probably related to an old template being used, or maybe you haven't upgraded your language files either.
0/5
1
2
3
4
5
Sorry, you don't have permission to post posts. Log in, or register if you haven't yet.
Comments on Installation finished?
Member
Usergroup: Customer
Joined: Jan 30, 2005
Total Topics: 5
Total Comments: 12
I just tried to upgrade my install of WSNlinks from version 3.x to the newest 4.x. Had a couple of minor error messages during install (the last one was the script complaining that it wanted write access to the language file). Install ends on a white page that has a white box (thin black frame) at the top, and a "WSN Links 4.1.39" underneath. No error message in the apache log.
So is that it? Does it mean it's a successful install, or should I go and shoot myself? Thanks for the insight.
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
Given that you'd already seen a permissions error about languages, it probably died from permissions problems.
Ideally, a host these days should be using suexec so that there are never any permissions issues. Those that for whatever reason don't use suexec and don't run php as cgi should provide the FTP extension, so that you can type your FTP info at Admin -> Settings -> System to let the script handle chmoding for you. Coming from 3.x though I don't believe the FTP options were implimented yet, so there were a mess of permissions which could be issues in such an upgrade... though it should normally give appropriate messages.
Of course, to say anything more useful I would have to know what version you were upgrading from. "3.x" could refer to any of approximately 70 releases.
To find out whether the install was at least somewhat successful, of course, you'll need to have a look at your website and see whether it's running or not.
Member
Usergroup: Customer
Joined: Jan 30, 2005
Total Topics: 5
Total Comments: 12
Thanks for the quick reply. Not sure why you think the script died from permission problems. Of course I don't make all my files world-writeable by default, and since the update instructions didn't say to make the language file writeable, I was bound to run into this error. I fixed the permissions, and here I am.
[rant]I hope you do realize that your comments about what hosts should or should not do these days aren't very helpful. You are obviously well aware that different hosts offer all kinds of environments, and that your update script seems to break in some of them. I guess it's not too much asked for if your script would at least throw some sort of meaningful error if it breaks - hell it could at least say it's broken when it's broken. There's no error message whatsoever in the log files, so if the script intercepts errors and then dies gracefully without a word, that only makes things worse.[/rant]
On to the constructive stuff.
Probably needless to say that it's a live site, which is why the problem neither puts me in a pleasant situation nor mood (you probably noticed
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
Not sure why you think the script died from permission problems.
Simply because I'm operating completely in the dark and that's the most common way I've seen people have troubles coming from 3.x.
I hope you do realize that your comments about what hosts should or should not do these days aren't very helpful
If you can't be bothered to ask your host to fix something they've broken, then you're going to have to do everything the hard way. That's how it goes. This isn't a matter of personal taste, it's a matter of making it logically possible to accomplish things. I do hope you realize I can't hack into your server to tell it to allow the script to set permissions. All I can do is handle everything automatically for properly set up hosts, and spit out a list of manual instructions which are easy to mess up for those stuck on broken hosts.
There's no error message whatsoever in the log files, so if the script intercepts errors and then dies gracefully without a word, that only makes things worse.
When the script dies without a message, that's because PHP is configured to suppress the message (which I actually try to override), or PHP dies before it's able to generate a message. The latter has tended to happen with people using ancient versions with PHP 5, but it's always concievable that something else could cause it.
A lack of log entry presumably means there's no PHP-based error, though it doesn't preclude the chance that some upgrade operation failed which didn't have any message to give since the circumstance created by 3.15 was unanticipated. Most likely everything worked though.
You are obviously well aware that different hosts offer all kinds of environments, and that your update script seems to break in some of them.
The update works with all hosting environments on the supported list (PHP+MySQL) for any reasonable instance of an upgrade, even if it is much more complicated and thus prone to user error for broken PHP setups. There are no issues in any hosting environment upgrading from 4.0.42 to 4.1.39 right now, for example. 3.15 to 4.1.39, however, is unreasonable and impossible to test so who knows what could go wrong with it in certain environments.
I cannot possibly test upgrading from each of the many hundreds of releases to each new release every time I make a release. I don't intentionally break compatibility with ancient upgrades, but if you're doing something nobody else has ever done before -- like 3.15 -> 4.1.39 -- then you can expect the unexpected.
The last time I did a 3.15 upgrade was probably to 3.3 several years ago, and I don't have a copy of 3.15 on hand. Even if I had a copy I couldn't run it since all my testing and hosting environments are PHP 5.
Of course, if you like, you can always stick me with doing the risky jumps for a small fee: scripts.webmastersite.net/w...index.php?section=upgrades . Once you've already gone through attempting it though it's too late.
That's what I'd have expected with a perfect install, since with the old install I've modfied the templates and some of the code to fit my needs, and I still need to apply those changes to the new install.
If you didn't follow the upgrade instructions when they said to overwrite your templates, then yes, it's going to be a mess. It sounds like everything went properly without error. The lack of message probably related to an old template being used, or maybe you haven't upgraded your language files either.