Jump to content

Paul

Blesta Developers
  • Posts

    6,737
  • Joined

  • Last visited

  • Days Won

    842

Posts posted by Paul

  1. 11 minutes ago, mackpaul said:

    I'm still seeing this in 5.12.3 
     

    • [2025-11-12T16:55:00.471793+00:00] general.NOTICE: E_DEPRECATED: Creation of dynamic property TicketManager::$SupportManagerDepartments is deprecated {"code":8192,"message":"Creation of dynamic property TicketManager::$SupportManagerDepartments is deprecated","file":"/opt/blesta/public/vendors/minphp/bridge/src/Lib/Loader.php","line":256}

    Steps to reproduce? PHP version?

  2. Maybe some details are lacking, but I'm not able to reproduce this:

    1. Universal module used, no special config.
    2. Adde service to client
    3. Using bulk option for invoice renewal (see screeenshot below)
    4. Date immediately bumped from Nov 7, 2025 to Dec 7, 2025.
    5. Nothing in the queue.

    Q: Do you have "Queue Service Changes Until Paid" enabled? Please provide a screenshot of all your Invoice and Charge Options.

     

    image.png

  3. On 8/30/2025 at 5:39 AM, Blikies said:

    Hello,

     

    When I try to add a configurable option and I fill this in the module section: {configoptions.backups} 

    I get an error that it has to be a number, how do I fix this?image.png.3f7ea3432c25a6d3df17d81c6fb4ed62.pngimage.thumb.png.a7cbe3f2a06fed6374dcec60e331350f.png

    Your config option needs to have at least "Client can Add" checked, or the option will not appear. I don't know why you have {configoptions.extra_backups} in that "Database Limit (optional)" field, but I'm pretty sure that should not be there. You get an error because it's supposed to be a number. Backups and database limits are 2 separate things.

  4. PayPal Checkout is newer and better than PayPal Payments Standard. If you have subscriptions from another billing system, then you'll need to redirect those IPN requests and you should add mapping for those within the gateway in Blesta. See https://docs.blesta.com/display/user/PayPal+Payments+Standard#PayPalPaymentsStandard-CommonIssues for more on doing a redirect.

    Note that PayPal Checkout IPN calls can interfere with PayPal Payments Standard, per the alert at https://docs.blesta.com/display/user/PayPal+Checkout It's generally a good idea not to use both.

  5. 5 hours ago, Sanora Digital said:

    Hi Paul,

    Thanks for your response.

    It seems that Blesta made it easy to adjust the logo 🙂

    Thanks

     

    Easy is our goal! Glad I could help. :) 

  6. Hi there! You just drag the logo and scale it up and down under Settings > Company > Look and Feel > Customize, for Staff or Client areas. Note it only works if you upload your own logo here.

    image.png

  7. 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.

    image.png

  8. 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?

  9. We haven't yet had any other requests for ACH with Braintree, and I'm not certain if it's an option that is compatible with the current credit card processing API or if it would require a new implementation. If there is any interest in sponsoring the feature let us know.

  10. On 5/1/2025 at 11:27 AM, trulyvu said:

    We are trying to remove the process of us having to upload the image for them. The idea is they can upload it to Blesta, our server can either pull the image location/download the image from Blesta and upload to our own server to show.

    I'm not sure I follow, it sounds like it's more complex that just uploading an image through Blesta... it needs to then be transferred/uploaded to your own server and then be shown somewhere? If you're trying to interface with some other software and you want Blesta to accept an image from the client and then update it somewhere else, you could likely accomplish this with a custom plugin.

  11. On 4/28/2025 at 9:25 AM, DDChris said:

    Hello Blesta,  I just signed up for a 30 day trial and I've hit an immediate problem.

    It looks like you have chosen to use the ISO 3166 data for addressing, which is wholly inappropriate for any type of online billing system.

    In the UK we use addressing in the form of Street Address -- Town / City -- County -- Postcode

    ISO 3166 does not conform to this  -  and while ISO 3166 may be some sort of standard - it is not the data anyone would use for UK addressing inside any business application. In fact, the only other application (in my 30 years working in IT)  where I've seen this used  is WHMCS - so it looks like you may have copied this from them. Bad idea because it is fundamentally wrong to use this data. Some of the most common counties do not exist within this data and this will prevent many users from being able to enter their correct addresses. While it is certainly informative information and lists all the principalities in the country, it just doesn't work for street/town/county addressing and I don't believe this data was ever meant to be used for domestic addressing within a commercial setting. That's probably why nobody else does it this way.

    Anyway, I'm not going to go on about it. I've made my point. You've obviously chosen this way under bad advice and are unlikely to change it now - however, I cannot use this software unless I can make changes to this list within the application. I'm not going to subject my customers to this infuriating inconvenience. It was simple within WHMCS to change the list, so I'm hoping it is just as simple in Blesta.

    1. I can see that the data is held within the following directory...
    vendors/respect/validation/library/Rules/SubdivisionCode
    2. The files have some sort of validation but I'm not sure if this means there will be an error if a file is changed.
    3. I'm assuming the data is being pulled out of these files directly, rather than from the database.

    My first question ... can I simply edit the GbSubdivisionCode.php file to replace the data with my own? I understand this would need to be changed upon every update.
    Secondly, are the three letter codes in those files used within Blesta for anything - or are they simply ignored?
    Thirdly, is there a better way to hack this with a hook or some javascript?

    Thank you for your time!

    Hi DDChris,

    We haven't copied anything from our competitor, especially not states and countries so that is interesting. They were originally pulled in from official data sets per https://docs.blesta.com/pages/viewpage.action?pageId=10551368#Debugging/Tools-StatesandCountries but we are planning to make some changes/improvements here as some data has either changed or may not have been totally accurate from the original sources. Perhaps our competitor used the same original sources, I'm not sure. Also, different regions have different preferences for how the date is constructed. You can see the task we're planning to implement here https://dev.blesta.com/browse/CORE-5391 If you have any comments on this task, let us know.

    Regarding that library, I don't believe this is used at all for this purpose. States and Countries are stored in the database in the states and countries tables, respectively. So, these can be adjusted there if you prefer, depending on what kind of change you want to make. Codes can't be changed to something other than a code, so changes that relate to how the address is displayed (code, or name, etc) due to the region will likely need to wait for this task to be implemented.

    Cheers,

    Paul

  12. On 4/29/2025 at 10:03 PM, Szilvia said:

    I added several of my old clients to the system under "Clients."
    For those whose subscription was still active, I issued an invoice in the system (2 clients). When I recorded a payment for one of them, I noticed that the system had generated a new invoice (even though I thought it would only generate a new one automatically a year later, after the client was added and the initial invoice was created).

    I checked the email log for the client and saw that the system was continuously sending emails every 5 minutes related to the invoice it generated. After recording the payment, it started sending the payment confirmation email every 5 minutes as well.

    I checked this with another client too: after I deleted the system-generated invoice, the emails stopped. However, with the first client, since I marked the system-generated invoice as paid, I can no longer delete it—and the emails are still being sent continuously.

    My questions:

    • How can I stop the continuous email sending? I even disabled the payment notifications for this client, but the emails are still being sent.

    • Where can I see the status of these emails? Are they actually being delivered? I assume not, because the invoice status shows "Unsent", which I guess is why the system keeps trying.

    • Is it possible to set a maximum number of delivery attempts (e.g., 3 times), and then have the system stop if the emails still fail to send?

    many-emails.jpg

    If the emails are being sent every 5 minutes, then Blesta thinks the email is failing to be sent and so the invoice is not marked as sent. Are you certain the email was actually sent and received by the recipient? Click the email in the log to expand and show the details, it may include errors.

    Also check Settings > Company > Emails to make sure your mail server is configured correctly and that your From Email address on all your email templates is correct.

    Then check ../logs_blesta/ logs to see if there are any errors when an email is sent.

    Also check if you can send the email to your own email address in the invoices widget by checking the box next to the invoice and sending to an address you specify.

    To prevent an invoice email from going out Edit the invoice and uncheck the "Email" option. This option is deselected automatically when an email is successfully sent, but for some reason it appears the email is either not sent or there is some error with sending.

     

     

  13. 1 hour ago, trulyvu said:

    Our use case with Blesta is different than just selling domains and hosting. We actually give our users a full website real estate website. All of the info, such as client's name, social media gets sent to our server to show on their website. We are trying to make Blesta the main control hub for our clients, but they need to also upload a picture of themselves so that it can display on their website. Is there any way to achieve that?

    It sounds like these are images they are providing so that you can work on their website. If they can't email files to you, right now probably the best thing to do is for them to upload files like this via the ticket system. They can open a ticket or reply to a ticket and add attachments. You can download the files from the ticket.

    There is a plugin called "Client Documents", but this is for admins to attach files to their account that they can download, not the reverse of that.

  14. On 4/10/2025 at 5:45 AM, Andrei Chira said:

    Yes, the invoices are closed with no transactions applied, and the clients have credit = the total amount they ever paid us.

     

    Screenshot 2025-04-10 at 15.39.32.png

    Screenshot 2025-04-10 at 15.40.03.png

    We are working on a fix for this in 5.11.3, you can try this out now if you like:

    Edit the file ~/plugins/import_manager/components/migrators/whmcs/whmcs_migrator.php

    Around line 70 look for the $actions code block, replace the entire block of code with the following (We moved importTransactions to below importInvoices.)

        $actions = [
            'importStaff', // works
            'importClients', // works
            'importContacts', // works
            'importTaxes', // works
            'importCurrencies', // works
            'importPackages', // works
            'importPackageOptions', // works
            'importServices', // works
            'importDomains', // works
            'importInvoices', // works
            'importTransactions', // works
            'importSupportDepartments', // works
            'importSupportTickets', // works
            'importAffiliates', // works
            'importMisc' // works
        ];

    If you try this, let us know how it goes.

  15. On 4/10/2025 at 5:45 AM, Andrei Chira said:

    Yes, the invoices are closed with no transactions applied, and the clients have credit = the total amount they ever paid us.

     

    Screenshot 2025-04-10 at 15.39.32.png

    Screenshot 2025-04-10 at 15.40.03.png

    Upon further inspection (and other reports), I believe there is a bug in 5.11 preventing the transactions from being applied correctly during import. At this time we'd recommend importing on 5.10.3 and then upgrading to 5.11.2 after that. We are trying to reproduce the issue now and if we can, we hope to have a fix in 5.11.3 soon.

×
×
  • Create New...