problem installing shipping modules in osc 2.3.4, fresh install

[nvram]

fresh install of osc 2.3.4 , no other mods, droped on centos 5.11.

install of osc - no problems.  

nothing done (configuration wise) except main "install" ,

now, if i go to admin>modules>shipping i can install any module with no problem (including USPS),

i then return to original state (only flat rate by default)

then i try to drop two shipping modules

UPSXML version 1.5 (from http://addons.oscommerce.com/info/9317)and  USPS with Dimensional Support 6.5 (http://addons.oscommerce.com/info/9332). i drop new shipping modules files to their respective folders, added xml.php in both places,  so all looks as:

 

  catalog/admin/includes/classes/xml.php

  catalog/includes/classes/xml.php

  catalog/includes/languages/english/modules/shipping/upsxml.php

  catalog/includes/modules/shipping/upsxml.php

  catalog/includes/modules/shipping/uspsds.php

  catalog/includes/languages/english/modules/shipping/uspsds.php

 

(original usps.php removed and replaced by new uspsds.php module)

 

+ fix catalog/admin/modules.php (as per notes that are same for both modules adding short snipped of code)

 

now, when i go to admin>modules>shipping>

i can see in top right hand "+ install module (5)" so the modules are counted properly

but, when i click on "+ install module (5)"i don't get the option to actually install a module (like i did before dropping files)

the only thing showing up is "back" button -see pic and line below listing one module "per item" no button  "+ install module"

that i should have. if i delete modules i added all works as it should.

 

btw, i scp files directly to the linux server to avoid any ascii/bin issue, i also drop entire install redo fresh one and try just to add one new module, nothing else done (except adding xml.php in "classes"), i try first upsxml with same results, then i try just to replace usps with new mod and again same results. all works on stock files but as soon as i add the mods it stops working. i check file permissions all looks good. btw, not using windows, all in linux to avoid windows formatting. 

i did few past installs of osc fairly have mod, never had this issue, just saying i am not a pro programer, but i can usually follow instructions and get things done , this time stuck for good, - :(

 

any idea what to check?  i know i must to do something wrong or miss something terrible, the stock install and these modules can't be an issue, i just can't find what i missed. beside editing /catalog/admin/modules.php with the short snipped of code there is no other file needing editing all drop in, end even if i don't edit the modules.php file should still show me an option to install, one i am not getting. 

 

any hint where to look next ?

 

[♥kymation]

It sounds like both module files are corrupted. Are you unpacking these files on a Windows box and then transferring them to the server? That would require the ASCII conversion that a FTP server would do for you.

 

If it's not that, it's something else you have done to corrupt the files, as both of these modules work on other systems.

 

Regards

Jim

[nvram]

that is why i am puzzled. i understand what you said that was my original thinking, but..

I don't use windows working off of mac. i transfer them several times using diff methods, 

i scp them individual one by one, i scp whole zip to the server and unzip on the server, i re-downloded files from oscommerce/addons and repeat same all with exactly same result, finally re-install entire store and repeat,.  all to same outcome. 

i got to the point i run both upsxml files through the md5 right after i downloded them on my mac and on the server. the checksum are same, so i am sure the files are not corrupted -:(

[♥kymation]

Uploading from a Mac to a Linux server should be OK. Unpacking on the server will definitely be OK. I think we can check off the corrupted files theory.

 

Are you certain that you have the files in the right places? There are two files named upsxml.php and they are very different.

 

Regards

Jim

[nvram]

i am sure of that, last i copied them directly from unpacked zip file on the server, 

 

[~/oscommerce-2.3.4/UPSXML_v1_5/catalog/includes/languages/english/modules/shipping]# cp -r upsxml.php ~/www/includes/languages/english/modules/shipping/

[~/oscommerce-2.3.4/UPSXML_v1_5/catalog/includes/modules/shipping]# cp -r upsxml.php ~/www/includes/modules/shipping/

 

i also try the other module (uspsds) removing original usps.php files with, same result.

understand what you saying that this works everywhere else, i am sure files are good. i must to do something wrong, just can't figure out what. 

are there any other depandancies like "configure.php" file ? this has pointers to path, but the only thing from install that i edited is to enable https, though i went back and forth enabling/disabling just to see if any diff.

[♥kymation]

The only dependencies on configure.php are that the path to the modules directory and the languages directory are correct. Those are not normally changed, and you would not get any of the modules to work if they were wrong, so that's not it.

 

This just sounds like a classic case of an incorrect/corrupted file. osCommerce does no error checking on the module files. It expects to see a PHP class with a specific set of methods and just crashes if it doesn't find that. You have copied the files to the correct location on the server, so that can't be right.

 

Trying to run osCommerce on PHP 7 would throw a bunch of errors but not crash like this. Any other version of PHP should just work.

 

One last (unlikely) test: Fire up your FTP client and copy the files up from your Mac using forced ASCII mode. If that doesn't work I'm going to have to admit defeat.

 

Regards

Jim

[nvram]

Jim, thx for all help, i am going to try tomorrow and let you know, will need to setup ftp on the server, never had one enabled. 

[nvram]

I finally got this to work, though not sure what effect this may have they way I did.

(btw, as said before this is fresh install, and as first step after install dropping new shipping modules, before any other configuration except initial web based install procedure).

I started to believe there are no way these are corrupted file issues. After all I was downloading all fresh zip files (both oscommerce stock install and modules), uploading them as original zips to the server and unpacking there, so should not be exposed to regular transfer issues (ascii/bin), though I went and did test with forced ascii transfer, and did that from linux pc and mac for tests. After all attempts failed  I was fairly positive the issue is elsewhere, so start looking what the files actually do. First what I realized, that modules in stock install do not require xml.php files in “classes/“, so that why they worked, but new modules not, ok, that was a clue. Then I looked inside catalog/includes/modules/shipping/upsxml.php and found this:

 

require_once (DIR_WS_CLASSES . ‘xml.php');

I commented this out for a test and bingo, I am able to install both modules (ususds and upsxml), though of course both did not to work but still, they are visible now and I can install them, what was not the case before. 

So I start to believe that this may have to do something with the php versioning.

I deleted all module addons and downloaded older upsxml package(1.4), the one that had both xml.php and xml_5.php files, 

I drop older package on the server and worked instantly, was visible in admin and I was able to install. 

So again I removed all but the xml* files, and drop just both new upsxml.php files from package 1.5.1 (the one that rely on single combined xml.php), but except replacing xml file I left the old one, then I went to 

 

catalog/includes/modules/shipping/upsxml.php

And redo lines as they are in upsxml in 1.4 package, basically to be able to call both xml file, 

 

So it came to this:

 

// Incorporate the XML conversion library 

//  require_once (DIR_WS_CLASSES . 'xml.php');

  if (PHP_VERSION >= '5.0.0') { // PHP 5 does not need to use call-time pass by reference

    require_once (DIR_WS_CLASSES . 'xml_5.php');

  } else {

    require_once (DIR_WS_CLASSES . 'xml.php');

  }

 

And that worked with no issue.

 

After that I ddi same with uspsds.php and again package worked as suppose to.

So in the nutshell I go this to work, but, bit wondering about long term issue. 

I checked both shipping modules for content pulled from UPS and USPS, looks good, though I am not quite sure as I have nothing to compare.

Ideally I would like to go back to original options, don’t like hacks in production, but need this to work and this got me through for now.

 

BTW, my server info returns:

 

 

 

 

Server OS:

Linux 3.14.25-grsec.3.el5

     Database:

MySQL 5.5.40-36.1-log

Server Date:

2016-03-07 11:33:53 -0600 CST

     Database Date:

2016-03-07 11:33:53

Server Up Time:

11:33:53 up 403 days, 9:56, 1 user, load average: 1.37, 1.78, 1.90

 

HTTP Server:

Apache

PHP Version:

5.5.31 (Zend: 2.5.0)

 

Any idea what to check or how to fix to be able to go with original new one xml.php file?

[♥kymation]

The XML library in xml.php is obsolete and should no longer be used. Unfortunately I don't have the time to rewrite those modules, so you'll have to deal with it as is.

 

Check the support thread for both of those modules. I believe that there are patches for the xml.php in the thread for UPSXML but I might be remembering the wrong place. In any case, that file can be patched to work with a modern version of PHP, mostly by taking the fixes I made to xml_5.php and making a few more.

 

Regards

Jim

[nvram]

thank you, i’ll do that. and thanks for your inside, appreciated.