hebcat Posted October 14, 2013 Share Posted October 14, 2013 Hi all, Have downloaded/uploaded v5.2.4 twice now to my client's hosting account and on both times I can't get to the setup page. I get: Parse error: syntax error, unexpected T_OBJECT_OPERATOR in ****/setup/index.php on line 582 Now I've seen other posts about this being an issue to do with old versions of PHP. This one runs PHP 5.2.17 and MySQL 4.1.22 Would either of these be too old? Server requirements on Cubecart site say it should be PHP 5.2.3+ so maybe that's the obvious answer but I thought I'd run it by here before changing anything on the hosting. Other related question -- there's an existing site on there which appears to be using the "Big Medium" CMS (written in PERL with file types are mostly .xml .txt and .shtml). If I have the host update PHP, the exsiting site shouldn't be affected, should it? Many thanks in advance Quote Link to comment Share on other sites More sharing options...
havenswift-hosting Posted October 14, 2013 Share Posted October 14, 2013 This one runs PHP 5.2.17 and MySQL 4.1.22 Would either of these be too old?Both of those are extremely old (4 or 5 years at least !) and not even supported any longer - you should definitely definitely get your hosting company to upgrade or better still move to a hosting company that specialises in CubeCart.Other related question -- there's an existing site on there which appears to be using the "Big Medium" CMS (written in PERL with file types are mostly .xml .txt and .shtml). If I have the host update PHP, the exsiting site shouldn't be affected, should it?The host may be willing to update the php and MySQL on that server although I would question why that hadnt been done before but you would need to check what the server requirements are for the specific version of that other CMS you are running before you ask Quote Link to comment Share on other sites More sharing options...
hebcat Posted October 14, 2013 Author Share Posted October 14, 2013 Ah thanks very much for that. I'll check with the host and see what they can do. It's Nativespace; have worked with them many times before and never had a problem. I'll keep this post up to date for future reference. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 14, 2013 Share Posted October 14, 2013 If the version of PHP were an issue, there would be parse errors earlier in the script. The code at line 582 (in CC524) has not changed since CC500. The statement looks fine to me. If you can, compare a copy of the file as it sits on your server with the file from the CubeCart download package. Quote Link to comment Share on other sites More sharing options...
hebcat Posted October 15, 2013 Author Share Posted October 15, 2013 Hello! Line 582 is the same between the local setup/index.php (unmodified since being downloaded & unzipped) -- and what sits on the server. Doing a comparison I've found three lines that look different. Here they are but I don't imagine they're important: Line 362, local: //Â Upgrade Main ConfigurationLine 362, on server: // Upgrade Main Configuration Line 405, local: //Â Rename existing keysLine 405, on server: // Rename existing keys Line 608, local:##Â Controller elementsLine 608, on server:## Controller elements On a side note.... Nativespace have offered to migrate the site to a more up-to-date server of theirs; I'm just waiting for approval from the client to do this. Thanks again. Quote Link to comment Share on other sites More sharing options...
havenswift-hosting Posted October 15, 2013 Share Posted October 15, 2013 All of those three lines are comment lines so wont make any difference although the fact that you are seeing character differences like that could indicate that there are other differences which may or may not be visible - it is difficult to say without seeing the files but it could be an issue with your FTP client and the upload method or it could be a hosting issue.Good that they are willing to move you but still amazed that any company is running any server on systems that are that old ! Quote Link to comment Share on other sites More sharing options...
hebcat Posted October 15, 2013 Author Share Posted October 15, 2013 I use WS_FTP and haven't changed any software or procedure since the previous installs of CC (see my sig file for details). Just to be sure, I reuploaded a third time, making sure I used the local>remote button (instead of selecting in windows explorer and dragging) -- but with the same outcome. Strange though I've never noticed the "Â" character in any other CC files I've worked on, and that's the local version!! :/ Will explore and report back if I get anywhere. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 15, 2013 Share Posted October 15, 2013 This is an indication that someone is not playing by the UTF-8 rules. If you do not see this anomaly on the file before sending it to the server, but you do afterwards, then perhaps you are using the ASCII or Auto mode of FTP transfer and WS_FTP is making a bad conversion (ASCII mode does that). If the above is the case, switch to Binary mode of transfer. (Not related to this problem, but for building the database, the source files have UTF-8 characters for city names and currency names.) Quote Link to comment Share on other sites More sharing options...
hebcat Posted October 15, 2013 Author Share Posted October 15, 2013 Hi there, Well actually it's the other way around -- the anomaly is showing up BEFORE I upload it to the server. And then once it's uploaded, those characters have disappeared. Is there anywhere I can download the previous release of CC from -- and test it out? Or does anyone else see the "Â" characters on lines 362, 405, 608 in setup/index.php in the freshly unzipped 5.2.4? Just looked back at the setup/index.php file from 5.1.5 and it doesn't have any "Â" characters. Thanks again. Quote Link to comment Share on other sites More sharing options...
hebcat Posted October 15, 2013 Author Share Posted October 15, 2013 PS. temporarily overwrote the 5.2.4 version of setup/index.php with the 5.1.5 one and it's given me the same error, except for line 601. It's the same line of code though: $skins[(string)$xml->info->name][(string)$style->directory] = ((string)$style->attributes()->images == 'true') ? true : false; Gotta try!! Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 15, 2013 Share Posted October 15, 2013 Looking at the hex mode of this file, I find no problem with the "Object Operator" (->). But the instances of the anomaly is caused by the byte sequence c2 a0, which is Unicode for a non-breaking space. I can only guess that the (one or more) programmer's at Devellion are using a text editor that does this when SHIFT-Space is entered on the keyboard. The difference in what you see may be based on what you are using to view the file. Locally, what are you using? For the file on the server, what are you using? If not the same text editor/viewer, then locally you may using an editor that does not know to show the file as Unicode. (A free and excellent programmer's text editor is NotePad++.) Quote Link to comment Share on other sites More sharing options...
hebcat Posted October 15, 2013 Author Share Posted October 15, 2013 Hi bsmither, Locally I use Homesite (it's ancient I know but it works well so I've kept it.... no issues at all with the software any other time in the decade I've used it). For remote viewing (ha ha) I use the "open" feature when I right-click on the file in WS_FTP. This opens in Notepad automatically. I then select all / copy / paste into Homesite. Saying that, when I open the local version in Notepad it doesn't show me the  character, so perhaps it's on the server as well but not showing up when I read it. Need to do the school run now, won't be back until tomorrow. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 15, 2013 Share Posted October 15, 2013 Just on the wild off-chance that your specific version/build of PHP* has a problem with the Object Operator, let's make a small edit: $skins[(string)$xml->info->name][(string)$style->directory] = ((string)$style->attributes()->images == 'true') ? true : false; To: $tmpAttributes = $style->attributes(); $skins[(string)$xml->info->name][(string)$style->directory] = ((string)$tmpAttributes->images == 'true') ? true : false; I'm working on the theory that grabbing the attributes(), followed immediately by selecting the images attribute, is a syntax that PHP does not like. *I am currently working with someone who has two servers, both with the same version of PHP, but a build with ever-so-slightly different capabilities. His code works on one but not the other. Quote Link to comment Share on other sites More sharing options...
hebcat Posted October 16, 2013 Author Share Posted October 16, 2013 Hi bsmither! Thanks for the suggestion! I've tried this. I now get the following error message: Fatal error: Call to undefined function: date_default_timezone_set() in ********/new/ini.inc.php on line 112 The code on line 112 of ini.inc.php is as follows: date_default_timezone_set('UTC'); //Set the default timezone for the scripts until the config gets loaded and over rights it Does this make any sense to you? Should I revert the setup/index.php file? Thanks Cat Quote Link to comment Share on other sites More sharing options...
hebcat Posted October 16, 2013 Author Share Posted October 16, 2013 In regards to the build, here's what details I can find about it: Apache version 2.2.23 PHP version 5.2.17 MySQL version 4.1.22-standard Architecture i686 Operating system linux Quote Link to comment Share on other sites More sharing options...
hebcat Posted October 16, 2013 Author Share Posted October 16, 2013 Hosting co has offered to move to a new server with the following: PHP 5.3.27 Apache 2.2.25 MySQL 5.1.68 Think this may be the way to go. Just waiting on confirmation from client they want to do this Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 16, 2013 Share Posted October 16, 2013 PHP 5.2.17??? The date_default_timezone_set function (as well as the Object Operator discussed earlier) is supposed to work in this version of PHP. The function is new to PHP510, so I'm starting to think your PHP installation is messed up in some fashion. Quote Link to comment Share on other sites More sharing options...
SimChris Posted October 16, 2013 Share Posted October 16, 2013 FYI to all, PHP Version 5.2.17 is still widely in use as it is the version supported by Plesk/Parallels 10x, and you can't upgrade PHP on a production server in certain instances with things like Red Hat ES Linux, Plesk/Parallels 10, without wiping the system. This a massive worldwide installed base, with plenty of patches for PCI-DSS and mod security, etc., so pretty much everything except leading "edge" products still have full support for PHP 5.2.17. We'll finally be upgrading our server in mid-December to the "latest and greatest" and moving to CentOS from RHES due to their wonky new licensing fees "per processor, per month." I only mention it here in case somebody searches related to this version of PHP. It's still "current" on tens of thousands of production servers, if not more. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted October 17, 2013 Share Posted October 17, 2013 Hi Cat, I don't know if your hosting company actually runs both PHP5 and PHP4? I know this error can exists with PHP4 and CubeCart should be fine with PHP5.2. It may be there is a setting in your hosting control panel or instructions with your host that can allow you to enable PHP5. Hope I'm not barking up the wrong tree here. To check for sure the PHP version upload a php file with any name (e.g. info.php) with the following code: <?php phpinfo(); ?> If you load that in your browser it will give you the most reliable source for PHP version. Quote Link to comment Share on other sites More sharing options...
hebcat Posted October 17, 2013 Author Share Posted October 17, 2013 Thanks bsmither, SimChris & Al, I've put up the PHPinfo file, says it's PHP version 4.4.9 ! I just assumed what it said in the cpanel would have been correct -- I hadn't thought of running this test. I did originally have a look around the cpanel and client area to see if there was I way I could update it myself, but there wasn't. Site in process of being migrated to new server in any case. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted October 17, 2013 Share Posted October 17, 2013 You would think so wouldn't you. I've seen this issue before too having accessed thousands of customers hosting accounts over the years. Not just cPanel lies about this!! Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 17, 2013 Share Posted October 17, 2013 On the first or second page of the setup sequence there should be a list of items and their compatibility status. The PHP version should have said "Fail". Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted October 17, 2013 Share Posted October 17, 2013 I think it has a fatal error before it can get to there rendering that code useless. I'll do some tests to improve this for the next release. Quote Link to comment Share on other sites More sharing options...
hebcat Posted October 18, 2013 Author Share Posted October 18, 2013 RESOLVED!!! :-D Migration was successful. The new server runs PHP 5.3.27 (checked with the phpinfo test -- not cpanel -- lesson learned!) Uploaded a fresh version of cubecart & created a fresh database in case any cobwebs got through. Installation easy peasy & successful on first try without any issues or warnings. So for anyone with a similar issue accessing this thread in future, to find out what PHP version your server is actually running do the phpinfo test (see Al's post further up). And indeed, I couldn't even get to the point during setup where it would say PHP had failed; the error was before then. Thanks so much everyone who helped out. I'm a little bit wiser today. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted October 18, 2013 Share Posted October 18, 2013 Great! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.