Cody

Different registrars require different "extended fields" based on TLD. .co.uk is not the same as .uk with respect to TLD submitted to registrars that require separting TLD from SLD (despite the fact that, by definition, TLD means top level, e.g. .uk). This is probably due to country TLDs not being resold through various countries directly until recently.

Re-opened because it may be possible to parse package email snippets when saving a package which could (in theory) resolve this type of issue.

Actually, the template is parsed when saved, what you see here is not a parse error but a runtime error. Not something we can check as there is no context when saving an email template (that is, no tag replacements). Closing as a "wish we could fix, but can't".

Fixed in 3.3.0-b2.

You will never have two pro forma invoices in the system with the same number. Once an invoice has been converted from pro forma to an invoice, the pro forma records no longer exists! Besides, the only way a customer would receive another pro forma invoice with the same number as a previous invoice is if the newest invoice belongs to them, they pay it, then the system generates a new invoice for the same customer before generating any other invoices, which is unlikely.

+1 for what Tyson said.

This isn't a bug, nor the forum for posting feature requests. Input validation is handled by the module. If you're using the Universal module, use a regex to validate the domain. Use the Support Forum if you need help.

Did you move servers? Update vhosts, etc., etc.? Changes made to your hosting environment could cause the Root Web Directory path to no longer be valid, hence you'll need to update it to the correct value.

The URI for emails delivered by the cron is derived from the Root Web Directory setting. Try adjusting that setting and see how it affects the URL in the email. 99% of issues with links in emails delivered by the cron are the result of an incorrect value set as the Root Web Directory.

CORE-1362 fixed in 3.3.0-b2.

If the issue is with emails delivered via cron, then the solution is to set the correct path for Root Web Directory as I mentioned in post #3.

He said 5.4.x

We don't have any immediate plans for a quote system.

Closing as not a bug. If the issue persists create another report.

That's no odd at all. Blesta doesn't know someone has payed with PayPal until PayPal sends the IPN. It wouldn't be normal for nothing to be logged. But that's not the case for you. You are getting data logged. It just so happens that the POST data is empty, and that's not normal. You shouldn't need to change anything with your configuration. PayPal is clearly hitting your server with IPN requests. The problem is none of the post data comes in. I have no doubt PayPal would not just send empty data to you -- so it's definitely a software/server/firewall issue. What version of Blesta are you running?

Closing as not a bug.

Can you request this in discussion or features forum? This is by design. An order can only be for one currency, and if you did not allow currency conversion or if the price was defined in the currency selected for a different term then we would need to remove those items from the cart, which wouldn't be good for the user.

Closed as not a bug.

Yes. Use file_get_contents(), or if javascript or CSS: "<script src="path/to/the/file.js"></script>" Any thoughts on using array instead of string? $return = $event->getReturnVal(); $return['head'][] "<script>alert('head');</script>" $return['body_start'][] "<p>Set at top of body</p>"; $return['body_end'][] "<p>Set at bottom of body</p>"; $event->setReturnVal($return); The more I think about it, the more I like using the array method (above).

CORE-1402. Fixed for 3.3.0-b2.

Do you have any 3rd party plugins, modules, or gateways installed? cURL can be configured to use a cookiejar. By the looks of it, you have code somewhere using a cookiejar defined in the root directory.

Looks like you're blocking POST requests from PayPal's IPN, given that the POST data is empty: "a:0:{}" This could be one of two things: You have PHPIDS plugin enabled and it thinks PayPal's IPNs are attacks -- check your PHPIDS log, adjust settings as necessary, OR Your server is misconfigured and is not allowing POST data from PayPal's IPN service.

See my reply to this thread.

base_uri is defined in AppController, so it's only available to controllers that extend AppController. Plugin classes are not controllers, so they don't have this variable set. Use WEBDIR constant to give you the installation path, and Configure::get("Route.admin") or Configure::get("Route.client") to give you the rest of the URI.

See my updated post.