Tyson

We keep track of, respond to, and close bug threads once their complete on a per-thread basis. This helps to keep things on topic, and easy for everyone to follow. If you post 10 bugs in a thread, the topic gets out of hand and it's difficult for anyone to determine which, if any, have been fixed. Likewise, each module, plugin, gateway, and Blesta itself have different versions, and we can't assume all versions experience the same issues. This is part of the reason why it's pertinent to have as much information as possible as described in How to Report a Bug. While you've mentioned that the bug applies to 'all modules', I've given an example of a case where it does not (at least, not for me). And as much as we would like to fix any and all bugs that are reported, we can't look into each bug without enough information to duplicate it. Since you experience the bug, you are in the best position to convey how, what, when, and where the bug occurs.

Changing the username would require an update to the module to fetch the client and then use his username, setting it as the SolusVM username. This may or may not affect existing SolusVM services when you attempt to perform an action on their service. Potential problems could arise when a user changes their username. And this is why we generate one unique to their account regardless of that. If a user changes their username, no module, like SolusVM, will change service details because of it. Performing actions on a SolusVM service will then need to also consider whether the username changed. It may also be possible for someone to change their Blesta username, and then someone else comes along and takes their old one. If a client had a SolusVM service with username "abc123", but later changed their Blesta username, but not their SolusVM username, a new client can come along, use the username "abc123" and create a SolusVM service. Now 2 services for separate clients are under the same SolusVM account. Additional logic would need to be added to resolve these kinds of conflicts, if possible.

We need more information as described in How to Report a Bug. e.g., version of Blesta, version of the module, steps to duplicate, etc. I don't experience this issue in v3.1.2 of Blesta for cPanel v1.1.0. There may be issues with some modules, like cPanel, not saving field changes on edit when Use Module is not checked, but this would be module-specific. If you're experiencing this with multiple modules, please create a new bug report for each one.

This is fixed in CORE-1110.

No you cannot. As the name suggests, it is a patch for v3.1.0 or v3.1.1 to v3.1.2. It does not contain new files from v3.0.x to v3.1.0. You should download the full v3.1.2 zip.

We have plans to better automate the upgrade process. No ETA yet on when the feature will be available, though.

I'll assume you want it below the client name and address. There are a few things you should note first: If you plan to print invoices and mail them to your customers, certain envelopes with windows to show the recipient name/address will likely also show these custom fields. There is not a lot of space below the client address and above the invoice listing "Description", so you may only be able to show 1 to 3 custom fields before overlaps occur. The width of the custom field name and values is expected to be rather small. If the values are too long, they'll wrap and you'll have less space, as in #2. Update /components/invoice_templates/default_invoice/default_invoice.pdf (line 481 in v3.1 of Blesta) from: private function drawAddress() { $address = $this->invoice->billing->first_name . " " . $this->invoice->billing->last_name . "\n"; if (strlen($this->invoice->billing->company) > 0) $address .= $this->invoice->billing->company . "\n"; $address .= $this->invoice->billing->address1 . "\n"; if (strlen($this->invoice->billing->address2) > 0) $address .= $this->invoice->billing->address2 . "\n"; $address .= $this->invoice->billing->city . ", " . $this->invoice->billing->state . " " . $this->invoice->billing->zip . " " . $this->invoice->billing->country->alpha3; $data = array( array($address) ); $options = array( 'font_size'=>self::$font_size, 'x_pos'=>44, 'y_pos'=>157, 'col'=> array( array('width'=>210) ) ); $this->drawTable($data, $options); } to: private function drawAddress() { $address = $this->invoice->billing->first_name . " " . $this->invoice->billing->last_name . "\n"; if (strlen($this->invoice->billing->company) > 0) $address .= $this->invoice->billing->company . "\n"; $address .= $this->invoice->billing->address1 . "\n"; if (strlen($this->invoice->billing->address2) > 0) $address .= $this->invoice->billing->address2 . "\n"; $address .= $this->invoice->billing->city . ", " . $this->invoice->billing->state . " " . $this->invoice->billing->zip . " " . $this->invoice->billing->country->alpha3; // Set my custom fields $cf_data = array(); if (property_exists($this->invoice->client, "id")) { Loader::loadModels($this, array("Clients")); $field_ids = array(6, 10, 15); $values = $this->Clients->getCustomFieldValues($this->invoice->client->id); foreach ($values as $value) { if (in_array($value->id, $field_ids)) { $cf_data[] = "\n" . $value->name . ": " . $value->value; } } unset($values, $value); } $data = array( array($address) ); // Include my custom field data below the address if (!empty($cf_data)) { foreach ($cf_data as $cf_value) $data[] = $cf_value; } $options = array( 'font_size'=>self::$font_size, 'x_pos'=>44, 'y_pos'=>157, 'col'=> array( array('width'=>210) ) ); $this->drawTable($data, $options); } Remember to update the comma-separated list of field IDs.

