-
Posts
6,731 -
Joined
-
Last visited
-
Days Won
841
Posts posted by Paul
-
-
ini_set is called throughout Blesta and in vendor code for legitimate reasons. In your case, /vendors/minphp/session/src/Session.php ini_set is used to set session variables. As far as I know, this has not changed recently, so it may be that a change to PHP 8 is responsible. We would probably recommend not disabling ini_set, but @Jono may be able to take a look when he has some time.
-
2 hours ago, TheNightOwl said:
What I am understanding then is that clients will just have to remember to request their payouts, right? Of course... I could send a monthly email to remind them to do this... Hmmm.
Thank you very much for the insight, Paul!
Yes, they would be able to request a payout when their balance meets your minimum requirement for a payout for matured funds. This is pretty common to have them make the request. In the future we may tie in an outbound payment option(s), after which automatic payouts might be a good feature.
-
20 hours ago, TheNightOwl said:
Is there a way for me to see how much I owe and to whom?
When affiliates reach the minimum payout amount you set, they can request a payout. The payout request would be available under Clients > Affiliates > Payouts.
20 hours ago, TheNightOwl said:Is there a way I can generate a list of affiliates who've met the thresholds and then just pay them once a month?
Not currently, but the current version of the affiliate system is the initial release for the most part and we are open to adding additional features and improvements. You can make a request at https://requests.blesta.com for a specific feature
20 hours ago, TheNightOwl said:The payout method seems to be just a label -- is there a place for the affiliate to tell me what their payout method username (like Venmo handle, for example) is?
You can create whatever payout methods you want, so yes, Venmo would be an option. Payouts are made manually after you receive a payout request. To add payout methods, go to Clients > Affiliates > Payment Methods and add 1 or more options.
-
2 hours ago, od-ana said:
Hello all.
I hope everyone well and healthy here.
I have questions regarding domain.
How to set price for each domain individually (in blesta)?
It seems it only have one price for all domain?
Thanks in advance.
Do you mean each TLD? TLD pricing is set individually per TLD under Packages > Domain Options > TLD Pricing. Just click Edit next to the TLD.
If you mean giving 1 customer a different price than the TLD, you can set a price override for them.
-
In case anyone else experiences this issue, this case was due to /config/blesta.php missing pagination settings. This could happen if the config file is not writable during upgrade.
-
13 hours ago, od-ana said:
hi,
I migrate blesta in sub domain using cpanel to direct admin. and it is now blank, not loading properly.
How to fix it?
thanks in advance
If you moved Blesta, make sure that you moved it correctly including copying ALL files + database. Review the big red note in our moving Blesta guide here https://docs.blesta.com/display/user/Moving+Blesta
If you moved Blesta correctly, then it's likely your new server doesn't meet the system requirements. See the requirements here https://docs.blesta.com/display/user/Requirements
You can temporarily enable errorReporting in /config/blesta.php by changing it's value from 0 to -1 and any errors may be output to your browser, but be sure to switch it back to 0 when done.
-
2 hours ago, wdfee said:
In earlier versions it was possible to edit the html code of email signatures. The introduced editor doesn't allow that anymore and is very restrictive.
As a minimum of customization I want to use my own company colors e.g. for links, but it is even not possible to use own colors.
In old version I used to have an html table with my logo left and address right. This now looks terrible and is not possible to adjust.
Could you please enable html editing of the whole signature again?In the Edit Signature, HTML tab you can use the "Insert HTML" option to paste in raw HTML. Ckeditor removed the "Source" option, then later they added it back. We have a task to update Ckeditor again to re-gain this option per https://dev.blesta.com/browse/CORE-4597 Using Insert HTML, you should be able to accomplish what you want, it just isn't as convenient.
-
On 5/27/2022 at 2:27 AM, MDHMatt said:
Confirmed, thanks for the report. https://dev.blesta.com/browse/CORE-4704
-
11 hours ago, Nyarango said:
On searching a domain name I get a 500 server error
How are you searching the domain? What registrar module are you using? What version of Blesta? What version of PHP?
-
2 hours ago, inspirenethost said:
The Enom module does not yet support DNS Management, Email Forwarding, or ID Protection yet. This is a new feature, which has yet to be updated for all registrar modules who's APIs support the actions. See https://docs.blesta.com/display/user/Enom
-
30 minutes ago, sunrisepro said:
That exact cron job has been there since my last comment so it's been active for 6 days and cron still needs to be run manually. I'm looking into SSH access to my VPS.
I'm also using Blesta 5.02 - does that affect anything?5.4.1 is the latest. It's possible that 5.0.2 does not have full compatibility with PHP 7.4, but I'm doubtful that is the issue here. If you can get SSH access and run that command via SSH it will tell us quite a bit.
-
On 6/7/2022 at 8:25 AM, sunrisepro said:
I'm stil stuck on this and have been running cron manually once a day. This is the path Blesta is showing in the Automation screen:
/usr/local/bin/php -q /home/username/domains/domain.com/public_html/subdomain/index.php cron > /dev/null 2>&1
This is what my host recommended using, including the correct path to php 7.4 (which I confirmed is the version in use):
/usr/local/php74/bin/php /home/username/domains/domain.com/public_html/subdomain/index.php
My host also noted that the '-q' flag is outdated and should not be used.
I'm also trying these cronjobs:
/usr/local/php74/bin/php /home/username/domains/domain.com/public_html/subdomain/index.php cron > /dev/null 2>&1 /usr/local/php74/bin/php /home/username/domains/domain.com/public_html/subdomain/index.php
All are set for 5 minutes, none are working. I'm happy to pay someone to resolve this for me as I'm lost on what could be wrong.
Based on this information, you should use:
/usr/local/php74/bin/php /home/username/domains/domain.com/public_html/subdomain/index.php cron > /dev/null 2>&1
If this doesn't work and you have SSH access you should try running it manually like this and see if it works:
/usr/local/php74/bin/php /home/username/domains/domain.com/public_html/subdomain/index.php cron
This last command should output to your shell any output from the cron. Take note of what is output.
If it works, run the following command to check what your cron job actually is:
crontab -l
-
On 6/3/2022 at 10:21 PM, Kal said:
@Paul, I've done some more tests and worked out that the problem is with the `DirectAdmin.password_length` setting. Regardless of what I set this to, the error appears if I enter a password of less than 12 characters. The `DirectAdmin.password_requirements` setting works as expected.
For example:
Configure::set('DirectAdmin.password_requirements', [ ["A-Z"], ["a-z"] ]); Configure::set('DirectAdmin.password_length', 9);
With these settings, a password of 'Abcdefghijkl' (12 characters) passes, but a password of 'Abcdefghijk' (11 characters) fails.
Is this a bug, or have I missed something?
That is unusual. I was able to reproduce this and have created the following task:
-
19 hours ago, Kal said:
Something just occurred to me… I have two-factor authentication turned on in DA (as every security-minded admin should). Is this incompatible with the module?
I'm not familiar with DA's 2FA and nobody else has mentioned it, but if you are forcing 2FA then that may be the problem. I would suggest temporarily disabling it to check if it works.
Edit: Obviously if API commands require 2FA they ill never be able to be automated.
-
7 minutes ago, Alexvw said:
Websites prove their identity through certificates that are valid for a certain period of time. The certificate for translate.blesta.com expired on 6/1/2022.
Thanks, I knew I had to have missed 1 or 2 when I updated a bunch of servers this week. FIxed.
-
On 5/28/2022 at 11:34 AM, Franz said:
Unfortunately, they will not they got out of the module making business some time ago (Official ResellerClub WHMCS Module) to focus on their API. I was looking at using the universal module for this but I have no idea how to...but I think it's possible.
Often times companies hire a dev firm to build the integration for them. They might have someone like that maintaining that integration from 10 years ago.
You can use the universal module and manually activate anything that you sell. See https://docs.blesta.com/display/user/Universal+Module#UniversalModule-ServiceOptions I linked directly to the service options section, because that and notifications is going to be the most important part of creating a Universal Module product. Any fields you want to request from the customer can be added here as service fields if they do not add to the cost. Any fields that would add to the package cost can be added as configurable options under Packages > Configurable Options, and assigned to an option group, that is then assigned to your package.
-
On 6/1/2022 at 4:13 AM, Kal said:
I have edited this file as described, removing unwanted requirements and reducing the minimum password length to 9, but as soon as I try to add a service I still get the same message:
Help!
(BTW, for anyone who still believes that character-composition requirements are a good idea, you might want to read the advice of security experts like Troy Hunt, NIST and Microsoft who all advise against this practice. See: Passwords Evolved: Authentication Guidance for the Modern Era. A poor decision for Blesta to turn this on by default IMO.)
When Blesta is not the authority on the password requirement, we go with the strictest possible requirement defined by the control panel. If the panel has a setting to force passwords of 12 characters, upper-case, lower-case, and a special character, then we require that so that there is not a failure to deploy a new account or update a password within the panel.
We are actually against such requirements that make it difficult for the user to remember the password while making it easy for a computer to guess. This sums up our thoughts on passwords: https://xkcd.com/936/
Regarding the issue, are you certain that you have modified the correct file? You don't have another copy of Blesta in another directory? You are using the DirectAdmin module and not another? The password you provided meets the password requirements for your DA server? The text of the error message will not change based on you changing the requirements, so if the password doesn't meet the requirements you set, you'll get the same error unless you modify that in:
/components/modules/direct_admin/language/en_us/direct_admin.php:$lang['DirectAdmin.!error.direct_admin_password.format']
-
If the plugin was already installed then its name and description, including what is shown under Settings > Company > Automation will use the language at the time it was installed. You could uninstall and re-install the plugin, or more preferably (To not lose data by uninstalling the plugin), update the language in the cron_tasks table and plugins table
cron_tasks.name, cron_tasks.description
plugins.nameThese are one of the few remaining things that do not pull the language dynamically.
-
On 5/28/2022 at 12:53 AM, MDHMatt said:
As per their documentation found here
https://www.namecheap.com/support/api/global-parameters/
and described here
https://www.namecheap.com/support/api/intro/
they use whitelisted ipv4 address to control access to the api which you enter into your account page. Should you enter a non whitelisted ip it gives an error.
this could also be useful for people with multiple IP address who maybe want to limit what ip to use for api calls
Ok, this is unusual because an IP restriction on the API would normally mean that the API would restrict the IP for the source of the request. If you can specify any IP and it uses that, it could be spoofed to bypass the check. It doesn't make sense. I think the 1st comment in that documentation you linked sums it up well:
QuoteCan anybody explain my WHY ClientIp must be included in request? NameCheap API server already knows which IP calls it from, right? It is not only data redundancy, it's error-prone misconception. Client should authenticate itself (username+token), API server should check if remote IP is on the whitelist, configured on NameCheap's side.
It seems to me that this is something Namecheap should fix. Adding a field to specify the IP is a pretty hacky-fix.
The example in this thread of using an IP address of 127.0.0.1 for ClientIP, does this work universally? If so, the simpler solution may be to just specify 127.0.0.1 for ClientIP in all requests like the example code, rather than requesting it. OR, if the IP address = IPv6, then instead of using that address, send 127.0.0.1. Thoughts?
-
4 hours ago, marcusdewald said:
Hello everyone,
I am currently evaluating several solutions, also Blesta.
I deployed a test instance via docker on my localhost but the trial license isn't available.
Error:
Sorry, a trial has already been issued for this domain and is no longer valid. To obtain a new trial key, please contact sales@blesta.com. If you'd like to purchase a license, please visit www.blesta.com.
Someone here who could help me out or am I missing something important?
Best regards
If you are loading Blesta through your browser using the hostname "localhost", then it won't work due to abuse. Use a different hostname, even if its one you make up and add to your hosts file. Also make sure your docker container's IP doesn't change or the license will stop working.
-
6 hours ago, MDHMatt said:
@Paul can we have a way to enter an ip in the module settings that lets us set the ClientIP? this could be auto populated using the existing code but having an option to adjust it would be great as namecheap get you to whitelist ip address to use the api with and only ipv4
What is the purpose of the ClientIP? Is this the IP address that API calls should originate from , or is it simply passed as a parameter in the API call? I have not looked into this myself. If $_SERVER['REMOTE_ADDR'] is returning an IPv6 address for your server, I can understand the fix posted above to force another IP. However, what are the implications if you enter an invalid IPv4 address, or one that does not resolve to this server? If the IP is just passed along to the API as a parameter, then I suppose it wouldn't cause any communication issues if the IP that made the request were different.
-
46 minutes ago, sunrisepro said:
The url is the correct path to Blesta's index.php - that's what should be accessed for the cron job?
This is not an issue, it was working fine for well over a year before I deleted the cron job by mistake last week.
The example Blesta shows under Settings > System > Automation is usually correct. Sometimes your path to PHP will be different, but it usually does a good job of detecting it.
If you deleted your cron job and don't remember what command you were using, probably you were calling a different version of PHP and that version met the system requirements while the new version does not.
-
On 5/14/2022 at 6:35 AM, planfourscott said:
I'm sandboxed with NameSilo and only EPP Code appears to work. Would love to have full functionality for this module.
What other modules have actually implemented DNS management, email forwarding and ID protection? I can't find anything in the specific module docs.
The Namesilo module does support DNS management, email forwarding, and ID protection. Are you running the latest version of Blesta? You must set pricing for these options, if they are enabled under Packages > Domains. Packages > Domains > Configuration: Configurable Options tab, click edit next to each option. Set pricing for each term/currency you offer.
-
On 5/15/2022 at 5:14 AM, LittleCreek said:
How can a client cancel a service? I thought it could be done by clicking Order History and cancelling from there but that does not seem to do anything. It doesn't actually cancel the service.
A client can click Manage next to their service in the client area, and there will be a cancel option.. assuming that you have enabled their ability to cancel under Settings > Company > Billing/Payment, by checking the option "Allow Clients to Cancel Services". If your client group settings are defined for the client, you may need to enabled it within their client group also, as these override the default company settings.
Inovoices are not being sent - Unsent
in Support
Posted
Hi Barry, when emails are generated are they queued for delivery? If you edit the invoice, is the Email box checked? If you aren't able to check quickly after they are created, you can create a manual invoice.
If an invoice is queued for delivery, then marked as sent, then most likely an attempt to send it was made and did not return an error. If you are using as SMTP server and the messages are being filtered out or rejected on that side quietly, then that could explain it.