Jump to content

DigitalSparky

Members
  • Posts

    7
  • Joined

  • Last visited

1 Follower

About DigitalSparky

  • Birthday October 10

Contact Methods

  • Website URL
    https://digitalsparky.com/
  • Skype
    matthewspurrier

Profile Information

  • Gender
    Male
  • Location
    Perth, Western Australia
  • Interests
    PHP, Web Hosting, Domain Names, Security, High Availability, Performance

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

DigitalSparky's Achievements

Newbie

Newbie (1/14)

5

Reputation

  1. I'd probably go back to the hosting provider and request the allow it, even if it's just for one profile. It's certainly more performant than having a composer package or something like that handle it (C compiled library vs PHP interpreted). Enabling for individual profiles these days is very simple, as there are user level php.ini's which you can enable/disable modules, and it's exactly what other module enable/disable controls use, so the only thing they really need to do is install it...
  2. Just to quickly add to this one, > /dev/null 2>&1 pipes everything to the abyss, which means you'll even lose errors. you may wish to remove the 2>&1 so you still get emails if there is an error, it may be helpful in the event errors occur, instead of silently failing :). FYI: >/dev/null = Pipe standard out to /dev/null 2>&1 = Pipe standard error to standard out, which in turn pipes to /dev/null so removing 2>&1 means stderr (standard error) will still come through, so you'll get emails in the event of errors, otherwise not. there are other ways to monitor your systems to ensure errors are picked up quickly, but they vary widely in complexity depending on requirements, so this is a rather simple approach, but can still be effective. YMMV, but monitoring, logging, trend analysis, etc will help considerably with bug and outage detection, allowing you to maintain higher uptime and business continuity.
  3. 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...
  4. btw, php5.5 and lower are EOL, and 5.6 is security supported only, so I'd personally suggest encouraging people more towards php7+ than anything else for security and continuity of service. That said, it's great that you do support php7, quite a few applications have been very behind on that.
  5. yay thx Paul :). yeah I do read docs... then again I am a dev/systems engineer...
  6. Yup, I just applied that and all is working - the hotfix, unfortunately, is not listed in the README.md... the PHP 5.5 one is though... haha...
  7. Hi folks, I just tried installing Blesta 4.0 with PHP 7.0.17 using the Ioncube loader for PHP 7 and got the following error: Fatal error: The file .../app/models/license.php was encoded by the ionCube Encoder for PHP 5.4 and cannot run under PHP 7.0. Please ask the provider of the script to provide a version encoded with the ionCube Encoder for PHP 5.6. in Unknown on line 0 So even though there is PHP 7 support for Blesta 4, looks like it needs to be re-encoded with the latest version for it to work.
×
×
  • Create New...