Max
-
Posts
283 -
Joined
-
Last visited
-
Days Won
6
Posts posted by Max
-
-
few developpers here including me will be able to create registrar modules, but for allow customers to edit DNS record, we will be creating form, tab in blesta customer area, but these form/table in fact should be created at the CORE and use blesta new api function in the purpose to map with registrar api to create/update DNS records.
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 ]; [....]} -
The install seems to only work with php 5.3 . Let me see if I can downgrade it
If you are using PHP 5.6 on the Blesta box, install a proper SSL certificate on https://server3.yatosha.com:2443/
-
Nope I don't need anything I'm stating that 4 out of the forum users isn't a lot see that poll from ModulesBakery there's a lot more active users. Yes they are important and yes they will be done but everyone thinks otherwise. I myself I don't care since Blesta works out of the box for most of my customers, and yes most of them sell domains and hosting and yes they are active on the forum too.
A poll under users that evaluated Blesta, but did not become a customer, would be more interesting.
-
oh yes, when you have resellers, you have to create/update so many invoices, because your reseller will not be renewing all services every month/year
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.
-
There's always ModulesBakery.
They charge reasonable development prices. I'm sure they'd be happy to develop an eNom module for you if you ask them to.
Or better yet, why not crowd-source the cost of the module development with ModulesBakery?
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.
-
I do agree on the domain front, however I think there are bigger features that take some precedence. One being a mass mailing feature, which is just down the road and affiliates which again is something coming in the next few versions.
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.
Not to mention there is a pretty extensible API to Blesta so you could look into adding the needed requirements for the domain module yourself.
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.Yeah for only 2 years in development from the launch date you can't expect it to be fully filled with features...
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. -
your request is something that need to be done in the next domain management module .
normally the domain management should have some universal command that should passed to any registrar class
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...
-
When payments originate from third-party sources Blesta doesn't have control over them. That's just the nature of the process. When Blesta constructs the form data that is sent to PayPal or any other nonmerchant gateway, it's (generally) treated more as a suggestion by the gateway that the user should pay the given amount.
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
General PaySquare exclusions; the following is in principle excluded, but might be considered after additional assessments and controls:
[...]
- Payment pages that do not use the PCI DSS compliant infrastructure of a certified Payment Service Provider;
- Payment pages that do not support the use of compliant security standards, such as but not limited to MasterCard SecureCode, Verified by Visa or J/Secure by JCB. These standards are also known as 3D Secure;
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:
-
Haha Post codes are mostly 6 digits LL46 2UN was an old one of mine, B49 6BE is my current one, no machine can mix a three letters for a post code. 1/2 letters three numbers and two letters.
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.
-
Who gives a dam in the UK? No-one and the royal mail use the "Post Code" that's all they use and the first line of the address.
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*
-
The ordering system of any dedicated servers provider is basically depending on this option, as there's no other way of making this work.
Actually, many bigger providers nowadays do not offer that many options anymore.
But limit it to the combinations that make the most sense like:
2x 2 TB SATA 7,200 RAID 1
2x 240 GB SSD RAID 1
4x 2 TB SATA 7,200 RAID 10
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.
-
I found this on a different forum
https://forum.vestacp.com/viewtopic.php?f=11&t=6760
Im using vestaCP
1) a2enmod remoteip
2) create an config file under /etc/apache2/mods-available named remoteip.conf
3)add the following lines
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 127.0.0.1 your.proxy.server.ip
4) link the file under /etc/apache2/mods-enabled
5) service apache2 restart
Step 4 im usure what he / she means.
I assumed he meant make a symbolic link. so i tried from the directory where I made the conf file...
ln -s remoteip.conf /etc/apache2/mods-enabled/remoteip.conf
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)?
-
/usr/local/apache/conf/userdata/std/2/USER/cp_php_magic_include_path.conf
That particular one seems to come from cPanel's broken "PHP Magic User Loader" add-on.
-
/usr/local/apache/conf/userdata/std/2/USER/cp_php_magic_include_path.conf. The solution was to comment out the line:
php_admin_value include_path ".:/usr/lib/php:/usr/local/lib/php:/home/USER/php"
Bug with PHP?
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:
- PauloV and Blesta Addons
-
2
-
Anyway as it's not possible to change numbering scheme during the year, by not accepting all types of numbering scheems, Blesta is refusing customers who have to wait for the beginning of the next year before changîg software.
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.
-
Hey there,
After configuring Mollie, it seems that the payment methods are not popping up. It simply states "Mollie" as payment method, instead of the various enabled payment methods, such as iDeal/PayPal. (http://d.pr/i/1lCzh)
That is normal.
Blesta only supports a single entry per module, so cannot have more options on that particular page.
If you select "Mollie" the payment fails. Below is a screenshot of what's logged in the Blesta Logging.
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 ?
-
For the number padding, I haven't found an official docment that states that it's obligatory, in 2007 our accountant told us we had to choose the right number of digits corresponding to roughly our sales estimates + 1 or 2 zeros.
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... :-)
-
How are we meant to know if the person who is signing up is a business or a consumer until they sign up (ie enter that information)?
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?
How do we know what vat rate to charge them until they enter their country?
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....
-
Depends which country in Europe your operating from. Each country has different rules regarding VAT.
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.
Article 6
Information requirements for distance and off-premises contracts
1. Before the consumer is bound by a distance or off-premises contract, or any corresponding offer, the trader shall provide the consumer with the following information in a clear and comprehensible manner:
(a) the main characteristics of the goods or services, to the extent appropriate to the medium and to the goods or services;
(b ) the identity of the trader, such as his trading name;
© the geographical address at which the trader is established and the trader’s telephone number, fax number and e-mail address, where available, to enable the consumer to contact the trader quickly and communicate with him efficiently and, where applicable, the geographical address and identity of the trader on whose behalf he is acting;
(d) if different from the address provided in accordance with point ©, the geographical address of the place of business of the trader, and, where applicable, that of the trader on whose behalf he is acting, where the consumer can address any complaints;
(e) the total price of the goods or services inclusive of taxes, or where the nature of the goods or services is such that the price cannot reasonably be calculated in advance, the manner in which the price is to be calculated, as well as, where applicable, all additional freight, delivery or postal charges and any other costs or, where those charges cannot reasonably be calculated in advance, the fact that such additional charges may be payable. In the case of a contract of indeterminate duration or a contract containing a subscription, the total price shall include the total costs per billing period. Where such contracts are charged at a fixed rate, the total price shall also mean the total monthly costs. Where the total costs cannot be reasonably calculated in advance, the manner in which the price is to be calculated shall be provided;
(f) the cost of using the means of distance communication for the conclusion of the contract where that cost is calculated other than at the basic rate;
(g) the arrangements for payment, delivery, performance, the time by which the trader undertakes to deliver the goods or to perform the services and, where applicable, the trader’s complaint handling policy;
(h) where a right of withdrawal exists, the conditions, time limit and procedures for exercising that right in accordance with Article 11(1), as well as the model withdrawal form set out in Annex I( b );
(i) where applicable, that the consumer will have to bear the cost of returning the goods in case of withdrawal and, for distance contracts, if the goods, by their nature, cannot normally be returned by post, the cost of returning the goods;
(j) that, if the consumer exercises the right of withdrawal after having made a request in accordance with Article 7(3) or Article 8(8), the consumer shall be liable to pay the trader reasonable costs in accordance with Article 14(3);
(k) where a right of withdrawal is not provided for in accordance with Article 16, the information that the consumer will not benefit from a right of withdrawal or, where applicable, the circumstances under which the consumer loses his right of withdrawal;
(l) a reminder of the existence of a legal guarantee of conformity for goods;
(m) where applicable, the existence and the conditions of after sale customer assistance, after-sales services and commercial guarantees;
(n) the existence of relevant codes of conduct, as defined in point (f) of Article 2 of Directive 2005/29/EC, and how copies of them can be obtained, where applicable;
(o) the duration of the contract, where applicable, or, if the contract is of indeterminate duration or is to be extended automatically, the conditions for terminating the contract;
(p) where applicable, the minimum duration of the consumer’s obligations under the contract;
(q) where applicable, the existence and the conditions of deposits or other financial guarantees to be paid or provided by the consumer at the request of the trader;
® where applicable, the functionality, including applicable technical protection measures, of digital content;
(s) where applicable, any relevant interoperability of digital content with hardware and software that the trader is aware of or can reasonably be expected to have been aware of;
(t) where applicable, the possibility of having recourse to an out-of-court complaint and redress mechanism, to which the trader is subject, and the methods for having access to it.
2. Paragraph 1 shall also apply to contracts for the supply of water, gas or electricity, where they are not put up for sale in a limited volume or set quantity, of district heating or of digital content which is not supplied on a tangible medium.
3. In the case of a public auction, the information referred to in points ( (b ), © and (d) of paragraph 1 may be replaced by the equivalent details for the auctioneer.
4. The information referred to in points (h), (i) and (j) of paragraph 1 may be provided by means of the model instructions on withdrawal set out in Annex I(A). The trader shall have fulfilled the information requirements laid down in points (h), (i) and (j) of paragraph 1 if he has supplied these instructions to the consumer, correctly filled in.
5. The information referred to in paragraph 1 shall form an integral part of the distance or off-premises contract and shall not be altered unless the contracting parties expressly agree otherwise.
6. If the trader has not complied with the information requirements on additional charges or other costs as referred to in point (e) of paragraph 1, or on the costs of returning the goods as referred to in point (i) of paragraph 1, the consumer shall not bear those charges or costs.
7. Member States may maintain or introduce in their national law language requirements regarding the contractual information, so as to ensure that such information is easily understood by the consumer.
8. The information requirements laid down in this Directive are in addition to information requirements contained in Directive 2006/123/EC and Directive 2000/31/EC and do not prevent Member States from imposing additional information requirements in accordance with those Directives.
Without prejudice to the first subparagraph, if a provision of Directive 2006/123/EC or Directive 2000/31/EC on the content and the manner in which the information is to be provided conflicts with a provision of this Directive, the provision of this Directive shall prevail.
9. As regards compliance with the information requirements laid down in this Chapter, the burden of proof shall be on the trader.
-
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.
Partial Refund Support
in Feature Requests
Posted
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.