devdesktop – William Turrell

macOS Catalina 10.15 – things to be aware/wary of

32-bit apps will no longer be supported at all (~~currently that still includes Acquia DevDesktop – for running Drupal development sites~~)
the default shell is going to change from Bash to Zsh
scripting languages won’t be installed by default (Apple gave Python, Ruby and Perl as examples in a support document, but didn’t specifically mention PHP). It’ll mean Homebrew will need to be installed differently. Presumably it won’t be an issue if you’re upgrading a previous macOS version, but, also presumably, it will be if you’re using a new computer, even with Migration Assistant.
iTunes has been removed and the Apple Music replacement apparently doesn’t support column view of your music library.
John Gruber writes that Catalina is a pain to use due to (a) bugs but also (b) excessive permission alert dialogs.

(As usual, my own policy is not to upgrade to a new macOS release until 9-12 months after it’s come out, to allow everything to settle. I write this – post updated Feb 2020 – on a machine that’s still running High Sierra, which should still get support until late 2020 – although again, Apple have never announced support lifecycle dates.)

Acquia Dev Desktop 32-bit MySQL

Update: Jan 2020 – newer versions of Dev Desktop, such as the following, are fully 64-bit on macOS:

Version: 2
Built: Sep 18 2019 03:15:11
Control panel rev: a0d1c92
Stack rev: bb3d2d8

It’s worth noting the version of MySQL that comes installed with Acquia Dev Desktop 2 (5.6.41-84.1) ~~is still 32-bit~~ (unlike PHP which is now 64-bit). Recently I was testing with a particularly large database and found it kept crashing with things like:

‘MySQL server has gone away’

Lost connection to MySQL server at ‘reading authorization packet’

Intensive operations such as Drupal-to-Drupal migration tended to trigger this.

I used MySQLTuner but the changes made little difference so then it occurred to me the 32-bit version simply wasn’t up to it, so I installed the latest 64-bit mariadb from homebrew instead and moved the relevant databases over to that (I have mariadb running on port 3306 and Dev Desktop’s MySQL on it’s default 33067).

So far it’s been stable.

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