Jonathan

Found a few cases where if error reporting and debugging are enabled the pages simply break and you're just sitting with an error. I've found two instances of this: Suspending/unsuspending services Modules > Universal Module > Add Product The error is different on each and only happens when error reporting is set to -1, and debugging is set to true. Happens on PHP 7.1 and 7.2. MariaDB 10.2 and 10.3. Nginx and Litespeed for whatever it's worth. This is consistently recreatable on a blank 4.3.2 install as well as 4.3.0. For suspending/unsuspending: Something went wrong. tempnam(): file created in the system's temporary directory on line 179 in /home/blesta/public_html/vendors/h2o/h2o/loaders.php Printing Stack Trace: #0 [internal function]: UnknownException::setErrorHandler(8, 'tempnam(): file...', '/home/blesta/pu...', 179, Array) #1 /home/blesta/public_html/vendors/monolog/monolog/src/Monolog/ErrorHandler.php(164): call_user_func(Array, 8, 'tempnam(): file...', '/home/blesta/pu...', 179, Array) #2 [internal function]: Monolog\ErrorHandler->handleError(8, 'tempnam(): file...', '/home/blesta/pu...', 179, Array) #3 /home/blesta/public_html/vendors/h2o/h2o/loaders.php(179): tempnam('5268432515b8838...', '') #4 /home/blesta/public_html/vendors/h2o/h2o/loaders.php(166): H2o_File_Cache->__construct(Array) #5 /home/blesta/public_html/vendors/h2o/h2o/loaders.php(38): h2o_cache(Array) #6 /home/blesta/public_html/vendors/h2o/h2o/loaders.php(33): H2o_File_Loader->setOptions(Array) #7 /home/blesta/public_html/vendors/h2o/h2o.php(75): H2o_File_Loader->__construct(Array, Array) #8 /home/blesta/public_html/app/models/emails.php(906): H2o->__construct() #9 /home/blesta/public_html/app/models/emails.php(569): Emails->buildEmail('service_unsuspe...', '1', 'en_us', Array) #10 /home/blesta/public_html/app/models/services.php(2598): Emails->send('service_unsuspe...', '1', 'en_us', 'jonathan@effect...', Array, NULL, NULL, NULL, Array) #11 /home/blesta/public_html/app/models/services.php(3300): Services->sendSuspensionNoticeEmail('unsuspend', Object(stdClass), Object(stdClass)) #12 /home/blesta/public_html/app/controllers/admin_clients.php(4850): Services->unsuspend('1', Array) #13 /home/blesta/public_html/vendors/minphp/bridge/src/Lib/Dispatcher.php(143): AdminClients->editService() #14 /home/blesta/public_html/index.php(21): Dispatcher::dispatch('/index.php/admi...') #15 {main} For Add Product: Something went wrong. count(): Parameter must be an array or an object that implements Countable on line 45 in /home/blesta/public_html/components/modules/universal_module/views/default/add_row.pdt Printing Stack Trace: #0 [internal function]: UnknownException::setErrorHandler(2, 'count(): Parame...', '/home/blesta/pu...', 45, Array) #1 /home/blesta/public_html/vendors/monolog/monolog/src/Monolog/ErrorHandler.php(164): call_user_func(Array, 2, 'count(): Parame...', '/home/blesta/pu...', 45, Array) #2 /home/blesta/public_html/components/modules/universal_module/views/default/add_row.pdt(45): Monolog\ErrorHandler->handleError(2, 'count(): Parame...', '/home/blesta/pu...', 45, Array) #3 /home/blesta/public_html/vendors/minphp/bridge/src/Lib/View.php(163): include('/home/blesta/pu...') #4 /home/blesta/public_html/components/modules/universal_module/universal_module.php(592): View->fetch() #5 /home/blesta/public_html/app/controllers/admin_company_modules.php(365): UniversalModule->manageAddRow(Array) #6 /home/blesta/public_html/vendors/minphp/bridge/src/Lib/Dispatcher.php(143): AdminCompanyModules->addRow() #7 /home/blesta/public_html/index.php(21): Dispatcher::dispatch('/index.php/admi...') #8 {main}

You'll probably need to do this with pecl. https://forum.directadmin.com/showthread.php?t=44201

@Paul can we get a task on this for 4.4? I'd rather not have to manually patch this every update