Under [Tools] -> [Modules], the logs are shown. You would need to find the particular one from the list, click on the row, and take a look at the Input/Output.

Yes, the accented characters are being encoded in the value field, which causes this issue. The task I linked will fix it, but I don't have an ETA on that. The only work-around to using those payment type names is to set them as language definitions instead. To do this, update the custom language file at /language/en_us/_custom.php, and add the following lines: $lang['_PaymentTypes.keszpenz'] = "Készpénz"; $lang['_PaymentTypes.atutalas'] = "Átutalás"; Then go into Blesta and update those two payment types under [settings] -> [system] -> [General] -> [Payment Types]. Change the Name value of "Készpénz" to "keszpenz", and check the box "Use Language Definition". Similarly, update "Átutalás" to "atutalas", and check the language box as well. The payment types should work correctly after you've saved those changes. Note also that the custom language file is a core file, so when you upgrade Blesta, that file will be overwritten, and you will need to merge these changes back into that file.

If there is no value, then the client doesn't have a value set for the custom field. Assuming you are more-or-less using the same code from my example, the value is set in the example below (line 414). My example above could be updated to show multiple fields by setting them like below Note that you would create a comma-separated list of field IDs like the "6, 10, 15" I have in the example. private function drawInvoiceInfo() { $cf_data = array(); if (property_exists($this->invoice->client, "id")) { Loader::loadModels($this, array("Clients")); $field_ids = array(6, 10, 15); $values = $this->Clients->getCustomFieldValues($this->invoice->client->id); foreach ($values as $value) { if (in_array($value->id, $field_ids)) { $cf_data[] = array( 'name' => $value->name . ":", 'space' => null, 'value' => $value->value ); } } unset($values, $value); } $data = array( array( 'name'=>Language::_("DefaultInvoice.invoice_id_code", true), 'space'=>null, 'value'=>$this->invoice->id_code ), array( 'name'=>Language::_("DefaultInvoice.client_id_code", true), 'space'=>null, 'value'=>$this->invoice->client->id_code ), array( 'name'=>Language::_("DefaultInvoice.date_billed", true), 'space'=>null, 'value'=>date($this->invoice->client->settings['date_format'], strtotime($this->invoice->date_billed)) ), array( 'name'=>Language::_("DefaultInvoice.date_due", true), 'space'=>null, 'value'=>date($this->invoice->client->settings['date_format'], strtotime($this->invoice->date_due)) ) ); if (!empty($cf_data)) { foreach ($cf_data as $cf_value) $data[] = $cf_value; } Where on the left? Invoice PDFs are generated very specifically, so you need to know exactly where you want to put additional fields and how much space they will take up in order to avoid breaking the display of other elements in the PDF.

This contribution will be in the SolusVM module for Blesta v3.2+.

Attached is the PayJunction gateway for Blesta. Special thanks to Kiran at Nirays Technologies for creating the gateway and giving us rights to it. We'll be including this gateway with v3.2 of Blesta. To install, you can upload the contents of the attached zip to your Blesta installation directory, and then head into Blesta's admin interface to install the gateway under [settings] -> [Payment Gateways] -> [Available]. payjunction.zip

