Tyson

I don't think reinstalling is necessary. It may just be a bug specific to the order form, but we'll need to try to reproduce it first. I've reopened CORE-765 to take a look into this issue.

Are you saying your input error rule is being validated when adding a service in the admin area, but not when adding a service via an order form?

This sounds like a separate issue. If you change the renew date, the domain name becomes blank in Plesk (and/or in Blesta)? What's in the Module Log regarding this? The fix I included in the file above specifies a filter for a customer if one is available, so you shouldn't experience a "delete all" issue again. The additional check I mentioned to refuse attempts to delete something without a filter set is indeed in a different file (the main plugin file), which Paul can attach to this thread.

Sorry to disappoint, but I don't follow hockey. However, I can think of 10 reasons why I should: the Staples Center is 30 miles from here and the Honda Center is 1.

What version of Blesta are you using? I recall a similar issue with the cron setting those URLs that has since been fixed.

This fix will also be in v3.0.4. In addition, the Plesk module will now refuse to attempt to delete any subscription, customer, or reseller if filter options are missing, so as to avoid Plesk's interpretation of "delete everything".

I found the issue. The API from the Plesk module was not properly setting the customer login name as you mentioned, which Plesk interprets as "delete all customers". And when Plesk deletes a customer, it also automatically deletes subscriptions assigned to those customers, so inevitably everything was deleted. Attached is the fix for this problem. You can replace /components/modules/plesk/apis/commands/plesk_customer_accounts.php in your Blesta installation with the one attached. plesk_customer_accounts.php

I'll have to defer to Cody on that. Not sure where it stands currently.

Walking through this real quick... from your log, I can see the input specifies a single subscription to delete, and Blesta received a response from Plesk indicating that only that subscription was deleted, so that looks okay. Then the customer was deleted, as identified by that login name. The response indicates 2 customer accounts were deleted. Was that login linked to 2 customer accounts? If so, then that looks correct too. Looking at the Plesk API, there is a way to delete *all* subscriptions via the API, if you do not specify a filter. While possible, your logs show that's not what happened. The Plesk API for deleting customers doesn't specify whether or not all customers can be deleted by not specifying a filter, but presuming it does, your logs don't seem to indicate that's what happened either. If a customer is deleted in Plesk, do domains/subscriptions associated with that customer automatically get deleted as well? Plesk might have certain dependencies like that, which we're not aware of, that could be the cause of everything being deleted. Based on that and the response from Plesk in your logs, the only data that should have been deleted are the customer and subscription. You may want to contact Plesk support and ask them how everything could be deleted via the API, especially considering Plesk's API response indicates it deleted only 1 subscription and 2 customer accounts.

What's in the Module Log related to that transaction with Plesk?

Trials are only limited in duration (time).

This is indeed a bug. Fixed in CORE-798 for v3.0.4. The error you received is legitimate--the addons were being incorrectly added following a grandfather scheme, rather than just as children to a single parent. The issue resides only with the Order plugin. If you want to pre-patch your install, then: Update /plugins/order/models/order_orders.php and change: $service_id = $this->addService($details, $addon, $packages, $coupon_id); if ($service_id) $service_ids[] = $service_id; to: $addon_service_id = $this->addService($details, $addon, $packages, $coupon_id); if ($addon_service_id) $service_ids[] = $addon_service_id;

Glad to hear you got it resolved.

If there are jquery conflicts between files, then I can see a problem. There isn't a way to remove the jquery/ui scripts from the head to replace them with another. You would need to use the versions of jquery and jquery ui that already exist in the system.

Is there an output log for every input log? In the case of the "Error parsing XML string" error, the output may not have been logged due to the error. And if Blesta didn't receive a response from the module, then clearly it wouldn't have a response to log. In any case, it seems rather intermittent. I know with Plesk, it's possible that immediately after a service is added via the API, Plesk may restart the server before sending a response back to Blesta, which creates the service in Plesk but never notifies Blesta that it was successful, causing a timeout. I wonder if something like that may be happening with SolusVM in this case. Not experiencing this issue myself, I can only suggest to log responses from SolusVM to a file and check for invalid XML.

I'll need to try to duplicate the issue to determine if it's a bug.

The issue you're describing was fixed in v3.0.0.b6. What version of Blesta and the cPanel module are you using?

You can call blestaSetHeadTag() to set CSS/scripts, e.g.: <script type="text/javascript"> $(this).blestaSetHeadTag("link", {media:"screen", type:"text/css", rel:"stylesheet", href: "<?php echo $this->Html->safe($this->view_dir . "css/styles.css");?>"}); </script>

It sounds like Blesta is receiving a malformed XML response from SolusVM, or no response at all. What's in the Module Log when this occurs?

I can't imagine identical behavior concluding in different results in this instance, but to me, this looks like a rounding issue in Stripe (or lack thereof) since only integers should be sent. By the way, Stripe expects the amount in cents, so 1499.5 = $14.995

The temp directory is not related to Blesta, but rather the server's temp directory. You shouldn't have to create this directory. The uploads directory comes with Blesta and is, by default, above your web directory. If the PDFs were written here temporarily, they would be deleted immediately after the invoice email was sent. The temp and upload directory settings need to be set to their absolute paths, e.g. /home/user/uploads/ The uploads directory should also contain two subdirectories "invoices" and "tickets".

No, you should be using TCPDF in v2.5. From the client profile page, when you check a box next to an invoice in the list, and then email it to your email address, does the invoice come in, but without the PDF attachment? The only thing that comes to mind is that the PDF may be written to the temp directory on the server before being sent, and if it couldn't write it to disk, then it wouldn't be included as an attachment in the email. You can make sure the temp directory set under Settings -> System Settings -> Basic Setup is writable.

Are you using TCPDF for PDF generation? The setting is under Settings -> System Settings -> Basic Setup.

These null values led to you receiving the "No host defined" error, which stems from the module row meta data being used. If your servers are apart of a group, check that each server has been saved with valid meta data information (i.e. host name, username, remote key, etc.). Do you experience the same error when you use a server group that contains only 1 server? If so, does the error occur when setting the package to specifically use that server?

Have you checked that your service and addons are not following a grandfather scheme? e.g. example_product is the parent of example_addon1 and example_addon1 is the parent of example_addon2 That error indicates this is what's going on.