Jump to content

Search the Community

Showing results for tags 'mysql'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • News
    • The Lounge
  • Community
    • Pre-Sales Questions
    • Support
    • The Marketplace
    • Contribute
    • Show Off
    • Feature Requests
    • Bugs
    • Contests
  • Developer Corner
    • General
    • Extensions
  • BlestaStore's Forum
  • BlestaStore's BlestaCMS
  • BlestaStore's Resellers
  • BlestaStore's BlestaForums
  • BlestaStore's Promotions
  • CubeData's Official Announcements From CubeData
  • CubeData's Peer Support
  • CubeData's Resellers
  • ModulesGarden Club's Topics
  • Blesta Addons's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Wire


Location


Interests

Found 3 results

  1. Hello everyone. Recently I've got the above browser error message in the middle of upgrading process (~/admin/upgrade/process/) from version 4.2.2 The same message also appears if I'm trying to upgrade any core plugins in the admin dashboard. I'm using Apache 2.4.34 + PHP 5.6.36 + Mysql 5.7.22-cll-lve Can I have any solutions to fix this problem? Thanks.
  2. Hi folks, Couldn't find this reported, however it seems there's a bit of an issue when attempting to install 4.0.0 using PHP 7. It appears there's a syntax error when taking into account MySQL Ports I've configured my development environment to use MySQL on port 13306 and entered the host as 127.0.0.1:13306 Installation works perfectly on PHP 5.6.23 (via FPM & CLI), however via PHP 7.0.18 it throws the following error: SQLSTATE[HY000] [2002] Failed to parse address "127.0.0.1:13306:3306" Changing config.php to the host as 127.0.0.1 and port 13306 does not remedy this issue, as such it appears that I'm unable to use PHP 7.0 with MySQL from a fresh install. Oddly enough an upgrade, admittedly on a slightly older php7 version, worked without issue. Note: it was installed using 127.0.0.1:13306 in the host string, as there was no separate port, despite the configuration having a port option. The exception is occurring on line 74 of core/ServiceProviders/MinphpBridge.php (the new PDO connection setup). var_dump($dbInfo); shows the following data: array(10) { ["driver"]=> string(5) "mysql" ["host"]=> string(9) "127.0.0.1" ["port"]=> string(5) "13306" ["database"]=> string(6) "blesta" ["user"]=> string(6) "blesta" ["pass"]=> string(6) "blesta" ["persistent"]=> bool(false) ["charset_query"]=> string(16) "SET NAMES 'utf8'" ["sqlmode_query"]=> string(26) "SET sql_mode='TRADITIONAL'" ["options"]=> array(0) { } } I've confirmed via debug that the data being input to new PDO is: string(40) "mysql:dbname=blesta;host=127.0.0.1:13306" Changing lines 64 to 74 from: $connection = new PDO( $dbInfo['driver'] . ':dbname=' . $dbInfo['database'] . ';host=' . $dbInfo['host'] . ( isset($dbInfo['port']) ? ':' . $dbInfo['port'] : '' ), $dbInfo['user'], $dbInfo['pass'], $options ); to $connection = new PDO( $dbInfo['driver'] . ':dbname=' . $dbInfo['database'] . ';host=' . $dbInfo['host'] . ( isset($dbInfo['port']) ? ';port=' . $dbInfo['port'] : '' ), $dbInfo['user'], $dbInfo['pass'], $options ); Resolves the issue, and the site is now operational. This fix obviously relies on the port being explicitly set, so having a field to fill in that port is still required. Edit: looks like it worked doing the upgrade because my other upgrade was on my other laptop, that runs mysql on 3306...
  3. When you have a blesta setup with relatively high client volume, you may want to periodically check if everything is OK, or clean up things that should not be there (i.e: data that is not automatically removed by blesta/plugins). I've come up to this queries which I use periodically: - Show users that have at least 1 active service and more than 3 unpaid invoices: This may happen when a provision plugin is not suspending a service, or just human mistake (useful to find customers that are not paying because of not having their services suspended) SELECT many_invoices_customers.id 'customer_id', services.id_value 'service_id' from (SELECT i.client_id 'id', count(*) 'c' FROM invoices i, clients c WHERE c.id = i.client_id AND i.status != 'void' and i.paid != i.total GROUP BY i.client_id HAVING c > 3) many_invoices_customers, services WHERE services.client_id = many_invoices_customers.id AND services.status = 'active'; - Show users that have more than 3 unpaid invoices and at least 1 suspended service: let's you clean up users that don't pay anymore (and manually cancel them) SELECT many_invoices_customers.id 'customer_id', services.id_value 'service_id', many_invoices_customers.c 'invoices_number' from (SELECT i.client_id 'id', count(*) 'c' FROM invoices i, clients c WHERE c.id = i.client_id AND i.status != 'void' and i.paid != i.total GROUP BY i.client_id HAVING c > 3) many_invoices_customers, services WHERE services.client_id = many_invoices_customers.id AND services.status = 'suspended' ORDER BY many_invoices_customers.c DESC; I haven't implemented auto service cancel yet, but maybe is useful to someone here *Those queries are meant to be executed directly into your blesta MySQL DB.
×
×
  • Create New...