Jump to content

johnhe

Members
  • Posts

    22
  • Joined

  • Last visited

  • Days Won

    1

johnhe last won the day on January 8 2023

johnhe had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

johnhe's Achievements

  1. This bug applies to current version of Blesta, version 5.9.3. When using the Upgrade/Downgrade feature for service management that uses the Virtualmin module, a change of Package/Term corresponds to a plan change in Virtualmin, as well as other changes. With this feature, although a plan is changed, limits of the changed plan are not applied, such as a change of allocated disk space or a change in allowed number of servers. The name of the parameter that is passed to virtualmin is --plan. It should instead be --apply-plan to also include changed plan limits. From https://www.virtualmin.com/documentation/developer/cli/modify_domain/ "To change a virtual server's plan and apply quota and other limits from the new plan, use the --apply-plan parameter followed by the plan name or ID. Alternately, you can switch the plan without applying any of it's limits with the --plan flag." To make this fix, edit line 1108 in file blesta/components/modules/virtualmin/virtualmin.php from: 'plan' => $package_to->meta->plan, to: 'apply-plan' => $package_to->meta->plan, In addition, if using php8 with Blesta 5.9.3, it is necessary to also make the following change to fix a TypeError bug Edit line 867 in file blesta/components/modules/virtualmin/virtualmin.php from: if (!array_key_exists($key, $service_fields) || $vars[$key] != $service_fields->$key) { to: if (!array_key_exists($key, (array)$service_fields) || $vars[$key] != $service_fields->$key) {
  2. I fixed the bug reported above myself by editing line 867 in file blesta/components/modules/virtualmin/virtualmin.php from: if (!array_key_exists($key, $service_fields) || $vars[$key] != $service_fields->$key) { to: if (!array_key_exists($key, (array)$service_fields) || $vars[$key] != $service_fields->$key) { However, although this restores behaviour to same as with php7, a detailed look at the effects showed only the plan name was changed in Virtualmin. This is another bug. I will post details of this additionally discovered bug after I have tested what may be a fix for it.
  3. Issue is unable to change plan used on Virtualmin, with Virtualmin module through Blesta, with upgrade/downgrade. Two stage manual change is a workaround (change without module on Blesta and then change directly on Virtualmin) Steps to reproduce are: Client, Service, Manage, Upgrade/Downgrade, change package/term (with Use module ticked -module is Virtualmin), Save URL page before error is .../admin/clients/editservice/...... Result is HTTP 500 error Blesta general error in logs: general.ERROR: Uncaught Exception TypeError: "array_key_exists(): Argument #2 ($array) must be of type array, stdClass given" at .../blesta/components/modules/virtualmin/virtualmin.php line 867 {"exception":"[object] (TypeError(code: 0): array_key_exists(): Argument #2 ($array) must be of type array, stdClass given at .../blesta/components/modules/virtualmin/virtualmin.php:867)"} OS is Debian 12, Blesta version is 5.9.3, PHP version is 8.2.7, Blesta Virtualmin module version is 1.8.0 This bug was originally reported in error to the 5.9 beta bugs section.
  4. Short answer: following on from Paul's answer, use an order form of type 'Domain and other'. Longer less specific answer: Selling hosting and selling DNS is selling two separate services that are linked by passing on a name. The services can be included in the same order. What links the services is the domain name (specified by the customer OR passed through automatically when using order type 'Domain and other') and the custom name servers (pre specified). It is not a simple process to set up but it does work. I would not consider it straightforward. But I would consider it appropriate given the complexities of what is involved.
  5. OK thanks, I will wait until version 5.10 beta 1 to report back For anyone else interested, following is a useful command to extract unique log messages, independent of date and with home directory removed. cat general-notice-2024-03-*.log | cut -d ' ' -f 1 --complement | awk -F, '!seen[$1]++' | sed 's/\home.*\/blesta\///'> uniquelineslogs.txt
  6. Although I have line 'Configure::errorReporting(0);' in config/blasta.php, this has no effect on reporting in daily logs in logs_blesta directory. With Blesta 5.9.3, there are still numerous E_DEPRECATED messages using php 8.2, for example megabytes worth in general-notice-XXXX-XX-XX.log. How can I stop this? John
  7. Sorry, just seen the previous topic. Please ignore.
  8. Can no longer pipe emails to Blesta. Worked with PHP 7 cat ~/sample_email | /usr/bin/php ./blesta/plugins/support_manager/pipe.php Uncaught TypeError, code 0 in .../blesta/app/models/blacklist.php on line 255 Message: Blacklist::verify(): Argument #1 ($input) must be of type string, null given, called in .../blesta/app/app_controller.php on line 0 OS: Debian Blesta: 5.9.2 PHP: 8.2
  9. .com.au domain registration with Namecheap from Blesta API requires additional information to that submitted from Blesta. Was able to register directly on Namecheap by choosing an addiitonal ID form and number. See images blow. Using Blesta 5.6.1, Rocky 8.7, PHP 7.4 Suggest we can be provided with an option in admin to add in extra arbitrary fields to complete a registration when a customer registration fails and be able to provide a warning to customer that more information may be required if a registration fails Blesta logs when attempting to register .com.au failed Extra information requirment in Namecheap when registering directly John Heenan
  10. Clicking on domain settings for a client for a .com with NameSilo results in a failure to confirm verification. From logs, input and output: https://www.namesilo.com/api/emailVerification a:3:{s:5:"email";s:0:"";s:7:"version";i:1;s:4:"type";s:3:"xml";} https://www.namesilo.com/api/emailVerification O:8:"stdClass":2:{s:4:"code";s:3:"108";s:6:"detail";s:46:"Missing parameters for the specified operation";} The result should state true or false. In fact the .com domain is 'contact email verified', according to NameSilo. Assuming this is a public API call, the missing parameter is the domain name. Using Blesta 5.6.1, Rocky 8.7, PHP 7.4 URL path is /client/services/manage/1/tabClientSettings/ See image John Heenan
  11. Some more information about error reporting with Blesta. This clears up confusion for me. Errors are reported to screen, even with display_errors set to off, as errors are trapped by file app/views/errors/error.pdt The boolean internal variable System.Debug decides whether error.pdt includes a stack trace or not To make sure no errors are visible error_reporting must be set to 0, such as by using Configure::errorReporting(0); Errrors are also logged to various files in logs_blesta directory
  12. Below is in a php.ini file for my server that I dd not alter. ; Default Value: E_ALL │ ; Development Value: E_ALL │ ; Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT │ ; https://php.net/error-reporting │ error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT What it means is that if you want to use the last configured error_reporting php.ini value then you need to comment out the following lines in conf/blesta.php Configure::errorReporting(0); E_ALL is equivalent to -1
  13. I have found a global fix for this bug. The fix implies Blesta 5.6.0, when used with PHP 8.1, is using deprecated code. This is not surprising and is considered normal for large projects. There is no urgency about fixing this. Here is the fix that enables PHP debug to be used with Blesta 5.6.0 and PHP 8.1 edit config/blesta.php and use Configure::errorReporting(E_ALL & ~E_DEPRECATED); instead of the current recomendation of Configure::errorReporting(-1); Note the spelling of E_DEPRECATED is correct
  14. If this bug is due to some additional type checking in PHP 8.1, maybe we can be told of some global setting to turn this off so we can get past this unhelpful message that obstructs debugging I don't know where the instruction #[\ReturnTypeWillChange] is supposed to go and if this is a global setting or not.
×
×
  • Create New...