If you’re working on Drupal core or a development site and get this error when running Drush commands, e.g.
drush cr or
PHP Fatal error: Declaration of Drush\Command\DrushInputAdapter::hasParameterOption() must be compatible with Symfony\Component\Console\Input\InputInterface::hasParameterOption($values, $onlyParams = false) in /Applications/DevDesktop/tools/vendor/drush/drush/lib/Drush/Command/DrushInputAdapter.php on line 27
It’s because in the next Drupal minor release (8.4.x) Symfony components have been updated to ~3.2 (in 8.3.x they remain at 2.8.x)
This causes a conflict with Drush – you should upgrade to Drush 9, which you can do via:
composer require drush/drush:9.*
One of several GitHub issues on drush-ops/drush
I’ve added a books page with some recent web development books I’ve read.
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
Scenario: you’ve upgraded Drupal core to the latest version (via composer) but Drupal thinks an earlier/previous version is the most recent, despite running drush updb, clearing the cache, running cron etc.
e.g. you’ve upgraded Drupal core to 8.3.1, but still see a “version 8.3.0 available” warning on /admin/reports/status
Simple fix: go to /admin/reports/updates and click “Check Manually” and you’ll see a progress bar and it will pull in the latest list of packages and the warning will go away.
The original problem:
- SPDY has been replaced by HTTP2, which is better in a number of ways
- As of June 2016, Chrome has dropped support for SPDY
- HTTP2 uses ALPN
- ALPN requires OpenSSL 1.0.2
- Debian Stable (aka Jessie aka v8) and others OSes only had 1.0.1
- Add jessie-backports and jessie-nginx-http2 (ansible playbook)
- Upgrade openssl them from the correct place:
sudo apt-get install -t jessie-backports openssl
- sudo apt-get install nginx-full (which should pull in various libnginx-mod packages)
- Change any references in your Nginx config files from spdy to http2
sudo nginx -t to verify the configuration is valid
- Start server
Verify HTTP2 is working (Chrome or Opera):
Developer Tools, Network tab, reload page, enable the Protocol column, look for H2, which means HTTP2.
Extra step for LetsEncrypt / Certbot compatibility:
A few days after doing this I got the following error when my weekly cronjob for renewing LetsEncrypt certificates ran:
build/temp.linux-x86_64-2.7/_openssl.c:415:30: fatal error: openssl/opensslv.h: No such file or directory
And on running it manually I had this:
The following packages have unmet dependencies:
libssl-dev : Depends: libssl1.0.0 (= 1.0.1t-1+deb8u6) but 1.0.2k-1~bpo8+1 is to be installed
Recommends: libssl-doc but it is not going to be installed
The solution was just to pull in libssl-dev from jessie-backports too:
apt-get install -t jessie-backports libssl-dev
Note, in my case, I have a git clone of certbot rather than a packaged version, though it is now available as a backport for Debian Jessie.
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)
This is a list of useful Drupal modules I’ve used (or plan to), with notes.
I’ll keep it updated:
Update: Nov 2018 – I’ve given this an overhaul recently and there are currently 91 modules listed.
I’d recommend any WordPress users install the disable-JSON-API plugin. This will prevent anonymous access to WP REST API endpoints, such as /wp-json/wp/v2/users – which provides a list of usernames (API docs).
The REST API was introduced in WordPress 4.7 and is (unfortunately) on by default with no option in settings to turn it off – the idea is it will in time be used for AJAX in some of the admin system, not just external requests. There is a good change if you were running 4.7.0 or 4.7.1 and did not immediately upgrade to the 4.7.2 security release posts may have been defaced.
Also be aware that the WordPress readme.html file no longer displays complete version numbers – e.g. it will show 4.7 rather than 4.7.2. (a step backward, IMHO). Though you might not be aware however you can get the version number by clicking on the WordPress icon at the left of the admin bar (and of course, WP-CLI users can do:
wp core version)
This extension lets you add define URLs using a regular expression, and have Chrome (or Opera) colourise the favicon in a colour of your choice.
Ideal for reducing the chance you’ll get your dev, staging and production servers mixed up.
Say you’re editing a CSV file in a table (Edit as table)
- Use shift to shade in a collection of cells
- Enter a value
- It’ll be inserted into all cells (i.e. you don’t have to edit them one-by-one)