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:
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)
Be aware that for Drupal, when testing patches from the core issues queue, you can only use the
git apply command on the main repository:
https://git.drupal.org/project/drupal.git (browse code)
(i.e. choose 8.2.x or 8.3.x according to issue )
and not on drupal-composer/drupal-project (e.g. a DrupalVM install)
This is logical, the commit IDs in the .patch file simply can’t be found in that repo, so git skips them. Instead you should use:
patch -p1 < example.patch
…as described here. (You still use
-R to reverse it.)
What’s less helpful is
git apply will give you no warning there’s a problem – you’ll run the command, see
[ok] but no other output, as though it had worked.
Likewise using any of these switches won’t print anything to the screen:
Annoying, the instructions for
--check imply it might tell you:
Instead of applying the patch, see if the patch is applicable to the current working tree and/or the index file and detects errors. Turns off “apply”.
- create a new branch for the patch you’re testing
git diff to check the files have actually been altered
drush cr too to reset cache/UI etc. before testing
In case you’ve recently installed a new site and wondered why the Drupal Console
site:mode command – which lets you switch between development and production settings for caching etc – isn’t working…
Command "site:mode", is not a valid command name.
…it’s been temporarily removed from v1.0.0-rc12 due to problems.
Useful advice which very few sites seems to be following.
(Reminder: there’s a Disable option in each Operations menu on admin/structure/views and that page is grouped into Enabled and Disabled sections.)