If all your PHP errors and warnings suddenly disappear from your IDE editor window, despite you having the language level configured correctly etc., double check you haven’t turned on Reader Mode by accident, as by default it hides “error and warning highlighting and the inspection widget”.
Therefore you’ll see the message “No errors found in this file” when pressing F2, even though there are some.
Also by default, it turns on font ligatures (the fancier versions of =>, != etc.) so if you’re seeing those and wondering why, even though you have the boxes unticked in Preferences Editor > Font, or Editor > Color Scheme > Color Scheme Font / Console Font – again, check it’s not activated.
All this is configurable in Preferences > Editor > Reader Mode.
Note that Reader Mode is toggled on and off for individual files.
Jetbrains official docs
This is a one line fix if you have missing string/array output from a custom WP-CLI command when using the WP Engine “SSH Gateway”.
- WP Engine is a WordPress hosting company*.
- They have an SSH Gateway – where you login to a separate machine and it will pass a limited range of useful commands to your actual server (basic file management, a MySQL console client, WP-CLI)
- WP-CLI is a timesaving WordPress command line utility.
The problem is the unorthodox way the gateway works suppresses ordinary output from certain commands – e.g.
echo. Symptom: you run a WP-CLI command of your own through the SSH gateway and lines of text you’re expecting are missing.
First, you should switch from
WP_CLI::line() (deprecated now anyway) to
WP_CLI::log() – the line() method doesn’t work because, if you dig into the source code, you’ll see it just echos the output, however log() uses the proper wp-cli Logger class.
That’s fine if you want to output strings. Unfortunately, it doesn’t work if you need to print an array.
This does though:
fwrite( STDOUT, print_r($foo, TRUE) );
To unpack that, we’re using print_r to neatly print the array. The second argument for print_r returns its value as a string. You need not fopen STDOUT first, as you would for another file handle.
And that’s it.
* Would I recommend WP Engine? No, given I have hosting knowledge myself, and when I asked for their assistance with this particular problem, their support agent told me it was out of scope and I should look at StackOverflow, for which they have earned this mildly passive aggressive paragraph in a blog post that will sink without trace. However, many people do like them, and if you’re a WordPress developer, you may well inherit a client with a site hosted there one day.
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
A straightforward problem, but one I’ve wasted time on when setting up a D6 LTS site.
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.
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.
# Use PHP56 as default
AddHandler application/x-httpd-php56 .php
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.
Here’s a gulpfile.js, tested with gulp.js 4.0.0 and BrowserSync 2.26.3
It also uses the Tailwind CSS framework.
View example gulpfile.js on GitHub
Here’s a good beginner’s guide to Gulp (although the syntax for task execution has changed in 4.0.0, you need to use gulp.series or gulp.parallel)
Update – Sep 2019: PECL memcached extension v3.1.0 and above support 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.
Updated Tue 8 Jan 2019
Symptom: drush updb hangs
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
- 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
- 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:
$ which drush
$ vim /Applications/DevDesktop/tools/drush
# edit the PHP version: [ -z "$PHP_ID" ] && PHP_ID=php7_1
See also: Acquia Dev Desktop known issues page
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
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.
- 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)