mrrsm

Similar to what Blesta Addons said, Blesta doesn't really setup anything. It makes API calls to something which sets up the services. Making a module to do these things is not that difficult however you need to be very specific as to what you need done. For example "Install Wordpress" could mean many things where "Install Wordpress via Softaculous on cpanel" is very specific and will allow people to help you.

If you want it done in a reasonable amount of time your best bet is going to be to hire someone to add those features. Fortunately their API is pretty good and easy to use so it shouldn't take someone too long to finish for you.

You would have your own track, pre-beta releases

I don't like the idea of my billing system ever auto updating. Things will invariably go wrong at some point and I can't risk my billing system going down and me not knowing what happened. I wouldn't mind having a notification in the admin telling me that there are updates available though that way I can take action and be reminded until I do.

It usually takes a short amount of time (unless they have automated the process some more) as they watermark the images for you. I have usually had a 1 day or less turnaround time.

Nope, if it was one of your's I am sure it would have been fixed already as you guys are on top of things. It was actually an old module that I no longer needed anyways. However due to it still being there when I tried to load the plugin page in the admin it would fail due to an incompatibility with the ioncube loader.

The only issue I had encountered was from a 3rd party plugin or extension which didn't support the ioncube encoder for php 7. Once that was fixed everything has been smooth for me.

Aren't all the gateway callbacks more or less the same Configure::set("Blesta.gw_callback_url", "http" . (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != "off" ? "s" : "") . "://" . (isset($_SERVER['HTTP_HOST']) ? $_SERVER['HTTP_HOST'] : "localhost") . WEBDIR . "callback/gw/"); Specifically for paypal the notify url is built 'notify_url' => Configure::get('Blesta.gw_callback_url') . Configure::get('Blesta.company_id') . '/paypal_payments_standard/?client_id=' . $this->ifSet($contact_info['client_id']),

Is there a reason that the providers give as to why it isn't enabled or why they can't enable it? I know in the past I ran into providers who didn't offer this extension. My guess was due to higher resource usage that that module could cause. Regardless, at this point I don't think there is a good reason for a reputable shared hosting provider to not have this. With cloud linux they can even more strictly control your resource usage if resource usage was the issue. Do you know of anything that can replace mailparse. I had looked many times and never found anything that worked as well as mailparse did.

You should probably change that to BlestaCMS has been released and not just Blesta

Hey @Paul the Blesta logo is broken on the marketplace link that you made.

For testing and maybe even production, depending on how many customers you have, a 512Mb instance is probably more than enough. You may need to tune some things to work better under a lower ram environment, such as mysql, or you can supplement it by adding swap which will probably rarely get used. An example for centos 6 is something like this https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-centos-6

I think you are missing the point of what I am saying. You come across, at least to me, as very combative which is very off putting. I honestly don't think anyone here is attacking you even if they are criticizing some things you are doing. I am just making suggestions of things you can do to improve your coding which will in turn improve your products. This doesn't mean you need to drop everything you are currently doing and/or release anything/everything open source. However if you find a small project that you can create and release it open source you will get feedback from others, be it code style, organization, or unit tests, which you can learn from. If you don't want to go that route there are a ton of good examples with Blesta being one of them that you can draw inspiration from as well.

If nobody is giving you feedback and you are not willing to learn the reasons people use the PSR standards (as well as others) you will never grow as a developer. Once you have clean code you will find out how much easier it is to follow and feel comfortable with. On top of this you can start writing unit tests which will help as well. You have to make steps though. Release a single module open source. People will give you feedback as well as possibly make pull requests against your code. Don't take things personally, instead take what people say for what it is and learn from it. I am confident you would learn quickly and your code would improve fast if you are willing to put yourself out there a bit to start with.

I gave it a read over and the english didn't seem bad to me. What things stood out as bad?

You wouldn't have a universal one. In reality the shared login will allow you to create a plugin/module for any of the forums out there in order to do a SSO style login. From there you can also use the API to do whatever else you need to do with the user's account. It shouldn't take much more than an hour per forum as long as there was some boilerplate plugin/module framework as most of them do similar things for handling login hooks as most of your code is the same between them.

That makes sense to me. It sounded like cyandark was starting a new project which means he should not need the bridge. I hope this will happen. What is in the github not kind of works but it isn't worth putting in a PR as v4 is using the minphp 1.0 and works so an update to the repo would fix most of the problems most likely.

