Tyson

It sounds like that may be an issue with PayPal. You can attempt to make a payment in Blesta, as a client, using PayPal, and when you get to the payment page with the PayPal payment button, view the page source and check the form for the button. It should contain an input field named 'return' with the URL to your Blesta installation. If that URL is correct, as I suspect it will be, then PayPal is prepending their 'paypalobjects.com' URL before yours when they generate the redirect link back to Blesta. You would need to ask PayPal why that is and see what can be done about it.

There is no specific thread per se, but there are at least a few threads discussing domain management on the forums. You're welcome to add feedback to any of those or create another thread with a complete overview of what you think it should contain (similar to naja7host). We have a pretty good idea what will need to be done for it, but any expectations you have that haven't already been mentioned are helpful in fine tuning its development. I can understand the frustration. Since domain management won't arrive until 4.1, our time has not been focused on laying out any UI designs for it. Once 4.0 is out, the focus on domain management will pick up.

Just had some time to test this issue, but I wasn't able to duplicate it. For me on v3.6.1, removing multiple IP addresses one at a time from the admin or client UI creates a transaction of the expected prorated credit amount. None of my transactions are showing a doubled credit. Is your config option for the extra IPs set to the Step of 1 as mentioned in the documentation? I don't recall exactly what behavior will occur if you set the step higher than one, but if it were set to 2, that could explain the credit doubling.

What would we offer bounties for exactly?

Blesta has a template system. It follows the MVC design pattern where the views (templates) are constructed dynamically from the needs of the controller and injected into the page structure where necessary. This is common practice now to save processing resources over less efficient designs and to separate business logic from presentation. If you find the design confusing, as you've mentioned at least three times, that's usually a good point to stop and take a step back to analyze what you're doing and to understand the constraints of the design you're working within. The template (.pdt) files for the admin and client UIs are found under /app/views/admin/ and /app/views/client/ respectively. Most template files are named according to the controller and method from which they extend for the page that they render. This naming scheme can also be derived from the URI of most pages in your browser, e.g. a URI of '/admin/clients/' is constructed from the /app/views/admin/default/admin_clients.pdt template file. I'm not sure what you're intending to do. After reading this thread, I don't think you've adequately described the behavior you're expecting to accomplish. "Wrapping" Blesta code means you are nesting it within your own. Blesta generates complete HTML pages, so unless you're using an iFrame or using the Blesta API to display your own content, "wrapping" it is not something that would work for you. Blesta does not contain all HTML in one file. This is why we have templates. You could change the parent template (structure.pdt) which generates the header and footer of every page, but that depends on the results you intend to achieve. Per the MVC design and the separation of business logic, templates do not make calls to anything in code. Curious which template calls you are referring to. As I mentioned above, when confused, step back and take a look at the bigger picture. Blesta is designed to be developer-friendly, where the source code is available for edit, natively. I get the feeling that you are not a developer per se, but rather an end-user programmer. It's common for end-user programmers to shy away from better designs, if only because they appear complex and unfamiliar. However, the MVC design is far superior to many other designs, which is why it has become popular in web application development. The mods/plugins others have mentioned are extensions to Blesta, like the Portal plugin, to enhance functionality beyond the core system. The Portal plugin currently only allows the edit of the main homepage of your Blesta installation. Anything else that is more custom needs to be written as such. naja7host's Admin Tools plugin, for instance, allows you to define more custom pages beyond simply the homepage of your Blesta installation like the Portal plugin allows. You say the competitor's script is easier to work with because they have a proper system? To which proper system are you referring? Contrary to your interpretation, your screenshot comparison of a template shows me that Blesta is easier to work with from a developer's stand-point. Here's a few reasons why: Blesta provides access to source code in templates, that is, the source PHP that renders template HTML, giving you complete control over its use Blesta does not obfuscate code through a middle-ware system, like Smarty templates, which adds additional syntax to understand and an unnecessary second layer to UI presentation Blesta makes it easy to secure your display of variables by using the HTML helper. Using the helper keeps you from making common mistakes that lead to XSS vulnerabilities by forcing variables to be output HTML-safe Blesta makes it easy to generate forms using the Form helper. The Form helper also embeds a CSRF token to prevent users from being the victim of CSRF attacks in Blesta. Blesta appears to be tabbed better for read-ability Blesta defines a more modern structure of HTML and CSS to avoid out-dated uses of multiple line breaks (e.g. <br /><br />) where paragraphs or CSS padding/margin should be used instead. Additionally, inline attributes (e.g. "align=") like "<p align='center'>" are avoided in lieu of proper CSS styling defined in stylesheets. I'm not sure why you think the second screenshot looks more appealing, but looks are subjective. I work within objective constraints. tl;dr What are you looking to accomplish with your theming exactly? It may be better for us to understand what you're doing if you could describe what parts of the system you intend to change, in what way, and provide examples to illustrate these points.

ACH support is something that could be added to the gateway with Blesta.

By 'notification', you mean a log entry that appears under [Tools] -> [Logs] -> (User Logins tab)? A user login entry could show whether two-factor authentication was required to login for the user and whether or not they did successfully login using it. However, determining if they 'abandoned' the two-factor authentication page (e.g. by closing their browser window) wouldn't be possible.

