Panormitis

Thank you Paul

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.

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.

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.

On <blesta_dir>/plugins/domains/lib/tld_sync.php On line 40, you have set: set_time_limit(60*60*15) // 15 minutes According https://www.php.net/manual/en/function.set-time-limit.php the value should have been set in seconds, so the correct would be: set_time_limit(60*15) // 15 minutes. 60*15 = 900 seconds (15 minutes). 60*60*15 = 54000 seconds (15 hours), which is incorrect.

Thanks Paul, it would be a nice feature when completed. For now I managed to do what I needed with my SQL query above.

Until this feature is ready, if you are using Domain Manager you could set the correct nameservers beforehand for each TLD and these nameservers will be autofilled during ordering a domain name. Unfortunately TLDs would have to be edited one by one to set the nameservers, so if you has a lot of TLDs is a pain, but you could use an SQL query on the database to update the TLDs faster: -- Define your desired nameservers as serialized PHP array SET @ns_value := 'a:4:{i:0;s:14:"ns1.domain.com";i:1;s:14:"ns2.domain.com";i:2;s:0:"";i:3;s:0:"";}'; -- Update only package_meta entries with key 'ns' and an empty value UPDATE package_meta SET value = @ns_value WHERE `key` = 'ns' AND serialized = 1 AND (value = 'a:0:{}' OR value IS NULL); Backup the database first, use it at your own risk. Change ns1.domain.com & ns2.domain.com to your actual nameservers and change s:14 to the correct string length of your nameservers (eg. ns1.domain.com is 14 characters long, that's why s:14).

Any updates on this?

Latest version, 5.11.3 Here are localization settings:

On Services when you select a service (or more) and on lower right, select Invoice Renewal, number of cycles 1, Sumbit. A php error is generated: [2025-04-23T20:01:05.131718+00:00] general.ERROR: DateMalformedStringException: DateTime::modify(): Failed to parse time string (+0 onetime) at position 9 (e): Double timezone specification in <omitted>/vendors/minphp/date/src/Date.php:140 Stack trace: #0 <omitted>/vendors/minphp/date/src/Date.php(140): DateTime->modify() #1 <omitted>/app/models/invoices.php(1857): Minphp\Date\Date->modify() #2 <omitted>/app/controllers/admin_clients.php(562): Invoices->createRenewalFromService() #3 <omitted>/app/controllers/admin_clients.php(318): AdminClients->updateServices() #4 <omitted>/vendors/minphp/bridge/src/Lib/Dispatcher.php(142): AdminClients->services() #5 <omitted>/index.php(21): Dispatcher::dispatch() #6 {main} Line 140 of <omitted>/vendors/minphp/date/src/Date.php is: $modified_date->modify($modifier); According PHP 8.3 specs (https://www.php.net/manual/en/datetime.modify.php): DateTime::modify() now throws DateMalformedStringException if an invalid string is passed. Previously, it returned false, and a warning was emitted. date_modify() has not been changed. Relevant PHP settings: cat /usr/local/php83/lib/php.ini | grep timezone ; Defines the default timezone used by the date functions ; https://php.net/date.timezone date.timezone = "UTC"

I can ask another support agent again. In the meantime, I do prefer the module to retrieve the retail prices for everything (even if that seems odd). I suppose the API call names aren’t going anywhere anytime soon, so even if the module gets updated, I’ll just change PE_GetProductPrice to PE_GetRetailPrice. I would be very surprised if I’m the only one who prefers this. An option in the module settings, to choose between PE_GetProductPrice and PE_GetRetailPrice could be a nice idea though.

I know Blesta can do it. What I'm saying is that Enom support said they will send notices too, no matter what. I can't disable Enom notices, they are obligatory. The only thing I can do is at least make the prices match, for transparency. Otherwise my customers will receive renewal notices with different prices. EDIT: I can tell them "Don't send notices yourself, I have a billing software that does", but they didn't give me that option. The way they said it, implies I don't have that option.

I have asked Enom support about this and their support agent explicitly said they are obliged to send renewal domain notices, no mater what, but at least they will show to the customers the retail prices I have set. This is why I want to sync the correct prices, for transparency.

I understand that, but I don't think it's practical. When the time comes for Enom's domain renewal notices (Enom is obliged by ICANN to send them on my customers) won't the domain notices list the renewal/retail price I have set on my Enom reseller account? This is what the customer will pay, not "my cost" price. It looks a lot cleaner to me to fetch the retail prices to sync everything perfectly, than fetching "my cost" prices and rely on markup to make profit.

Hello, I have an Enom reseller account. I started using Enom domain module and I noticed when I try to sync the TLD prices, the prices retrieved are the base "my cost" prices, not the retail domain prices I have set for the customers, which I find odd. I managed to fix it so I just wanted to share my solution in case anybody finds it useful. Open file <blesta_dir>/components/modules/enom/enom.php for editing. Find: PE_GetProductPrice Replace with: PE_GetRetailPrice There should be 3 instances, on lines 185, 193 amd 198. Save the file, clear Blesta's cache directory and enjoy! I really think this should have been fixed by Blesta developers. Domain prices should be synced to the retail prices, not the base ones.

Contact your web hosting company or server administrator. Perhaps a custom php path is used or crond service is not running. cron accesses files directly, not via apache/webserver. .htaccess shouldn't matter

As Blesta indicates, example cron command, it's not necessarily correct, it's just an example to get you started configuring. You are running DirectAdmin, the path of the php binary is different. Change the part /usr/bin/php to /usr/local/bin/php In Minute text box set it as */5 not just 5. Assuming you want the cronjob to run every 5 minutes. You could also just put a single asterisk in the Minute text box, that would make the cronjob to run every minute, but it's not necessary to run that often.

Some coupons are always working, for example: COUPONFCNC provides a 20% discount every time a transaction is made (domain registration/renewal/transfer etc.). NEWCOM649 gives you a new .com domain registration for just $6.49 The Namecheap module settings could have a coupon text field that is applied in the API every time a transaction is made, or few text fields (let's say 3) for various coupons that can be configured in the settings to be applied on specific events. For example NEWCOM649 only when a new .com domain is registered. COUPONFCNC when any transaction is made that doesn't involve a new .com domain registration.

Yes Namecheap coupons can be passed to the API, check PromotionCode https://www.namecheap.com/support/api/methods/domains/create/ It can be passed also on domain renewals and domain transfers.

Any updates on this? A coupon / PromotionCode field in settings, would be nice.

This happened to me too today. The client paid manually (bank transfer) two weeks ago. I recorded the payment, the domain was included in the invoice. Date Expires was updated. Date Renews wasn't updated. And Blesta went ahead and sent an e-mail to the client "This is a notice that the domain <domain.com> has expired on 2025-02-08 and is no longer under your ownership. To re-purchase this domain, please log in at ...". This needs to be fixed, worried clients are bad for business...

I found out the solution thanks to Discord, I'm just posting it here, in case it helps others. 1. Go to the domain you want to cancel or delete & click Manage. 2. The actions you have there are: Change Auto Renewal, Renew Domain, Update Nameservers, Push to Client, Unparent and Reset Price. You don't need these for now, just click the Edit Service button in the lower right corner. 3. Now you have the actions Suspend, Cancel, Schedule Cancellation, Change Renew Date, Update Coupon. 4. You can choose to use the module or not. You could cancel the domain right away by selecting Cancel & clicking Save. 5. Afterwards the domain is placed in canceled domains, where you can delete it.

Hello, I'm using Blesta 5.9.3, I recently activated the domain manager plugin and now domain names have their own section and not appearing as services anymore. However in the past if I wanted to remove a domain name from a client, I could cancel (and delete if needed) the corresponding service. I don't see how I can do this with domain manager. How can I cancel and potentially delete a domain name of a client? I'm not asking how to delete it from the registrar, just how to cancel it and potentially remove it from the client account. The only potential solution I found is to manually edit the database, which seems like a bad idea.