Jump to content

Syntax error on installation of v5.2.4


hebcat

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 Configuration
Line 362, on server:
        // Upgrade Main Configuration
        
Line 405, local:
            // Rename existing keys
Line 405, on server:
            // Rename existing keys
            
Line 608, local:
## Controller elements
Line 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.

Link to comment
Share on other sites

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 !

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!! :)

Link to comment
Share on other sites

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++.)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...