All Activity

Open source Then I will buy,

200USD Fixed Peice. If you agree I can sell 100 If Custom Agreement PM me on Whatsapp.

PM sent

Hello, I have recently added Stripe Payment Gateway. It works perfectly. Question: how do I make it as default Payment method instead of PayPal?

Hello! I see Blesta's fraud integrations only listing Maxmind and FraudLabs Pro. Has anyone tried out Sensfrx? I recently found it in a group I am in and trying to find more information. They are actively selling a lifetime deal and also doing a giveaway. Not sure if I can link here though. Just wanted to share for awareness and see if anyone has tried it yet.

When selecting a field for a password, it shows the dots, which is what it is supposed to do. But is there a way support can see the information, other than changing the field to a Text field? Or being able to toggle the visibility? This is necessary when working on 3rd party servers. Thanks

Hello, I ordered a theme and I haven't received it and I can't find your contact details.

MovieBox Pro is a top-rated streaming that lets you enjoy movies and shows in HD and 4K on your favorite device. It has something for everyone, with a huge selection of content ranging from Hollywood and Bollywood movies, TV series, and live sports. The app works across various platforms, including Android, iOS, Mac, Apple TV, Android TV and Roku TV. Follow the download links below to get the latest version for your device and start streaming today.

Under Settings > Plugins > Manage for PHPIDS, there's a Logs tab. This log should contain more information. Most likely someone was attacking your installation with malicious requests, which PHPIDS blocked.

Just got several emails re this. The first issue I have had since installing Blesta'. Should I be worried?

I'm selling a Blesta Owned Unbranded License for $300 USD. 🔹 License Details: ✅ Owned – Lifetime access, no renewals ✅ Unbranded – No “Powered by Blesta” footer ✅ Transferable – I will pay the $25 transfer fee ✅ Same features as directly from Blesta 🎁 Bonus: I will include one addon company at no extra charge (normally a paid $95 upgrade)! Save $95 💳 Payment Options: PayPal Bank Transfer to our registered company account (preferred ) 📦 What’s Included: License transfer to your Blesta account Addon company enabled I handle the transfer fee with Blesta 📩 Contact: PM me

When editing a contact in admin, Blesta triggers the Contacts.get event for plugins to append custom properties to the contact object passed in params. The addt'l properties are present in the resultant Blesta view. But as soon as try to save the contact, a 500 error. Below is the error logged. This problem did not exist in v5.11.3. I believe it just surfaced after patching to v5.11.4. [2025-06-09T23:06:02.853593+00:00] general.ERROR: E_RECOVERABLE_ERROR: Object of class stdClass could not be converted to string {"code":4096,"message":"Object of class stdClass could not be converted to string","file":"/chroot/home/%username%/%userdomain%/html/app/models/contacts.php","line":401} The error is triggered within Blesta's Contacts Model on line 401 within the edit() method: // Calculate the changes made to the contact and log those results $diff = array_diff_assoc($old_contact, (array) $new_contact); At that point in code, the Contacts Model has first retrieved an old_contact record using $this->get(), and a new contact record also using $this->get(). The added properties are present in the $old_contact and $new_contact variables during the attempt to save the contact. PHP is throwing the 500 error because the contacts being compared have nested properties. If we just assign properties like: $contact->property1 = 'value #1'; $contact->property2 = 'value #2'; $contact->property3 = 100; Then there is no 500 error. But if we assign an object (or even an array) as a custom property to the contact, 500 error when save. Reporting this as a bug only because if we are permitted to append properties to a contact object in Blesta, then we need a way to encapsulate those appended properties such that another plugin that ALSO appends custom properties does not have potential to overwrite our plugin's custom properties. You can replicate this problem by having one or more plugins listen for the Contacts.get event. Here is a short excerpt of basically what we are doing. We could either define a custom array property, or object property. They both yield 500 when saving. // event handler for Blesta's Contacts.get event trigger public function getContact( $event ) { $params = $event->getParams(); $contact = $params['contact']; if( $contact ) { // append arbitrary data to contact using a nested property (this WILL trigger 500 error when Blesta saves the contact) $contact->meta = new \StdClass; $contact->meta->member_number = 93; $contact->meta->ancestor = 537; // append arbitrary data to contact using simple property (this will NOT trigger 500 error when Blesta saves the contact) $contact->member_number = 93; $contact->ancestor = 537; // set modified contact back into params $params['contact'] = $contact; } // set params back into event to pass back to trigger $event->setParams($params); }

How can i register a user with the API? I have a hard time making sense of the API documentation. 🙃 Just a small example would be appreciated. i just need to see an example, to wrap my head around it.

Thank you Paul

I have not been able to reproduce this on PHP 8.3, however we did make a similar update as suggested to account for this change in behavior in PHP 8.3 per CORE-5452, which will be included in 5.12.

