Jono

Then you would do {service.direct_admin_password | escape} I believe.

Correct, two packages for ordering either subdomain or full domain. We are working on features to accommodate this. I believe it is planned in the eventual domain manager release, but more immediately there is a task for Namesilo to automatically generate/update packages based on current pricing.

As far as the sandbox, I believe the results are based on which domains are already taken specifically in their sandbox environment. Care to describe your first error more? At which step does it redirect you back to the search? Is there any error message or anything?

So plugins will usually have a parent controller that their other controllers inherit from that has a name in the format my_plugin_controller.php In that file/class there should be a method called preAction and you should add that code at the end of that method.

Orders are different than services. Orders are made by the client through the order system and can be viewed in the order widget under Billing > Overview

CORE-3520

An iframe huh? That sounds gross X) Anyhow, you can look at plugins/order/views/templates/wizard/checkout_complete.pdt, ../ajax/checkout_complete.pdt, ../standard/checkout_complete.pdt. At the bottom of each you will see: <div class="col-md-12"> <div class="btn-group pull-right"> <a href="<?php echo $this->Html->safe($this->base_uri . 'order/main/index/' . $this->Html->ifSet($order_form->label));?>" class="btn btn-plain btn-sm"><i class="fa fa-arrow-left"></i> <?php $this->_('Checkout.complete.order_more_btn');?></a> </div> </div> So you'll want to update that.

?? Authorize.net, Paypal Payflow, Braintree, and Converge all support EUR and definitely do not operate only in the US. Am I misunderstanding your question?

Any chance this installation is in maintenance mode? That is the only circumstance I've found that can account for this error.

X) How are you outputting it? $contact_numbers is an array of objects. I guess in your case you are looking for a particular number so maybe just grab the first one <?php $verify_phone = $this->Html->ifSet($contact_numbers[0]->number); ?> <script> window.intercomSettings = { app_id: "app_id", phone: "<?php echo $verify_phone; ?>", name: "<?php echo $this->Html->_($contact->first_name, true) . ' ' . $this->Html->_($contact->last_name, true);?>", email: "<?php echo $verify_email; ?>", // Email address user_hash: "<?php echo $email_sig; ?>" // HMAC using SHA-256 }; </script> You may also want to submit the $type argument to Contacts::getNumbers() to get only 'phone' type numbers.

Yea, so you would load the Contacts model inside your controller. You said you want this to be passed to structure.pdt? I assume this is for client interface? You can update client_controller.php in the preAction() and load the contacts controller: $this->uses(['Contacts']); Then set the numbers to the structure: $this->structure->set('contact_numbers', $this->Contacts->getNumbers($this->client->contact_id)); That will make the $contact_numbers variable available to app/views/client/bootstrap/structure.pdt

I believe this can be accomplished through the $options parameter for Emails::send(). Specifically you'll need to determine to which client the email belongs and set $options['to_client_id'] = $client->id;

See Contacts::getNumbers(); should be what you need

Interesting concept, and I can certainly see the appeal. Currently this is not possible through Blesta. Staff members are not associated with particular client groups and the client list page doesn't filter by client group anyhow. If you'd like to see this in future releases, submit a request here https://requests.blesta.com/.

What version of Blesta and PHP are you on?

You'll need to make sure that the packages are in the same package group and that package has the "Allow Upgrades/Downgrades between Packages within this Group" option checked

Hmm this is would actually require a rather involved change to the code base. Basically what we are showing in the drop down is the simple price from the package. What appears in the cart is a breakdown created by a robust pricing library we've written that takes into account many things like proration, tax, discounts, etc. To change the drop downs from the first to the second would take a decent amount of work.

Thanks for your update! We've created CORE-3410 to update these instruction

You are saying these do not work? What use cases are not failing/succeeding as expected? A couple notes on the username regex. The i modifier at the end makes it case insensitive so it can be upper or lower case. Also you allow for the $%^ characters in the username, is that intentional? Also I notice that you use the negate option for the domain rule. So you are validating that the submitted domain does NOT match that regex. Finally, you are missing a comma after the curly brace just before the start of the "password" rule.

This was updated as a part of v4.8.0. See https://dev.blesta.com/browse/CORE-3295

Which module are these services for?

That field comes from the Stripe Elements and Stripe JS API. It is an iframe that Blesta does not control directly and the zip code field I believe appears conditionally on the kind of card you enter. You may be able to find some option in the API to alter this behavior. In that case you would modify the JS in components/gateways/merchant/stripe_payments/views/default/cc_form.pdt The API reference is here https://stripe.com/docs/js

Make sure that the directory for your gateway is in the component/gateways/nonmerchant folder and that the main file has the same name as the directory (ex. components/gateways/nonmerchant/mygateway/mygateway.php).

It should still be valid. If you upgraded Blesta, perhaps the change was overridden?

Reading your post more carefully, you said that the problem is with recent accounts. My suggestions still apply if you are using the "Stripe" gateway, let me know though if you made the switched to "Stripe Payments" because that will be slightly different.