Max

Create a credit note (invoice with negative amount to be refunded, and same VAT percentage as original invoice), and apply the partial refund against that. Shouldn't require a db scheme change, only getting rid of the rule that disallows negative amounts in your invoice model.

Yes, and not just for domain modules, but also for all other modules. It should not be the module's task to create an user interface, unless the module has special needs. With another billing software package, modules can just inherit a common class for that product type and specify which of the common fields they use: Much less duplication than requiring each module to have its own add_row/edit_row/manage views and a language file with pretty much the same strings. class MyModule extends HostingModule{ protected $description = "My module"; protected $serverFields = [ 'ip' => true, 'username' => true, 'password' => true, 'ssl' => false, 'status_url' => false, 'hostname' => false, 'maxaccounts' => false, 'hash' => false ]; [....]}

If you are using PHP 5.6 on the Blesta box, install a proper SSL certificate on https://server3.yatosha.com:2443/

A poll under users that evaluated Blesta, but did not become a customer, would be more interesting.

Maybe have separate pro-forma invoices -as voluntary offer to the customer to renew a service-, but do generate a single final invoice if multiple proformas are paid together? Or a single proforma with a link to a page where the customer can change which items to renew. Do note that some accountancy firms charge per invoice booked. So having too many separate ones is not desirable for business clients either.

Why should a customer have to cough up these development costs, when Blesta itself advertises eNom support on their front page? There aren't any "only works with .com and .net domains, not with .co.uk, .eu, .ca, etc." restrictions listed there, are there? Doing your own development make senses if you want a registrar not already supported, or an exotic feature. It shouldn't be necessary for core functionality.

Can imagine that for UK businesses, the ability to register a .co.uk domain may be a tiny bit more important, than having a mailing list. That said, you might want to ask eNom why they still require this particular field though. Nominet (the .uk registry, of which eNom is a reseller), no longer has a hard requirement on having that information, and made it optional. See the EPP spec: http://registrars.nominet.org.uk/namespace/uk/registration-and-domain-management/epp-commands#create "The schema http://www.nominet.org.uk/epp/xml/contact-nom-ext-1.0 can be used to specify optional account fields." They do are pretty strict about the information you do send them. Once had a customer who was ordering as private individual, and put in a "-" as company name instead of leaving the "company" name blank. Got his domain suspended by Nominet's burocrats because company "-" did not exist in the company name databases they cross-check against. I do disagree with that. Blesta needs better core functionality before any third-party can write proper domain modules for that. Certain domain extensions do require extra fields, and a proper mechanism to ask the user for extra information would be helpful. E.g. where domain modules extend a base class that knows what information the major extensions need, and handles prompting the user for that, instead of requiring every domain module to define its own forms, and have its own strings (which is burdensome if you want to translate them). As well as that Blesta should check the availability of multiple domains with a single function call, instead of making multiple calls, resulting in a seperate connection being made for each domain to check. With all due respect, Blesta 3 has been in development since at least 2011, when they ran "buy Blesta 2, get Blesta 3 when it lands, really soon now" style advertising. And it's still lacking essential functionality, especially for hosting companies outside the USA, of which this thread is yet another example.

But DNS entry management -unlike the other things you list- is normally not handled by a registrar module, but by an independent one. One could have different backends for that. Recall the competition has a module to create DNS entries on a cPanel server, and one that creates database entries to be used by a standalone PowerDNS server.

Updated the module Changelog NOC-PS module v0.4 Fixes running tasks under crontab (was being terminated, because the module attempted to add a log entry with empty $url parameter) Now uses json-rpc instead of xml-rpc to communicate with server. Removes dependency on Zend framework components. Option to enable/disable validation of the SSL certificate of the server. Allow black- and white listing of profiles on a per package basis. E.g. disallow installation of Windows, unless customer bought a Windows server. Adds WHMCS import file. Adds new simplified "start rescue system" screen, showing only the rescue system profiles. Booting a rescue system profile was previously already possible through the normal "provision" window, but customers did not look for them there...

Form posts are great if you want to have a "donate by Paypal" button on your static website. But the majority of non-merchant gateways also offer APIs nowadays that work like this: 1) call their webservice first to register the transaction with the amount, currency, description, status callback url, etc. 2) receive a URL like http s://payment-service-provider/b2990dac-ff0a-11e4-bd29-00270e120a22 back to redirect the user to. Nothing that the user can change that way. And the user doesn't have to click on a form submit button first, you can just HTTP redirect them to the payment page.

In many European countries using merchant gateways is problematic. Banks are more strict about PCI compliance, and require you to explain yourself to them if you want to collect card details yourself. E.g. from the acceptance criteria used by Dutch banks: http://www.paysquare.eu/en/Images/Acceptance_Policy_tcm71-11266.pdf Most companies (even bigger ones) prefer not to go through those "additional assessments" and use a payment page provided by a certified non-merchant gateway instead. Problem is that Blesta currently displays the name of the non-merchant gateway in the "payment options" section on the order page, while it would be nicer if it displayed the payment method like "Credit card" instead. Also many non-merchant gateways offer more payment options than just credit cards, so it would be nice if a single non-merchant gateway could have more than one entry in the payment options section. == Ideally it would also be nice if it was possible to add extra fields to the payment option section. E.g. some payment methods require the user to select his bank from a list, and it would be nice if that could be done straight away on the page you select the payment method, instead of on a separate page. What we have in our current system, for reference:

