John Heenan
-
Posts
76 -
Joined
-
Last visited
-
Days Won
1
Posts posted by John Heenan
-
-
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.
-
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.
-
On 3/17/2024 at 11:41 AM, Janet said:
Actually, it doesn't help at all.
I've done that. Domain registration that way works beautifully. But not hosting.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.
-
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
-
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
-
Sorry, just seen the previous topic. Please ignore.
-
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 -
.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
-
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
-
6 hours ago, Amit Kumar Mishra said:
Hi @johnhe
i like your passion
even without any response from the community, you could resolve it
not only that you contributed to the community by answering to its fix
keep up the good work
Thanks!
-
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
-
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
-
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
-
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.
-
This problem was originally reported for Blesta beta version 5.6.0-b2. Blesta 5.6.0 has now been released. I upgraded to 5.6.0 as per recommended for a new release (overwrite all files).
The problem and reporting remain the same. PHP debug is unusable because Minphp reports a type error. I assume this is due to tightening up with PHP 8.
Hence I have edited the topic and contents to remove the '-b2' beta suffix.
-
Additional Information:
Blesta version 5.6.0-b2 using ioncube-loader for PHP 8.1
PHP version: 8.1.13
MySQL version: MariaDB 10.3.35
-
Additional Information:
Blesta version 5.6.0 using ioncube-loader for PHP 8.1
PHP version: 8.1.13
MySQL version: MariaDB 10.3.35 -
Setting PHP debug in Blesta 5.6.0 editing config/blesta.php to below
// PHP error_reporting. 0 to disable error reporting, -1 to to show all errors // Consult php's documentation for additional options Configure::errorReporting(-1); // Override minPHP's debugging setting. true to enable debugging, false to disable it Configure::set('System.debug', true);
always results in error message starting with below in browser, making Blesta unsuable with PHP debug.
Something went wrong. Return type of Minphp\Session\Handlers\PdoHandler::open($savePath, $name) should either be compatible with SessionHandlerInterface::open(string $path, string $name): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice. Return type of Minphp\Session\Handlers\PdoHandler::open($savePath, $name) should either be compatible with SessionHandlerInterface::open(string $path, string $name): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice on line 65 in ...../blesta/vendors/minphp/session/src/Handlers/PdoHandler.php UnknownException::setErrorHandler Line 232 ...../blesta/vendors/monolog/monolog/src/Monolog/ErrorHandler.php Monolog\ErrorHandler->handleError Line 10
-
I replaced the three default 5% markups in TLD Sync with nothing instead of 0 (to be interpreted as 0). If this was an issue, I would have expected Blesta to complain or replace them with 0. It didn't.
After this TLD sync failed to work and errors such as following were generated:
general. ERROR log reports:
2022-12-18T09:23:54.705204+00:00] general.ERROR: Uncaught Exception TypeError: "Unsupported operand types: string / float" at ....../blesta/plugins/domains/lib/tld_sync.php line 141 {"exception":"[object] (TypeError(code: 0): Unsupported operand types: string / float at ....../blesta/plugins/domains/lib/tld_sync.php:141)"}
Blesta version: 5.6.0-b2
Fix for bug in Virtualmin module of Blesta that prevents changed plan limits being applied
in Bugs
Posted
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:
to:
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:
to:
if (!array_key_exists($key, (array)$service_fields) || $vars[$key] != $service_fields->$key) {