Jonathan

There's currently an event for contacts.edit which is great but we need one for when an email address for a contact is successfully verified as well for other systems that might need to be updated by plugins for a user's new email address but only need to happen upon the successful validation of the address.

Presently there's no way to access the suspension reason within the suspendService() method in modules.  Looking at the source in app/models/services.php this is because the updated suspension_reason isn't set until after suspendService() runs, thus the suspension_reason field in the $service object is incorrect (ie it's the old/previous reason, if any).
It would be great to be able to pass this value along to modules which may have their own methods of notifying customers, taking actions, etc.

Any thoughts?  Pretty basic nicety for module development...

Presently there's no way to access the suspension reason within the suspendService() method in modules.  Looking at the source in app/models/services.php this is because the updated suspension_reason isn't set until after suspendService() runs, thus the suspension_reason field in the $service object is incorrect (ie it's the old/previous reason, if any).
It would be great to be able to pass this value along to modules which may have their own methods of notifying customers, taking actions, etc.

Presently there's no way to access the suspension reason within the suspendService() method in modules.  Looking at the source in app/models/services.php this is because the updated suspension_reason isn't set until after suspendService() runs, thus the suspension_reason field in the $service object is incorrect (ie it's the old/previous reason, if any).
It would be great to be able to pass this value along to modules which may have their own methods of notifying customers, taking actions, etc.

Some modules take several minutes to activate a service and they don't create a lock of any sort when starting activating to prevent another process, be it cron or human, from duplicating the action.
I've seen multiple instances of an order getting entered, a staffer clicking "activate" on the service to go ahead and provision it and either the cron was already running, or starts running while the staff-induced activation is still running and two services are setup, two activation emails are sent, but only one record exists in blesta so you end up with a totally orphaned service.
A simple fix for this is to use locks in the database during provisioning.

Perfect!
SolusVM is impacted as well.

Would love if we could get some traction on this.  It's stupid simple, and insanely annoying for customers.

with php 7.2, in cPanel module when adding server it return error
count(): Parameter must be an array or an object that implements Countable on line 72 in /home/xxxxxx/public_html/blesta/components/modules/cpanel/views/default/add_row.pdt a simple fix
$num_servers = count($this->Html->ifSet($vars->name_servers, []));  

No it wouldn't, since it uses similar syntax that's what really matters.  Blesta on the back-end would have some work to do but when changing libraries that will always be the case.  If it can be done with little to no impact to end users and how their templates are built then it can be done without customers noticing since templates wouldn't have to be updated.

Of course not, but I run my dev env. with debugging on and when this happens it's quite confusing as to thinking my code is broken, and of course preventing me from debugging errors of mine that are hit after this point.

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

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

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

Thank you Jonathan for providing us this great module

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

NameSilo Domain Module
This module is a complete solution for domain registrations and transfers through NameSilo.  This module builds upon and continues the work by @NETLINK.  He and I will be jointly contributing to this project and we welcome any other contributions on GitHub.
An old thread related to this plugin was at https://www.blesta.com/forums/index.php?/topic/3399-namesilo-plugin
Features
Domain registrations Domain transfers Supports all NameSilo-supported TLDs by dynamically listing the available ones to package creation Proper .us/.ca support with necessary fields on order forms NameSilo audits Sync service's renewal date with domain expiration date Register/manage nameservers/hosts Set/change nameservers Update WHOIS details Lock/unlock domain Retrieve EPP code DNSSEC management Check email validation & resend validation email if needed Toggle WHOIS privacy Manually extend registration Transfer status tracking Screenshots
Coming soon
Installation
https://github.com/knownhost/Blesta-Namesilo/blob/master/README.md
Upgrading
Nothing special is required except when updating from <1.8.0.  In this case see the "Other" section below.
Known Issues
A domain transfer can be ordered for more than 1 year.  NameSilo's API does not allow a transfer to extend more than one year so the extra years would be lost if not manually corrected.  I'm unsure of how we'll solve this at this point. Future Plans
Update for Blesta's new domain management system when release.  This will be the v2.0 milestone and will likely be mostly a rewrite of the module. Clean code and remove unnecessary code. Manually extending as an admin should support invoicing/queuing to post-payment.  We should be able to do this with the proration logic. DNSSEC management Implemented! Source
This module is fully open source and can be found on GitHub.  Two repos are kept fully updated with releases currently being built on the second:
https://github.com/knownhost/Blesta-Namesilo
https://github.com/NETLINK/Blesta-Namesilo
Download
I will make every effort to maintain the listing in the marketplace at https://marketplace.blesta.com/#/extensions/80-NameSilo Module
GitHub will always definitely be up-to-date: https://github.com/NETLINK/Blesta-Namesilo/releases
Other
The version 1.8.0 release is a major update building upon @NETLINK's work.  The new auditing features will not work properly until you "manage" and save your NameSilo account settings.  Everything else should be fully backwards-compatible.

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

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

The intent is to perform proration separately from a service edit, such as apart of a pricing presenter (which is what we had done in some places, like queued service changes, in v4.0), and overall decrease the number of separate actions that a service edit performs.

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.

Version 1.8.4 released.

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.

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

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