Hello everyone, I’ve built a custom non‐merchant gateway (QueyePay) for Blesta, but after the customer completes payment on the QueyePay site, they always end up back at my Blesta homepage and the invoice remains unpaid. My callback() or validate() methods never run, and I can’t figure out why. Below is a brief overview: 1. buildProcess() In my gateway’s buildProcess(), I create a “return URL” like this: $protocol = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') ? 'https' : 'http'; $host = $_SERVER['HTTP_HOST']; $returnRoute = '/blesta-dev/index.php' . '?controller=gateways' . '&action=success' . '&gateway=queye_pay' . '&invoice_id=' . $invoiceId . '&client_id=' . $clientId; $returnUrl = $protocol . '://' . $host . $returnRoute; // Send this as "x-return" header to QueyePay $headers = [ "x-key: {$vendorKey}", "x-secret: {$vendorSecret}", "x-name: {$productName}", "x-currency: {$currency}", "x-price: {$price}", "x-return: {$returnUrl}" ]; After QueyePay processing, QueyePay redirects the user back to that returnUrl. However, nothing happens in Blesta—no logs, no invoice update. 2. success() & validate() I have a success() method that simply calls my validate(): public function success(array $get, array $post = null) { file_put_contents('/path/to/success_debug.log', print_r($get, true), FILE_APPEND); return $this->validate($get, $post); } public function validate(array $get, array $post = null) { file_put_contents('/path/to/validate_debug.log', print_r($get, true), FILE_APPEND); if (empty($get['invoice_id']) || empty($get['tr_id'])) { $this->Input->setErrors(['tr_id' => ['required' => 'Missing tr_id']]); return; } // Call QueyePay status API, then: return [ 'client_id' => $get['client_id'], 'amount' => $transactionAmount, 'currency' => $transactionCurrency, 'invoices' => [['id' => $invoiceId, 'amount' => $transactionAmount]], 'status' => 'approved', 'transaction_id' => $trId ]; } 2. success() & validate() I have a success() method that simply calls my validate(): public function success(array $get, array $post = null) { file_put_contents('/path/to/success_debug.log', print_r($get, true), FILE_APPEND); return $this->validate($get, $post); } public function validate(array $get, array $post = null) { file_put_contents('/path/to/validate_debug.log', print_r($get, true), FILE_APPEND); if (empty($get['invoice_id']) || empty($get['tr_id'])) { $this->Input->setErrors(['tr_id' => ['required' => 'Missing tr_id']]); return; } // Call QueyePay status API, then: return [ 'client_id' => $get['client_id'], 'amount' => $transactionAmount, 'currency' => $transactionCurrency, 'invoices' => [['id' => $invoiceId, 'amount' => $transactionAmount]], 'status' => 'approved', 'transaction_id' => $trId ]; } Neither success_debug.log nor validate_debug.log ever receive any data, which means Blesta isn’t hitting these methods. Should the return URL always use action=callback (not action=success)? If so, is my URL format wrong? Are there any sample .htaccess rules to force HTTPS but still allow Blesta’s controller=gateways&action=callback to pass through intact? Any other ideas why Blesta never hits callback() or validate(), and always redirects to the homepage?

I just wanted to write an update for anyone happened to face this issue and needs help: While TLD Sync was delaying the cronjob, it wasn't causing the duplicate invoicing issue. Finally this is solved. It all started when I reported one line of code is misbehaving when using PHP 8.3: PHP 8.3 handles DateTime::modify() differently compared to PHP 8.2 and older PHP versions. Until this is fixed in Blesta's code, a temporary workaround is: On <blesta_dir>/vendors/minphp/date/src/Date.php Replace line 140: $modified_date->modify($modifier); With: try { $result = $modified_date->modify($modifier); if ($result === false) { return false; } } catch (\DateMalformedStringException $e) { return false; } catch (\Throwable $e) { return false; } To mimic PHP 8.2 behavior. Or don't use PHP 8.3 and just use PHP 8.2.

Also, check Tools > Logs: Cron tab filtering by the word "Create" to list the Create Invoice tasks. I want to know the frequency of this task running (Start Date / End Date) as it should be a full day apart, and click the records to expand to show the output from the run. I want to know if the task is running more often than once a day and if the invoices are created in duplicate across separate runs or within the same run.

Your logs show no errors, but the info log does show the invoice generation. I've replied to your ticket for more information, but this is consistent with what I said earlier that the renew_date may not be being bumped forward which should happen automatically after invoice creation. Any 3rd party extensions or customizations will be suspect, particularly any that tie into events.

Paul (or anyone else from Blesta stuff) please check ticket #9573368

Paul the issue is happening again, I killed the cronjobs and stopped the cronjob from running further. I have the gathered the logs this time. I'll open a ticket in blesta.com for further investigation. The only thing I did is I re enabled maldetect's cron 10 minutes ago, but I don't think that's relevant

