Fixing invalid public key for packages.sury.org

If you’re running Debian and using:

deb https://packages.sury.org/php/ stretch main

(it might be in /etc/apt/sources.list.d/php.list rather than the usual sources.list)

… you may see this error:

Err:5 https://packages.sury.org/php stretch InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/php stretch InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743
W: Failed to fetch https://packages.sury.org/php/dists/stretch/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743
W: Some index files failed to download. They have been ignored, or old ones used instead.

This isn’t widely blogged yet, however the best source of info is the Issue queue for the deb.sury.org GitHub repository – it turns out that in mid-March, the key for each repository on sury.org was regenerated due to a compromised server.

Here’s the command to download the new one, after which apt will work as expected.

sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg

 

Drupal 6 – troubleshooting ‘Site off-line’ db error

A straightforward problem, but one I’ve wasted time on when setting up a D6 LTS site.

Symptom:

The site is currently not available due to technical problems. Please try again later. Thank you for your understanding.

If you are the maintainer of this site, please check your database settings in the settings.php file and ensure that your hosting provider’s database server is running. For more help, see the handbook, or contact your hosting provider.

The uncommented example line in default.settings.php is:

$db_url = ‘mysql://username:password@localhost/databasename’;

I spent some time verifying usernames/passwords and adjusting ansible scripts, what I hadn’t noticed was I need mysqli (Mysql Improved – which has been around since way with mysql v4.1.3), not mysql.

So remember to check the connection protocol as well as the credentials.

 

Drupal – troubleshooting PHP files downloading rather than executing

A fairly straightforward problem that won’t be unique to Drupal, but you may run into when migrating PHP applications from other hosts.

I was reviving an old D6 site that had been hosted on another ISP (Hostgator, as it happens) and on setting it up on Acquia DevDesktop (which is a local MAMP stack) found PHP wouldn’t execute as normal.

First, isolate the problem:

  • i.e. do other sites besides this one, running on the same computer (typically you’ll get this problem on a local dev setup) work correctly?
  • create a test PHP file (e.g. containing  <?php echo "Hello, world!";  or <?php phpinfo(); and load it

Solution in my case:

  • check the .htaccess – it had the following, which was redirecting all PHP requests to a PHP  binary that didn’t exist.  Once commented it out PHP could run correctly.
# $Id$
# Use PHP56 as default
AddHandler application/x-httpd-php56 .php
<IfModule mod_suphp.c>
 suPHP_ConfigPath /opt/php56/lib
</IfModule>

Of course any .htaccess files become irrelevant if you move your dev or production sites to Nginx, but it’s a good idea to read through it anyway.

Memcached and PHP 7.3

Just a note that the PECL memcached extension doesn’t work with PHP 7.3 yet, you need to stay on PHP 7.2.

This is the error I got when trying to running sudo perl install memcached (along with several sasl deprecation warnings):

/private/tmp/pear/install/memcached/php_memcached.c:1284:20: error: expression is not assignable

NB: Also, don’t get memcache and memcached mixed up when searching extensions.

Troubleshooting Drush with Acquia Dev Desktop

Updated Tue 8 Jan 2019

Symptom: drush updb hangs

If drush updb is hanging, first, run it with the --verbose script to see exactly what’s going on – that will show you the MySQL connections. (It turned out in my case Drush was connecting to the wrong database).

Symptom: drush connects to wrong database

Checklist:

  • Try starting the terminal connection via DevDesktop (the icon top right) and see if that makes a difference
  • Double the database connection details in the appropriate loc_ file in ~/.acquia/DevDesktop/DrupalSettings/
  • Check your drush status output
  • Check what happens if you run drush sqlc
  • Try installing the latest Drush (composer require drush/drush) rather than relying on the version that comes with DevDesktop (at time of writing that’s 8.1.7, whereas Drush is now up to 9.5.2)

My situation: I have two MySQL installations running, the 32-bit DevDesktop supplied version, and a 64-bit mariadb (for a very large site where I was experiencing connection timeouts).  They are on different ports. I had a site where ordinary drush commands and drush sqlc connection went to the correct MySQL server but drush updb used the wrong one (confirmed using the --verbose option – in fact it was connecting to a database with a different name entirely.

I couldn’t figure out what was going on, so I upgraded from Drush 8 to 9 and that fixed it immediately.

Symptom: large Drupal 7 site where cache is extremely slow or fails to clear…

drush cc all

…and eventually PHP runs out of memory (“cannot allocate”).

Check Drush is using the correct version of PHP, it may not be – use drush status or, more simply: drush php

To fix:

$ which drush
/Applications/DevDesktop/tools/drush

$ vim /Applications/DevDesktop/tools/drush

# edit the PHP version: [ -z "$PHP_ID" ] && PHP_ID=php7_1

 

PHP troubleshooting: edit the phpcs config file to fix missing or moved coding standards

If phpcs isn’t working properly and running phpcs -i (to get a list of installed coding standards) gives you an error message like this:

PHP Fatal error: Uncaught UnexpectedValueException: DirectoryIterator::__construct(/path/to/a/set/of/phpcs/coding/standards/that/no/longer/exists): failed to open dir: No such file or directory in /usr/local/Cellar/php-code-sniffer/2.8.1/CodeSniffer.php:2250

The quickest way to fix it is to search for the CodeSniffer.conf file (MacOS users, try /usr/local/etc/PHP_CodeSniffer/CodeSniffer.conf) and then edit the installed_paths key to remove or rename the problem directory.

Your output should then look something like this:

$ phpcs -i
The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz, Zend, Drupal, DrupalPractice, WordPress, WordPress-Core, WordPress-Docs, WordPress-Extra and WordPress-VIP

Troubleshooting: Where has the PhpStorm PHP 7 Compatibility Inspection gone?

If you’ve read this guide to checking PHP code for PHP 7 compatibility / used the inspection in the past, you may notice that it’s apparently disappeared – you’re supposed to be able to choose Run Inspection by Name… and choose PHP 7 Compatibility from the list.

This is because it’s been merged with the Language Level inspection.

So:

  • Preferences > Languages and Frameworks > PHP
  • set desired PHP Language Level under Development environment
  • Run inspection by name…
  • choose Language Level

Thanks to Jetbrains Support for helping me with that..

(Tested with PhpStorm 2017.1 EAP)

Troubleshooting Composer timeouts (IPv6 issue)

If composer hangs and you eventually see this error:

The "https://getcomposer.org/versions" file could not be downloaded: failed to open stream: Operation timed out

it could be a problem with IPv6 (for example if you’ve lost your IPv6 address for some reason.)

On MacOS you can turn IPv6 on and off via the command line.  This:

networksetup -listallnetworkservices

…will give you a list of network interfaces (e.g. Ethernet, Wi-Fi, any VPNs)

networksetup -getinfo Wi-Fi

…will list all it’s settings; IP address, MAC and IPv6 status.

networksetup -setv6off Wi-Fi

…will turn IPv6 off. (To turn it back on, you’ll typically want -setv6automatic, though there’s also an option to set it manually.)

In my experience turning it off fixed the problem immediately, and composer worked straight away.

Obviously it’s preferable to fix your IPv6 and turn it back on, but this may be inconvenient if you have to reboot router etc. or beyond your control if there’s a problem with your ISP.

Useful page to test your IPv6 connection: http://ipv6test.google.com/

See also this GitHub issue

Tested with MacOS El Capitan 10.11.5