Paul

naja7host is right here, are you certain the plugin directory is named myplugin? /plugins/myplugin/ /plugins/myplugin/myplugin_plugin.php ...

Blesta uses AES-256 for encrypting service meta data.

If the user changes their password in cPanel then it won't work because Blesta doesn't have the right password. We need to use their new API for single sign on to improve this.

Looks great, and I like your theme

We are looking at a free domain option, it seems to be a very popular feature. Question about this for everyone. Do you offer just the first year free, or is it free as long as the hosting account is active? What are the requirements to get a free domain? We have it designed so that ID Protect, Email Forwarding, and DNS management would be TLD independent.. but you could not charge more or less depending on Register, Renew, Transfer. We would have to create a new order form that works with the Domain Manager. Awesome! Yes, close. There are some issues with the minPHP 1.0 bridge that we have to resolve. Some issues were not readily apparent. A couple features are not quite going to be ready for Beta 1 but will come by Beta 2 or 3.

Great! I would suggest downloading and installing the free trial if you haven't already. The demo is a little out of date, and installing the free trial will set up a private environment you can fully test. www.blesta.com for download link and install docs.

I'm not saying there won't be some way to convert existing domains over, just that we have not considered that yet. Thanks for your feedback, I'll look into seeing what would be necessary to combine invoices if we go with this method. TLDs each have their own rules about when a domain should be renewed. This means that for people who bill for services 5 days in advance, this may be unacceptable for some of their domains. Additionally, Blesta services renew until cancelled. For domains, customers may want to disable auto renew and renew their domains manually, or add additional years. This makes forcing domains into services very difficult. Do you see any problems with treating domains separate from services, other than importing existing domains into the new domain manager? If you can import them all over, does that solve the issue?

If you don't define a price for the other years, they won't be available to select. Still, it may be a good idea to define renew prices for those years even if you don't for new domains. If I have a domain that is paid up for 6 years, I might want to add 4 more to max it out. The templates would exist, however the way we are looking at it is that the reminder interval will be defined for each domain. This will be pulled in from somewhere, either by the module, or an option for the TLD. So, if there are no reminder intervals defined, no reminders will be sent.

Yes, you can certainly do that. Mike mentions putting the quantity to 8, but this won't accomplish what you want which is to send the unique credentials to the user. If you create 8 packages with a quantity available of 1 you can accomplish this. The user will see 8 possible packages during checkout though, which might be confusing. After the packages are ordered, mark them as inactive.

By default no, existing domains would work as they do now. In terms of a migration utility, it's too early to say though that would definitely be a nice to have. With the domain sync option, it probably wouldn't be too difficult to migrate current domains, but I don't know what exactly would be involved in that yet. We will provide more information about this at a later time.

Awesome, thanks for the feedback! Yes, EPP code request for bulk actions, forgot to mention that. A question I forgot to ask, and maybe there will be varying opinions on this, but do you expect customers to be locked in to the same renew price? For example, if you update the renew price from say $14/year for .com to $15/year, should this apply to all renewals or only new customer renewals? I could be wrong, but in my research it seems as though most applications will charge the price in the price matrix and not lock the customer in. This is perhaps more often the case in the domain business because price hikes from ICANN or the TLD registries must be passed along due to thin margins.

