Tyson

If installing soap and libxml doesn't take care of it, then it could be an invalid XML response, but we would need to see what the error message actually is to determine if that's the case. You can go to manage your Interworx server in Blesta (under [settings] -> [Company] -> [Modules]), edit your server, and set Debugging to Log. This will include the request and response in the log. However, the exact error being generated would be useful as well, but would require you to update the module code before you could see it. If you're willing to do that, then try the following: Open /components/modules/interworx/apis/interworx_api.php and find catch(Exception $e) { throw new Exception("soap_error2"); } and change it to catch(Exception $e) { throw new Exception($e->getMessage() . "\n" . $e->getTraceAsString()); } Then re-test creating a reseller. When it fails, check the logs and see what error is described.

CORE-1370 If the orders are still pending, you can add them manually through interworx, then try provisioning the service in Blesta. Assuming the information is the same, they should go through. However, if it is a reseller account, Blesta currently has the reseller ID "0" set, and I don't think there is a way to change that value without updating the database manually. So you may want to consider deleting the service in Blesta and re-adding it manually, or updating the reseller ID to the value you set in Interworx. I'll look into seeing if we can improve any of that when fixing the main issue. If updating the reseller_id service field manually in the database, you can find it under the `service_fields` table. Given the service ID, you can update it via the query (after replacing 'ABC' and 'XYZ' with valid values): UPDATE `service_fields` SET `value` = 'ABC' WHERE `service_fields`.`service_id` = 'XYZ' AND `service_fields`.`key` = 'interworx_reseller_id';

Invoices are unsent unless they have been queued and delivered via cron. Sending them manually would not update this status. The list of tags are generally a subset of those available, usually showing those most-likely-to-be-used. We haven't yet updated the tag listing to better list each tag in the UI. Users Address - The address information is available in the {contact} tag, i.e. {contact.address_1}, {contact.address_2}, {contact.city}, {contact.state}, {contact.zip}, {contact.country} Last Invoice Amount - Blesta doesn't include information on the 'last invoice'. I'm not sure what the 'last invoice' would be, however, the included list of {invoices} have a "previous_due" amount available for each invoice. But since {invoices} is a list of 1 or more invoices, you would likely loop over them to show the amount. e.g. ---- {% for invoice in invoices} When this invoice was created, this amount was still outstanding: {invoice.previous_due | currency_format invoice.currency}. {% endfor %} ---- Payments/Adjustments (payments since last invoice) - Maybe you should clarify this one, but it sounds like all transaction data should be available, which could be an extraordinary amount of information, and I don't see why that would be useful. However, each invoice in the given {invoices} contains the amount that has already been paid toward it. e.g. ---- {% for invoice in invoices} This invoice already has already had {invoice.paid | currency_format invoice.currency} paid toward it. {% endfor %} ----

This error is usually due to the missing SOAP dependency. The module requires the libxml extension be enabled in php. Kind of strange you got that error, as the module checks for these dependencies before it is installed. In any case, you'll need to make sure you have PHP SOAP and the libxml extension installed and enabled on the server. I notice Blesta is referencing "modifyReseller" in the logs. Is this on service creation? It may be related to the issue in this thread, where setting order forms to "Require manual review" leads to this issue. I suspect that the problem may be that the service is created in Blesta before it is provisioned on the Interworx server. Then when it finally is provisioned, it attempts to update the server, but the server doesn't exist on Interworx yet, thus leading to an "invalid domain" or "invalid reseller ID" error response. The Interworx module only sets the reseller_id on service creation, defaulting to "0" if it is unknown. That is probably why reseller ID 0 is passed when attempting to modify the account. The module will likely need to be updated to handle this case better. Are you attempting to add the service via an order form? Per the aforementioned thread, does disabling "Require manual review" on the order form resolve the issue?

Fixed in CORE-1355 for v3.2.3/3.3.0

Mail servers can reject attachments above a certain size limit, so a client may not even receive an email with a 20MB attachment. I think email size is best kept to a minimum.

Payments::processPayment has a parameter, $options, which allows for invoices (referenced by ID) to be specified along with the amount to be applied to them, e.g. $options['invoices'] = array('26' => "5.25", '107' => "4.75"); The amounts in the invoice list should be <= the total amount specified in the $amount parameter.

They may only be saved locally, which could be the problem here.

Is it that Namecheap is ignoring them, or that Blesta is not setting them correctly? Blesta calls the domain->create API action to set the nameservers when the domain is created. Can you check the module logs under [Tools] -> [Module Logs] for a log of a new domain registration, and see whether the nameservers are being set properly when passed to Namecheap?

You do not need to create an initial invoice for the service, as you can append it to an existing invoice, or choose not to generate one at all. Invoice generation for service renewal is handled by the cron and related cron tasks. By default, yes, the Create Invoices cron task will generate invoices from services that are renewing. Whether a service is set to renew depends on the associated package and its term/period settings.

Not sure why the delete action did not work. I suspect the lack of an error may be due to Blesta not receiving the client_id parameter. However, POST would be a better alternative to DELETE than GET would.

Looks fine to me. What are the errors? A client can only be deleted if there are no associated any invoices, transactions, or services.

The _custom language file has definitions in it that are used in the core of Blesta as well, so any changes made to those would require an update to the file anyway. But it sounds like you want to avoid merging customizations where possible. Since Blesta only loads what it needs when it needs it, simply renaming a file to anything you want wouldn't work. What might be a better solution is a setting, or configuration value, to specify your user-defined language file, and possibly when to load it.

I'm not sure what you mean. Could you clarify? The language you quoted is straight-forward.

Sounds strange. Did you check the client's mail log to see if the text copy there is blank as well?

Hi Christopher, If that's the entirety of the controller, then you are missing the preAction method, which should contain a call to the parent::preAction(). See the documentation for more info.

If you were using Blesta v2.5, you can simply download the v2.5 files and upload them to your server, just to get back up and running. You will need the old Blesta config from your backup. After that, you can perform the migration to v3.2. Also, you should at least change your database users' passwords, since you shared them in the first few posts of this thread.

You read the documentation? It sounds like naja7host mentioned, you may be missing "newsletter_plugin.php" or you did not name the class "NewsletterPlugin".

No, you can't use those two together. The design simply cannot accommodate both. Per the documentation, the link buttons only work with links, not tabs.

Someone actually said this? I'm not sure there exists a system in the world where how the infrastructure is setup 'doesn't matter'.

I may have misunderstood. Only the Name of the custom field, itself, can be used as a language definition. The Option Name of drop-down values do not use language definitions. Is that what you were referring to? That might be a good feature request, though.

I'm not sure why Siteworx is rejecting the email address, unless you are not including the domain as well (per my screenshot above)? I can't login to our server with the nickname. While that is technically the username, Siteworx still expects you to enter your email, password, and domain when logging in. The "Log in" link in Blesta actually works using the email/domain combination for this reason.

If this is your language: $lang['_CustomFields.drop1value1'] = "Value 1"; $lang['_CustomFields.drop1value2'] = "Value 2"; Then the keys you set in the "Name" field of the custom client field are "drop1value1" and "drop1value2", respectively. i.e. everything after "_CustomFields."

Not sure exactly what you're trying to do, but I use # Only let the IP 123.123.123.123 view the site. Redirect everyone else to /my/page.php Options +FollowSymlinks RewriteEngine On RewriteCond %{REQUEST_URI} !/my/page.php$ RewriteCond %{REMOTE_HOST} !^123\.123\.123\.123 RewriteRule $ /my/page.php [R=302,L]

Each core file is subject to being updated/overwritten on upgrade, including, but not limited to, the config file. If there are custom changes that you've made and that you want to persist, you should be mindful of those changes and merge them in with any upgrade you're performing.