mrrsm

You need to apply the blesta hotfix for php 7.1 that was included in the blesta files you can download.

Will there be an easy way to migrate from the NETLINK/KnownHost modules to the Blesta official one? Edit: Now that I wrote this I am guessing it will just overwrite the same directory and just work.

Is there a reason it has to be a dropdown and not an input tagged as numeric and validated? If there aren't technical limitations to arbitrary lengths why limit it? Just default the number to something reasonable (30 days maybe).

1) Lightsail doesn't have a module built already but it seems like something fairly easy to create a module for. You could even potentially use the universal module to call some scripts that manage it for you. 2) Domains are okay on a small/cursory level. The basics work (registration/renewal) but are a bit rough around the edges on the admin side of things. 3) The forum is just Invision Community, if you email address has issues that is strange but it doesn't really reflect much on Blesta as a piece of software.

Assuming you purchased an owned license directly from Blesta you are entitled to 1 dev license to use only on a non production system. If you did purchase an owned license directly from Blesta just open a support ticket and they will get you setup.

If you haven't used it in that long there is a good chance you need to re-provision your license. You are usually able to do that in your client dashboard where you manage your license. As you said it is an owned lifetime license this will be on your blesta account page.

Owned lifetime licenses can only be purchased from Blesta directly.

4 days ago you said Are you selling an owned lifetime license still? If you are selling it at full price why would anyone want to buy it from you rather then just purchasing it directly? If you are selling it for less you should put an asking price for people to start negotiations with you. If the license is no longer for sale you should state that and have the topic closed.

I feel like most php web applications don't ship a docker container as there are plenty of dedicated hosting setups for php. I also think that it has to do with the fact people are very set in how they like to mange their setups. Either using nginx+php-fpm, apache+mod-php, or some other combo. After that you need to setup your web server with the appropriate ssl values as well as anything else which may be specific to your deployment requirements. This makes it not an easy task for the developer of the application to ship a docker image that works for most people. On top of that, Blesta seems to have a very limited team size. Having something to maintain outside of the application itself would probably make many people a bit irritated as there are many features that have been promised and not yet delivered.

As the module is opensource under the MIT license I will either maintain it myself or pay someone to maintain it for me if it stops working. There are many things I want Blesta to do that aren't building modules that currently exist.

The community module works great. There isn't much need to have an official one when the community one is free and maintained.

Lines 901 and 904 of vultur.php are not using the new method calls to getModuleRow which causes them to error out as they try to directly access a private member of their parent class. // Get the available templates $templates = $this->getTemplates($this->module_row, $package); // Get the available locations $locations = $this->getLocations($this->module_row, $package); They should probably look more like // Get the available templates $templates = $this->getTemplates($this->getModuleRow($package->module_row), $package); // Get the available locations $locations = $this->getLocations($this->getModuleRow($package->module_row), $package); At least based on the other modules I looked at

You would need whatever program you are trying to sell license keys for to integrate with the Blesta License Manager. The keys are provisioned right away and sent to the user. If you are doing a PHP application you should have 0 issues with it. If you aren't using PHP this is not an easy task as they do some things with keys that won't work in other programming languages (as of the last time I looked at it).

It looks like almost any module that accepts a hostname uses that check to validate it. PHP offers FILTER_VALIDATE_DOMAIN that you can use with filter_var to check a hostname (along with the flag FILTER_FLAG_HOSTNAME in php 7+) which which would provide a more robust checking mechanism. This still would have issues with internationalized domain names but covers a large majority of cases. On the other hand if you fix this yourself, adding support for IDN's would be something nice as well as they seem to be gaining popularity.

If you aren't planning on making changes to the license manager itself it is unlikely you will be able to make a client plugin in a different language. The main thing that will cause troubles is signing with the public key. I mentioned this in another question about a java client.

It's less of a bridge more of an extremely simple SSO.

If you are using the module as is that is the only part that is really stopping you from using a different license server. Once the public key is pulled/saved it becomes a bit harder to switch as well unless you are clearing the locally stored info.

The private key is the rsa private key that is saved on the server side. They are just doing something strange by signing with the public key in the client. I'm hoping someone on the Blesta end can shed some light onto why it is done this way as most libraries won't let you do this. This is the stackexchange post I found about signing with a public key for whatever, if anything, it is worth https://crypto.stackexchange.com/questions/2768/signing-with-public-key

Hey @NETLINK, I would be happy to make a PR to add the change for pulling/caching all the available extensions from namesilo. As long as you plan on merging PR's I'm happy to contribute. @Lucas you should be able to overwrite it as it is just an update to the same module.

This is quite confusing as technically this is frowned upon though the security library they are using seems to let them do it. Most other languages won't let you sign things with the public key which will make it very hard to mimic in another language from what I can tell. Maybe a dev can comment on the code because the comment on the function is different from what the parameters and code is doing. /** * Signs the given data using RSA signature with the provided private key * * @param string $data Data to be signed. A hash of this data will automatically be computed and the hash signed. * @param string $public_key The public key to use to sign the data * @param string $hmac_key The key used to compute the HMAC hash, if null will only compute a normal hash of the data * @param string $hash The hash to use (md5, sha1, sha256, sha512, etc.) * @return string The signature of the $data in base64 format */

12/monthly would mean bill every 12 months (which is yearly). You would want to set it up a 1 monthly which means bill every month. I am not sure if there is a way to add an end date effectively for it to stop billing after a year.

From what I see the renew date as displayed to the customer need to be the date the next invoice is due. If they currently have an invoice for that package it should be that invoces due date (even if it is passed). I also agree with you that it should keep billing even if they don't pay it but it should show the date in the past (possably in red and bold) showing them it is overdue.

It looks good to me, not too distracting but it is one of the first things I see and look at and then can easily dismiss on subsequent page views.

I think the banner is a great idea as it actually draws your attention so people see it. At the same time you don't want to scare away potential customers which may happen if they see that on every page. As I was writing this I checked your site, the wording is great now and I don't think seeing that wording would hurt to be seen everywhere. The only other thing that is uninviting is the size of the notice. It is the most prominent thing on your entire site. It is larger than your logo. Do to your site having a blue theme and the notice being in red I think having it just be the size of a normal div with a little added padding may be enough as it still grabs your attention. I changed the css on .w3-red to the following as well as changed the h1 to a div to give it a less prominent look. I am sure you can play with it to have it fit your theme better but that was something quick and dirty to show you what I was thinking. .w3-red, .w3-hover-red:hover { color: #fff!important; background-color: #f44336!important; padding: 5px; margin-bottom: 5px; }

Does this mean someone can not place an order on the weekends with you? I think it makes sense for the ticketing system pages but you may want to exclude it from your ordering pages unless you manually activate purchases.