Paul

So what you're saying is that they killed off PagSeguro and released a totally new replacement with a new API? Did they publish anything online about this? If that is the case, we will have to remove PagSeguro entirely and consider whether we want to write a new payment gateway for PagBank or not. This would be a new gateway integration, not an update to the existing.

It sounds like the upgrade may have failed on the 5.0.0-b1 migration for some reason. If you ran the upgrade and it failed, and you ran it again and then received this error that would explain it. I'm not sure if your solution is the right one, but if all the navigation links look and work correctly, then it's probably fine.

Was the domain created through Blesta using the Domain Manager, or was it imported from another system? If it was created by Blesta in an old version, before the Domain Manager, did you use the Import Packages option under Packages > Domain Options > Configuration: Import Packages? I would find the associated Package. Packages > Filter by Hidden, and make sure only a single TLD is assigned to the Package under the Module tab, and that the Package is either Active on Inactive (Not restricted).

@Jono What do you think of this feature request? I can see the utility in being able to filter out particular emails from being sent from a plugin.

Incoming webhooks require that you have your own plugin that listens for the event so that it can trigger whatever action you want. Outgoing webhooks seem to work for me. Try setting up an Outgoing webhook using https://webhook.site/ This will give you a unique URL to create your webhook using, and the browser page will refresh automatically when the webhook is triggered, showing you the data. I just set up a test using Packages.edit with POST_JSON and the webhook.site page updated with the details.

Does this happen on an unmodified installation with no 3rd party extensions installed? I've tried and have been unable to reproduce this. When I search the gateway log, I'm seeing the expected results. We will need steps required to reproduce.

If you set all the service to the same renew date, they will be combined on the same invoice by default.. unless you have disabled this feature. Separately, we would consider a feature request for combined monthly billing for services that do not have the same renew date. https://requests.blesta.com

I tried to reproduce this with Stripe Payments (Not able to test with PayPal Payments Standard, but it shouldn't matter). Using the filter option, and entering the transaction # in the content box (Not selecting anything for dates), and clicking Submit did return the gateway log that contains the transaction # in the response data. If the transaction # is included in the gateway log for PayPal, it should find a match, it does appear to do a LIKE search on the response data. I would check ../logs_blesta/ logs to see if there are any errors while performing the filter operation.

@John Heenan I'm not sure I have a complete understanding of this, but I've created the following task if you want to review and advise whether this is the proper solution. https://dev.blesta.com/browse/CORE-5168 @Kurogane I don't see a bug here at all, if these altcoins are plugins to BTCPay Server and not configurable out of the box, then they fall squarely under the category of feature request. You can make a feature request at https://requests.blesta.com to recommend adding support for additional coins.

Make sure your server is not doing any caching. If requests are proxied via Cloudflare, or a reverse proxy like Nginx or something else, it may be caching page details causing the captcha not to work. To disable the captcha, edit the order form (Packages > Order Forms: Edit) and make sure "Require Human Verification Challenge for All Signups" is unchecked.

Ok, to see if I understand: The payment method is set by the Blesta button, so that the BTCPay invoice generated requires payment via that method. BTCPay supports (Bitcoin or Lightning, or any of the 4 you mentioned) as returned. You said: But it appears that it may also be possible for us to allow the payment method (From the 4 mentioned) to be set in the gateway configuration in Blesta) so that the payment button generates a BTCPay invoice in the desired method. Or, we can simply remove the option and allow the client to select it. What path would you recommend? Allow the payment method (of the 4 options) to be set in the gateway config in Blesta, so that the button specifies that method when a BTCPay invoice is created. Or, comment out the line so that the client is presented with the options? Curious what you think is the best way to go. Do you think admins want to force the client to pay with Lightning or BTC on the gateway config level, or let the client choose? I assume that the client will only be able to choose from methods that have been configured in BTCPay Server? So if BTC is the only option, then only it will appear.

Removing this option lets the user select Bitcoin or Lightning like your original screenshot from a BTCPay invoice? Do you consider this the best solution? I assume if you don't have Lightning configured it'll just default to Bitcoin.

What currency is the invoice in? I assume it is being converted automatically to BTC? So the issue is that payments from Blesta can only be made in the standard BTC, not through the Lightning network which is also BTC but off chain? If this is specified in the button code, it may need to be a setting in the BTCPay gateway config to specify the type.

Thanks, please continue to report any findings in this thread. I've created CORE-5165 so that we can correct as many of these as possible for 5.10.0.

Oh just to add, the TLDs appear to be jumping around in your video, that should not happen in 5.10+, we made an update to better handle sorting.

There isn't but I agree there should be, I've created CORE-5163 for this.

Thanks, we have created the following task https://dev.blesta.com/browse/CORE-5160

Thanks for the report, we've created the following task: https://dev.blesta.com/browse/CORE-5156

Your issue is much earlier, in a 5.5 upgrade task. Not to say you won't experience the same issue if your upgrade makes it to 5.8. In any case, I've mentioned this to the team so we can investigate. This is an issue for some people, but not all people so it may be partly dependent on MySQL/MariaDB version. @exception0x876 what is your MySQL or MariaDB version?

If you are on 5.9.3, there are substantially fewer notices in ../logs_blesta/ that in 5.8. We'll release version 5.10 beta 1 soon. I would recommend installing it, if you see any notices on PHP 8.2, let us know what they are and how you encounter them and we'll take a look.

What control panel are you using for hosting? The typical flow is: 1. Install module Settings > Company > Modules 2. Create Packages 3. Create Order form Packages > Order Forms

The label is determined by the module you're using. If you're using the Universal Module, then the label is the 1st Service field created for the Universal Module Product. If you are using "None" for the module, you might consider using the Universal Module instead https://docs.blesta.com/display/user/Universal+Module#UniversalModule-ServiceOptions

The deprecated notice probably has nothing to do with it. There's a bug as part of 5.9.2 that does not allow reports to be written to the default temp directory under Settings > System > General. If you create a new directory called "tmp" within your uploads directory, and set your path to that for temp, that should work. Until we release 5.9.3 (probably this week).

The line number is approximate, the important part is to find the code mentioned and update to what is shown.

You MUST update to 5.8.3 if you are running 5.8.2, or you are not protected. Apply the patch (blesta-5.8.0-5.8.3), ignore "hotfix" directories. Backup everything first.