Alk

I agree as this was also my concern. I can understand why it is currently like this as it makes the selection process more apparent. If this were to be implemented (and I hope that it does for the aforementioned reasons), I think that the current setup with a greyed out "Select" button that then turns green is sufficient. Of course, there would also need to be an error check in place should a customer attempt to continue through checkout without having first selected a package.

If a client logs in to their account -> goes to "manage account" -> alters their email address (as per attached screenshot), their username (which is using their email address) does not update to reflect their new email address. Consequently, clients have difficulty logging in again! However, if you update their email address from the admin portal, the client's username is updated to reflect their new email address. As the default is to use email addresses as a client's username, this poses quite an issue.

I want to add some further information to this bug report as this needs to be recognised as an issue by Blesta. So if you want to use an order form for domain purchases only, you setup the order form as per the attached screenshot. IE. You set a "Domain package group", but not any other "package groups". If you also select to use any of the wizard or ajax based order form templates (the standard template doesn't have this issue) you will be presented with a blank page, prompting you to "make a package selection" - as illustrated in the screencast. Furthermore, as illustrated in the screencast, whilst with the "wizard slider" and "wizard boxes" templates you are presented with a blank page prompting to "make a package selection", you still get the "show cart" button to allow you to continue through checkout. However, with the "ajax boxes" and "ajax slider" templates, you don't get the "show cart" button, so you are completely stumped and cannot continue checkout! At the moment, the only workaround is to use the Standard order form template if you are only selling domains. I have to also point out that it is necessary to have a separate order form for customers who only want to order a domain name because if you attempt to only use one wizard or ajax based order form for all services which you offer (ie. an order form which has a domain package group set + other package groups) the customer cannot only order a domain name without being forced into having to purchase another package with the domain name due to the way that the wizard and ajax based order form templates work. The only way to prevent this is to use the standard order form template. I have opened a feature request for this issue here: http://www.blesta.com/forums/index.php?/topic/2984-do-not-pre-select-a-package-on-order-form/

Could it be made possible that with the ajax boxes and wizard boxes order form templates, that a package is not pre-selected please? ie. that the customer has to purposefully select which package they would like to purchase. For example, rather than having this: Have it like this: I have 2 reasons for requesting this: 1. I think that it is good business practise not to pre-select packages because the customer may feel that you are forcing them into purchasing a package that they don't want. 2. If you have one order form with both a domain package group + other package groups (eg. webhosting) but a customer does not want to purchase one of these other packages, because they only want to purchase a domain name from the previous step, they currently cannot do this without being forced into having to select a package.

I've discovered a bug which means that if you use the standard order template and go to purchase a domain name for a 1 year term on Step 1, on Step 2 of the checkout, it will alter it to be for 2 years. As per the below screenshots: You search for a domain name and choose to purchase for 1 year: But on step 2, it has altered to 2 years: Using Blesta v3.2.1.

I will point out that the Blesta team have already made an improvement on this issue if you are running 3.2. See: http://dev.blesta.com/browse/CORE-996

I appreciate your input Cody. I agree that PayPal's buttons are not the most aesthetically pleasing! Paulo's suggestion was also to do away with the graphics, so if this topic were to be moved to a feature request, perhaps others from the community could also give their feedback? To be honest, it may well be the best way to go, thereby covering all gateways. However, my opinion is that it doesn't matter that it doesn't mention "PayPal" on the buttons because the user has already chosen, on the previous screen, to pay with PayPal (they are the official PayPal buttons).

Thank you very much everyone; you have all helped me get to the bottom of this. So when the plugin is installed, it takes the entry in the language file I mentioned and writes it to the database in table: plugin_actions In this table you will find 2 rows with these entries in the "action" column: nav_primary_client nav_primary_staff (self-explanatory) and these 2 rows will have the "support" text in the "name" column. Just go ahead and alter the text in the "name" column for the rows. Like so: Then clear your cache by deleting the "1" folder from the cache folder (eg. blesta_install_dir/cache/1/) (or use the emptycache plugin by naja7host) and reload the page.

When a client logs in and modifies their contact details from the client portal (eg. URL: domain.com/client/main/edit/), the client custom fields are not visible unless the "Client may set Language" box is ticked in Company Settings -> General -> Localization. So with the "Client may set Language" box ticked, the client custom fields are visible when the client edits their contact details: But with the "Client may set Language" box unticked, the client custom fields disappear when the client edits their contact details (even though the custom client fields are set to be visible to the client):

I was also bemused by this when I came across this today. I uninstalled the Emptycache plugin, but as the link was still cached in the navigation bar, I could still access it via the URL, as if it was still installed. Suppose there was a vulnerability in a plugin and it was uninstalled; as it is currently, would it still in effect be active even though it was uninstalled?

Would a moderator be able to move this topic to the feature requests forum please? I've been playing around with the buttons again, now that the order form page has been updated in 3.2. So now I'm using the following buttons: https://www.paypalobjects.com/webstatic/en_US/btn/btn_paynow_cc_144x47.png https://www.paypalobjects.com/webstatic/en_US/btn/btn_subscribe_cc_147x47.png Which results in the order form looking like: For comparison, it originally looked like: But what (in my opinion) previously looked so unprofessional was the pay invoice page: Now it looks like: (all the buttons match and line up) All I did was change the URLs to the images in /components/gateways/nonmerchant/paypal_payments_standard/views/default/process.pdt. Would Blesta consider making these buttons standard please, as my alternative PayPal buttons are neater and more helpful to users?

Thanks Mike, unfortunately clearing the cache still hasn't altered the text in the nav bar. I think I must be editing the wrong language file, but I don't know what other file it could be.

Hello, I would like to alter the "Support" text in the navigation bar for both the Staff and Client Portal: I have tried modifying the "Support" text entry in the file: \plugins\support_manager\language\en_us\support_manager_plugin.php line 12 & 13: $lang['SupportManagerPlugin.nav_primary_client.main'] = "Support"; $lang['SupportManagerPlugin.nav_primary_staff.main'] = "Support"; However, in practise, it is not changing. Could anyone help please? Thank you!

You've beaten me to this feature request! It wasn't until recently that I realised that this was the case and I would really like a Payment confirmation email to be sent for non-merchant gateways, such as PayPal, please. I propose that the current email template "Payment Received (Manual Entry)" is ideal for this purpose. To explain for anyone that does not realise; whilst clients making new orders, paid via PayPal, may receive a "Invoice Delivery (Paid)" email (or even an "Invoice Delivery (Unpaid)" email if the payment is not received in a timely fashion), renewals paid via PayPal will only ever receive the "Invoice Delivery (Unpaid)" email. This is because "Invoice Delivery" emails are separate to the payment process, are only sent once (unless manually queued for delivery again by a staff member) and whether the Paid or Unpaid email is sent depends on the state of the invoice when the invoice is delivered. This is why Payment confirmation emails are necessary, but they are currently only sent for merchant gateways.

That's great - thank you Tyson.

In support manager, I have noticed that ticket attachments are not emailed out to the client (in the "Ticket Updated" email). I first noticed this when Tyson sent me an attachment via a ticket with Blesta Support and I did not receive the attachment in my inbox. I had to login to the client portal to download the attachment. I have recreated this on my own Blesta installation. Incoming attachments, sent via email, from clients appear in tickets OK. However, these incoming attachments from clients also do not appear in the emails sent to staff members (notifying a ticket update - the "Staff Ticket Updated" email). So it would appear that any outgoing email from support manager, whether to staff or client, simply does not include ticket attachments.

Perhaps it is just for the UK Resellerclub, but these are the emails concerning the charges implemented: http://cdn.resellerclub.com/mailers/rc/uk-privacy-protect-vps-ubuntu-09-04-14.html http://cdn.resellerclub.com/mailers/rc/uk-buzz-launch-updates-to-paid-privacy-protect-23-04-14.html

Thanks for your reply. Well, I was testing things and trying to buy a new domain such as "aktest.com" for example. I was logged in as a test client that I created and trying to purchase the domain as this test client. So it is true that the domain does not yet exist in my account (nor does the customer) as I was trying to make a new order.

Hi, I would be grateful for any help please. I've configured the logicboxes module for my resellerclub account. I've whitelisted the server IP in resellerclub and then put in my resellerclub ID and API key into the logicboxes module. I've created a package group for domains and I've setup some packages for purchasing of the various TLDs (eg. .com), given the appropriate pricing for the package TLD, and added the package to the package group for domains. I've then got an order form using the domains package group. This is all fine and the TLDs are showing on the order form and you can search for availability of a domain name and go through to purchase. So I've got a test account and I'm trying out the ordering process of a new domain name. I get all the way through to the end, choose my payment method, click to proceed and then I get the error message: "website does not exist for testdomain.com" All that the module log outputs is: https://httpapi.com/api/domains/orderid.json{"status":"ERROR","message":"Website doesn't exist for testdomain.com"} Could anyone help me resolve this error please? Thank you!

I'm in agreement with everyone, the label "date renews" (and its variants) is incredibly confusing for end users, including ourselves. Now that the Blesta team have explained how it works it all makes perfect sense and is good design, but as PauloV said, those not in the know will only get confused. I'm going to take another approach. As Cody has explained that this is the date when the next invoice is due, I'm going to change the language files to say "Next due date" (like competitors do in their control panels). I think that the label is the issue here. Unfortunately it is quite a few files to alter: \language\en_us\admin_billing.php \language\en_us\admin_clients.php \language\en_us\admin_search.php \language\en_us\client_services.php \plugins\order\language\en_us\admin_main.php \language\en_us\services.php

Fabulous, I'm very pleased to hear that Cody, thank you. For anyone that is interested, I have managed to resolve this for myself, with the existing 3.1 version, by replacing the existing paypal button with: as obtained from a list of button choices: https://developer.paypal.com/webapps/developer/docs/classic/api/buttons/ As I am only using PayPal and offline payment gateways, this button gives me the liberty to resolve the quirk with the "to complete your order click the pay button below." text appearing for offline payments by removing the text from the plugins\order\views\templates\standard\language\en_us\main.php file altogether, as this paypal button makes the text no longer necessary. This now gives me the result: As a chance bonus, this new button is the correct size to line up with the existing subscribe button so it is level now (it previously wasn't by default). I'm really pleased with the result; many thanks Mike!

