cloudrck

Running the latest 3.0.2 version. No matter what I enter as the Package Options Nothing shows up on the order page, it's as if Package Options is never set. Service Options work as expected. So what is the difference and how are Package Options suppose to work? Has anyone got the same issue?

Works for me. What browser and OS are you using?

Exactly, it's supposed to be a "drop in replacement". But reading the documentation, there seems to be a gray line. https://kb.askmonty.org/en/mariadb-versus-mysql-compatibility/ I can't find anything to mention specific compatibility issues. This seems like a bug with MariaDB. If someone can point me to the lines of code, and how Blesta handles this specific functionality (transactions?), I'd file a bug report with MariaDB.

No as I'm unfamilar with how Blesta handles SQL. I'm using the latest stable version of MariaDB. Are you saying Blesta isn't retrieving the last_reply information, or is it not updating it?

The code at https://github.com/CpuID/pve2-api-php-client works. I've been meaning to port it to Blesta

MariaDB, wrong time/person on last reply, I replied 1-2mins ago Array ( [0] => stdClass Object ( [id] => 39 => 3847526 [department_id] => 1 [staff_id] => 1 [service_id] => [client_id] => 5 [email] => [summary] => IP order /29 [priority] => low [status] => open [date_added] => 2013-07-23 18:20:01 [date_closed] => [last_reply_date] => 2013-07-23 18:20:01 [department_name] => Sales [company_id] => 1 [last_reply_by] => client [last_reply_first_name] => Bob [last_reply_last_name] => Harmen [last_reply_email] => [last_reply_time] => 4 d 6 hr 4 min } MySQL correct ( [0] => stdClass Object ( [id] => 1 => 2602798 [department_id] => 1 [staff_id] => 1 [service_id] => [client_id] => 1 [email] => [summary] => ryrry [priority] => emergency [status] => open [date_added] => 2013-07-25 02:32:01 [date_closed] => [last_reply_date] => 2013-07-28 00:30:51 [department_name] => tes [company_id] => 1 [last_reply_by] => staff [last_reply_first_name] => Daejuan [last_reply_last_name] => Jacobs [last_reply_email] => [last_reply_time] => 0 min ) )

Yes, everything is identical except the 'last reply', the last reply when using MariaDB always displays the user/time of who/when it was created. No matter how many updates. While using MySQL it works as expected, displaying the actual last time/user

I can confirm this bug is NOT present in MySQL 5.5 Interesting, I assume there is a transaction MariaDB doesn't like

How are updates to the last reply handled? No MySQL, but I can set one up

I'm having the same issue on a fresh b6 install. So maybe MariaDB issue? Last Reply is never updated.

That makes more sense

I'd rather not have to do a fresh install and re-create client accounts/services. Hopefully re-installing the plugin will work. If not I'd rather look around the database before I consider a complete re-install. I'll post my findings soon.

I've been live since b2. Blesta has come a very long way since than. Aside from a few issues that had to be fixed manually it's been fairly stable compared to what's on the market. I never considered WHMCS due to the security issues they've had, leaves a bad taste in my mouth knowing they have such poor coding standards.

$99 for presales is the worse

I'm assuming this will delete all tickets?

Yes, I reported this before but was told no one could duplicate it, so I waited until b6 hoping it would go away. I have updated the support plugin and all other modules/plugins.

I've had this problem since 3.0.0b2. No matter how a ticket is created, or how many times it is updated, the 'Last Reply' shown on the main ticket always shows the initial ticket creator as the last reply. Example, this ticket was updated today around time of this post by staff, though it shows it was last replied to by the customer at the time it was opened. Debian Wheezy PHP5.4 Nginx 1.4.1 MariaDB 5.5

I don't see it being v Wouldn't this be better handled at the mail server level? Since it's the mail servers job anyway.

I do get spam from similar services. No way to combat it besides adding it to blacklist on the mail server.

I don't have this issue on Nginx. Again, it would helped if someone posted their logs.

Check your webserver and/or PHP logs.

Odd, I never had the same issue OP had, but the issue at http://staging.blesta.com/forums/index.php?/topic/384-email-client-url-error/ is fixed by this finding.

I'm curious as to who these were.

Because as of now it looks like a config issue rather than a problem with Blesta, I have deployed Blesta on several Nginx servers without issue. What does your fastcgi_params file look like? Assuming your fpm/php.ini is set correctly there should be no issues.

I'm the one who put the config on githhub as I use Nginx only. I've not run into this issue, nor can I recreate it. What is your OS, PHP version, are you running PHP-FPM? What does your config look like for that domain? Do you use the stock Nginx configuration in addition to the domain config, or do you have other additional settings? Do you have cgi.pathinfo set in both the domain config and php.ini?