Jump to content

Extension install fail


Jonathan

Recommended Posts

Have a brand new Cubecart install on one of our servers and are hitting a brick wall trying to install even one simple extension: PayPal Commerce. Trying the 'Token' method results in a blank white page directed to "<ourdomain>/admin.php?_g=plugins". Trying to enable the error_log as recommended here in the forum (from 2016) results in no error_log, nor any clue to assist in the process, and no errors are shown in the site's primary error_log. So we Google "install Cubecart extension" simply looking for manual install instructions - because we cannot find any on the Cubecart site - and mainly find references to creating the error_log file; but no direct extension install information at all. Running Cubecart 6.2.8. Googling for "Cubecart 6 documentation" yields a link to an archived v3.0.0 version from 2005. (????)

What are we missing here? Where is Cubecart's documentation? Where can we find basic manual installation information for extensions?

The lack of basic documentation is a very worrying issue.

 

Link to comment
Share on other sites

Hi Jonathan,

Please check the values for adminFile and adminFolder are correct in the include/global.inc.php file. 

Also make sure PHP is configured with ZipArchive so it can extract zip files.

To install manually just download the package, extract it and upload the paypal_commerce folder to the modules/plugins directory. It will then show in the Manage Extensions section of the control panel.

Out of interest how was the store setup? Did you use a 3rd party one click install system?

Link to comment
Share on other sites

As a follow up on this... Tried to delete the thread before replies; it didn't work.

We found a few solutions/answers:

1. The error log -was- created and logged to. We just didn't know it showed up in the admin logging - as web geeks we assumed (cough) it was a stand-alone log file.

2. The token method was failing because (as the venerable Al Brookbanks illustrated) of PHP not liking ZipArchive. We installed just about every zip extension for PHP that we could - no joy. Found manual extension install instructions in an old thread and - once we figured out which folder they needed to be in - the admin saw and installed the extensions. Did not see Al's reply until after we got it working because I thought the thread was deleted.

3. The permissions issues for CubeCart still bother me. We had to 777 just about everything to get it working. After we finish devel we will return to roll back what we can. Seeing folders with 777 rights gives me the creeps.

And on the 'how did you install' question I did it manually - none of the 'one lick install' training wheels for me (smile). Like I have for WordPress, Drupal, etc I just copied the files to the target site and started banging my head with a permissions/rights hammer until submissive mercy was found.

 

Link to comment
Share on other sites

Good to hear you installed it yourself. That method or https://hosted.cubecart.com is best.

You wouldn't have had any of these compatibility issues with our hosting platform which is designed and optimised for CubeCart.

With correct web server configuration a CHMOD value of 0755 should work.

Thanks for posting back your findings.

Link to comment
Share on other sites

Unless there is some sort of error_log setting that can be locked by the server admin, the script that tells PHP where to write the error log takes precedence. That is, the statement:
ini_set('error_log', 'error_log');

tells PHP that the error_log setting is to call the error log "error_log" and to write it at (no path specified, so...) the same folder of the script that set this setting -- which is either index.php or admin_aBcDeF.php located in CubeCart's main folder. (All other scripts are include/require off of this main script.)

Some FTP clients can be configured to not show certain files: those beginning with a period (.htaccess) and those that have no extension (which is rare).

CubeCart tells PHP of CubeCart's own error_logger to be inserted in the chain of loggers so that some errors can be better managed. (Smarty also inserts it's own error_logger into the chain.)

Link to comment
Share on other sites

Thanks for that reply Al, and I saw & understand the hosted solution. After over 20 years of working & coding for Miva Merchant and suffering through their transition to SAS I still have blisters on my hiney. Not faulting SAS just don't like riding other people's bicycles (grin). At one time I self-hosted over 200 Miva Merchant sites for my clients on 40+ servers I hand built; the advent of SAS almost destroyed my business. Doesn't help that I hate PHP and its security fails like a toothache. As a language, 20-yr old MivaScript code is still 100 times more secure and convenient for ecom - for me.

Looking forward to getting more intimate with CubeCart and trying to get past my distaste for PHP by doing so.

 

3 minutes ago, bsmither said:

Unless there is some sort of error_log setting that can be locked by the server admin, the script that tells PHP where to write the error log takes precedence. That is, the statement:
ini_set('error_log', 'error_log'); tells PHP that the error_log setting is to call the error log "error_log" and to write it at (no path specified, so...) the same folder of the script that set this setting -- which is either index.php or admin_aBcDeF.php located in CubeCart's main folder. (All other scripts are include/require off of this main script.)

Thanks for that bsmither - problem there is that no error_log was created ("find / | grep error_log" yielded nada) - but the errors showed in the CubeCart admin logging menu, so I was placated.

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...