Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/10/2016 in all areas

  1. Warming up the beta forums. We've scheduled Beta 1 to start next Thursday, September 15th. We've had quite a few issues pop up with regard to the minPHP upgrade, and we're really close to having those all resolved. That's not to say we've caught everything. Being a major release, please consider 4.0 beta 1 more of an alpha, and do not under any circumstances run it in production. Looking forward to it!
    2 points
  2. Plugins and other extensions should be backwards compatible yes.. but you should *test* this. We've run into some issues where our plugins were not working properly and have had to make adjustments to the minPHP bridge. As Mike mentioned, you may want to update your buttons in your plugins to use the new Bootstrap ones, but if you don't they should still work. Test, test, test, everything you can think of. It's possible we missed something, and being a major release, this version requires extra scrutiny.
    1 point
  3. The LogicBoxes module does not look for configurable options to set. I imagine you would want to name the config option "protect-privacy" since that is what LogicBoxes uses (to be consistent). You would support it through the module's addService method.
    1 point
  4. Everything, really, since essentially everything has been updated. i.e. submit every form with good and bad data perform every action (including those in extensions) check for anything out of the ordinary like blank white pages, or pages with errors upgrade from version 3 to 4 create a new installation of v4 perform migrations from v2.5/whmcs to v4 check for obvious (or not so obvious) page styling issues see if anything comes across confusing that you think can be improved ensure current functionality still works try out the Mass Mailer plugin A dev system would be perfect, but where would you be importing data from? Not real data from a production environment, correct? Sometimes people insist to me that they want to test changes in a dev environment where the data mirrors what is on the production server. It sounds like a simple and convenient way to test what is and what will be, for comparison. They'll just disable emails from being sent and disable payments from going through in order to be sure real customers do not receive emails or get charged from the dev environment while they are testing it. However, this is a horrible, horrible, horrible idea for numerous reasons. Not only does it limit what you can test (e.g. can't test sending emails or making payments), but bugs may exist that send emails, make payments, etc., even when disabled. All data in a test/dev environment must be test data. I hope that's the intent of everyone that will be trying out the beta.
    1 point
  5. Welcome to the new member of blesta team ...
    1 point
  6. The service_id is available via line_items, see https://docs.blesta.com/pages/viewpage.action?pageId=4161679#InvoiceDelivery(Unpaid)-SupportedTags but it may not be possible to determine what package the service is linked to within the email template. You can use the tag {% debug %} to see all of the data that's available to the template. YOU SHOULD BE CAREFUL THOUGH, not to send out an email with this tag to any customers. There could be sensitive information in the output.
    1 point
×
×
  • Create New...