Not for the customers that are confused by this on a daily basis while trying to order. I know cPanel and SolusVM are both impacted. Beyond that I'm not sure but a quick search for modules that define "validateHostName" as a function, it's quite a few beyond this!

Currently the validateHostname() function in most modules looks something like this: /** * Validates that the given hostname is valid * * @param string $host_name The host name to validate * @param bool $require_fqdn True to require a FQDN (e.g. host.domain.com), * or false for a partial name (e.g. domain.com) (optional, default false) * @return bool True if the hostname is valid, false otherwise */ public function validateHostName($host_name, $require_fqdn = false) { if (strlen($host_name) > 255) { return false; } $octet = "([a-z0-9]|[a-z0-9][a-z0-9\-]{0,61}[a-z0-9])"; $nested_octet = "(\." . $octet . ')'; $hostname_regex = '/^' . $octet . $nested_octet . ($require_fqdn ? $nested_octet : '') . '+$/'; return $this->Input->matches($host_name, $hostname_regex); } While sure hostnames shouldn't contain uppercase characters (my opinion), it's perfectly valid RFC and we shouldn't cause undue burden on the customer with vague rejection messages that what they entered isn't a valid domain/hostname simply because it contains uppercase letters. A better solution would be to update the regex to accept A-z and then in the modules run it through strtolower().

I see that the "prorate" parameter is marked as deprecated >4.0+. What's the intended future functionality? I'd imagine that it's simply get rid of the "if" block here and always do proration? That will be pretty inconvenient as there's many times when editing a service that you don't want to prorate. There's no code or anything to imply what the intended future functionality is so I'm hoping for some answers here.

Perfect, thanks!

I'm not sure when it stopped (version), but PDO (Record) isn't throwing exceptions when erroneous queries are thrown at it. I tracked this down to PDO::ERRMODE_EXCEPTION not being set on the actual queries. When I set this manually in the library all of the built in exceptions worked as expected again. I see code in the minphp PDO library that's supposed to set PDO::ERRMODE_EXCEPTION but it's not getting set for some reason, at least not on plugin-related things when using Record. To recreate, take a plugin, do something to a query via Record that will throw a MySQL error. The result is Blesta thinks things succeeded instead of throwing an error on the exception from the try/catch block since the exception was never thrown.

Ah, yes. 1.8.4 fixed some issues with admin-side registrations. See the change log. https://github.com/NETLINK/Blesta-Namesilo/releases/tag/1.8.4

What TLD are you trying to register? Some of the ones with special requirements, namely .us and .ca have been a bit of a headache to properly implement so I'm wondering if this is surrounding some of the requirements of those.

Glad it's working well for you! This is something several people have requested but as I don't need it in my use case I haven't had any direct plans to add it. If I'm ever bored working on the module I may, or you're welcome to do it yourself and submit pull requests on GitHub.

Shoot, it is possible! Awesome! The trick is moving the selector over to "module" instead of "package"

It would be great if the mass mailer recipients could be filtered by module row data. For example, say when using the cPanel module you need to email the customers of a single server for a maintenance window. Currently this is not possible. I'm aware of the WHM mail utility but that has a number of downsides one of which is potentially wrong/outdated email addresses, poor deliverability, people don't expect that sender, etc.

Version 1.8.4 released.

Care to elaborate?

That's pretty much my point for having the ability to completely disable it. As soon as it's there people can/will get offended. If it's not there, everyone is equal.

If such fields were added to core as opposed to using custom fields it should also be possible to disable them completely as not everyone will want to use these fields or even allow customers to fill them in.

As far as I know they link to this github project from https://www.namesilo.com/Support/Reseller-Options

This is essentially a feature request, and a pretty good one. @Paul

It's just a cess pool of abuse and issues

No, quite the opposite. All of this "master reseller" garbage should die!

Precisely.

It would be great if the mass-mailer supported sending to only contacts of the specified/selected countries as a filtering options.

If you are not in the EU and don't follow GDPR then there's nothing the EU can do to you unless: 1) you have assets in the EU 2) your country has some special treaty with the EU forcing you to comply for be held liable in your country The EU is not the new world order like they seem to think they are nor can they force their ways on other countries without the aforementioned treaties.

Version 1.8.3 released.