Back to The Past
Using Acquia DevDesktop + Visual Studio Code on Windows 10
2010 called, and it wants it’s GUI apps back
It’s that time of the year (or decade) where I’m again shopping for a new job, stepping outside of the enterprise bubble that I’ve lived for the last 3+ years. Of the the dozens of interviews I have conducted so far I yet have to find an organization that is using Docker, in the year 2020.
All of the Drupal shops I’ve talked to so far are still using Acquia Dev Desktop, an 8 year old or so technology. And why blame them? It’s the lowest entry barrier to Drupal.
So I’d thought I’d take Acquia Dev Desktop for a spin and configure it for Visual Studio Code.
Requirements:
- You can download and install Acquia Dev Desktop from here: https://dev.acquia.com/downloads
- You can download Visual Studio Code from here: https://code.visualstudio.com/
- Visual Studio Code PHP IntelliSense extension.
Finding php.exe
The first part to configuring Visual Studio Code is telling PHP IntelliSense where
In order for Visual Studio Code to validate your code and provide suggestions, it needs an existing PHP binary location.
To find the location of the PHP binary provided by Acquia Dev Desktop, open the Dev Desktop, and on the upper menu click on Preferences -> Config.
On the Preferences -> Config tab, go down to the Stack Configuration Files section, and click Edit:
Once an editor opens up with the corresponding php.ini file, you can trigger to the prompt to save the file, in this case File -> Save As …
On the Windows prompt to save the file, you can see the location to the php.ini file. On this location is where the php executable php.exe for that particular PHP version is also located.
You can copy the path to the php.ini directory from the address bar in the Save As prompt, as shown below:
If you copy this path, in my example C:\Program Files (x86)\DevDesktop\php7_0_x64 , then add \php.exe at the end, that’s your PHP executable under Acquia Dev Desktop.
Update Visual Studio Code Settings
Studio Code supports two settings files: workspace and user. User settings are global and apply to all your projects, whereas workspace settings are restricted to the local scope of your current project (workspace).
If you only have one installation of PHP in your machine (Acquia Dev Desktop ), then using user settings to point Studio Code to the php.exe binary is fine.
But if you’re like me, and have multiple PHP binaries distributed between different platforms, then workspace settings (non-global) will make more sense. That way you can target each Studio Code project to different PHP distributions.
By installing Acquia Dev Desktop, in my machine now can find PHP binaries in: 1) Dev Desktop; 2) Windows Subsystem for Linux, and 3) Docker containers.
Read more about user and workspace settings here in the Studio Code documentation.
If you wish to open the workspace settings, press Ctrl+Shift+P to open the VSC Command Palette, type workspace settings, then select Preferences: Open Workspace Settings (JSON):
In Visual Studio Code settings.json you have to escape backward slashes, so you have to use double slashes. In my case, this is what the VSC settings for the PHP executable would look like:
// settings.json"php.executablePath": "C:\\Program Files (x86)\\DevDesktop\\php7_0_x64\\php.exe","php.validate.executablePath": "C:\\Program Files (x86)\\DevDesktop\\php7_0_x64\\php.exe",
However, after plugging those settings into VSC and restarting, I get the following notice:
Fair enough, Acquia Dev Desktop comes with support for various PHP 7.x versions out of the box:
So let’s bump it to the lowest common denominator for both Drupal and VSC support, version 7.1.3.
Under the Dev Desktop Settings -> Config -> Default PHP version (dropdown), I select 7.1.x.
Then update my VSC settings to point to that PHP executable:
\\ settings.json"php.executablePath": "C:\\Program Files (x86)\\DevDesktop\\php7_1_x64\\php.exe","php.validate.executablePath": "C:\\Program Files (x86)\\DevDesktop\\php7_1_x64\\php.exe",
After restarting Visual Studio Code, I open the Output console, then select PHP Language Server from the list of output consoles:=
As you can see the language server in VSC starts indexing Drupal files immediately.
And that’s it! That’s all the basic configuration you need to have Visual Studio Code working with Acquia Dev Desktop.
For more advanced customization, there is an exhaustive and updated list of Studio Code extensions you can use over at this Drupal.org community post.
For those of you interested on how to use Drupal with Docker, you can check this A-Z list of Docker environments that come with Drupal support in mind. That list includes options such as lando, ddev, and docksal.
Trusted Site Settings
Upon installing your brand new site with Acquia Dev Desktop, if you head over to admin/report/status you will see the following welcome message:
When I installed my site with Dev Desktop, I pretty much used as much defaults as I could on any of the prompts the install process presented to keep things simple.
That approached left me with a site called drupal-8–8–1.dd. By following the advice on Trusted host setting for Acquia Dev Desktop 2 (tested with Drupal 8.6.2 and PHP 7.2.8), I inserted the following code:
$settings['trusted_host_patterns'] = array(
'^drupal-8-8-1\.dd$',
);Into my drupal-8.8.1\sites\drupal-8–8–1.dd\settings.php and behold, error gone 🥳.
Your Site Is Out Of Date
The second warm welcome message you might receive from your Dev Desktop installed site is that the fresh, brand new site you just installed is out of date!
But how, if I just installed it?!? 🤦🏻♂️
The Good News is that Dev Desktop comes with Drush support of of the box, so you can run a drush command to update Drupal core.
The Bad News is that it might not work.
The Ugly News is that the command shell Dev Desktop provides runs with administrator privileges 👀. So if your enterprise restricts privilege escalation in Windows (which in my experience most large companies do), you might or might not even be able to run drush. To add insult to injury, most users of Dev Desktop might not be adept at the command prompt, so if you run or copy/paste the wrong thing from Stack Overflow into that shell, you might brick your machine ☠️.
Here is how you fire the integrated drush console using Dev Desktop:
Next, the Update core using Drush documentation states that running drush pm-update drupal, will update the site for you:
As you can see in the screenshot above, the console opened by Dev Desktop is running with admin privileges. In addition, the bottom right characters are meant to represent color escape codes for a unix-style shell. But since this is a raw cmd.exe shell, and not Windows Terminal or anything unix-compatible, the color escape codes are represented as junk code.
But no big deal, assuming you can get Admin privileges and get over the horrible DX presented by non-compatible color escape codes. Except that it doesn’t work:
Yikes!
According to alexpott and greg.1.anderson, running either another drush command or drush cr, which stands for drush clear registry will solve the issue.
Subsequently running drush cr followed by drush st (drush status) show no warnings or errors.
Visiting the update page at admin/reports/updates gives the green checkmark of approval indicating that the new site is now up to date:
And visiting the status report page at admin/reports/status presents us with a clean bill of health:
Hooray 😸 😸 😸 !
Help: I get a WSOD when visiting my homepage
.
WSOD = White Screen of Death 💀💀💀.
You just installed your brand new site with Acquia Dev Desktop, and when you visit the homepage you get a blank screen, or a blank screen with some cryptic error. I wrote a story just to solve that scenario Acquia Dev Desktop: Drupal install causes WSOD, because obviously it happened to me!
Extra: How Windows finds your site.
If you’re wondering how when you open your browser, your computer is able to find the sites being hosted by Acquia Dev Desktop, there’s an entry on your etc\hosts Windows equivalent corresponding to each site you “create” in Dev Desktop.
In my Windows version 10, the hosts file can be found over at C:\Windows\System32\drivers\etc\hosts.
fileThis is amongst one of the reasons why Dev Desktop asks you for administrator permissions when starting up — so that it can edit the privileged etc\hosts file and add that corresponding 127.0.0.1 your-drupal-site.dd entry.
WARNING: I recommend you don’t edit the hosts file unless you know what you’re doing!
