Paul

I saw the latest Hobbit movie the other day, Kate (Evangeline Lilly) from Lost plays Tauriel. Awesome series. And it's 2015 here now. Hope everyone has an awesome year!

I can provide a virtualmin VPS for testing, if you want.

It's 10:30am here right now, we got a long ways to go. You guys are in the future.

I don't mind taking a look at it. It's a good idea to install Blesta on a VPS though, separate from vulnerable shared hosting accounts. If you have a fresh VPS with say CentOS 6.x on it with root access I can get it working for you.

Are you having trouble with POP or IMAP also? If pipe.php is getting the email via stdin, as with any email piping, it should work. Try what I suggested with sending the output of an email in a text file to pipe.php. If that works, you've narrowed down the issue to the mail server. If worse comes to worse, and you're willing to give me access.. I'm happy to dig into it and see what I can find out. Edit, also enable error reporting in config/blesta.php. piping a text file via a shell to pipe.php, or a bounce email may then have more information about the error.

No, mailparse is required. "pecl install mailparse" will usually do it. via a shell, "php -i | grep mailparse" shows it's available? Anything in /var/log/maillog (or your mail log pertaining to this?) I've seen cases where 777 causes issues, try 755 instead. You may try piping an a copy of the email directly to pipe.php.. ie Where file.txt is a copy of the email, including headers. To get this, send yourself an email, view the source, and copy the entire source to the file.txt file. If you must, change the to address to the proper department. This will bypass the mail server entirely.

What's your path to PHP? Is there a hashbang in pipe.php that matches? Really there should be no difference between Blesta and anyone else in terms of piping. pipe.php needs to receive the email as standard input, if it does, then it should work. The only other thing is that Blesta requires mailparse, so you should verify that mailparse is available both in your CLI and through your web server.

755 should work, that's executable for all. You could try chmod +x pipe.php to be certain, but that's probably not the issue. Where does DA store the forwarder file? You've probably seen this page http://docs.blesta.com/display/user/Support+Manager#SupportManager-EmailPiping On a fresh CentOS/RHEL install, it would be in /etc/aliases. This page from the docs gives an example of what to use. Also, you may need to create the symlinks as described in /etc/smrsh to php and pipe.php.

Well said @PauloV. Cheers.

Happy New Year! 2015 should be a good one!

Since you are using Blesta Future it's hard to say as I'm stuck in 2014 at the moment. Good to know there will be a 5.4, I hope it's awesome. In all seriousness, you need to find the module row. In MySQL check the "modules" table for your module. Note the "id". Search the "modules_row" table where modules.id=modules_row.module_id to find the module_row.id for all module_rows related to that module. Then, for each module_rows.id that matches that module, search the "services" table, services.module_row_id. That should help you identify which services are using that module. If you can remove those services, then you should be able to remove the module. I hope that helps!

Domain Management is a big priority, it's also a big feature. The new domain management is large enough to basically require its own full release, and then some. Since we have quite a few high priority items, and since some of them are much quicker to implement, we are trying to knock those out of the way so we can put our full efforts into domains.

Yeah, if you have ACL perms to it, it should show up under Support > Knowledge Base

Did you run /admin/upgrade in your browser?

You can create a recurring invoice by creating a manual invoice and selecting to make it recurring. If you want a service that renews and customers can order, then you can use the Universal Module. Just create a Universal Module product under Settings > Company > Modules > Universal Module that has a name. If you require the customer enter any details during checkout for the service, create service fields for the Universal Module product.

Yeah, lol.. I was looking at the calendar on my taskbar and I forgot to +1 that.

Yeah, the ability to disable the Tax ID field is in 3.4, which is likely to be officially released tomorrow, Mon Dec 28th. As Joseph mentioned, there are custom fields as well. The other default fields will be able to be enabled/disabled/required in a future update. The biggest complaint was the Tax ID field so we tackled that first.

Ultimately a manual import, or a custom importer. If you can determine that Ubersmith is saving your card details (and not a token) then the question is, how are they being stored? Are they encrypted? If so, with what cipher? AES? What is the key? (rhetorical) We have done some importers in the past where "proprietary encryption" aka "caesar ciphers" and other lame methods were used to encrypt data. In those cases, we sometimes had the importer make curl requests to the application to fetch the unencrypted card data from a browser as an admin. That's painfully slow, and not ideal. So the question really is, what's feasible? Are you importing dozens of records, hundreds, thousands? The more records, the more it makes sense to code an importer. We can help with that, but it is likely to be fairly expensive.

Awesome!

Merry Christmas everyone, and all the best for the New Year!

If I remove the width: 108px from "#wpnav .drop ul" on line 110 of base.css, then the menu doesn't look broken. But I'm not sure which images are suppose to be on the right? I see the arrows to the left of each element, and the divider in the <span>'s between each <li>. Here's what it looks like to me. (see attachment)

Check out /app/models/users.php. I believe this is where the session is set. I'll ask Cody or Tyson to take a look at this thread.

Take a look at /components/session/session.php, I *think* that's what you want. Cody or Tyson would know better than me though.

We will consider that. There's also a new setting in 3.4 (currently in beta 2, final out soon) under Staff groups to force logout on IP change. This prevents an attacker from using a stolen cookie. It's enabled by default for new installs and new staff groups, but if you're upgrading you'll need to explicitly enable it.

You might find this useful http://stackoverflow.com/questions/24129201/add-secure-and-httponly-flags-to-every-set-cookie-response-in-apache-httpd We suggest forcing SSL/TLS with your web server, and setting the necessary flags through the web browser. Many people still use Blesta without SSL, which isn't a good idea but broken installs are no fun either.