We are in the process of fully spec'ing out the Domain Manager plugin for 4.1 and would love your feedback. I want to give you a basic overview of what we're considering for the Domain Manager, and get your feedback. We want to resolve the current issues and frustrations with how domains are currently handled. Please understand that the new domain system may not include everything in the first release, but our goal is to build the proper foundation so that it can easily be improved upon in the future. What is the Domain Manager? The Domain Manager is a plugin that will be responsible for all things domain related. Think of the Order System, and the Support Manager which cover all things related to orders, and support, respectively. How will I define pricing? A pricing grid will exist, likely under Domains > TLD Pricing where the price can be set for each TLD for 1 through 10 years for Register, Renew, and Transfer. This will provide a simple pricing grid, with different price options for Register, Renew, and Transfer. Additionally, special pricing can be set on a Client Group level, which will override the default pricing. Additionally, domain extras like ID Protect, Email Forwarding, and DNS Management will be options on a per-TLD basis and pricing can be set for these. The customer would be able to check if they want these options during checkout. Question: Is it sufficient to have a single price of ID Protect, Email Forwarding, and DNS Management for all TLDs, or would you want the ability to set a different price for these extra options on each TLD? Are domains services? This is a question that has resulted in much debate internally. My personal thoughts are that domains are very unique and do not easily fit with services. I am proposing that domains be treated completely separately from services. This means there would be a separate table in the database that stores domains and information unique to domains like: Domain Name, Registrar, Status, Date Registered, Date Expires, Management Features Available, Expiration/Renewal Reminders, Last Sync Date, and whether to Auto Renew or not. If domains are not services, they will not be listed with services. For the Staff area, I propose a new Domains widget on client profile pages. For the client area, I propose a new primary nav link called Domains. The Domain Manager would be responsible for renewing domains, and invoicing for them and services and domains would not appear on the same invoices, even if they are billed on the same day. Question: What are your thoughts on domains not being considered services? What about email templates? The domain manager would create several new email templates, likely to include the following: Domain Registration, Domain Transfer Initiated, Domain Transferred, Domain Renewed, Domain Expired, Domain Renewal Notice (domains listed are going to expire in the next x days). What about automatic things? The Domain Manager would be responsible for the following Automation Tasks: Send expiration emails at the reminder intervals Renew domains that are set to automatically renew Synchronize renew dates with the registrar at a given interval What about Registrar Modules? The Domain Manager would implement its own module system, and existing registrar modules would not be compatible. The new registrar module system would be drop-in similar to the existing, but these would be enabled and configured under Domains > Registrars. New registrar modules would likely be more lightweight than current registrar modules as the plugin would implement the common features across registrars. What management features would be available? This will depend on the specific registrar module, but the following features would be supported: Register, Transfer, Renew Domain (obviously) with Renew Domain being an option for Clients and Staff Manage DNS for Domain (Get, Update DNS zone records if DNS hosted by registrar) Manage Registrar Lock for Domain (Enable, Disable registrar lock) Manage Email Forwarding for Domain Manage ID Protection for domain (Enable, Disable ID Protection) Manage Contacts for Domain Whois (Registrant, Admin, Tech) Update Name Servers for Domain (Get Name Servers, Update Name Servers) Register Name Servers (Unsupported by many registrars or not commonly done by average users, may be optional for first release) What about existing registrar modules? Existing registrar modules would be incompatible with the Domain Manager plugin. However, services using current domain registrar modules will continue to work as they do now. Any bulk features? We plan to have bulk features for both Staff and Clients. For Staff, under Domains > Browse Domains and under the Client Profile, Domains Widget. For Clients, under the Domains page. Bulk editing/tasks would work similar to selecting invoices for delivery with a checkbox on the left and some options to choose from like Renew Domain, Manage ID Protection, Domain Lock, Name Servers. I'm certain I'm missing something, but wanted to give you a rough overview of what we are planning and get your feedback. Please let us know what you think!

@PauloV @naja7host @timnboys <- One of these guys may be able to help you.

So if you change your PHP mail settings back to PHP Mail, then email piping works again? These are unrelated and one should have no impact on the other. With piping, an email forwarder needs to be set up on your server to send email to Blesta directly. Mike mentioned a configuration where you are checking email via cron every 5 minutes using IMAP. IMAP/POP and Piping are 2 separate methods for fetching tickets. If you have Blesta configured for piping, and you send an email to the department, you should get some kind of response. Either a reply from the support system, or a bounce from the server if it's unable to pipe the email to Blesta. See https://docs.blesta.com/display/user/Support+Manager#SupportManager-email-pipingEmailPiping for docs on email piping to make sure you have it configured properly.

Automating this by pulling from a pool of credentials would require a simple module. Doing it in the way Mike describes, requires staff to manually enter the information before accepting the order. With a module, you could pull these credentials out of MySQL or a text file and provision automatically. So, the answer is, out of the box you can but you have to manually enter the credentials before approving the order. To do so automatically, you need a simple custom module. There are some developers on the forums here that can help you out with a custom module for probably not too much if you want to go that route.

While the path to the order form doesn't seem logical at first, it really is. The path tells Blesta exactly what it needs to render the right page. For example, since Blesta supports unlimited order forms instead of just one, the label for the order form is included in the path. It would be nice to have shorter URLs in places though, and I see what you're saying. Information on linking to a specific package can be found at https://docs.blesta.com/display/user/Order+System#OrderSystem-LinkingtoOrderPages but I don't believe this will work when using a Domain & Other order type that starts with a domain. It's likely there will be a new domain order form type with the new domain manager.

Very nice work! Looks really good.

CORE-2250 Thanks

Email piping for the support system and using SMTP for outgoing mail are completely separate and should not affect each other in any way, except that all outbound email, including that of the support system, would use SMTP for outgoing mail. If SMTP is not working for the support system, it shouldn't be working for any email. Double check that your credentials are correct and that the necessary ports are open at your firewall.

It would probably be a good idea to disable the pay button on click so that it cannot be clicked more than once.

See CORE-2249. This has been requested before as well, but an excellent idea.

Which IRC client do you prefer?

This is a very odd issue indeed. It likely points to a javascript error. This could be because of some custom plugin, or code modification, or something on the web server interferring. Even more odd that it works in some browsers and not others. Perhaps some browsers handle the javascript errors different. I'd inspect the page in your browser, reload and check the Network > XHR (In Chrome anyway) and see if the widgets are being returned, and if there are any errors.

What version of MySQL are you running? This came up before here - The error code normally indicates an SQL syntax error according to MySQL, but I'm not sure that's entirely accurate. This other user installed on a different machine and moved the database. If you install on a different machine and move it, just follow the Moving Blesta guide.

Is this what you're looking for? CORE-2212