What is the name of your payment type? You should not be using any special characters unless you set them as a language definition in the custom language file. I've created CORE-1106 to improve how payment types are displayed, such that they use their key as a value rather than their name. This would fix the issue you described, but also the rest of the system where they are used.

The client area was a bit of a pain to integrate to bootstrap. It's not just the templates/styles that change, it's all of the javascript that make DOM changes, how partial views are abstracted, modules/gateways/plugins, how module form fields are rendered, etc. I can only imagine the time necessary to convert the admin area to bootstrap.

What's in the Module Log related to that transaction? The output from the module may give additional insight on why it failed. Different TLDs have different requirements, so it's not all that surprising that something like a phone number missing the country phone code would cause it to fail. Managing all of these additional requirements per TLD can be a pain.

We need more info as described in How to Report a Bug. Although, I suspect the item the customer had in their cart does not have pricing set for the term selected. You may want to take a look at your package and double check the pricing. Going through your own order process should help narrow it down as well, if you can duplicate the issue.

Thanks. This is now fixed in CORE-1095. It is only a display issue, but resaving your client group settings would have used the "1 Day" value instead.

Yes, and they actually use it.

Can you elaborate and provide an example? The system general settings should have the full path to the root web directory, e.g. "/home/user/public_html/", and the company hostname should be set to the respective domain name, e.g. "domain.com" Can you make sure that you have PayPal setup to accept USD by checking that currency under [settings] -> [Company] -> [Payment Gateways] -> (click to manage PayPayl Payments Standard). Also check that the "Payment Options" option you have selected applies to the order, or just use the option "One time and subscription payments when possible". Then confirm your order form under [Packages] -> [Order Forms] -> (click to edit the order form), by checking that it has both the USD currency and PayPal gateway selected. The PayPal pay button should load from https://www.paypalobjects.com/en_US/i/bnr/horizontal_solution_PP.gif

Blesta wouldn't be overriding any of your webserver logs, no. Blank pages can occur for any of several reasons, including a php error or 500 internal server error. You can enable error reporting in Blesta by updating /config/blesta.php (line 11) from: Configure::errorReporting(0); to Configure::errorReporting(-1); And then see if that blank page displays any errors.

Closing thread as not a bug.

I've duplicated this in v3.1.2, but no other version. I'm not sure of the cause, but it doesn't appear to affect our upcoming releases.

Attached is the PagSeguro gateway for Blesta. Special thanks to Kiran at Nirays Technologies for creating the gateway and giving us rights to it. We'll be including this gateway with v3.2 of Blesta. To install, you can upload the contents of the attached zip to your Blesta installation directory, and then head into Blesta's admin interface to install the gateway under [settings] -> [Payment Gateways] -> [Available]. Additional information on configuring the gateway is available in the gateway's documentation. pagseguro.zip

The state/province displays the ISO-3166-2 abbreviation code rather than the full name, and for some states/provinces, like Panama, the abbreviations are numbered.

It sounds like your questions are related to how the module should interface with the Webdrive API, and as far as Blesta is concerned, you can handle that however you'd like. Rather than using experimental functions like xmlrpc_set_type, you should handle XML with an XML library like SimpleXML, and make the libxml extension a dependency in your module's install() method, if you find that to be a necessity. As far as your other questions, the best way to handle things is up to your judgment and what you think is best. It comes down to OOP technique and abstraction. I haven't looked at the Webdrive API, but based on what you've described, I imagine you can abstract the different authentication methods outside of your Blesta module and into the API in order to authenticate each API action properly. PHP is typeless, or rather, handles types on the fly, so any necessary type casting or manipulation can be done after the data has been passed into your module. I see no need to create new methods that accept different data types, unless you find this useful for abstraction. Each module in Blesta is independent, and its use of its own API is irrelevant to your module. If you need to pass an array of domains to an API method, then by all means, pass an array. You don't need to use a comma-separated list of domains just because another module does so. As for programming style, we have a guide for that.