Jump to content

John Heenan

Members
  • Posts

    76
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by John Heenan

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

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

     

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

    1669802856_Screenshotfrom2023-05-1419-09-40.png.b5ec0b95651c902781ed680507ae385d.png

     

    Extra information requirment in Namecheap when registering directly

    882782464_Screenshotfrom2023-05-1419-03-20.png.e3b2a58e2fe82a6145088112fde8f3b5.png

     

    John Heenan

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

    1037673592_Screenshotfrom2023-05-1418-43-44.thumb.png.86a3e2ab7300377d26b78aab75f73bf1.png

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

     

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

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

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

     

     

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

     

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

     

×
×
  • Create New...