Tyson

You would want to install the minphp/bridge.

Blesta will attempt to perform the upgrade automatically for all plugins that are a different version at the same time you upgrade Blesta itself, but whether a plugin can be upgraded depends solely on the plugin. If you get a blank white page, or some errors when you attempt to upgrade a plugin, it is most-likely due to poor code in the plugin.

This issue is fixed in beta 3.

The data available depends on the controller and what it retrieves. For individual contacts, only the 2-character state and country are available (i.e. what is stored with the contact). If you need more information, such as additional information on the state/country based on those 2-character state/country codes, then you would need to fetch them separately from the States and Countries models.

So minphp v1.0 will likely be the same as it is for Blesta, where it will require the bridge. Maybe a 2.0 would not require the bridge. Constants are not subject to change (they are "constants" after all). If you really needed to change them without modifying core files, then you *might* be able to define them at run time through the AppController::preAction event, which may or may not suffice for what you use them for.

Blesta uses the native template system, php itself. There is no smarty/twig integration. My experience is that these template engines unnecessarily add undo stress with additional constructs to learn, and come with their own set of issues and limitations. I wouldn't trust a web designer with source code either, so I don't. Any web designer should be able to create a mockup of any design updates through markup and a developer can review and integrate them into the system. Custom pages are typically created within plugins, otherwise you would need to add/update source code in Blesta itself. Blesta is built on an MVC framework, so you would need to create an appropriate controller, all views (templates), and if you need to access data, a model as well. Then you would need to integrate that wherever you plan to use it. You should also create permissions for access to your new page. This is where developing a plugin shines, as you can design and construct complex pages/actions without updating the core system at all. Modules can define their own pages which will appear as tabs when managing the service they are attached to. There is a short example in the module documentation for creating tabs.

Any developer can create a payment gateway. You could ask PerfectMoney and PayUMoney whether they are interested in creating a gateway for Blesta, or another developer on the forums here may be interested in doing so. It would be useful to have reference to their API documentation.

From a development point-of-view, it is much easier to use the existing cancel service/create service actions to make this change. This provides this smallest headache in managing the service. I see what you're saying, though, it would be nice to simply change the package's module. But this affects all customers using the package as apart of their service. This can have unknown and often disastrous consequences for your customer's services. I know you understand that service fields will be affected for customers using that package, but some users will not understand the implications of this behavior. I would rather integrate a better feature to manage this behavior effectively than allow an admin to simply change data around without respect to their relations in the system.

All gateways should be integrated as described in the gateway documentation. PayUMoney may be able to create a gateway for Blesta, or you could find another developer on the forums here that could do it if you're not a developer yourself.

This would be much easier if the plugins/modules were namespaced, which they are not. Until that is required (probably a version 5.0) this would not likely be available.

Updating phpseclib (again) would necessitate several changes to the codebase. We'll do it eventually, but I don't think this close to a 4.0 launch would be a good time.

Do you receive any errors in the PHP error log? Why is the page blank? Are you receiving a 500 internal server error?

The last thing it would do is update the payment_cc_approved email template from the `emails` table to change the erroneous tag "{company_name}" to "{company.name}". If you had already done this in your installation prior to the upgrade, then there would be no changes. Before that, all the `company_settings` are updated to set all 'tax_id' keys to disable inheritance (`inherit` = 0). Unless you have created multiple companies, you wouldn't notice any change here. If you have both a client and admin theme named "FOUR" that work correctly, then the database updates were likely successful.

Glad you figured it out! PHP7 can still cause some issues in the v4 beta.

You'd have to ask @Cody that.

To reiterate, most modules support remote API access to support automated functionality, such as service creation, suspension, etc. If you plan to manage services manually, the Universal Module will do, as it integrates with no third-party API.

minphp v1.0 no longer supports debug mode, which is why you receive no stack trace.

The Support Manager will stop sending auto-responses if it has sent 5 in the last 5 minutes to the same address. If the other system responds less frequently than that, you could still have a loop (e.g. they auto-respond once every 1.5 minutes).

Can you provide a simple before/after example to illustrate your date issue? e.g. Current behavior: Start: 2016-09-30 End: 2017-09-31 What should happen: Start: 2016-09-30 End: 2017-09-30

The major email providers will block spam or those perceived to be spam, so don't send spam and you shouldn't have much of a problem. Emailing a lot of users will take a long time to send anyway. If you send 5000 emails from the mass mailer, I would not be surprised if it took 90 minutes to complete. I don't think this would trigger a rate limit.

Is the web server running php 7? If so, the installation will fail. The first change to the database would be to add a new theme to the `themes` table named "FOUR".

That would make sense. Have you tried to install via CLI?

It's more setting the structure of the TLDs via HTML to make it easier for you to set CSS styles to obtain your desired look. The only coding necessary is to display the TLDs.

How long did it take to finish? Maybe the request timed out because it took too long?

It should have added that debug line to the config file anyway. I see it in my v4 installations.