Issue with Dev Cloud vs Prod Cloud

255 Posts

CMHWorks Reply #1, 9 years, 10 months ago

Platform: Modx Cloud
MODX Version: 2.2.14.pl
PHP Version: 5.4

I've been struggling with this for a few days now and was hoping someone could point me in the right direction. I been working on a Modx Cloud site that uses Paypal Rest API and developed all my snippets as external files in an IDE and included in the snippet calls. Initially I had an issue with Paypal's API requiring composer to install but managed to work around that and got it all working in Dev just fine. I thought I was just about done but then...

I made a snapshot of dev site and imported into production. I worked through all the url mappings, etc and even internalized the snippets (no longer calling external files) to try to resolve. No matter what I do, I am getting the following error (and the only error) in the log:

[20-Jun-2014 05:28:48 America/New_York] PHP Parse error:  syntax error, unexpected 'use' (T_USE) in /paas/c0011/www/core/cache/includes/elements/modsnippet/32.include.cache.php on line 20

A few interesting this to note:

I am calling this snippet uncached, yet the error log seems shows it being cached. Not sure what that's about.
This same error appears whether the snippet is included as an external file or directly in the snippet code
exact same code worked on dev cloud but not prod cloud

The snippet code where this is failing is:

require_once($modx->config['base_path'].'config.core.php');
require_once MODX_CORE_PATH . 'model/modx/modx.class.php';
$modx = new modX();
$modx->initialize('web');
$modx->getService('error', 'error.modError', '', '');Only used in included version of the snippet

$modx->setDebug(E_ALL & ~E_NOTICE); // sets error_reporting to everything except NOTICE remarks
ini_set("display_errors", 1);

require($modx->config['base_path'].'assets/snippets/lvr/lib/LVRSubmitConfig.inc.php');
require($modx->config['base_path'].'assets/snippets/lvr/lib/LVRSubmitFunctions.inc.php');
// kint debugger
require($modx->config['base_path'].'assets/snippets/lvr/lib/kint/Kint.class.php');
// nusoap for SP list item creation
require($modx->config['base_path'].'assets/snippets/lvr/lib/nusoap/lib/nusoap.php');
// paypal  rest api bootstrap
require($modx->config['base_path'].'assets/snippets/lvr/lib/pp/bootstrap.php');

use PayPal\Api\Amount;
use PayPal\Api\Details;
use PayPal\Api\Item;
use PayPal\Api\ItemList;
use PayPal\Api\CreditCard;
use PayPal\Api\Payer;
use PayPal\Api\Payment;
use PayPal\Api\FundingInstrument;
use PayPal\Api\Transaction;
use PayPal\Api\RedirectUrls;
use PayPal\Api\ExecutePayment;
use PayPal\Api\PaymentExecution;

The paypal rest api is loaded via the bootstrap.php called on line 11 above which is where the issue is.

I also installed composerX and generated the autoloader, etc and modified the bootstrap.php to require the generated autoloader thinking there was something wrong with the directory structure (though it appears to be exactly the same) and still no dice. The bootstrap.php file pointing to the composer generated autoloader looks like this:

<?php

// Paypal bootstrap file.

// Include the composer autoloader
if(!file_exists($modx->config['base_path'].'core/components/composerx/vendor/autoload.php')) {
	echo "The 'vendor' folder is missing. You must run 'composer update --no-dev' to resolve application dependencies.\nPlease see the README for more information.\n";
	exit(1);
}

require($modx->config['base_path'].'core/components/composerx/vendor/autoload.php');

use PayPal\Rest\ApiContext;
use PayPal\Auth\OAuthTokenCredential;

$apiContext = getApiContext();

function getApiContext() {
	$apiContext = new ApiContext(
		new OAuthTokenCredential(
			'AZpoTBCHzdWtFr0G-BrIiNt0eC-rjLBn5wWQHktPnsjmgdIQ79M5CVEA1_f2',
			'EKIR6xDpc8T76kE3KVRui9VGH5blQ8t8Sjln1A5RThmZvqy_Uj4QWPP8iTGA'
		)
	);

	// #### SDK configuration
	$apiContext->setConfig(
		array(
			'mode' => 'sandbox',
			'http.ConnectionTimeOut' => 30,
			'log.LogEnabled' => true,
			'log.FileName' => 'PayPal.log',
			'log.LogLevel' => 'FINE'
		)
	);

	return $apiContext;
}

What's interesting is that the use statements in the bootstrap.php file seem to be just fine. It's the first use in the snippet code that is causing the error. I'm not sure what environmental differences there are between dev and prod, but something is fubaring in prod what is working fine in dev. Anyone with any ideas would be much appreciated.

If anyone is interested in seeing it in action, the dev cloud is running at: http://c1124.paas1.tx.modxcloud.com/. You would need to put items in the cart and go through the checkout wizard all the way through. It's all sandbox so I wont charge you I promise.

I hope it's something simple that I am just overlooking. TIA...

This question has been answered by harveyev. See the first response.

[ed. note: harveyev last edited this post 9 years, 10 months ago.]

2,877 Posts

mrhaw Reply #2, 9 years, 10 months ago

What if you place the use calls at the very top?
// https://github.com/browscap/browscap-php/issues/1

@hawproductions | http://mrhaw.com/

Infograph: MODX Advanced Install in 7 steps:
http://forums.modx.com/thread/96954/infograph-modx-advanced-install-in-7-steps