In The Netherlands postal codes are in the format "1234 AB" That doesn't prevent the system from getting confused if there are additional character codes added to the address though. I know, because the postal services here attach a sticker like this to your mail if delivery has been delayed, because it had to be manually processed: Occasionally receive those on mailings from the USA, where the sender's software added some kind of invented state code (like XX) to the address on the same line as the postal code. The sticker suggests you contact the sender and tell him to put a properly formatted address on the envelop next time.

Yes, the automated sorting systems of the post offices in most countries scan for anything that looks like a postal code in the adress. Which can a problem if there is some kind of weird 3 character code taken from that ISO standard for political subdivisions (that has nothing to do with postal mail addressing) that looks a bit similar to a postal code in it... *mumbles something about a 2013 feature request for configurable international adress formats per country*

Actually, many bigger providers nowadays do not offer that many options anymore. But limit it to the combinations that make the most sense like: Personally I really wouldn't offer unreliable configurations like RAID 0 as a standard option. Same with things like partition layouts. The default is fine for 99% of the customers. The others can contact support and explain their wishes there, not on the order form. Field logic would still be useful for other things though. E.g. selling software licenses available for the OS selected.

The target is not relative to the current working directory, but to the link. So with your command you are making it point to itself, which will not work as intended. Try instead: ln -sf ../mods-available/remoteip.conf /etc/apache2/mods-enabled/remoteip.conf Pretty sure a2enmod also creates the link though, provided remoteip.conf exists. So might be easier to swap step 1 and 2. Create remoteip.conf first, then run a2enmod... Also check your nginx config and verify that the client IP is passed through X-Forwarded-For matching the Apache configuration you quote (and not some other header like X-Client-IP)

Using a reverse proxy setup (e.g. nginx in front of Apache)?

That particular one seems to come from cPanel's broken "PHP Magic User Loader" add-on. https://forums.cpanel.net/threads/fatal-error-cannot-redeclare-_pear_call_destructors-previously-declared.123693/#post-552541

No, not a bug in PHP itself. By design PHP made "php_value" overridable by code, "php_admin_value" not. The question however is which package added that config file, which is using the php_admin_value directive, where they should be using php_value. And main problem with CentOS is that CentOS itself tend to only have older versions of software, so people resort to using third party repositories, and often more than one. Which complicates finding the problem even more.

If you choose to charge the customer different (inclusive VAT) prices depending on location (as opposed to absorbing VAT differences yourself, which should also be a configurable option), the customer should be able to just select his country. Fine if it defaults to your own home location, or one determined by geo-ip, but the customer should be able to change it with 2 clicks, instead of requiring him to jump through hoops like registration. Example from a big European hosting company: Another one:

That may be something specific to France as well. My own country does allow you to have multiple series of invoice numbers, as long as the invoice numbers are sequential within one series. Mainly meant for situations where you have multiple branches, or multiple employees doing work on location (plumbers etc.), that need to be able to (hand) write invoices independently. But could be argued that a separate independent webshop is a valid reason as well.

That is normal. Blesta only supports a single entry per module, so cannot have more options on that particular page. Seems to be a known bug in the Omnipay Mollie module. Can you check if making the following change fixes that: https://github.com/thephpleague/omnipay-mollie/pull/14/files ?

Think that may have been a "requirement" of your accountant, rather than an official one. Some do prefer leading zeroes in the filename of .pdf invoices. So that when you save them all to a folder, and sort on file name, they sort correctly... :-)

If you target both, you must at least display the price inclusive VAT. Although you do are allowed to display both the price excluding and including simultanously. Have you ever seen prices excluding VAT in a brick-and-mortar shop in the EU that caters to consumers? Why do webhosters think things are different online? We charge consumers the same total price inclusive VAT, regardless where they live. That the VAT rate differs is not their problem, it is ours. If they live in a country with a higher rate than the Netherlands we pay more VAT and have slightly less gross turnover, if they live in a country that has a lower percentage we make a little more. It all evens out, and we do not gain or lose from it. But if you do not want to do that, you are free to prompt the customer for his country the moment he enters your site. No need to wait for that until he registers, you don't need his full address for it....

If you are in Switzerland -which is in Europe, but not part of the European Union- you can have your own rules. But for the 28 countries that do are part of the European Union that is simply not the case. All EU directives have to be implemented into the local laws of all EU member states. Your country can essentially have more rules, but not less. And displaying pricing inclusive all taxes -when selling to consumers, not being companies- is definitely a hard requirement demanded by the EU consumer protection directive. DIRECTIVE 2011/83/EU OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 October 2011 on consumer rights

Beware that the abbreviation "ACH" is not used outside the USA, so may lead to confusion. Calling it "direct debit" is more common internationally. That involves PULLing money from customer's account, and I don't think that is what the TS means. "bank transfer" more commonly refers to a wire transfer from one bank account to another. The customer initiates those through his own bank (e.g. via Internet banking), and pushes the money to your account number. You would be using the "offline payment" gateway in Blesta to process those manually. And no, I don't think there is an option right now, to configure different payment methods/gateways per customer.