Timothy

The server does allow the use of exec. In fact it has no disabled functions. The user Blesta is running under does have /usr/local/bin in path and can execute mysqldump binary. Changing the backup.php to hard code the path to mysqldump gets me a step further. Now I get 373 byte backup. Basically the first 10 lines of sql and then it cuts off.

mysqldump: /usr/local/bin/mysqldump The temp folder is setup correctly and writable according to settings/system/general/basic/.

It is installed and works when I use it manually.

Hi guys, I seem to be having a issue with database backups. Attempting to do a manual backup leads to a 26 byte gzip archive to download. The sql file is empty. This is happening on version 3.0.6. Anybody have any idea why this might be happening?

Upgraded here. Everything seems to be working as expected. Thanks

CubicWebs is right. You need to add the group for your products to show up.

Hi, Do you have packages assigned to the group you associated the order form to?

Glad I could help

That looks like a issue with PHP. The imagecreatefrompng function is part of GD library. This tends to be a separate package/port from the base PHP install. Can you verify you have that installed? It would be called php55-gd or php5-gd or some variation of that depending on your operating system.

Make sure you have a currency selected on the order form. This will be near the bottom of the form right above the gateway settings. If you do not have a currency selected the order forms will not show any packages.

You don't need a admin folder to restrict by path. For Apache servers you can use the location example as stated above to do it. More information can be found at https://httpd.apache.org/docs/current/mod/core.html#location For security you should probably rename your /admin area to something else. Change the following line in the route.php file. Configure::set("Route.admin", "admin"); to something like Configure::set("Route.admin", "ziggyzoo"); to change the path to /ziggyzoo. Hope that helps.

You could try using a location match. Apache 2 or 2.2.<Location /admin>Order Deny,Allow Deny from all Allow from 1.1.1.1</Location> Apache 2.4 <Location /admin> Require ip 1.1.1.1 </Location>

+1 as well.

This also happens when the qty field is on the primary product. Each add on product will have the same quantity set as the primary. The example above only tested between add on products.

This bug appears to exist on 3.0.4 as well. Any ideas?

I have tested this on a clean install of 3.0.4 as well. The same bug exists there. Should I test earlier versions or can anybody else replicate this?

I have done a clean install of 3.0.4 and added twenty one products to a test user. The paging issue with services on the client portal is still present. Should I try testing earlier versions or can anybody else replicate this on 3.0.4 and 3.0.5?

When adding a service to a customer that has multiple addons and at least one of the addons has a qty field the value is passed down to all services that follow it. How to duplicate: Create 3 Products with the universal module. A primary product and two addon products. 1: The primary product should have no fields 2: The first addon product should have a required service field with qty in the label area. 3: The second addon product should have no qty field. 3: Create the associated packages and link the two addon products to the primary. Adding services to client 1: On a client profile click to add a service. 2: Add the primary service 3: Select both addon services. 4: On the first addon service set a quantity. 5: Add the second addon and proceed to the review screen. The bug: The second addon has the same quantity as the first addon. The qty field from the first addon product applies to each addon service that comes after it. This happens even if the additional addons do not have 'qty' fields of their own. If the additional services have their own 'qty' fields then the issue does not come up. Expected behavior. The 'qty' field from one service should not affect any additional services. Server setup is Freebsd 9.2 with Nginx 1.4.2 using PHP 5.4.21 through php-fpm and Mariadb 5.3. I am using Blesta v3.0.5

The value of 'Allow Clients to Cancel Services' does not respect the client group settings. It always uses the default settings. The Bug: Clients assigned to a client group are still using the global company settings for 'Allow Clients to Cancel Services' instead of the client group settings. Other client group settings appear to be working correctly with limited testing. Server setup is Freebsd 9.2 with Nginx 1.4.2 using PHP 5.4.21 through php-fpm and Mariadb 5.3. I am using Blesta v3.0.5

If a client has more then 20 services, the services are displayed with a pager. Using the pager does not cause the page to refresh. This only applies to the client portal. The admin side works fine. Bug: Click on any page number. The page does not refresh and show the new content. In addition the first/prev buttons never change to be clickable no matter which page number you try and go to. Additional information: The url does change. For example clicking on page two causes the url to change to client/services/active/2/?sort=date_added&order=desc. However the page does not change the content. In addition the header sorting does work. This has been tested using Firefox 24, Opera 12.6, and Chrome 28. Server setup is Freebsd 9.2 with Nginx 1.4.2 running PHP 5.4.21 through php-fpm and talking to Mariadb 5.3. I am using Blesta v3.0.5 Can anybody replicate this?

+1 on both. Thank you for making this.

Another +1 for this. We also use monitoring (nagios) email alerts sent to our ticket system.

Thank you for the update. I can live with having to double check the open tickets considering how much time Blesta saves me on the billing side. Still, it would be nice to have a resolution eventually. Is this already a feature request or bug somewhere?

I guess I'll chime in too. I am having the same issue with v3.0.5 using IMAP instead of piping. Responses sent from the client portal will change the status. Responses sent via email does not.

I have done more testing on this one and I think I have found a pattern that may help. The bug only triggers on every other product. Oddly enough only the even number ones. The following examples assume you are adding each of the addons to the cart and then removing the primary product at step four. For example if you have two addons, then addon two is left when removing the primary product. If you have three addons, then only addon two is left. If you have four addons, then addon two and four are left. If you have six addons, then addon two, four and six are left. You get the idea I have also updated PHP to 5.4.21 from my above post and duplicated the testing on Mysql 5.5. The bug is same either way. Any ideas?