That looks to be the one - thank you so much. I will play with that on Monday and report back.

Thank you for your reply. I realise that it is the official paypal button, but PayPal also offer "Pay now" buttons: https://developer.paypal.com/docs/classic/button-manager/integration-guide/NVP/ButtonMgrOverview/ which would be more appropriate to use for the reasons mentioned in my original post. This is what I would like to achieve, but how?

Hello, Is there anyway to change the paypal buttons please? Here is my reason for wanting to change the buttons: When checking out, there is no real issue with the current button that displays because there is a textual instruction which says to complete checkout, click the button below and the button is central to the page. However, as covered in my unanswered topic here having this textual instruction when an offline payment method is selected leads to immense confusion as no button is present. But what is worse is that when attempting to pay an invoice, you obviously get no textual instruction at all, so the page appears like so: An end user is not going to know that the paypal button is clickable. It just looks like a logo describing what cards are accepted by paypal. What I want to do is alter that button to one of paypal's "pay now" buttons or similar. Is this possible please? Thank you.

It becomes apparent when you create a custom theme with stark colours to differentiate between "Navigation Text Color" and "Navigation Text Active Color" that the "Return to portal" and "Log in" buttons are back to front in their colours. To illustrate, I create a theme with these colours for the Navigation text: It appears like this: As you can see, the "Return to portal" and "Log in" buttons are using the "Navigation Text Active Color" even though they are not active (in contrast, the bar underneath is behaving correctly). When looking in the CSS (app\views\client\default\css\theme.css), if you look carefully it is apparent that it is back to front in the code. As it stands, this is how the code is: .login_sec .button a { color:#theme_navigation_text_active_color;} .login_sec .button a:hover { color:#theme_navigation_text_color;} However, it should be: .login_sec .button a { color:#theme_navigation_text_color;} .login_sec .button a:hover { color:#theme_navigation_text_active_color;} With the css corrected, the "Return to portal" and "Log in" then use the correct colours: