Leaderboard

Unfortunately there is no feature to translate multiple at a time, or to accept contributions uploaded separately from the translator itself. I would imagine that it would take about the same amount of time, or less, to go through each definition in the Translator as it would be to update text files manually. Manually, you would need to duplicate all language files, place them in their approprate directories, and make sure you don't create any syntax errors while updating any of the 100s of files, while also ensuring you haven't missed any. And when updates to Blesta come out, you'd need to merge the changes and add/update/remove some of the definitions. That sounds time consuming. I think we have plans to use Google to translate the language definitions for all languages, and allow users to update them for accuracy through the Translator. That way, all languages would be 100% translated, and for example, your language would be at least 13% accurate. I like your upload idea, though. Curious what others think.

Hi, Blesta only has been translated to my language for 13% so I am eager to help, I translated other solutions so I thought it would be again using a code editor and downloading the language files straight on the server, zipping them and uploading them somewhere, However there seems to be an entire blesta translation project going on; nice idea! However, it's taking me several times as long as editing straight in the files because the page has to load after each sentence/word. My question: - If I translate the language files via my editor, can I somehow upload them into the translate project for others to improve? - Is it possible to get 20/30 sentences/words shown at the same time? I really wanna help translate blesta but I find this way very time consuming and not very productive...

Please note! We have extended the contest to June 22nd. Not everyone has had a chance to upgrade to Blesta 3.2 yet, and we need more entries. Tell your friends!

Yup. I remember thinking, "what a ridiculous thing." WHMCS also has a "feature" that allows you to change the currency of all previously submitted transactions by changing the client's currency.

You are required to do PCI scans because card data touches the server, even though it is not stored. The proposed stripe.js implementation passes the card details directly to Stripe so they don't technically go through your server. In that case, you wouldn't have to do the scans at the moment. We have not implemented the stripe.js method yet. Since your server renders the markup, I believe even stripe.js implementations will be required to do PCI scans in the future. It's a sort of loophole that I expect they will close before long. (If your server was compromised, an attacker could alter the javascript and intercept the card details anyway) So, short answer. Yes, you should do PCI scans

Please add the tlds to /components/modules/namecheap/config/namecheap.php

Blesta will not store the card number in that case. Blesta has to store some card information, though. This includes the card type, last 4 of the card, and expiration date. This is required so that Blesta can send card expiration notices to clients, identify the card to the user for proper selection, and process refunds and voids.

I agree the Google translations aren't very good for the most part, but there seems to be a high demand for having them anyway, and we can make them available for those that want it. It sounds like you're thinking of it in terms of options, which is what I would like to see as well. Whether to include/exclude Google translations when downloading a language could be one of those options. However, time has not permitted us to improve the translator that much yet.

If you check "Store Card Information Offsite" when configuring Strip in Blesta, Blesta will not store card details locally. You must enforce the HTTPS protocol. An SSL cert itself is useless if you're not forcing people to use it. See Forcing HTTPS in the User Manual. You still need to perform PCI compliance scans if you accept credit card payments. The only way you can get around that is if you only use non-merchant gateways (paypal, skrill, etc.).

That merely tests your SSL settings, not the rest of your server. Need a quarterly scan from an approved provider from this list: https://www.pcisecuritystandards.org/approved_companies_providers/approved_scanning_vendors.php Starts at around $ 250 / year (Comodo)

From that site: Stripe.js is not used, nor is Checkout. The payment information is not transmitted directly to Stripe's servers, but it is transmitted indirectly to them through your servers instead. This has the consequence that your servers are the ones needing quarterly security testing. And you need to be able to answer "yes" to at least all the questions on: https://www.pcisecuritystandards.org/documents/pci_saq_c_v2.doc (and if you take the definition of "storing card holder data" literally these: https://www.pcisecuritystandards.org/documents/pci_saq_d_v2.doc ) Note that if you are processing a low number of transactions, compliance validation is not required, meaning your credit card processor is not required to ask you to submit proof that you actually did the testing or completed the SAQ. You still have to be in compliance though, meaning you can get into trouble if there is an incident, and it turns out you "forgot" to do them.

Man, I hope they don't kill LogicBoxes platform...so many decent registrars use it...like NetEarthOne...

Directi sold out to EIG: - ResellerClub - Big Rock - LogicBoxes And more are EIG now. http://www.thewhir.com/web-hosting-news/endurance-international-group-completes-directi-acquisition-expanding-indian-presence

No worries, if I set it up that way intentionally I forgot my reasoning.. so might as well be open!

Any updates on the how to? When I activate it and then add a menu link to the page, all it does is say "Blesta Access" without loading anything else.

I'm up to give it a +1. Anything to help Blesta get more audience.

I must admit I am shocked this is not clearly stated on the main pages of Blesta's website. I've just spent 2 hours looking through features and comparing Blesta with WHMCS and I was so close to making the switch until I discovered this thread. Having the choice to use Stripe.js is a must have feature I am afraid. I hope you can implement this change ASAP and rescue lots of unsuspecting users.

The domain plugin belongs to CORE-818. I've added a note to the task regarding domain privacy. The plugin would likely give the client the ability to disable and re-enable privacy protection as is often necessary (when purchasing an SSL certificate that requires verification for example). The price and ability to purchase the privacy protection would likely be set up through a configurable option, and the module / plugin would provision it automatically.

I think we're missing the point here: there are a potentially high number of people using this plugin thinking that it doesn't contact the card numbers at all, when it actually does. These people need to be informed of this so they can make informed decisions about what to do next - be it PCI compliance or a plugin / gateway / software change.

Server is properly configured -> PCI compliance. My issue is that there is nothing that makes it clear to users that Blesta's Stripe integration doesn't support full no-contact with card details. As a result, there will be people (like I almost did, and like others on this post) who are preparing to or have already implemented this in live environments without filling out the necessary PCI questionnaire (which you can avoid if you don't touch the details) and without any idea that their regular hosting environments aren't good enough for it. That is where the compliance rules are being broken, and people are becoming liable for fines. These people need to know the exact spec of the plugin so they can make informed decisions about how to use it.

I'm certainly keeping a very close eye on this thread.. I have been using stripe so I'm not very sure what to do now. I, like everyone else didn't realize tokenized transmission wasn't supported.

I'd like to add a vote here. We've recently signed up with Stripe and was about to launch it as a payment gateway. So glad we didn't. I think this might be worth sending an email to all clients about or at least adding to the docs. I'd imagine there are a lot of people who are non-compliant as a result of this.

From business point of view I would prefer getting money first and worry about the details (CSR) later.