Without that change, if I run what is in the minphp repo directly I get the following error Fatal error: Class 'minphp\Language\Language' not found in /code/php/minphp/src/lib/language.php on line 7 Fatal error: Uncaught Error: Class 'View' not found in /code/php/minphp/src/lib/controller.php:87 Stack trace: #0 /code/php/minphp/src/lib/dispatcher.php(165): Controller->__construct() #1 /code/php/minphp/src/lib/unknown_exception.php(58): Dispatcher::raiseError(Object(UnknownException)) #2 [internal function]: UnknownException::setFatalErrorHandler() #3 {main} thrown in /code/php/minphp/src/lib/controller.php on line 87 This happens because the View class depends on the Language class which has an invalid use statement. I am not sure what the bridge has to do with anything if you are creating a new project as you shouldn't need to use it if you just use the new 1.0 code. I haven't fully looked into the bridge but that is what I got from reading the README.

If you want to get the current version in master working as of 2016-11-28 against commit ed21031213e395cf38e902d8b4c2b2cbf072dc0c here is what you need to do. I would be happy to submit PR's to get the code in the repo working but the repo looks fairly dead to me. git clone https://github.com/phillipsdata/minphp.git Edit the composer.json file - "minphp/html": "dev-master", + "minphp/html": "~1.0", Download/Run composer install php composer.phar install Edit src/lib/language.php -use minphp\Language\Language as FrameworkLanguage; +use Minphp\Language\Language as FrameworkLanguage; That should get what is currently in the repo to work. (at least it did for me). I tested it by running a webserver out of the src directory via php locally on port 8000 cd src php -S localhost:8000

This is what I had to do. Wouldn't it be nice if it would just show you what it would look like with some dummy info added in?

I have never used or looked at the blestacms code so I am not much help there. It may be a good feature request to make though as it is a good security measure to have if they can pass the blesta one through to the user.

You are more or less protected than if you have good mod_security rules in place. If you look at the forms Blesta creates they add a CSRF token <input type="hidden" name="_csrf_token" value="f366be67543fb4413174a63bf048bd383d65177a65194eaf55d5a37ab185d705"> This will help, among other things, people submitting forms multiple times, submitting a form from somwhere that is not the form, and multiple others things. The wikipedia page has a pretty full description of things tokens can help protect you against.

I'm not sure how I feel about people just being able to put in my website and see what plugins of yours I am using or if I am using your plugins at all. Other things which I know have similar features are billing systems, forums, etc but with all of those it is hard to tell that I am not using them. For a fraud checker or vultur provisioner (examples) I don't really need anyone to know what plugin I am using for that. How is someone even going to know if the billing system is using X plugin or module behind the scenes? Without that knowledge I am not sure why someone would even bother, or know, to go to your site and check to see if they are using a valid license. On to the analysis of it You may want to fix that 1 at the end Looks like it shows up on both positive and negative results. You also may want to make the page look a bit nicer. The main point of the page is the form but there is nothing telling me what to do with it. Not even a placeholder on the input box. The blue bar outshines the rest of the page way too much, only because there isn't anything around the form currently. Finally you may want to lockdown your endpoint at least a little bit as right now just about anyone could hammer on it. I didn't test it too much but I didn't have a hard time sending multiple requests in succession directly to the endpoint. I am going to guess that you are using mysql or a flat file somewhere to manage your license and that is probably being hit every time a lookup is done. This is bad because someone could essentially do a denial of service attack by beating on that one url and it can't be cached so they know it will hammer a resource behind the scenes and they don't have to login or get a CSRF token to do it. You may just want to mitigate that as a firewall rule but there are in-code ways to reduce the attack vector as well that wouldn't hurt. Finally this is listed on your site under products. Is this something you are planning on selling or is it just due to the fact it is validating the license on your products. If it is the latter I would suggest moving it under the "Quick Links" section as to me it makes more sense for it to be there. This is a good proof of concept but still has a way to go before I would think it is production ready.

Your php version has nothing to do with it. Your provider should be enabling the mailparse extension in their WHM EasyApache config. This means every time they update the module should be there as well. I would be a bit wary of your provider if they are having issues with this.

If your modules gets updated and becomes a more solid experience I will be so happy. It isn't bad per-say now but it isn't that user friendly which usually means a bit more work from the admin side to get things done when a user can't figure it out on their own.