I'm unclear on exactly what your intentions are--to either create an addon service (a separate service altogether) or add fields to the Universal Module service. Both are very different. From your screenshot, I can see you attempted to perform the latter. The reason only the names of the service options appear is because you have not defined any service option values (i.e. the radio options). Take a look at the documentation. I think you want to only have one service option line rather than two. Set the label and name field to whatever you like, the type to 'radio', and the values field to: "option1:Option 1|option2:Option 2".

Sounds strange, I would expect the username to have been updated. In any case, it's good to hear the alternative works for you instead.

I've added this as CORE-2069.

I see. It looks like the cPanel module only makes the changes if Use Module is checked. You should be able to do the following: Update their service in Blesta to change their username to the username they have in cPanel Remove their password (set it to a blank value). This is so that Blesta will not attempt to overwrite it in case it differs from what's stored in cPanel Leave "Use Module" checked Save Their username should now be updated in Blesta, and no data should be changed in cPanel because it's all the same anyway.

Yeah, I think the easiest solution is to update their username in Blesta to reflect the same username in cPanel, and save it with "Use Module" unchecked. What error do you receive when you say it's not letting you update it?

What Multicraft update thing? Setting the server port? Did you look at my post here?

Scan all files for "get_defined_vars" and remove any references to it you find.

There is currently no reliable way to determine what constitutes an upgrade. The assumptions that Paul described above is only one way of looking at it, and smaller quantities or unchecked values could be desired as upgrades instead of the other way around.

This issue is most-likely webserver related, possibly due to a conflict/misconfiguration with Wordpress. You should check the webserver's error log for more information.

If you cached the page as I mentioned in post 8, then you can clear it programmatically via: class MyController extends AppController { public function myPage() { $this->clearCache(); ... } } If the URI differs from the URI of the page you cached, you can specify the cached URI as the first argument to clearCache in order to remove it from the cache.

The dispatcher fetches cached templates and then displays them. Depending on what you're doing, this may or may not be what you want, as your controller logic will be bypassed. Consider the following scenario: - Your plugin requires an admin to be logged in, and then displays information only they should see. - Your plugin caches the template that was shown (as mentioned in post 8) when the admin visits the page. Now anyone that visits the URI that the admin went to will see the cached data. You do not need to be logged in, as the dispatcher will display the content immediately, bypassing your controller and any other logic that may exist to verify the user's authentication. So, if you are showing static data that any public user should see, caching like this will be fine. However, if you are looking to restrict access to the template, then you do not want to cache it in this manner.

The cron is run via CLI, so Apache does not handle the request, and your virtual directories are not known. The virtual directory aliasing only occurs with Apache, so you should either remove the virtual directory aliasing to Blesta's directory so the path can be determined correctly via CLI, or run the cron via wget so that it will use Apache instead. If you opt to remove the alias to Blesta (i.e. rename the 'blesta' directory to 'services') and you get a 'license invalid' page when you try to login, then you just need to reissue your license key. To do this, log into your account, click to manage the service, check the 'Reissue' checkbox and save. Then the license will revalidate at the new location when you login to your installation.

Template files can be cached automatically by specifying so, e.g. class MyController extends AppController { public function myPage() { $this->startCaching(Configure::get("Blesta.cache_length")); ... } }

Something like.. // Fetch from cache $cache = Cache::fetchCache('file_name', $this->company_id . DS . 'directory' . DS); if ($cache) { $data = unserialize(base64_decode($cache)); } else { // Fetch the data to store in the cache $data = 'my data'; // Write to cache if (Configure::get('Caching.on') && is_writable(CACHEDIR)) { try { Cache::writeCache( 'file_name', base64_encode(serialize($data)), strtotime(Configure::get('Blesta.cache_length')) - time(), $this->company_id . DS . 'directory' . DS ); } catch (Exception $e) { // Couldn't cache } } } // Use $data

I think you'll need to write an importer to map the service fields in the Universal Module to the corresponding fields for the OpenSRS module and then update all Universal Module services to assign them to an OpenSRS module row.

Did you make any manual changes to the database, or run the upgrade script more than once if it had failed? Several database changes have been made form v3.4.3 and v3.6.1. You'll have to check what partial changes it did make in order to manually adjust the upgrade script to perform the rest. You'll need to see which company settings have been added at the point of the error: SELECT `key`, `value`, `company_id` FROM `company_settings` WHERE `key` LIKE 'inv_display_due%' ; Do you have these three keys set for each company? inv_display_due_date_draft inv_display_due_date_proforma inv_display_due_date_inv What is the structure of the coupons table? DESCRIBE `coupons`; What is the structure of the package options table? DESCRIBE `package_options`;

If the support department is 'hidden', then clients cannot see the department nor open a new ticket in that department. However, they can still reply to tickets that are opened in that department.

Sounds like BungeeCord is not retrieving the correct port from Multicraft. I'm not sure what you can do about that besides ask BungeeCord for support.