Jonathan

For what it's worth Blesta runs well on PHP 5.6 and MariaDB 10.0.14 behind Nginx

Do you have to use the API or can you do some direct MySQL queries? If the latter, I can show you how.

You need to talk to WHMCS about this, not Blesta. Not sure why Blesta would help you move off of Blesta...not much sense in that.

You can't file a DMCA as the content is technically being served from your own system, thus you'd be filing a DMCA against...yourself.

Well presumably it would work loading the core files - at this point I've got it dirtily converted into a plugin function I'm calling directly. I did that while ruling things out and there's no point in going back now. It's sped up this process I'm doing ten-fold. Don't have a full idea yet as I'm still converting things in my script from making API calls to now internal calls but I suspect it will take this, previously 2-3 hour long process down to 10-20 mins based on what I've tested thus far.

Well I got it figured out. The problem is/was that the api expects the input arrays to be in the format of $vars 'vars' var1 var2 Whereas internally the calls are expected to be like this: $vars var1 var2 Basically drop the 'vars' array which contains the values for the API and set the values directly on the parent array passed to the method. A bit of clarification in the documentation could certainly save folks some time. This got me both starting using the API as well as trying to convert from the API to internal for speed.

Right - I'm working locally. Figured I'd try throwing all of this into a plugin so I can make the calls locally to the core Models (the ones at http://source-docs.blesta.com/package-blesta.app.models.html) and it seems I'm in the same boat as trying to initialize Blesta externally. Any calls to get data work great. Any calls that write data such as lets say PackageGroups->add or Packages->add, etc. fail with absolutely 0 return or errors. Even nothing useful from strace. They literally just seem to do nothing.

Yeah I've tried the CLI API calls but unfortunately the connect/disconnect overhead that goes along with each call is still my biggest slowdown. I've got the actualy HTTP overhead to such a minimum by doing things locally with a good web-server configuration that the difference in the two in my benchmarks was negligible which is why I was hoping to just initiate Blesta directly in my code as to avoid this overhead. EDIT: Just noticed that your calls are bypassing the API and going for a direct execution of the methods. What sort of overhead does calling to the API have via command line versus calling directly like this? Will this get rid of a noticeable amount when doing tens of thousands of calls?

+1

I thought it was enough too but only loading it threw undefined class errors everywhere whereas loading the other two files at least got get-style requests working. Yes, I've got full error reporting turned on everywhere.

Yep, and it works, but I'm trying to speed things up. The overhead of API style (connect, execute, disconnect) is what I'm trying to work around now. Initializing the functionlity directly takes the connect and disconnect out of the equation which is what's really slowing me down at this point. This includes the "local" CLI API method as well. I'm hoping Cody or Tyson can let me know what element(s) I'm missing here as I know I'm close - gets work, posts just don't seem to do anything.

To my knowledge there's not an importer for WHM->Blesta. There is however an importer for WHMCS->Blesta. It's built in to the importer plugin. http://docs.blesta.com/display/user/Import+Manager

A few other applications have a nifty ability to automatically merge template changes which are required for Blesta updates. It would be awesome if Blesta had something similar. I use XenForo and their implentation of such a system is amazing and has always worked flawlessly for me through several major updates with lots of template changes even. https://xenforo.com/community/threads/template-merging-and-history.48846/

This would be nice upon package setup, sure, but how often do you really setup new packages? This is development time best spent on other things IMO.

Is it possible to initialize all of blesta apps/models/etc in a script completely external to Blesta? So far I've found that I need to load the following files: require_once('../lib/init.php'); require_once('../app/app_controller.php'); require_once('../app/app_model.php'); Loader appears to be working properly also: Loader::loadModels($this, array("Clients","Accounts","Services","Packages","PackageGroups","PackageOptions","PackageOptionGroups","Companies")); If I then for example do a call to $this->Clients->getAll(); or something similar it works as expected and I can print_r the return array, but as soon as I make a call to anything needing to write data it just fails, we'll say $this->Clients->add() for example. I get no return, no errors, nothing.

Hmm looks like you're right. The display of it in plain text threw me. Would love it if the text box for the field could be converted to type="password".

Hmm I do think I over-complicated the admin side, but I disagree with electric and I do think a native admin-side button is needed. It can simply be "generate next invoice" or something and do the exact same thing as the client-side one except emailing the invoice instead of taking you to the pay page.

Yes, it is more work hence this request as many competing systems do have this and it's pretty automated. Implementation would be similar to the following: Admin: Text box to accept a number. This number will represent the number of invoice cycles to generate based on the package's billing cycle. IE 12x 1 month would generate 12 1-month inovices. 12 x quarterly would generate 12 quarterly invoices, or 3-years worth. This makes it a pretty dynamic way to generate as many or as few cycles as wanted/needed. If such flexibility is not possible a button for the admin identical to the client "renew now" button below would work. This should have the ability to email the customer the invoice since directing the admin to the pay now page for the client would make no sense. Client: Give the client the ability to go ahead and renew for their next billing term with a simple "renew now" button. This should generate an invoice for the renewal of the term the package is on and take them to the payment page. The "due" dates on either of these methods should be set as if the invoice was generated on the normal terms, per the actual renewal day when the package would normally be due. If these invoices are generated, but not paid, and the service isn't due to renew yet, suspension should not occur as that would be erroneous and wrong.

Well that explains a lot. How embarrassing Thanks

Currently when using the API to create a service with a coupon ID defined it will fail to import. I've managed to identify why and come up with a fix for my scenario. Error example: stdClass Object ( [error] => stdClass Object ( [message] => An unexpected error occured. [response] => SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ''(60)' AND `coupons`.`id` = '1' GROUP BY `coupons`.`id`' at line 1 ) ) Here's an example of my $vars array: Array ( [vars] => Array ( [package_group_id] => 1 [pricing_id] => 178 [client_id] => 4 [status] => active [coupon_id] => 1 [override_price] => [override_currency] => [module_row_id] => 1 [date_canceled] => [date_added] => 2013-08-15 00:00:00 [date_renews] => 2014-11-15 00:00:00 [use_module] => false [quantity] => 1 [ip] => 1.2.3.4 [hostname] => removed.com [configoptions] => Array ( [625] => No [618] => No [619] => No [620] => No [624] => Yes [613] => No [623] => Yes [615] => Yes [622] => No [616] => No [617] => No [621] => No [612] => No ) ) [packages] => 60 ) As you can see, I have coupon_id defined to "1". This generates the following query to MySQL when actually running the API call: SELECT `coupons`.`id`, `coupons`.`code`, `coupons`.`company_id`, `coupons`.`used_qty`, `coupons`.`max_qty`, `coupons`.`start_date`, `coupons`.`end_date`, `coupons`.`status`, `coupons`.`type`, `coupons`.`recurring`, `coupons`.`limit_recurring` FROM `coupons` INNER JOIN `coupon_packages` ON `coupon_packages`.`coupon_id` = `coupons`.`id` WHERE `coupons`.`company_id` = '1' AND `coupons`.`status` = 'active' AND (`coupons`.`max_qty` = '0' OR `coupons`.`max_qty` > `coupons`.`used_qty`) AND (`coupons`.`start_date` <= '2014-10-13 17:32:33' OR `coupons`.`start_date` IS NULL) AND (`coupons`.`end_date` > '2014-10-13 17:32:33' OR `coupons`.`end_date` IS NULL) AND `coupon_packages`.`package_id` IN '60' AND `coupons`.`id` = '1' GROUP BY `coupons`.`id` Now there's one big problem with this query. It will fail because the very last "IN" statement isn't valid. AND `coupon_packages`.`package_id` IN '60' AND `coupons`.`id` = '1' GROUP BY `coupons`.`id` When using IN, the values have to be comma-separated within parentheses. When correcting this last part of the query to this it works: AND `coupon_packages`.`package_id` IN ('60') AND `coupons`.`id` = '1' GROUP BY `coupons`.`id` Now the fix: In your apps/models/coupons.php around line 153: Change if ($packages) { $this->Record->innerJoin("coupon_packages", "coupon_packages.coupon_id", "=", "coupons.id", false)-> where("coupon_packages.package_id", "in", $packages)-> group("coupons.id"); } to if ($packages) { $this->Record->innerJoin("coupon_packages", "coupon_packages.coupon_id", "=", "coupons.id", false)-> where("coupon_packages.package_id", "=", $packages)-> group("coupons.id"); } The change is from "in" to "=" on the 3rd line of this code.

Yeah having a client side button for this too would be nifty.

Great! Then I guess my request is even easier: lets make this default for the key/password field in the enom module in the core release so I don't have to merge changes every release. It's a better default setting anyway, why not secure anything powerful since the ability is already there and sounds so easy to use. A tad bit of overhead for decryption here is not a bad tradeoff for immensely better storage of such credentials.

To my knowledge bcrypt isn't reversible. Whatever is used has to be reversible since the password has to be sent to the API as the password, not an ecrypted value.

For example, the enom module stores and displays the account password in plain text. It would add a bit of peace of mind if this could be stored using some sort of two-way encryption like mcrypt perhaps and then obviously displayed as a password field and not plain text. This would probably be a pretty minor fix.

It would be handy to have a hello world example. Basically a framewprk to build on