Recap: Portland, OR (PDX) MODX CMS Meetup, Oct 6, 2015. US Bancorp Tower
http://mrhaw.com/modx_portland_oregon_pdx_modx_cms_meetup_oct_2015_us_bancorp_tower

☆ A M B ☆
24,524 Posts

sottwell Reply #3, 9 years, 10 months ago

1. That is the snippet code itself, not the snippet output. When you call a snippet uncached, it's the output that is not cached.

As for the rest of it, I'm not familiar with it so can't be of any help.

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

255 Posts

CMHWorks Reply #4, 9 years, 10 months ago

Just tried that at your suggestion. I had read that post yesterday but it didn't try it then. Alas, same exact error. Here's the the cached snippet (again why its caching I have no idea but that's a different problem):

<?php
function elements_modsnippet_32($scriptProperties= array()) {
global $modx;
if (is_array($scriptProperties)) {
extract($scriptProperties, EXTR_SKIP);
}
// debug info (comment out for production)
error_reporting(E_ALL ^ E_NOTICE);
ini_set("display_errors", 1);

use PayPal\Api\Amount;
use PayPal\Api\Details;
use PayPal\Api\Item;
use PayPal\Api\ItemList;
use PayPal\Api\CreditCard;
use PayPal\Api\Payer;
use PayPal\Api\Payment;
use PayPal\Api\FundingInstrument;
use PayPal\Api\Transaction;
use PayPal\Api\RedirectUrls;
use PayPal\Api\ExecutePayment;
use PayPal\Api\PaymentExecution;

require($modx->config['base_path'].'assets/snippets/lvr/lib/LVRSubmitConfig.inc.php');
require($modx->config['base_path'].'assets/snippets/lvr/lib/LVRSubmitFunctions.inc.php');
// kint debugger
require($modx->config['base_path'].'assets/snippets/lvr/lib/kint/Kint.class.php');
// nusoap for SP list item creation
require_once($modx->config['base_path'].'assets/snippets/lvr/lib/nusoap/lib/nusoap.php');
// paypal  rest api bootstrap
require($modx->config['base_path'].'core/components/composerx/vendor/autoload.php');

Makes me think it's something to do with class mappings but I have no idea why it would work on one cloud but not another supposedly identical cloud.

And the error log :

[20-Jun-2014 06:49:32 America/New_York] PHP Parse error:  syntax error, unexpected 'use' (T_USE) in /paas/c0011/www/core/cache/includes/elements/modsnippet/32.include.cache.php on line 11

255 Posts

CMHWorks Reply #5, 9 years, 10 months ago

Quote from: sottwell at Jun 20, 2014, 10:48 AM

1. That is the snippet code itself, not the snippet output. When you call a snippet uncached, it's the output that is not cached.

As for the rest of it, I'm not familiar with it so can't be of any help.

Okay that makes sense, duh!. Thanks Susan! Now why the use fails...

discuss.answer

255 Posts

CMHWorks Reply #6, 9 years, 10 months ago

Ok. In the interest of desperation, I re-injected the dev cloud and left the snippet calls exactly as they were in dev. The error log then showed:

[2014-06-20 07:22:42] (ERROR @ /paas/c0011/www/core/cache/includes/elements/modsnippet/28.include.cache.php : 7) PHP warning: file_exists(): open_basedir restriction in effect. File(/paas/c1124/www/assets/snippets/lvr/LVRSubmit-Snippet.php) is not within the allowed path(s): (/paas/c0011)
[2014-06-20 07:24:19] (ERROR @ /paas/c0011/www/assets/snippets/lvr/LVRSubmit-Snippet.php : 3) PHP warning: require_once(): open_basedir restriction in effect. File(/paas/c1124/www/config.core.php) is not within the allowed path(s): (/paas/c0011)
[2014-06-20 07:24:19] (ERROR @ /paas/c0011/www/assets/snippets/lvr/LVRSubmit-Snippet.php : 3) PHP warning: require_once(/paas/c1124/www/config.core.php): failed to open stream: Operation not permitted

So I thought it must be security on prod clouds that is not applicable in dev clouds preventing me from accessing from the basedir. I then modified my include snippet like so:

if (file_exists($file)) {
   $basePath = $modx->config['base_path'];
   $o = include $basepath . $file;
} else { $o = 'File not found at: '.$basepath . $file; }
return $o;

And then changed my include calls to:

[[!include? &file=`assets/snippets/lvr/LVRSubmit-Snippet.php`]]

And viola! I tested all my snippets and they appear to be working. I wish I could internalize these snippets but that is a problem for another day. I'll probably just move them out of the web root as a minimal precaution at least. Though this is probably an obscure problem and related only to cloud, it may help someone in the future.

☆ A M B ☆
24,524 Posts

sottwell Reply #7, 9 years, 10 months ago

dev clouds also have their base_path set. It's set to something like "paas/c0102" - the site's location on the server.

I'll bet that somewhere something was cached with the original page (dev's path) after the base_path system setting was processed.

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

255 Posts

CMHWorks Reply #8, 9 years, 10 months ago

Could be. But the path being reported in the error log was the correct path on the prod server. In any case referencing the file using

$basePath = $modx->config['base_path'];

seems to have solved my issue. Weird one for sure.

Thanks!

Quote from: sottwell at Jun 20, 2014, 12:22 PM

dev clouds also have their base_path set. It's set to something like "paas/c0102" - the site's location on the server.

I'll bet that somewhere something was cached with the original page (dev's path) after the base_path system setting was processed.

Answered Issue with Dev Cloud vs Prod Cloud