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.