Most likely the TLD sync task was halting all the other tasks. Before this happened, the customer purchased a service for 23€. What I assume, is that the cronjob never fully completed all the tasks regarding the purchase/invoice and while the other cronjobs were running in parallel, kept generating invoices for the same thing (while being halted again by the TLD sync task), since they thought the procedure was never finalized. Since I have excluded the TLD Sync task and run it via a separate cronjob (which takes 2 hours to complete because it's synchronizing 462 entries), I had no further issues so far. This generated around 11000 duplicate invoices in total, so it was a huge mess to even keep logs or files, so I decided to remove everything (logs/files/database) and restore a weekly backup and then find a solution.

Thanks, we'll update this per https://dev.blesta.com/browse/CORE-5448

When a service or domain is invoiced for renewal, the services.renew_date is bumped forward (+ term/period, e.g. 1 year, or 1 month, etc), which prevents it from being invoiced again because Blesta is only looking for services set to renew within a set period of time. I'm curious whether the renew_date was being bumped forward on this service/domain or not. Did all the invoices show the same period/date range on the line items? My guess is that something was preventing the renew date from being bumped forward, there may be some errors in your ../logs_blesta/ logs that could give a clue. Overlapping cron jobs are normally not a problem because Blesta locks the task when it starts it by logging the attempt, then when it's finished it logs the end datetime. Until the end datetime is set, it should not run again. However, it is possible that if multiple cron jobs start at exactly the same time, this may not be detected. In that case you will find in the log_cron table multiple runs that start at the same time and overlap. You should confirm that you have only a single cron job set up for Blesta. The TLD sync task should not interfere with other tasks and we have no other reports of this. This is because each individual task is locked while it is running and cannot run again until the previous run finishes. If the TLD sync task is taking a long time, then you could have another Blesta cron task run, but it should only process tasks that are not currently running and should be started again. Can you provide more information?

Hello, I'm using Blesta 5.11.3 with PHP 8.3 and OpenLiteSpeed. I'm using also Domain Manager and the Enom domain module. I have activated most TLDs and set TLD pricing sync as well. Out of the blue, one of the customers contacts me and says his Blesta account is filled with duplicate unpaid invoices. I checked the customer's account and he had about 3000 unpaid invoices and Blesta was keep generating more... The same thing was happening to a second customer too. Both of them had one past due invoice, I don't know if that was relevant. When I was stopping the cronjob, the generation of duplicate invoices stopped too, when I was resuming the cronjob the generation of invoices resumed too. I checked the cron logs and it seems the cronjob was taking too long to complete because of TLD pricing sync for the TLDs and essentially the cronjob was never fully completed. The command ps -aux | grep cron was also showing multiple cronjobs of Blesta running simultaneously. At this point everything was a huge mess so I decided to restore a backup. I killed all the cronjob processes and then I went to Settings -> Company -> Automation -> Plugin and unchecked "Domain TLD Synchronization - Synchronize packages with the TLD pricing from their registrar module" Finally the cronjob was able to fully run: Accept Paid Pending Orders Download Tickets Close Tickets Build Mailing Export Send Mass Email Delete Trash Tickets Send Reminders Process Abandoned Orders Transition Quotations Apply Payments to Open Invoices Provision Paid Pending Services Deliver Invoices Exchange Rate Updates Process Service Renewals Unsuspend Services Process Service Changes However I also wanted TLD pricing synchronization to work, without messing anything up, so I decided to make a script to run it as a separate cronjob: <?php // Blesta environment location. define("BLESTA_DIR", "/home/user/domains/domain.com/public_html/blesta"); require BLESTA_DIR . "/vendors/autoload.php"; require BLESTA_DIR . "/index.php"; // Load the TldSync class require_once BLESTA_DIR . "/plugins/domains/lib/tld_sync.php"; // Initialize the TldSync tool $tldSync = new TldSync(); // Optional: define which TLDs to sync. Empty = all. $tlds = []; // e.g., ['.com', '.net'] // Optional: filter by module (e.g., only Enom), or by terms $filters = [ // 'module_id' => 3, // 'terms' => [1, 2] ]; // Try to sync the prices... try { $tldSync->synchronizePrices($tlds, Configure::get("Blesta.company_id"), $filters); echo "Pricing synchronization of TLDs completed successfully!"; } catch (Throwable $e) { echo "Error during pricing synchronization: " . $e->getMessage() . "\n"; } I saved it as sync_tld_prices.php one level above public_html because I don't want it to be accessible by visitors and added a cronjob every 48 hours for it: 0 1 */2 * * /usr/local/bin/php -q /home/user/domains/domain.com/sync_tld_prices.php So far I haven't seen any duplicate invoices again, so hopefully the situation is resolved.